[Esip-discovery] Fwd: [OWS Context SWG] discussion of link attributes in metadata
Lynnes, Christopher S. (GSFC-6102)
christopher.s.lynnes at nasa.gov
Tue Dec 13 11:29:05 EST 2011
>From Pedro:
Begin forwarded message:
> From: Pedro Gonçalves <pedro.goncalves at terradue.com>
> Date: December 13, 2011 11:14:16 AM EST
> To: "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov>
> Cc: "esip-discovery at lists.esipfed.org" <esip-discovery at lists.esipfed.org>, Stephen M Richard <steve.richard at azgs.az.gov>
> Subject: Re: [Esip-discovery] [OWS Context SWG] discussion of link attributes in metadata
>
> Thanks Christopher
>
>
> On Dec 13, 2011, at 2:20 PM, Lynnes, Christopher S. (GSFC-6102) wrote:
>
>> 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.
>
>
> This is already a big step in keeping the compatibility with browsers and market tools
> and the table is a very good starting point for our discussion today ...
>
> I wrote a few quick notes to organize my questions and comments (tbd today )
>
>
> #1 Collections
>
> rel = related
> subrel = http://esipfed.org/ns/discovery/1.1/collections#
> serviceProtocol = http://a9.com/-/spec/opensearch/1.1/
> type = application/atom+xml
> Purpose = Point to a list of served collections from an scast entry (sic)
>
> - is this a list of collections that related to the collection we are seeing or this is the list of collections available in some server ?
> - Could this be represented by the @rel "index" ?
> In that case we just need the mime-type
>
>
> #2 - Services
> rel = related
> subrel = http://esipfed.org/ns/discovery/1.1/services#
> serviceProtocol = http://a9.com/-/spec/opensearch/1.1/
> type = application/atom+xml
> Purpose = Point to list of available services from a collection cast entry
>
> - I suppose that this is a list of services for each collections ... or all of them ?
>
> #3 - Data Access
> rel = enclosure
> subrel = http://esipfed.org/ns/discovery/1.1/data#
> service protocol = n/a
> type = (format of data files)
> Purpose = Point to direct download location (FTP or HTTP) of a data granule (e.g., file)
>
> - Agree, but why do we need the subrel? aren't all links with the @rel=enclosure meaning that represent a resource bigger than the atom:entry ?
>
>
>
> #4 - Data Access
> rel = enclosure
> subrel = http://esipfed.org/ns/discovery/1.1/data#
> service protocol = http://xml.opendap.org/ns/DAP/3.3#
> type = application/x-netcdf (netCDF), text/html (HTML Form), text/plain (ASCII download), application/octet-stream (DODS)
> Purpose = Point to direct download location (FTP or HTTP) of a data granule (e.g., file)
>
> - To be discussed,
> - I see the opportunity for a new relation, this is in fact a data access service that might have a kinda of getcapabiities (or html form where we see what is possible to perform)
>
> #5 - Icon
> rel = icon
> subrel = http://esipfed.org/ns/discovery/1.1/browse#
> service protocol = OGC-WMS
> type = image/jpg
> Purpose = Point to a browse image for a granules from a datacast entry
>
> - subrel and icon are in fact equivalent ... what is the extra gain ?
> - service protocol can in fact have some utility
>
> #6 - Search
>
> rel = search
> subrel = http://esipfed.org/ns/discovery/1.1/search#
> service protocol = http://a9.com/-/spec/opensearch/1.1/
> type = application/opensearchdescription+xml
> Purpose = Point to a search service from a collection cast entry
>
> - again the same equivalence between rel and subrel
> - also between protocol and type
>
>
> #7 - Data Access
> rel = related
> subrel = http://esipfed.org/ns/discovery/1.1/service#
> service protocol = OGC-WCS
> type = -
> Purpose = Point to WCS service from a collection or data cast entry
>
> - isn't this an enclosure ?
> - same as #3 and #4 ?
>
>
> #8 - Related
> rel = related
> subrel = http://esipfed.org/ns/discovery/1.1/event#
> service protocol = -
> type = app/atom+xml
> Purpose = Point to related event cast from any kind of cast or XML metadata
>
> - what is an event ? is it a equivalent data entry ?
> - It seems that this is an entry in some other collection .. right ?
>
> #9 - Documentation
>
> rel = describedBy
> subrel = http://esipfed.org/ns/discovery/1.1/documentation#
> service protocol = -
> type = text/html, application/pdf
> Purpose = Point to documentation relating to a data or service item (service cast, data cast or dataset)
>
> - Agree, but what is the gain of the subrel to the rel ?
>
>
>> 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
>>
>>
>
--
Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
More information about the Esip-discovery
mailing list