<div dir="ltr">Hi Markus,<div><br></div><div>Sorry for coming late to the discussion, but I have some concerns about section 4.1 of the specification (Dataset Identifiers).  What troubles me is the resolution of these identifiers, and the fact that the spec itself states that &quot;This specification does not exhaustively define the resolution of publisher DIDs. Instead, we recommend the following procedure...&quot; .  Here is why I think this is a problem:</div><div><br></div><div>- the spec seems to suggests that resolving these is more a matter of heuristics than anything else, so different implementors may chose to tweak the logic in ways that are not totally consistent</div><div>- even if the recipe were prescriptive, an addition of a new capability (e.g. Datalink in addition to SSA) could potentially change the way a particular DID is resolved, thus yielding a different result at a later time</div><div>- there is no hint of what would be returned when a client tries to resolve one of these DIDs, which I think is a problem for any application which wants to do something with them</div><div><br></div><div>Ultimately I am still confused as to the role and usefulness of these DIDs: they are not persistent, are difficult to resolve (it seems), and there is no infrastructure for returning standard metadata about the resource that they point to (is this correct?).  Which makes me wonder why one would not want to use DIDs rather than plain http URIs for retrieval or more durable identifiers if persistence and metadata registration is required.</div><div><br></div><div>It&#39;s possible that my confusion comes from a lack of understanding of Datalink and the other referenced protocols, so if I am misinterpreting things please bear with me.</div><div><br></div><div>Thank you as usual for your effort on an otherwise well-written spec.</div><div><br></div><div>-- Alberto</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 9:32 AM, Markus Demleitner <span dir="ltr">&lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Registry,<br>
<br>
Again on Identifiers 2.0 -- this one:<br>
<span class=""><br>
On Thu, Sep 24, 2015 at 03:37:31PM +0200, Markus Demleitner wrote:<br>
&gt; or just download the whole built document from<br>
&gt; <a href="http://docs.g-vo.org/Identifiers.pdf" rel="noreferrer" target="_blank">http://docs.g-vo.org/Identifiers.pdf</a> (for a while).<br>
&gt;<br>
</span>[...]<br>
<span class="">&gt; Given this is a fairly serious change, I&#39;d like to give everyone<br>
&gt; interested another opportunity to re-read things.  I would, however,<br>
&gt; like to go to TCG review some time between now and Oct 10th or so.<br>
&gt; If you forsee you can&#39;t make it till then please let me know.<br>
<br>
</span>I&#39;ve not also implemented a PubDID resolver working as outlined in<br>
the spec (except it&#39;s only half-greedy: it will not stop at the first<br>
match, although it won&#39;t hit the served-by services if it&#39;s<br>
successful on the primary referenced service) at<br>
<br>
<a href="http://dc.g-vo.org/ivoidval/q/didresolve/form" rel="noreferrer" target="_blank">http://dc.g-vo.org/ivoidval/q/didresolve/form</a><br>
<br>
This assumes new-style ivoids -- if you already have some of those,<br>
please give this a whack.<br>
<br>
With this, I&#39;d consider Identifiers 2.0 ready for TCG review.<br>
Objections?<br>
<br>
Cheers,<br>
<br>
         Markus<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Dr. Alberto Accomazzi<br>Program Manager<br>NASA Astrophysics Data System - <a href="http://ads.harvard.edu" target="_blank">http://ads.harvard.edu</a><br>Harvard-Smithsonian Center for Astrophysics - <a href="http://www.cfa.harvard.edu" target="_blank">http://www.cfa.harvard.edu</a><br>60 Garden St, MS 83, Cambridge, MA 02138, USA</div>
</div>