Difference between revisions of "Federated Search Convention"
Line 20: | Line 20: | ||
== Extensions == | == Extensions == | ||
+ | === Granule-level Links === | ||
Atom allows inclusion of multiple links for a given entry, a key advantage for the rich variety of manifestations for a given data granule, such as: | Atom allows inclusion of multiple links for a given entry, a key advantage for the rich variety of manifestations for a given data granule, such as: | ||
*data | *data | ||
Line 27: | Line 28: | ||
*On-the-fly format conversion | *On-the-fly format conversion | ||
However, it is important for a client to be able to distinguish the different kinds of links, which can be done using the "rel" attribute. As the standard set of "rel" attributes (self, related, alternate, enclosure, via) is insufficiently rich, we extend the standard using URIs within the ESIP namespace. The convention for this namespace is still under discussion, with the current proposal being: | However, it is important for a client to be able to distinguish the different kinds of links, which can be done using the "rel" attribute. As the standard set of "rel" attributes (self, related, alternate, enclosure, via) is insufficiently rich, we extend the standard using URIs within the ESIP namespace. The convention for this namespace is still under discussion, with the current proposal being: | ||
− | *http://esipfed.org/ns/fedsearch/ | + | *http://esipfed.org/ns/fedsearch/data |
− | *http://esipfed.org/ns/fedsearch/ | + | *http://esipfed.org/ns/fedsearch/browse |
− | *http://esipfed.org/ns/fedsearch/ | + | *http://esipfed.org/ns/fedsearch/metadata |
*http://esipfed.org/ns/fedsearch/opendap | *http://esipfed.org/ns/fedsearch/opendap | ||
etc. | etc. |
Revision as of 10:56, October 26, 2009
Motivation
Overall Architecture
Reuse of Existing Standards
Modification of Standards
Restriction Conventions
Response Formats
Although OpenSearch allows a number of different formats (HTML, RSS, Atom), the ESIP Federated Search convention is to return an Atom response. This is (mostly) intelligible to browser-based newsreaders (the lowest common denominator) while providing a relatively rich structure for parsing as well as accommodating domain-specific extensions.
Time in Atom Response
Time is specified only for the query, not the response, in the draft Time extension to OpenSearch. The ESIP Federated Search convention is to represent Time of datasets or granules as the following:
- The namespace is defined as xmlns:time="http://a9.com/-/opensearch/extensions/time/1.0/"
- Time is represented as XML elements "start" and "stop" (following the draft for the Query), e.g.:
- <time:start>YYYY-MM-DDTHH:SS:MMZ</time:start>
- <time:stop>YYYY-MM-DDTHH:SS:MMZ</time:stop>
- By convention, time is in Universal (Zulu) time, using the format YYYY-MM-DDTHH:MM:SS[.SSS]Z. Fractional seconds are optional.
Extensions
Granule-level Links
Atom allows inclusion of multiple links for a given entry, a key advantage for the rich variety of manifestations for a given data granule, such as:
- data
- browse image
- metadata file
- OPeNDAP URL
- On-the-fly format conversion
However, it is important for a client to be able to distinguish the different kinds of links, which can be done using the "rel" attribute. As the standard set of "rel" attributes (self, related, alternate, enclosure, via) is insufficiently rich, we extend the standard using URIs within the ESIP namespace. The convention for this namespace is still under discussion, with the current proposal being:
- http://esipfed.org/ns/fedsearch/data
- http://esipfed.org/ns/fedsearch/browse
- http://esipfed.org/ns/fedsearch/metadata
- http://esipfed.org/ns/fedsearch/opendap
etc. This will eventually be linked to servicecasting namespace, so that services advertised through that mechanism can be referenced as types as well.