[Esip-preserve] Fwd: Re: [esip-semanticweb] posted initial version of ToolMatch data model

[Curt Tilmes]

FYI -- Semantic Web group also talking about identifiers and how
they get used in interfaces.  These issues are important for
each of us.

If you're not part of that discussion, here's some background
on ToolMatch: http://wiki.esipfed.org/index.php/ToolMatch

Curt

-------- Original Message --------
Subject: 	Re: [esip-semanticweb] posted initial version of ToolMatch
data model
Date: 	Fri, 2 Mar 2012 13:12:10 -0600
From: 	Matt Jones <jones at nceas.ucsb.edu>
To: 	Mattmann, Chris A <chris.a.mattmann at jpl.nasa.gov>
CC: 	esip-semanticweb at rtpnet.org <esip-semanticweb at rtpnet.org>



Hi everyone --

We've thought about these issues of embedding identifiers in URIs for
REST calls in DataONE as well.  In particular, it gets a bit tricky when
an identifier is itself a URI, which you then want to embed inside a
RESTful URI, as the URI reserved characters in the identifier should
technically be escaped to properly represent a URI in another URI.
   We've decided to follow RFC 3986 closely on this point, and have a
writeup of our approach here (see in particular the section on
'Serializing' identifiers):
http://mule1.dataone.org/ArchitectureDocs-current/design/PIDs.html

On Fri, Mar 2, 2012 at 9:42 AM, Mattmann, Chris A (388J)
<chris.a.mattmann at jpl.nasa.gov <mailto:chris.a.mattmann at jpl.nasa.gov>>
wrote:

     In the above scenario, I'd advocate for:

      > http://toolmatch.esipfed.org/findtools/doi/10.1594/PANGAEA.695832
      > 
http://toolmatch.esipfed.org/findtoolsgcmd/dif/GES_DISC_AIRX3STD_V005

     Those are inherently more RESTful, and path parameter based.


We have similarly structured web URIs for DataONE, but we made the
decision to leave URI scheme prefixes intact when embedding URI
identifiers.  So, for example, the doi: prefix would stay as part of the
URI of the identifier, and reserved characters would be escaped.  So I
would use a single collection of resources with each identifier using
its own URI scheme like:

  > http://toolmatch.esipfed.org/findtools/doi:10.1594%2FPANGAEA.695832
<http://toolmatch.esipfed.org/findtools/doi/10.1594/PANGAEA.695832>
  >
http://toolmatch.esipfed.org/findtools/gcmd_dif:GES_DISC_AIRX3STD_V005
<http://toolmatch.esipfed.org/findtoolsgcmd/dif/GES_DISC_AIRX3STD_V005>

Note that the "/" character in the DOI above was escaped so that it gets
properly represented in the string identifier, as opposed to being
interpreted as a path segment in the containing URI.   Alternatively,
maybe Chris is arguing to have each identifier type represented as a
REST collection of resources.  In which case I would argue for:

  > http://toolmatch.esipfed.org/findtools/doi/10.1594%2FPANGAEA.695832
<http://toolmatch.esipfed.org/findtools/doi/10.1594/PANGAEA.695832>
  >
http://toolmatch.esipfed.org/findtools/gcmd_dif/GES_DISC_AIRX3STD_V005
<http://toolmatch.esipfed.org/findtoolsgcmd/dif/GES_DISC_AIRX3STD_V005>

The only difference there is that the URI scheme delimiter (:) has been
replaced with the path separator (/), but I didn't have to some how know
that the underscore in gcmd_dif is supposed to be replaced as in Chris'
proposal.

Matt