Difference between revisions of "Discovery Change Proposal-8"

From Earth Science Information Partners (ESIP)
(Created page with "<< Back to the Discovery Change Proposals page = DCP-8: Standardized Linking from one cast to another or to additional metadata = * '''Progres...")
 
 
(10 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
* '''Progress''' (fill in the dates as the process moves forward)
 
* '''Progress''' (fill in the dates as the process moves forward)
 
# '''Submitted on''': 14 July 2012
 
# '''Submitted on''': 14 July 2012
# '''Review period''': ??
+
# '''Review period''': July to December 2012
  
 
== Description ==
 
== Description ==
Line 17: Line 17:
 
Following the Atom standard, we will use <link> tags and reuse the 'xlink' attribute
 
Following the Atom standard, we will use <link> tags and reuse the 'xlink' attribute
 
conventions to standardize as many kinds of such links (pointers) as possible.  Each link tag will have multiple '''standardized''' attributes:
 
conventions 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
+
* '''title'''        - a descriptive title for display
* '''xlink:role''' - a specific purpose standardized in the Discovery namespace
+
* '''rel'''           - a generic purpose, values standardized by IANA for use in Atom feeds
 +
* '''xlink:role'''   - a specific purpose standardized in the Discovery namespace
 
* '''xlink:arcrole''' - a specific versioned protocol specifier for the type of REST service call in the URL
 
* '''xlink:arcrole''' - a specific versioned protocol specifier for the type of REST service call in the URL
* '''href'''       - the URL of the link
+
* '''href'''         - the URL of the link
* '''type'''       - the MIME type of the resource returned by the href URL.
+
* '''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
 
So, for example, a service cast can solve the problem of specifying what collections
Line 27: Line 28:
 
collections in the collection cast format (Atom feed).  The link would look like:
 
collections in the collection cast format (Atom feed).  The link would look like:
  
  <link rel="related"                                         # IANA generic purpose         
+
  <link title="Datasets accessible from this service"                    # description
      xmlns:esip="http://esipfed.org/ns/discovery/1.1/"      # our namespace
+
      rel="related"                                                   # IANA generic purpose         
       xmlns:xlink="http://www.w3.org/1999/xlink"             # xlink namespace
+
       xmlns:xlink="http://www.w3.org/1999/xlink"                       # xlink namespace
       xlink:role="http://esipfed.org/ns/discovery/1.1/collections#" # collection cast   
+
       xlink:role="http://commons.esipfed.org/ns/discovery/1.2/collectionCast#" # collection cast   
       xlink:arcrole="http://a9.com/-/spec/opensearch/1.1/"   # doing a search
+
       xlink:arcrole="http://a9.com/-/spec/opensearch/1.1/"             # URL calls a search service
 
       href="<OpenSearch URL that does the appropriate search>"
 
       href="<OpenSearch URL that does the appropriate search>"
       type="application/atom+xml" />                         # response MIME type  
+
       type="application/atom+xml" />                                   # response MIME type  
  
For this link, the information is generically ''related'', the URL is an OpenSearch  
+
For this link, the information (rel) is generically ''related'', the URL is an OpenSearch  
service call with version 1.1, the specific purpose is to return a list of collections  
+
service call with version 1.1 (arcrole), the specific purpose (role)is to return a list
(a cast), and the response MIME type is, of course, Atom.
+
of collections (a cast), and the response MIME type is, of course, Atom.
  
The table below describes an inital set of '''standard''' links.  All values of the
+
The table below describes an inital set of '''standard''' links.  All values (specific
'''xlink:role''' attribute will be in the Discovery namespace ???(prefix esip)  ''http://esipfed.org/ns/discovery/1.1/''.  The values of the '''xlink:arcrole'''
+
purposes) of the '''xlink:role''' attribute will be in the Discovery namespace (''http://commons.esipfed.org/ns/discovery/1.2/'').  The values of the '''xlink:arcrole'''
 
attribute should be official URI's representing a versioned service interface.  
 
attribute should be official URI's representing a versioned service interface.  
  
Line 47: Line 48:
 
|-
 
|-
 
! rel (generic purpose, IANA)
 
! rel (generic purpose, IANA)
! xlink:role (specific purpose, ESIP)
+
! xlink:role (specific purpose, ESIP conventions)
! xlink:arcrole (URI for a version service protocol)
+
! xlink:arcrole (URI for a versioned service protocol)
 
! type (MIME)
 
! type (MIME)
 
! Purpose (explanation)
 
! Purpose (explanation)
 
|-
 
|-
 
|related
 
|related
|http://esipfed.org/ns/discovery/1.1/collections#
+
|http://commons.esipfed.org/ns/discovery/1.2/collectionCast#
 
|http://a9.com/-/spec/opensearch/1.1/
 
|http://a9.com/-/spec/opensearch/1.1/
 
|application/atom+xml
 
|application/atom+xml
Line 59: Line 60:
 
|-
 
|-
 
|related
 
|related
|http://esipfed.org/ns/discovery/1.1/services#
+
|http://commons.esipfed.org/ns/discovery/1.2/serviceCast#
 
|http://a9.com/-/spec/opensearch/1.1/
 
|http://a9.com/-/spec/opensearch/1.1/
 
|application/atom+xml
 
|application/atom+xml
Line 65: Line 66:
 
|-
 
|-
 
|enclosure
 
|enclosure
|http://esipfed.org/ns/discovery/1.1/data#
+
|http://commons.esipfed.org/ns/discovery/1.2/data#
 
|n/a
 
|n/a
 
|(format of data files)
 
|(format of data files)
Line 71: Line 72:
 
|-
 
|-
 
|enclosure
 
|enclosure
|http://esipfed.org/ns/discovery/1.1/data#
+
|http://commons.esipfed.org/ns/discovery/1.2/data#
 
|http://xml.opendap.org/ns/DAP/3.3#
 
|http://xml.opendap.org/ns/DAP/3.3#
 
|application/x-netcdf (netCDF)<br>text/html (HTML Form)<br>text/plain (ASCII download)<br>application/octet-stream (DODS)<br>
 
|application/x-netcdf (netCDF)<br>text/html (HTML Form)<br>text/plain (ASCII download)<br>application/octet-stream (DODS)<br>
Line 77: Line 78:
 
|-
 
|-
 
|icon
 
|icon
|http://esipfed.org/ns/discovery/1.1/browse#
+
|http://commons.esipfed.org/ns/discovery/1.2/browse#
 
|OGC-WMS
 
|OGC-WMS
 
|image/jpg
 
|image/jpg
Line 83: Line 84:
 
|-
 
|-
 
|search
 
|search
|http://esipfed.org/ns/discovery/1.1/search#
+
|http://commons.esipfed.org/ns/discovery/1.2/search#
 
|http://a9.com/-/spec/opensearch/1.1/
 
|http://a9.com/-/spec/opensearch/1.1/
 
|application/opensearchdescription+xml
 
|application/opensearchdescription+xml
Line 89: Line 90:
 
|-
 
|-
 
|related
 
|related
|http://esipfed.org/ns/discovery/1.1/service#
+
|http://commons.esipfed.org/ns/discovery/1.2/service#
 
|OGC-WCS
 
|OGC-WCS
 
| -  
 
| -  
Line 95: Line 96:
 
|-
 
|-
 
|related
 
|related
|http://esipfed.org/ns/discovery/1.1/event#
+
|http://commons.esipfed.org/ns/discovery/1.2/eventCast#
 
| -  
 
| -  
 
|app/atom+xml
 
|app/atom+xml
Line 101: Line 102:
 
|-
 
|-
 
|describedBy
 
|describedBy
|http://esipfed.org/ns/discovery/1.1/documentation#
+
|http://commons.esipfed.org/ns/discovery/1.2/documentation#
 
| -  
 
| -  
 
|text/html<br>application/pdf
 
|text/html<br>application/pdf
Line 144: Line 145:
  
 
By having both the role and arcrole attributes, we can solve complex linking problems.
 
By having both the role and arcrole 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
+
In a collection or data cast, if a script finds a ''related services'' link tag, then
protocol is OpenSearch, and the MIME type Atom, then it knows this lookup is
+
it knows what is being pointed to (a service cast).  If the arcrole is OpenSearch,
indirectly provided via a canned OpenSearch query.  A GUI presenting the collection
+
and the MIME type is Atom, then it knows this '''services''' 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
 
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
Line 152: Line 154:
 
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-2The required OpeNDAP "data#" links
+
This DCP-8 supersedes the defunct (proposed) DCP-3It is supposed to be a generalization
of DCP-2 would be specified as in the third row of the table above.
+
of DCP-6 for standardizing OpeNDAP "data#" links.
  
 
== Discussions ==
 
== Discussions ==
Line 161: Line 163:
 
== Consensus ==
 
== Consensus ==
  
Voting: ??
+
Voting: By December 20, 2012

Latest revision as of 14:35, November 20, 2012

<< Back to the Discovery Change Proposals page

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

  • Progress (fill in the dates as the process moves forward)
  1. Submitted on: 14 July 2012
  2. Review period: July to December 2012

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 and reuse the 'xlink' attribute conventions to standardize as many kinds of such links (pointers) as possible. Each link tag will have multiple standardized attributes:

  • title - a descriptive title for display
  • rel - a generic purpose, values standardized by IANA for use in Atom feeds
  • xlink:role - a specific purpose standardized in the Discovery namespace
  • xlink:arcrole - 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 title="Datasets accessible from this service"                    # description
      rel="related"                                                    # IANA generic purpose        
      xmlns:xlink="http://www.w3.org/1999/xlink"                       # xlink namespace
      xlink:role="http://commons.esipfed.org/ns/discovery/1.2/collectionCast#" # collection cast  
      xlink:arcrole="http://a9.com/-/spec/opensearch/1.1/"             # URL calls a search service
      href="<OpenSearch URL that does the appropriate search>"
      type="application/atom+xml" />                                   # response MIME type 

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

The table below describes an inital set of standard links. All values (specific purposes) of the xlink:role attribute will be in the Discovery namespace (http://commons.esipfed.org/ns/discovery/1.2/). The values of the xlink:arcrole attribute should be official URI's representing a versioned service interface.


rel (generic purpose, IANA) xlink:role (specific purpose, ESIP conventions) xlink:arcrole (URI for a versioned service protocol) type (MIME) Purpose (explanation)
related http://commons.esipfed.org/ns/discovery/1.2/collectionCast# http://a9.com/-/spec/opensearch/1.1/ application/atom+xml Point to a list of served collections from an scast entry
related http://commons.esipfed.org/ns/discovery/1.2/serviceCast# http://a9.com/-/spec/opensearch/1.1/ application/atom+xml Point to list of available services from a collection cast entry
enclosure http://commons.esipfed.org/ns/discovery/1.2/data# n/a (format of data files) Point to direct download location (FTP or HTTP) of a data granule (e.g., file)
enclosure http://commons.esipfed.org/ns/discovery/1.2/data# http://xml.opendap.org/ns/DAP/3.3# application/x-netcdf (netCDF)
text/html (HTML Form)
text/plain (ASCII download)
application/octet-stream (DODS)
Point to DAP access to a granule (e.g., file) from a datacast entry
icon http://commons.esipfed.org/ns/discovery/1.2/browse# OGC-WMS image/jpg Point to a browse image for a granules from a datacast entry
search http://commons.esipfed.org/ns/discovery/1.2/search# http://a9.com/-/spec/opensearch/1.1/ application/opensearchdescription+xml Point to a search service from a collection cast entry
related http://commons.esipfed.org/ns/discovery/1.2/service# OGC-WCS - Point to WCS service from a collection or data cast entry
related http://commons.esipfed.org/ns/discovery/1.2/eventCast# - app/atom+xml Point to related event cast from any kind of cast or XML metadata
describedBy http://commons.esipfed.org/ns/discovery/1.2/documentation# - text/html
application/pdf
Point to documentation relating to a data or service item (service cast, data cast or dataset)

Problem Addressed

We need standardized link tags to point from one cast to another, and to point from cast entries to additional resources (e.g. data or browse image links). 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-style service protocol implicit in the link URL (href).


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 for Discovery, and specifying them in the standard attributes xlink:role and xlink:arcrole.

The values of the xlink:role attribute (the known specific purposes) are being standardized for Discovery. The values of the xlink:arcrole should be versioned service protocols (official known URI's) or other information needed to properly invoke the service. If the href is a simple HTTP-GET URL, the arcrole attribute can be omitted.


Rationale for the Solution

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

The xlink attributes, role and arcrole, are perfectly legal within the W3C <link> tag and won't cause feed validators to reject our cast formats.

By having both the role and arcrole 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 (a service cast). If the arcrole is OpenSearch, and the MIME type is Atom, then it knows this services 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.

This DCP-8 supersedes the defunct (proposed) DCP-3. It is supposed to be a generalization of DCP-6 for standardizing OpeNDAP "data#" links.

Discussions

Talk:Discovery_Change_Proposal-8

Consensus

Voting: By December 20, 2012