Difference between revisions of "Discovery Change Proposal-3"

From Earth Science Information Partners (ESIP)
Line 6: Line 6:
  
 
[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]
 
[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]
 +
  
 
= DCP-3: Standardized Linking from one cast to another or to additional metadata =
 
= DCP-3: Standardized Linking from one cast to another or to additional metadata =
Line 72: Line 73:
 
|http://esipfed.org/ns/discovery/1.1/data#
 
|http://esipfed.org/ns/discovery/1.1/data#
 
|OPeNDAP
 
|OPeNDAP
 +
| -
 
|Point to DAP access to a granule (file) from a datacast entry
 
|Point to DAP access to a granule (file) from a datacast entry
 
|-
 
|-
Line 123: Line 125:
 
serve these specific purposes.
 
serve these specific purposes.
  
The values of the subrel attribute are also being standardized in the Discovery
+
The values of the subrel attribute (the known specific purposes) are also being  
namespace.  The values of the serviceProtocol should be the official known URI's
+
standardized in the Discovery namespace.  The values of the serviceProtocol should
for particular version of the specific REST protocol.
+
be the official known URI's for particular version of the specific REST protocol.
  
  
Line 132: Line 134:
 
This solution provides great flexibility and specificity, while retaining maximal
 
This solution provides great flexibility and specificity, while retaining maximal
 
compatibility with the existing usage of <link> tags in feeds.  We are reusing the
 
compatibility with the existing usage of <link> tags in feeds.  We are reusing the
generic ''purpose'' values standardized by IANA (e.g. related, enclosure, icon, etc.)
+
''generic purpose'' values standardized by IANA (e.g. related, enclosure, icon, etc.)
 
and fitting our '''more specific''' purposes into the appropriate generic purpose.
 
and fitting our '''more specific''' purposes into the appropriate generic purpose.
  
Line 146: Line 148:
 
or data cast can follow this link and thereby also present metadata about the
 
or data cast can follow this link and thereby also present metadata about the
 
available services.  Collection metadata is kept in the collection cast in standard
 
available services.  Collection metadata is kept in the collection cast in standard
format, and service metadata is kept in the service cast in the known format, but
+
format, and service metadata is kept in the service cast also in the known format, but
 
the two sets of metadata are strongly linked for presentation to the user.
 
the two sets of metadata are strongly linked for presentation to the user.
  
It is hoped that this DCP-3 can supersede DCP-2.  The required OpeNDAP links of
+
It is hoped that this DCP-3 can supersede DCP-2.  The required OpeNDAP "data#" links
DCP-2 would be specified as in the third row of the table above.  
+
of DCP-2 would be specified as in the third row of the table above.  
  
 
== Discussions ==
 
== Discussions ==

Revision as of 21:22, October 10, 2011

<< Back to the Discovery Change Proposals page

<< Back to the Discovery Change Proposals page

<< Back to the Discovery Change Proposals page

<< Back to the Discovery Change Proposals page


DCP-3: Standardized Linking from one cast to another or to additional metadata

  • Progress (fill in the dates as the process moves forward)
  1. Submitted on: 10 Oct 2011
  2. Review period: ??

Description

Service casts have a need to <link> to datasets (i.e. collections) that are made available by a given service. Similarly, collection casts need to link to services available to discover & access the collections. In addition, all kinds of cast entries need to link to additional resources or metadata. For example, a data granule cast entry may want to point to a browse image for that granule.

Following the Atom standard, we will use <link> tags to standardize as many kinds of such links (pointers) as possible. Each link tag will have multiple standardized attributes:

  • rel - a generic purpose, values standardized by IANA for use in Atom feeds
  • esip:subrel - a specific purpose standardized in the Discovery namespace
  • esip:serviceProtocol - a specific versioned protocol specifier for the type of REST service call in the URL
  • href - the URL of the link
  • type - the MIME type of the resource returned by the href URL.

So, for example, a service cast can solve the problem of specifying what collections it serves by hiding the lookup behind an OpenSearch query that returns a list of collections in the collection cast format (Atom feed). The link would look like:

