PubDIDs (and DIDs in general, maybe)

[Markus Demleitner]

Dear List,

On Tue, Jan 14, 2014 at 09:23:27AM -0800, Patrick Dowler wrote:
> >[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...

Yeah, the "what's at the end of the reference" thing is the real hard
part here, mainly because there's many "wouldn't it be nice" things
here.  I still believe that once we agree what we want, it should be
possible to give the Good Advice in 1 .. 2 sentences.

Here's some nice-to-haves that came across my mind at one time or
another:

(a) you have PubDIDs *and* CreatorDIDs in SSAP and presuambly other
S*AP services in the future.  It'd be nice if these services would
work as their own "resolvers", as that would just require another
parameter (or, ouch, maybe REQUEST value if you insist).  This is
fairly trivial and keeps simple servers in business.

(b) for SSAP, a simple ID parameter may not be enough if we want to
allow feeding creatorDID.  And feeding in creatorDID might have a
strong use case as it should be more stable than publisherDID if and
when creators actually start assigning those -- find that lost
dataset in archival obscore services!  archive.org of the VO!

(c) Datalink is an obvious candidate for a DID->dataset resolving
service, too.  It seems there's going to be a datalink capability
ready to be dumped into registry records, so that'd be fairly easy to
include whatever the IVORN points to.  But then, datalink has more
requirements than just an endpoint dumping data on receiving an ID,
raising implementation requirements fairly significantly.  Can't we
get around that?

(d) Obscore services may be collecting data from quite a few
subordinate resources.  For these, it's imperative that the DIDs
themselves contain enough information to locate their resolution
service(s).  There's no way obscore services could sensibly provide
that information "out of band" (band=identifier) with the current
obscore schema.

(e) While DID->dataset is nice, there's also something to be said for
DID->datalink (i.e., a description of associated data and access
modes).  If we can figure that out how to allow (specifying) both,
more power to us.


Unfortunately, all this doesn't for me lead to an obvious solution.
One thing is clear: The DID must resolve to something in a VO
registry, as that's what the Identifiers REC says.

Also, we probably cannot *require* such services for SSAP, Obscore,
or whatever in the Datalink spec (and probably should not anywhere
else, except maybe in Identifiers), so the best we can do is give
Good Advice and build things in a way that lets clients figure out
(easily) whether or not a service wisely accepted our Good Adivce.


Given that, I see two possibilities:

(1) the resource referenced should have one or more DID-resolving
capabilities

(2) the resource referenced should have one (or more?) "DIDResolver"
relations.

Option (1) currently is a bit awkward as DataCollection resource
records do not admit capabilities in the current VOResource schema.
That's unfortunate in many respects, so there's talk of changing that
anyway.  But changing VOResource schemata is hard work.

On the other hand, going through relations is always a bit ugly, so
it might still be worth it.

In option (2), we'd also have to say what kind of service should be
on the other end.  Is it enough to say "use ID=?" and see what you
get back (could be data, could be datalink)?  Do we want special
rules if there's DAL services at the other end?

As to "how would that work", a client would do a request like

SELECT a.ivoid, access_url FROM rr.interface AS a
  JOIN rr.relationship AS b ON (a.ivoid=b.related_id)
WHERE relationship_type='DIDResolver'

to a relational registry (with all details as to what services it
would want left out).

As I said, I'd really like a brainstorming session on this ASAP
(either telecon or, more likely, in Madrid; this shouldn't hold up
Datalink's standards progress as long as we're just talking about
non-normative sidebar content).  I'd be happy to give a 5 minute
intro talk on this based on what I've written here, and I'd gladly
include further use cases if you have them.

Cheers,

            Markus