[Esip-discovery] [OWS Context SWG] discussion of link attributes in metadata
Lynnes, Christopher S. (GSFC-6102)
christopher.s.lynnes at nasa.gov
Tue Dec 13 08:20:48 EST 2011
To followup on Steve's comments and give you a heads-up before our telecon today, I wanted to mention that our latest change proposal (http://wiki.esipfed.org/index.php/Discovery_Change_Proposal-3) actually rolls back the special rel attributes to the standard enclosure/icon/etc., but adds ESIP-specific attributes to the link elements to specify more exactly what kind of enclosure. Thus, this should be backward compatible with the mass-market tools, but give our applications more information on what kind of enclosure link it is.
The most obvious case where this is necessary is when data providers (like mine) offer data both as an FTP download and through OPeNDAP (coming your way in OGC soon I understand!). We also offer downloads in netCDF and ASCII through OPeNDAP as well, so that ultimately, we would like to offer 4 "enclosure" links for the same data file.
For example, the following 5 URLs are valid links for a granule:
ftp://acdisc.gsfc.nasa.gov/data/s4pa/Aqua_AIRS_Level3/AIRX3STD.005/2011/AIRS.2011.12.11.L3.RetStd001.v5.2.2.0.G11346145836.hdf
http://acdisc.gsfc.nasa.gov/opendap/Aqua_AIRS_Level3/AIRX3STD.005/2011/AIRS.2011.12.11.L3.RetStd001.v5.2.2.0.G11346145836.hdf
http://acdisc.gsfc.nasa.gov/opendap/Aqua_AIRS_Level3/AIRX3STD.005/2011/AIRS.2011.12.11.L3.RetStd001.v5.2.2.0.G11346145836.hdf.nc
http://acdisc.gsfc.nasa.gov/opendap/Aqua_AIRS_Level3/AIRX3STD.005/2011/AIRS.2011.12.11.L3.RetStd001.v5.2.2.0.G11346145836.hdf.ascii
According to our currently pending DCP-3, this would amount to:
rel esip:subrel esip:serviceProtocol mime-type
enclosure http://esipfed.org/ns/discovery/1.1/data# (n/a) application/x-hdf
enclosure http://esipfed.org/ns/discovery/1.1/data# http://xml.opendap.org/ns/DAP/3.3# application/octet-stream
enclosure http://esipfed.org/ns/discovery/1.1/data# http://xml.opendap.org/ns/DAP/3.3# application/x-netcdf
enclosure http://esipfed.org/ns/discovery/1.1/data# http://xml.opendap.org/ns/DAP/3.3# text/plain
On Dec 13, 2011, at 12:26 AM, Stephen M Richard wrote:
> Pedro—
> It’s taken awhile to get back to this! Thanks for your thoughtful reply. To recap, the conversation has to do with what properties need to be associated with links (typically http URIs) between resources that are meant to be used by software with minimal user interaction. Use cases emerge in metadata documents, atom or rss feeds, OWS context / workspace portability and linked data contexts. I compiled approaches to this problem in a variety of contexts and summarized results in a doc available at http://lab.usgin.org/groups/metadata-interest-group/actionablelinks.
>
> You suggest that rel and type (MIME type) are sufficient to meet requirements “to assure a broad usage of the resulting files”. I think use of rel=search to denote that the link target is an OpenSearch end point is symptomatic of why the rel attribute is already so overloaded with non-interoperable usages that a more semantically clear ‘purpose’ attribute is called for. OpenSearch is certainly not the only possible target of a link to a search interface (what about CSW, for example?).
>
> I know people are creating MIME types like “application/opensearchdescription+xml”, but I’d argue that this is overloading the intention of MIME, and we have a situation similar to the ‘rel’ attribute for the ‘type’ attribute. The semantics are fuzzy and there are all kinds of interpretations and usages of the property already in use, making interoperability more difficult. Shouldn’t the MIME type specify the format of the file that the link will GET? (e.g. XML, maybe XML+atom or GML or RSS…).
>
> Let’s say you’ve got an app parsing a list of links, needing a CSW that supports the INSPIRE ISO profile. What’s the rel value (wouldn’t ‘search’ make sense?), does using MIME types like ‘application/xml+csw2.0.2+inspire1.0 scale’? What about an entry about a geologic map data set with links for representations as a shapefile, pdf, tiff, a WMS (lithostratigraphic units, lithology, or stratigraphic age styles, from different servers), WFS 2.0 (GeoSciML v3 MappedFeature), WFS 1.0 (GeoSciML v2 MappedFeature), WFS (GeoSciML-Portrayal GeologicUnitView), WFS (NCGMP09 MapUnitPoly)? One could probably account for all of these cases with content negotiation and by requiring clients to access and parse a service description document (e.g. GetCapabilities), but wouldn’t life be a heck of a lot simpler if there were labeled links with attributes that allowed the client to know these options directly from the feed, context doc, or metadata doc?
>
> steve
>
> Stephen M. Richard
> Arizona Geological Survey
> 416 W. Congress St., #100
> Tucson, Arizona, 85701 USA
> phone: 520 209-4127
> AZGS Main: (520) 770-3500. FAX: (520) 770-3505
> email: steve.richard at azgs.az.gov
>
> From: Pedro Gonçalves [mailto:pedro.goncalves at terradue.com]
> Sent: Wednesday, September 07, 2011 2:32 AM
> To: Stephen Richard
> Cc: owscontext.swg at lists.opengeospatial.org
> Subject: Re: [OWS Context SWG] discussion of link attributes in metadata
>
> Hi Stephen
>
> Many thanks for your inputs and document
> I think that we in the OWS Context SWG and also on the OpenSearch interface for CSW are following the same data link path that you describe in your document
> In the OWS Context wiki you'll find information on how we are considering the use of atom links to express relations to resource and to enable the direct navigation between resources
>
> I was already familiar with the ESIP work and the main difference I see on this SWG is the desire to assure a broad usage of the resulting files. For example ESIP defines a new relation (@rel) to express a data product file (e.g. http://esipfed.org/ns/discovery/1.1/data# ) when in fact a rel="enclosure" already exists and it's used on the "mass market" world (e.g. browsers, email clients)
> By defining this new relation values, ESIP might be closing the scope and adoption potential.
>
> This said, I'm not against registering new relation values when we see that none is available.
> In this case the IANA process is quite straightforward. For those situations I think that we should create new relations instead of defining a new esip:serviceType and esip:purpose attribubtes to the atom:link element.
>
> For the other two new attributes proposed for the atom:link (esip:protocol and esip:outputscheme) I think that they are already covered by the current href and type attributes
>
> For example, your document you describe a link to an opensearch description document as:
> {{
> rel="search" esip:purpose="...search#" esip:ServiceType="OpenSearch" type=’application/xml+atom outputScheme=’http://esip.org/ESIPdiscovery’href="..."
> }}
>
> but in fact the information carried by servicetype and outputscheme are redundant and not correct.
>
> according to its definition a link with the "search" relation points to an opensearch description document that is identified by its mime-type application/opensearchdescription+xml and not application/xml+atom
> something like this
>
> {{
> rel="search" type="application/opensearchdescription+xm" href="..."
> }}
>
> so the information defined on esip:purpose it's already included on the rel="search" attribute and the information of the esip:ServiceType is already available on the mime-type. The information of the outputscheme is available on the opensearch description document that informs the client which are the url templates available
>
> So I think we should check if is really necessary to define/introduce new foreign elements that duplicate the function of the atom:link and IANA relations that already support this.
>
> On the wiki, you'll find a discussion page (resulting from a telco back in jan/feb) where we list the IANA registered relations that we found out useful. The list is not normative :) so we can include and discuss it through, add/remove values ... etc. ... so we need to continue this discussion
>
>
> thanks and best regards
>
> Pedro
>
> Pedro Pereira Goncalves
> http://www.terradue.com
>
>
>
>
> On Sep 6, 2011, at 10:06 PM, Stephen Richard wrote:
>
>
> A context document is in many ways equivalent to an ATOM feed describing a collection of resources that are web accessible, and in that sense very much like a collection of metadata records returned from a catalog as the result of a catalog search (e.g. CSW). Links to described resources in in these metadata collections need to be actionable by client software to access the resources and make them available in the user’s workspace. This problem overlaps a number of related activities 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, ESIP-Discovery discussions). 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.
>
> I think there are 4 important facets. Here' s the gist of the proposal:
>
> href the link URL
> type MIME type of response. Specifies encoding and optionally the native
> software application environment
> rel URI from IANA rel vocabulary for consistency with IETF5988
> title free text to label link in GUI
> esip:protocol ftp, http, other. Default is http if attribute not specified
> (ietf registry at http://www.rfc-editor.org/rfcxx00.html). Equivalent to protocol
> property in 19115 CI_OnlineResource
> esip:serviceType URI that identifies a service protocol and version
> (one attribute or two?). ISO19119 property, needs registry of 'standard' URIs.
> esip:purpose analogous to ISO19115 function, specified by
> CI_OnlineFunctionCode
> esip:outputscheme profile for content of message retrieve 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 attached word doc is a concept development document for discussion.
>
> Stephen M. Richard
> CIO, Chief, Geoinformatics Section
> Arizona Geological Survey
> 416 W. Congress St., #100
> Tucson, Arizona, 85701 USA
> phone: 520 209-4127
> AZGS Main: (520) 770-3500. FAX: (520) 770-3505
> email: steve.richard at azgs.az.gov
>
> <MachineActionableWebLinking.docx>_______________________________________________
> OWScontext.SWG mailing list
> OWScontext.SWG at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/owscontext.swg
>
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
Christopher Lynnes
Goddard Earth Sciences Data and Information Center, NASA/GSFC
301-614-5185
More information about the Esip-discovery
mailing list