<link rel="related"                                     # IANA generic purpose        
      type="application/atom+xml"                       # response MIME type 
      xmlns:esip="http://esipfed.org/ns/discovery/1.1/" # our namespace
      esip:subrel="http://esipfed.org/ns/discovery/1.1/collections#" # collection cast  
      esip:serviceProtocol="http://a9.com/-/spec/opensearch/1.1/" # doing a search
      href="<OpenSearch URL that does the appropriate search>" />

For this link, the information is generically related, the URL is an OpenSearch service call with version 1.1, the specific purpose is to return a list of collections (cast), and the response MIME type is, of course, Atom.

The table below describes an inital set of standard links. All values of the esip:subrel attribute will be in the Discovery namespace (prefix esip) http://esipfed.org/ns/discovery/1.1/. The values of the esip:serviceProtocol attribute should be official URI's representing a versioned service interface.


rel (IANA) esip:subrel (ESIP) esip:serviceProtocol type (MIME) Purpose (e.g.)
related http://esipfed.org/ns/discovery/1.1/collections# http://a9.com/-/spec/opensearch/1.1/ application/atom+xml Point to a list of served collections from an scast entry
related http://esipfed.org/ns/discovery/1.1/services# http://a9.com/-/spec/opensearch/1.1/ application/atom+xml Point to list of available services from a collection cast entry
enclosure http://esipfed.org/ns/discovery/1.1/data# OPeNDAP - Point to DAP access to a granule (file) from a datacast entry
icon http://esipfed.org/ns/discovery/1.1/browse# OGC-WMS image/jpg Point to a browse image for a granules from a datacast entry
search http://esipfed.org/ns/discovery/1.1/search# http://a9.com/-/spec/opensearch/1.1/ OpenSearch Description Document (OSDD) Point to a search service from a collection cast entry
related http://esipfed.org/ns/discovery/1.1/service# OGC-WCS - Point to WCS service from a collection or data cast entry
related http://esipfed.org/ns/discovery/1.1/event# - app/atom+xml Point to related event cast from any kind of cast or XML metadata
describedBy http://esipfed.org/ns/discovery/1.1/documentation# - text/html Point to HTML documentation from any cast

Problem Addressed

We need standardized link tags to point from one cast to another, and to point from cast entries to additional resources. The links should be strongly typed so that machine scripts can automatically discover certain types of links, interpret and follow them, and handle the responses. To accomplish that, we need to mark links with known purposes and specify the REST service protocol implicit in the link URL.


Proposed Solution

The generic purposes standardized in the IANA rel attributes are not specific enough, and the MIME type is insufficient to automatically use the URL, which may be a specific version of a REST service protocol. Thus, we are standardizing two additional attributes in the Discovery namespace, subrel and serviceProtocol, to serve these specific purposes.

The values of the subrel attribute (the known specific purposes) are also being standardized in the Discovery namespace. The values of the serviceProtocol should be the official known URI's for particular version of the specific REST protocol.


Rationale for the Solution

This solution provides great flexibility and specificity, while retaining maximal compatibility with the existing usage of <link> tags in feeds. We are reusing the generic purpose values standardized by IANA (e.g. related, enclosure, icon, etc.) and fitting our more specific purposes into the appropriate generic purpose.

The new attributes, subrel and serviceProtocol, are defined in a namespace (the Discovery namespace) so they are perfectly legal within the W3C <link> tag and won't cause feed validators to reject our cast formats.

By having both the subrel and serviceProtocol attributes, we can solve complex linking problems. In a collection or data cast, if a script finds a related services link tag, then it knows what is being pointed to. If the service protocol is OpenSearch, and the MIME type Atom, then it knows this lookup is indirectly provided via a canned OpenSearch query. A GUI presenting the collection or data cast can follow this link and thereby also present metadata about the available services. Collection metadata is kept in the collection cast in standard format, and service metadata is kept in the service cast also in the known format, but the two sets of metadata are strongly linked for presentation to the user.

It is hoped that this DCP-3 can supersede DCP-2. The required OpeNDAP "data#" links of DCP-2 would be specified as in the third row of the table above.

Discussions

Talk:Discovery_Change_Proposal-3

Consensus

Voting: ??