The Sensorpedia team is happy to announce a draft release of the Sensorpedia API documentation. We welcome your feedback, suggestions, and other input. Requested Actions for BETA Testers The following actions are requested of Sensorpedia BETA testers to help improve the Sensorpedia API:
Note: The URLs listed in this document do not point to the current live BETA services. Once ready for testing, the live URLs will be migrated to match those listed here. Items indicated by † may not be fully implemented or tested in the BETA services. Sensorpedia Application Programming Interface (API) DRAFT Documentation
Sensorpedia Extensions to Atom Specification. 3 Special Handling for Atom Elements. 13 Example Registration Atom Document. 14 Example Search Result Atom Document. 22 Use of Atom SpecificationThe Sensorpedia Application Programming Interface (API) provides an easy mechanism for interfacing autonomous and incompatible sensor data to existing and future enterprise applications. To utilize the Sensorpedia framework, sensors and sensor systems are registered with Sensorpedia using Sensorpedia’s Atom-based API. Registered sensors may communicate and publish data with either standards-based or proprietary protocols. Applications such as the Sensorpedia web application and other third party software discover and subscribe to sensor data using the Sensorpedia API. Some data providers may choose to use the Sensorpedia API directly to post sensor data updates. Others may use the framework to provide links to existing systems or services to subscribe directly to the sensor system. Figure 1 shows the use of the Sensorpedia API. Figure 1. Sensorpedia Framework The Sensorpedia API is based on the Atom Syndication Format, an XML language used for web feeds. The Atom 1.0 specification[1] was released in December 2005 by the Internet Engineering Task Force (IETF). Web syndication standards such as Atom and RSS (Really Simple Syndication) were originally developed to provide an automated method to check for updates published on a web site without requiring a user to visit a site in a browser. Instead, Atom publishes a list (or “feed”) of recent articles or content in a standardized, machine-readable format. Many feed readers and aggregators have been developed to manage feed subscriptions. The Atom content model is flexible and extensible, and the specification was written to support a wide variety of content beyond web site update notifications. The Atom model also allows for links to additional resources for visualization, alternate format representations, and any number of other requirements. The Sensorpedia API uses the Atom content model to represent registered sensor systems and to provide subscription links to observation data. Since the Atom specification supports extensions, the Sensorpedia API specifies the GeoRSS format to represent spatial information associated with each sensor entry. A simple RESTful web service interface is used to provide insert, update, delete, and query operations on the stored Atom documents. In addition, the AtomPub protocol[2] may also be used to access stored Atom documents.† The Atom-based API does not constrain data publishers to a given data format for representing observation data. Rather, the API provides the ability to link to any number of representations of the data, such as Atom, GeoRSS, SensorML, Web Feature Service (WFS), Sensor Observation Service (SOS), HTML, or other proprietary formats. The Atom format also allows the embedding of observation data within the feed document itself, making the Atom feed self contained. Sensorpedia Extensions to Atom SpecificationThe Sensorpedia API fully conforms to the Atom Syndication Format specification. All element definitions and formats apply. It is assumed that readers of this document and users of the Sensorpedia API have familiarized themselves with the Atom formats and requirements described at the above link. Where appropriate, excerpts from RFC 4287[3] are included here to provide context and definitions. In addition to the base specification, the Sensorpedia API adds some semantic conventions for how standard elements should be utilized. The API also adds a limited number of additional Atom extensions for describing metadata not covered by the base specification. All such extensions use the Sensorpedia namespace to differentiate them from the standard Atom format. The XML Namespaces URI for the XML Atom Syndication Format described in this specification is: http://www.w3.org/2005/Atom The XML Namespaces URI for the Sensorpedia extensions described in this specification is: http://www.sensorpedia.com/api/spedia The XML Namespaces URI for the GeoRSS extensions described in this specification is: http://www.georss.org/georss/10[4] The namespace prefixes "atom:", “sp:”, and “georss:” are used in this document to denote the Atom, Sensorpedia, and GeoRSS namespaces respectively. Note that the choice of namespace prefix is arbitrary and not semantically significant. In some cases, the Sensorpedia extension element names are the same as those used within the Atom namespace, but use the Sensorpedia namespace instead. In these cases, the element definition and format is exactly the same as for the Atom namespace. A new element with the Sensorpedia namespace is only defined so that the element may be reused in alternate locations for storing additional metadata. In addition to the extensions defined in the Sensorpedia namespace, the API also uses the elements described by GeoRSS to represent location data. Like the Sensorpedia extensions, the formats and definitions are exactly as described in the official GeoRSS documentation, but similar to some Atom elements, the API applies some special conventions for how GeoRSS is used for describing sensors and sensor data. Atom Usage & ConventionsExtension definitions and conventions are described here as annotations to excerpts from the official Atom Syndication Format specification (RFC 4287). Atom defined metadata elements for both feed and entry documents have been repurposed to describe the sensors and sensor system as described below. Unless otherwise noted here, all Atom defined elements must follow all rules as defined in the RFC, even if not explicitly stated here. Sensorpedia Atom-based documents should be fully compliant Atom documents. Some Atom element definitions here include more formalized RELAX-NG notation as used in RFC 4287. Construct names used within these definitions reference the definitions given in RFC 4287 except for those items in bold which indicate Sensorpedia specific constructs defined here. Container ElementsThe “atom:feed” ElementAn Atom feed document is used to describe a sensor system or other similar group of related sensors. In this way, consumers may subscribe to a Sensorpedia Atom-based registration document to be notified of updates or modifications to a sensor system. The Sensorpedia API adds two required extension elements to the atom:feed definition, sp:published and sp:summary. atomFeed = element atom:feed { atomCommonAttributes, (atomAuthor* & atomCategory* & atomContributor* & atomGenerator? & atomIcon? & atomId & atomLink* & atomLogo? & atomRights? & atomSubtitle? & atomTitle & atomUpdated & georssBox? & georssPoint & spediaPublished & spediaSummary & extensionElement*), atomEntry* } The "atom:entry" ElementIndividual Atom entry elements describe a single, specific sensor. atomEntry = element atom:entry { atomCommonAttributes, (atomAuthor* & atomCategory* & atomContent? & atomContributor* & atomId & atomLink* & atomPublished? & atomRights? & atomSource? & atomSummary? & atomTitle & atomUpdated & georssPoint & spediaSubtitle? & extensionElement*) } The "atom:content" ElementThe "atom:content" element either contains or links to the content of the entry. The use of atom:content is optional but recommended for use to embed or point to sensor data from the described sensor. The "type" AttributeOn the atom:content element, the value of the "type" attribute MAY be one of "text", "html", or "xhtml". Failing that, it MUST conform to the syntax of a MIME media type, but MUST NOT be a composite type. If neither the type attribute nor the src attribute is provided, Atom Processors MUST behave as though the type attribute were present with a value of "text". The "src" Attributeatom:content MAY have a "src" attribute, whose value MUST be an IRI reference [RFC3987]. If the "src" attribute is present, atom:content MUST be empty. Atom Processors MAY use the IRI to retrieve the content and MAY choose to ignore remote content or to present it in a different manner than local content. If the "src" attribute is present, the "type" attribute SHOULD be provided and MUST be a MIME media type, rather than "text", "html", or "xhtml". The value is advisory; that is to say, when the corresponding URI (mapped from an IRI, if necessary) is dereferenced, if the server providing that content also provides a media type, the server-provided media type is authoritative. Metadata ElementsThe "atom:author" ElementThe “atom:author” element is a Person construct that identifies the data publisher/owner of the entry or feed. It is recommended that the author atom:name element match the user’s Sensorpedia alias. The atom:uri element may point to the Sensorpedia user profile of the author. An optional sp:summary element (described below) may be used to provide a short description of the data publisher. At an individual atom:entry level, the optional author element may be used to identify contact information for a specific sensor. If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above. The "atom:category" ElementThe Atom Syndication Format assigns no specific meaning to the content (if any) of the “atom:category” element. But for the Sensorpedia API, this element is specifically used to capture user- and system-defined tags, or labels, to support multifaceted classification of sensors and sensor systems. Tags may be added to the sensor system as a whole (at the atom:feed level) or to specific sensors (at the atom:entry level). atomCategory = element atom:category { atomCommonAttributes, attribute term { text }, attribute scheme { atomUri }?, attribute label { text }?, attribute via { text }, undefinedContent } The "term" AttributeThe "term" attribute is a string that identifies the tag applied to the entry or feed. Category elements MUST have a "term" attribute. The "scheme" AttributeThe "scheme" attribute is an IRI that identifies a categorization scheme. Category elements MAY have a "scheme" attribute. Note that different users MAY use the same tag (“term”) string with different meanings. The scheme attribute gives data publishers a method to define how specific tags are being used. Tags supplied by other Sensorpedia users will typically not contain a scheme attribute. The "label" AttributeThe optional "label" attribute provides a human-readable label for display in end-user applications. The "via" AttributeThe Sensorpedia API reserves the values “author”, “user”, and “system” for the “via” attribute. A value of “author” indicates tags supplied by the data publisher. “User” indicates tags that have been supplied by other Sensorpedia users. For tags used internally or supplied by the Sensorpedia framework automatically, the “system” value is used. Other values may be used for this attribute but no specific meaning to alternate values. The "atom:contributor" Element†The "atom:contributor" element is a Person construct that indicates a person or other entity who contributed to the entry or feed. Within the Sensorpedia API, the atom:contributor element is rarely used but may be used to identify owners of input source data that may be used by the described sensor. The "atom:generator" Element†The "atom:generator" element's content identifies the agent used to generate a feed, for debugging and other purposes. The "atom:icon" and “sp:icon” ElementsThe "atom:icon" element's content is an IRI reference that identifies an image that provides iconic visual identification for a feed. If provided, the Sensorpedia web application uses the supplied icon for indicating sensor location on the map. The “sp:icon” element is identically defined as atom:icon but may be used within an atom:entry element to provide a sensor specific icon for display purposes. The Atom document may be dynamically updated or the icon URI may point to a dynamically generated image to provide additional sensor status visualization capabilities. The image SHOULD have an aspect ratio of one (horizontal) to one (vertical) and SHOULD be suitable for presentation at a small size. The "atom:id" ElementThe "atom:id" element conveys a permanent, universally unique identifier for an entry or feed. Its content MUST be an IRI, as defined by [RFC3987]. Note that the definition of "IRI" excludes relative references. Although a required element, Sensorpedia registration documents may be submitted without an atom:id element and the Sensorpedia service will automatically generate and insert a unique ID. For more information on the special handling of the atom:id element, see “Special Handling for Atom Elements” below. When an Atom Document is relocated, migrated, syndicated, republished, exported, or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource. The content of an atom:id element MUST be created in a way that assures uniqueness. Because of the risk of confusion between IRIs that would be equivalent if they were mapped to URIs and dereferenced, the normalization strategy described in the Atom RFC 4287 specification SHOULD be applied when generating atom:id elements. The "atom:link" ElementThe "atom:link" element defines a reference from an entry or feed to a Web resource. The Atom specification assigns no meaning to the content (if any) of this element, but the Sensorpedia API utilizes the atom:link element in conjunction with the “rel” attribute to reference specific types of additional resources such as alternative data representations and related sensor information. atomLink = element atom:link { atomCommonAttributes, attribute href { atomUri }, attribute rel { atomNCName | atomUri }?, attribute type { atomMediaType }?, attribute hreflang { atomLanguageTag }?, attribute title { text }?, attribute length { text }?, undefinedContent } The "rel" Attributeatom:link elements MAY have a "rel" attribute that indicates the link relation type. If the "rel" attribute is not present, the link element MUST be interpreted as if the link relation type is "alternate". This document defines five initial values for the Registry of Link Relations:
The "type" AttributeOn the link element, the "type" attribute's value is an advisory media type: it is a hint about the type of the representation that is expected to be returned when the value of the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation. Link elements MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type. The "hreflang" Attribute†The "hreflang" attribute's content describes the language of the resource pointed to by the href attribute. When used together with the rel="alternate", it implies a translated version of the entry. Link elements MAY have an hreflang attribute, whose value MUST be an RFC 3066 language tag[5]. The language tag definition does not allow the specification of translated compter-readable languages and should only be used to provide links to alternative human-readable language translations. The "title" AttributeThe "title" attribute conveys human-readable information about the link. The content of the "title" attribute is Language-Sensitive. Entities such as "&" and "<" represent their corresponding characters ("&" and "<", respectively), not markup. Link elements MAY have a title attribute and is highly encouraged for use with the Sensorpedia API to provide descriptive text to be displayed along with the IRI. The "length" AttributeThe "length" attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. Note that the length attribute does not override the actual content length of the representation as reported by the underlying protocol. Link elements MAY have a length attribute. The "atom:logo" ElementThe "atom:logo" element's content is an IRI reference that identifies an image that provides visual identification for a sensor registration document. The image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical). The "atom:published" and “sp:published” ElementsThe "atom:published" element is a Date construct indicating an instant in time associated with an event early in the life cycle of the entry. Date values within Atom follow RFC 3339 and are compatible with ISO 8601 “extended format” also used for xs:dateTime in the W3C XSD. Date values MUST indicate the appropriate time zone through the use of an uppercase “Z” character (for UTC) or a numeric time zone offset of the form nn:nn. The following are proper date values: <published>2009-04-28T18:30:02Z</published> <published>2009-04-28T18:30:02.25Z</published> <published>2009-04-28T14:30:02-04:00</published>
Typically, atom:published will be associated with the initial creation or first availability of the resource. It should be used in the Sensorpedia API to represent registration time for an atom:entry representation of a sensor. The “sp:published” element uses the same definition but is applied to the “atom:feed” element to indicate creation time for the registration document. The "atom:rights" Element†The "atom:rights" element is a Text construct that conveys information about rights held in and over an entry or feed. The atom:rights element SHOULD NOT be used to convey machine-readable licensing information. If an atom:entry element does not contain an atom:rights element, then the atom:rights element of the containing atom:feed element, if present, is considered to apply to the entry. The atom:rights element is reserved for future use in the Sensorpedia API to indicate usage rights of the supplied sensor data. The "atom:source" Element†If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's Metadata elements as the atom:source element's children. Such Metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:rights, or atom:category and those child elements are not present in the source atom:entry. The atom:source element is designed to allow the aggregation of entries from different feeds while retaining information about an entry's source feed. The atom:source element isn’t used directly by the Sensorpedia API but should be utilized if sensor atom:entry elements are used outside the context of the original containing document. The atom:source element is also reserved for future use by the Sensorpedia API when generating search results in the form of an aggregated Atom document. The "atom:subtitle" and "sp:subtitle" ElementsThe "atom:subtitle" element is a Text construct that conveys a human-readable description or subtitle for a feed. Within a sensor registration feed document, the atom:subtitle element provides an additional description of the sensor system. Similarly defined, the "sp:subtitle" element is used at the atom:entry level to describe a specific sensor device. The subtitle may be used as a brief summary in search results or as a tooltip display where appropriate. The "atom:summary" and “sp:summary” ElementsThe "atom:summary" element is a Text construct that conveys a short summary, abstract, or excerpt of an entry. It is not advisable for the atom:summary element to duplicate atom:title or atom:content because Atom Processors might assume there is a useful summary when there is none. The atom:summary is used at the atom:entry level to describe the specific sensor. Similarly defined, the "sp:summary" element is included at the atom:feed level to provide a summary description of the sensor system or sensor group. The sp:summary element may also be used as part of the atom:author element to provide optional biographical or descriptive text regarding the data publisher. The "atom:title" ElementThe "atom:title" element is a Text construct that conveys a human-readable title for an entry or feed. This element provides a short descriptive title for the sensor system (at the atom:feed level) or specific sensor device (at the atom:entry level) and may be used for display purposes in search results or data visualizations. The "atom:updated" ElementThe "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value. Publishers MAY change the value of this element over time. The Sensorpedia services do not modify this element automatically on a document update. Date values must follow the same format as described for the atom:published element. The Sensorpedia services currently do not maintain an archive of changes over time, but this functionality may be included in future versions. GeoRSS ExtensionsThe “georss:point” ElementThe georss:point element is used at both the atom:feed and atom:entry level of a Sensorpedia Atom document to describe location metadata. At the atom:entry level, the point element should describe the actual physical location of the sensor (if applicable). If the sensor is virtual and has no physical location, the point element should indicate an appropriate location for displaying an identifying icon on a map. At the atom:feed level, the point element is primarily used to indicate icon location as well. If there is only one sensor represented by the Atom document, the point element should be identical in both locations. If the Atom document represents a sensor system with multiple devices at different locations, the data provider must decide on a location that best represents the sensor system as a whole. The “georss:box” ElementThe optional georss:box element is used at both the atom:feed and atom:entry level of a Sensorpedia Atom document. At the atom:entry level, the box element represents the extent (or possible extent) of data from the described sensor. This element is primarily designed to support mobile sensors. The box may be statically defined for all possible observation locations or it may be dynamically updated by the user through the use of the update function described below to indicate actual sensor data locations. At the atom:feed level, the box element should be, at a minimum, the union of all entry level box elements. The feed box element may also be statically or dynamically defined. Sensorpedia API ActionsThe Sensorpedia API contains four main functions: Register, Update, Delete, and Query. All functions are implemented as a RESTful web service call of the form: http://www.sensorpedia.com/api/<function>[? Parameters]
API Example Calls: l http://www.sensorpedia.com/api/register?url=... l http://www.sensorpedia.com/api/register (Atom document as POST content) l http://www.sensorpedia.com/api/update (Atom document as POST content) l http://www.sensorpedia.com/api/delete?id=123 l http://www.sensorpedia.com/api/query?id=123 l http://www.sensorpedia.com/api/query?tag=foo,bar l http://www.sensorpedia.com/api/query?author=abc&inline=true l http://www.sensorpedia.com/api/query?search=text l http://www.sensorpedia.com/api/feed?id=123 Special Handling for Atom ElementsID and Link AssignmentWhen registering a sensor using the Register function, users have two options for handling ID and Link assignment.
Exceptions
GeoRSS LocationsSensorpedia utilizes the GeoRSS point and box elements to specify locations for sensors and sensor systems. For a sensor feed document, the user SHOULD supply GeoRSS point and box elements specifying where an icon may be placed on the map to represent the sensor system and the extent of the sensor system respectively. If the feed document does not contain a point element, the system MAY calculate the property using location metadata from individual entries if possible†. Individual sensor entries MUST contain a point or box element. An error will be returned if it is not included. JSON RepresentationThe Sensorpedia API may also be used with an alternative JSON representation of the Atom feed document based on the Google Data API. The alternative JSON representation may be substituted anywhere an Atom document is specified as an input† or output of a service. To request the JSON format as output from a service, use the format=json or alt=json parameters. The format parameter is optional and defaults to 'atom'. The alternate JSON format may also be specified using HTTP Accept header with a value of “application/json”. Examples
Sensorpedia API ExamplesExample Registration Atom DocumentThe following is an example Atom document representing a sensor system with multiple sensor locations. This document is representative of the input expected for the Register and Update functions. <feed xmlns="http://www.w3.org/2005/Atom"
xmlns:georss="http://www.georss.org/georss/10" xmlns:sp="http://www.sensorpedia.com/ns/sensorpedia"> <id>urn:uuid:1234567890-dasmet</id> <title type="text">DASMet Weather Sensors</title> <subtitle type="text"> Provides a wide range of climate information for the Oak Ridge Reservation (ORR) </subtitle> <sp:summary type="html"> This site contains a wide range of climate information for the Oak Ridge Reservation (ORR), much of which is not available anywhere else. Additional information about Oak Ridge climate data is available from the DAS/MET Homepage. </sp:summary> <sp:published>2009-01-13T10:15:07.000Z</sp:published> <updated>2009-02-10T10:15:37.000Z</updated> <author> <name>David Resseguie</name> <uri>http://www.sensorpedia.com/profile.php?username=Resseguie</uri> <sp:summary type="text"> Works at ORNL and developed the Sensorpedia web application. </sp:summary> </author> <georss:point>35.941567 -84.305649</georss:point> <georss:box>35.605924 -84.790627 35.989039 -84.252459</georss:box> <icon></icon> <logo>http://farm3.static.flickr.com/2483/3704176887_6d41a002a3.jpg?v=0</logo> <link href="http://www.sensorpedia.com/SpediaAtomService/api/feed?id=urn:uuid:1234567890-dasmet" rel="self" /> <link href="http://www.ornl.gov/~das/web/ORRMET.HTM" rel="alternate" type="text/html" title="DASMet Overview"/> <link href="http://ornlntrc1.ctr.utk.edu/tower-report/folder2.kml" rel="alternate" type="application/kml+xml" title="View in Google Earth"/> <link href="http://www.ornl.gov/~das/web/RECWX1.HTM" rel="alternate" type="text/html" title="Recent Weather"/> <link href="http://www.ornl.gov/~das/web/TABWX1.HTM" rel="alternate" type="text/html" title="DASMet Table Graphes"/> <link href="http://www.ornl.gov/~das/web/RECWX5.HTM" rel="alternate" type="text/html" title="Oak Ridge Reservation - Climate Data, Normals, and Extremes"/> <link href="http://www.ornl.gov/~das/web/LCM.HTM" rel="alternate" type="text/html" title="Local Climate"/> <link href="http://www.ornl.gov/~das/web/HISTWX1.HTM" rel="alternate" type="text/html" title="Historical ASCII-Formatted Data"/> <category term="weather" via="author" /> <category term="met" via="author" /> <category term="ornl" via="author" /> <entry> <id>urn:uuid:1234567890-towa</id> <title type="text">Tower A</title> <sp:subtitle /> <summary type="text">DAS/MET Tower A Data</summary> <published>2009-02-10T10:15:37.000Z</published> <updated>2009-02-10T10:15:37.000Z</updated> <georss:point>35.91813 -84.304088</georss:point> <sp:icon /> <link href="http://www.ornl.gov/~das/met/Data/hour/ORNL/TOWA_Daily/TowerA.txt" rel="alternate" type="text/html" title="Tower A Hourly Data Averages" /> <link href="/eoc/obs/TOWA.xml" rel="alternate" type="application/kml+xml" title="Raw XML Data Format" /> <link href="/eoc/obs/TOWA.html" rel="alternate" type="text/html" title="Table view of latest sensor data" /> <content type="text/html" src="http://www.sensorpedia.com/eoc/obs/TOWA.html" /> <category term="dasmet" via="author" /> </entry> <entry> <id>urn:uuid:1234567890-towm</id> <title type="text">Tower M</title> <sp:subtitle /> <summary type="text">DAS/MET Tower M Data</summary> <published>2009-02-10T10:15:37.000Z</published> <updated>2009-02-10T10:15:37.000Z</updated> <georss:point>35.909282 -84.388078</georss:point> <sp:icon /> <link href="http://www.ornl.gov/~das/met/Data/hour/ORNL/TOWM_Daily/TowerM.txt" rel="alternate" type="text/html" title="Tower M Hourly Data Averages" /> <link href="/eoc/obs/TOWM.xml" rel="alternate" type="application/kml+xml" title="Raw XML Data Format" /> <link href="/eoc/obs/TOWM.html" rel="alternate" type="text/html" title="Table view of latest sensor data" /> <content type="text/html" src="http://www.sensorpedia.com/eoc/obs/TOWM.html" /> <category term="dasmet" via="author" /> </entry> <entry> <id>urn:uuid:1234567890-towb</id> <title type="text">Tower B</title> <sp:subtitle /> <summary type="text">DAS/MET Tower B Data</summary> <published>2009-02-10T10:15:37.000Z</published> <updated>2009-02-10T10:15:37.000Z</updated> <georss:point>35.934397 -84.29742</georss:point> <sp:icon /> <link href="http://www.ornl.gov/~das/met/Data/hour/ORNL/TOWB_Daily/TowerB.txt" rel="alternate" type="text/html" title="Tower B Hourly Data Averages" /> <link href="/eoc/obs/TOWB.xml" rel="alternate" type="application/kml+xml" title="Raw XML Data Format" /> <link href="/eoc/obs/TOWB.html" rel="alternate" type="text/html" title="Table view of latest sensor data" /> <content type="text/html" src="http://www.sensorpedia.com/eoc/obs/TOWB.html" /> <category term="dasmet" via="author" /> </entry> </feed> Same document in JSON format: {Example Search Result Atom DocumentThe following is an example XML document representing the result of the Query function returning two matching sensor documents. <sp:queryResult> Same search results in JSON format: {† Element, attribute, or feature may not be fully implemented or tested in the BETA services. |
