Talk:Discovery Change Proposal-3

DCP-3 Discussion -- Jess Lacy (JessLacy) 09:00, 25 October 2011 (MDT)

The Atom Link Element

The goal of DCP-3 is to provide a standardized link definition for relationships between casts and a definition for a cast's relationships to other resources. Each of these link types can be addressed separately.

Links to form relationships between Casts

There are four cast types defined: Data, Service, Collection, and Event. Each type serves a unique purpose and requires specific extensions to the base ESIP Atom Response. Linking casts forms a relationship that answers questions like: "Which services are available for this data?" and "Which collections are related to this data?" and "What data is available for this event?"

An Atom link only requires an href. And, since the relationship between casts is between Atom entries, the value of the href must be the entry id, which "identifies the entry using a universally unique and permanent URI,",

The Atom spec very clearly states in the "Extending Atom" section that any fully qualified URI can be used as the value for the "rel" attribute and that . So, the original approach of using an ESIP defined "rel" attribute makes sense. However, the only necessary "rel" values are:

Link type	Description
http://esipfed.org/ns/discovery/3.0/cast/data#	Micro-articles of actual data.
http://esipfed.org/ns/discovery/3.0/cast/collection#	Micro-articles about collections of data.
http://esipfed.org/ns/discovery/3.0/cast/service#	Micro-articles of service definitions.
http://esipfed.org/ns/discovery/3.0/cast/event#	Micro-articles of natural phenomenon.

This approach clearly delineates types of casts with minimal extension to the Atom specification.

Links to external resources

The IANA rel values are very appropriate for external resources. The DCP-3 "esip:subrel" is not necessary in that context. For example, inside a data cast, a rel value of "enclosure" is well understood to refer to the data itself. The Cast (Atom entry) itself informs an agent about its type (Data, Service, etc.) and repeating that information in the subrel obfuscates the intent of the link.

The esip:serviceProtocol extension is a necessary "evil" to work around non-RESTful and non-describing web services. The value could be changed to "esip:protocol" to cause less confusion.

It is important to note that rel, esip:protocol, and type are optional. The use of the values within ESIP Atom Responses is by convention.

References: Atom link element description Atom extensibility

Machine actionable links in web documents -- Steve.richard 21:36, 12 December 2011 (MST)

From e-mail to discovery list 9 and 10/2011

I spent some time researching this issue in the context of some other projects I've been following or involved in (OWS context Standards Working Group, energy industry ISO19115 metadata profile, and USGS CGI Web Application Integration Framework group). I would like to see this considered in a larger context to come up with a solution that can be used in these various contexts, because it's essentially the same problem. Here' s the gist of the proposal outlined in a more complete discussion in this doc http://lab.usgin.org/sites/default/files/group/file/u4/MachineActionableLinksSummary20111212.pdf:

href -- the link URL

type -- MIME type of response. Specifies encoding and optionally the native software application environment. We're sort of stuck with this because of existing usage. One big question is how much of serviceType, puprpose, and outputScheme it makes sense to conflate in the MIME type. I favor keeping the MIME type limited to low-level file formatting--to answer the question 'what software can read this file in a useful way' Understanding the content and intention of a document or the interface to a service should be specified by separate properties.

rel -- URI from IANA rel vocabulary for consistency with IETF5988. This one is already embedded and is used in a WIDE variety of ways - 69 values from existing specs or proposals (IANA, ESIP, ISO, RDFa, DataCite, DCT) are in Table 4 in the word doc; after AGU last week I could probably add 20 or 30 more. My opinion is that at this point this attribute is not very useful for interoperability except for the very general values suggested in the original Atom (RFC-4287) or WebLinking (RFC 5988) specs.

title -- free text to label link in GUI

protocol -- ftp, http, other. Default is http if attribute not specified (ietf registry at http://www.rfc-editor.org/rfcxx00.html). Equivalent to property in 19115 CI_OnlineResource/protocol. Because RPC-3986 mandates that “each URI begins with a scheme name”, this is probably unnecessary. Explicit inclusion might make some filter queries simpler ("link/@protocol='doi'" instead of "link/href like 'doi:*'").

serviceType -- URI that identifies a service protocol and version (one attribute or two?). ISO19119 property, needs registry of URIs for service specifications that is community agrees to use.

purpose -- analogous to ISO19115 CI_OnlineResource//function, specified by CI_OnlineFunctionCode (but need a better vocabulary, see attached doc)

outputscheme -- profile for content of message retrieved by href URL; may be WFS feature name, URI for xml schema or JSON scheme, other description of data structure and content? Need conventions, clear definition.

The word doc referenced in the text is a concept development document, and can be obtained at http://lab.usgin.org/groups/metadata-interest-group/actionablelinks. The first three sections could be the basis for a DCP-3 to supersede DCP-2 (and incorporate DCP-1). The rest is supplemental information and background. --Steve.richard 21:36, 12 December 2011 (MST)

Reconcile with DCP-3

subrel and serviceProtocol in the 2011-10-11 DCP proposal could be considered analogous to the purpose and serviceType attributes proposed here. Its not too important what they are called, just that the semantics are clearly enough explained and a registry is available and accessible to promote use of the same URIs. OutputScheme is still not accounted for in the DCP-3 proposal. Steve.richard 17:11, 15 December 2011 (MST)

Consideration of the example links encoded below indicates that for WMS, ESRI MapService, and WFS services that offer multiple layers or featuretypes, the outputScheme URI should uniquely identify the layer or featureType. Layers and featureTypes typically have a name scoped to the service. Featuretypes will have some kind of information schema, but that may be defined in the context of a namespace that defines a variety of feature types (e.g. GeoSciML). FeatureType URI's might be defined with hash tags on the xml namespace URI (http://xmlns.geosciml.org/GeologicStructure/3.0#ShearDisplacementStructure), or a registry defining feature types (versioned...) wouldneed to be accessible (e.g. https://www.seegrid.csiro.au/wiki/CGIModel/CGIGeoSciMLRegister).--Steve.richard 09:12, 16 December 2011 (MST)

Example Atom entry links for a dataset with a variety of information and distribution links

Just the links included here. These would be in the atom entry section for an entry describing a Borehole temperature dataset for the state of Arizona. All of the links should be live--this is real data.

--Steve.richard 17:19, 15 December 2011 (MST)