Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
DataLink capability and DataLink registration #13
There is a discussion about the need for DataLink capabilities (section 2.3). Markus is doubtful about this. CADC however is using that for distinguishing http/https endpoints and managing various authentification methods. CADC plans to add this capability to data collections. CDS also could add it to HiPS in a near future. I didn't make any proposal/pull request on that because I'm basically supporting a "keep it" position.
On Fri, Oct 18, 2019 at 07:29:03AM -0700, Bonnarel wrote: There is a discussion about the need for DataLink capabilities (section 2.3). Markus is doubtful about this. CADC however is using that for distinguishing http/https endpoints and managing various authentification methods. CADC plans to add this capability to data collections. CDS also could add it to HiPS in a near future. I didn't make any proposal/pull request on that because I'm basically supporting a "keep it" position.
The reason I'm doubtful about speaking about a VOSI capabilities *endpoint* is that all datalink capability *declarations* I've ever created (except one; see below) set next to "main" capabilities, like TAP or SSAP. The standards governing these "main" capabilities themselves say something about VOSI capabilities, and having apparently conflicting claims on the capabilities endpoint is at least not helpful. I'll add that the more often we say "Have a capabilities capability", the more often we'll have to fix it if and when we change the way VOSI endpoints are to be discovered (which we still can cheaply do as I'm not aware of anyone doing this in the registry). Why not just say "Do what VOSI says as far as VOSI endpoints goes"? That way, we only have one point to fix things in (and client authors have one place to read how it's done).
Beside this there is related registration issue. register a datalink could be useful to attach the links endpoint to non VO services : journals with associated data storage for example.
To explain this in a bit more detail for those who've not followed this closely -- this is the only use case I can see for discovering datalink endpoints (which is only connected to the VOSI capabilities *endpoint* insofar as both use a capabilities *element* with a datalink standardID): Use them to resolve publisher DIDs according to a suggested (if that term isn't already too strong) recipe in IVOA Identifiers 2.0 (http://www.ivoa.net/documents/IVOAIdentifiers/20160523/REC-Identifiers-2.0.html#tth_sEc4.1). My service at http://dc.g-vo.org/ivoidval/q/didresolve/form actually implements that, and you can see in the DALI examples of that service that it does indeed work. As a matter of fact, DaCHS has a global endpoint for dataset retrieval, and if people register that, it gets registered using a datalink capability (see http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/~ for an example). This may all appear as if I'm arguing using Datalink for pubDID resolution a good idea -- I'm not. I think it's cute, but really, people should be using obscore for pubdid resolution, and journals with such needs (and given that datacite DOIs will cost real money soonish, that may again be on the agenda) should run obscore. Anything else is just making thing unnecessarily complex for our implementors. But that doesn't mean we shouldn't define a standardID and that people can't add a datalink capability *element* to some sort of Registry content. We just should keep mum about a VOSI capabilities endpoint and about any requirements or non-requirements for registration.