Identifiers 2.0 Public RFC results

[Accomazzi, Alberto]

Hi Markus,

On Wed, Oct 7, 2015 at 6:04 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

>
> Ok, I've made an attempt at language expressing that in volute rev.
> 3090 (see the diff without checking out using
> svn diff -r3089:3090
> https://volute.g-vo.org/svn/trunk/projects/registry/Identifiers
> )
>
> Here's what it says now:
>
>   Note that by this specification publishers have no obligation to
>   ensure continued access to datasets identified with PubDIDs. They
>   are not persistent identifiers with guarantees on resolvability.
>   Their main function is to provide globally unique identifiers for use
>   in, e.g., federating responses from different services.
>
>   Publishers are, however, encouraged to provide PubDID-resolving
>   services[2] as a capability of the resource referenced by the Registry
>   part of a PubDID. In that way, clients can attempt to resolve
>   standalone PubDIDs by querying the registry for the "embedding"
>   resource and seeing if it supports any PubDID-resolving protocol they
>   understand.
>

To be honest I still don't love the language used here, but recognize that
the reason may be due to my own baggage, so please bear with me.

What I dislike the most in the two paragraphs above is the use of the term
"resolution," which in my mind is the simple process of mapping an
identifier to one or more actionable addresses (typically http URLs).  This
process can be enhanced to provide useful identifier metadata by the
resolver using things such as content negotiation (see e.g.
http://www.crosscite.org/cn/)

If we start calling all or most VO services "resolvers" of pubDIDs then the
meaning of what a resolver does gets diluted to the point that one would
not know what it means.  To me, SSA, Obscore, etc. are services that accept
PubDIDs as optional input and return different kinds of metadata about
them.  So while they may understand what to do with a PubDID, they don't
necessarily resolve it, but rather process it returning content which is in
some service-specific schema.

I know that I sound like I'm nitpicking here, but one hint that there is a
distinction to be made was indirectly provided by Markus with his
implementation of what he called "global pubDID resolver" (
http://dc.g-vo.org/ivoidval/q/didresolve/form), which does most of what I
would think a resolver should be doing, and which is not one of the
services that we are talking about (Datalink, SSA, etc).

Does this matter in the end?  Not sure, but if we want to leave the door
open to having resolving services within the VO interoperate with different
identifiers (including http URIs, DOIs, etc), I think we need to worry
about these things, and consider all possible use cases.  For instance, I
have been contemplating whether the legacy use of the Dataset Identifiers
originally implemented by the NASA Archives (
http://arxiv.org/abs/astro-ph/0611575) can be handled through the VO
infrastructure. Going forward, we may want to reuse resolving services for
DOIs, and hopefully the discussions in Sydney will show how much interest
there is on this topic.  So clarifying what a resolver is is rather
critical.


>
> and the footnote 2 is:
>
>   At the time of this writing, Datalink, Obscore, and SSA are IVOA
>   recommended protocols allowing the resolution of PubDIDs with various
>   mechanisms. SIA (Tody & Plante 2009) will, according to current
>   proposed recommendations, have a PubDID-resolving facility in version
>   2.0
>
> Does that reflect something like a consensus we've reached here?


I think we are getting close, but I would like to get the semantics right,
while also clarifying things in my own head.

Thanks,
-- Alberto



-- 
Dr. Alberto Accomazzi
Program Manager
NASA Astrophysics Data System - http://ads.harvard.edu
Harvard-Smithsonian Center for Astrophysics - http://www.cfa.harvard.edu
60 Garden St, MS 83, Cambridge, MA 02138, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20151007/95707764/attachment.html>