PubDIDs (and DIDs in general, maybe)

[Patrick Dowler]

Thanks for brining this up Markus. It has also been in the back of my 
mind that some conventions and advice would be enough to make the pub 
DIDs much more useful.


On fragments: we did that, Norman covinced me it is wrong, we stopped 
doing that :-)

More comments below...

Pat

On 14/01/14 04:54 AM, Markus Demleitner wrote:
> (a) should we have HTTP-URL-like keyword-value pairs after the stop
> char or just the path?
>
> That is, should the new PubDIDs look like
>
>    ivo://dc.g-vo.org?did=gigaAndromedaCube
>
> or do we just dump the path like this:
>
>    ivo://dc.g-vo.org?gigaAndromedaCube
>
> There's something to be said for both options (the second is more
> straightforward and simpler, the first lets us encode other semantics
> in the keyword if we need it) -- opinions?
>
> Even if you don't see a need or can't be bothered to put your opinion
> into words, you could help me by replying to me personally, checking one
> of the following boxes (I'll summarize on-list if I get votes):
>
> [ ] with did=x    [ ] just the local identifier
> [X] should be left to the publisher   [ ] undecided


right-hand side of the separator (?) should be opaque from a user 
point-of-view.
>
> (b) Should there be recommendations or even requirements for the base
> URI?  One thing that has come up now and then is to require that the
> resources they resolve to are datalink services (if we want those in the
> registry at all) or at least should have some relationship to a
> service that allows access to the dataset referred to.
>
> Again, if you'd like do vote:
>
> [X] require relation    [ ] leave open   [ ] forbid
> [ ] undecided

First, I can't vote with enough +s for the idea of being able to parse 
and resolve a pubDID and get somewhere useful. At one point I thought 
the base ivorn should resolve to specific service type with metadata and 
links. Now, I think it should resolve to a DataCollection and that can 
have one or more associated services. It would be  best if at least one 
took a pubDID as an input/query parameter... so DataLink qualifies and I 
don't see why the ID parameter could not be rather standard across many 
services (TBD).

So, while I think it would be best to resolve and it should probably be 
to a DataCollection, I don't see how "require relation" would actually 
work. Would a DAL service that emits pubDIDs be non-compliant if they 
cannot be resolved? Eg. handing out invalid pubDIDs? It is admittedly a 
really minimal effort to comply and any related services would still be 
optional...
>
> (c) Based on my own doubts when I had to come up with various PubDID
> schemes in my resources, I do believe this Good Advice should be made
> explicit in a prominent place.  I believe two paragraphs would do, so
> something like a non-normative sidebar would do just fine.  Probably
> even an appendix would be overdoing it.
>
> The question is: where could that reside?  A natural place would be
> the Identifiers REC, but I don't see anyone taking that up any time
> soon (though I'd argue that removing the XML form of identifiers
> would be a positive move).  An alternative would be datalink close to
> the introduction of the ID parameter, where it could illustrate what
> kind of value there'd typically be in that parameter.  Or, we could
> expand what one of obscore, SSAP, or SIAv2 have to say about their
> DIDs.  For the record, I'd like a sidebar in datalink most (but I
> acknowledge the desire to keep that document short).
>
> So, the options to me look like this:
>
> [ ] Identifiers REC   [X] Datalink   [ ] Next available DAL Spec
> [ ] Obscore  [ ] I want a Note on this   [ ] Oh, just leave it alone


DataLink is about both a specific service resource and more general 
advice about linking services via VOTable metadata; it is already about 
relations and navigating from one service to another so I could see it 
being in scope for DataLink. It would not be out of place as an 
informative section, which gives it more exposure than an appendix.


I'm not crazy about the practice of specifying something in a specific 
DAL protocol and then assuming/inheriting it in other sibling protocols.


-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9A 2L9

250-363-0044 (office) 250-363-0045 (fax)