[Esip-discovery] [OWS Context SWG] discussion of link attributes in metadata

Tue Dec 13 00:26:12 EST 2011

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#
<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
<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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20111212/32a7c0ec/attachment-0001.html>