VOSpace vs WebDAV

[Paul Harrison]

On 2014-05 -15, at 14:49, Norman Gray <norman at astro.gla.ac.uk> wrote:

> 
> Greetings, all.
> 
> Is this question of persistent identifiers going to be discussed in Madrid next week?  I've cc-ed @Alberto, in case this is on the agenda.
> 
> On 2014 May 15, at 13:20, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
>> On Thu, May 15, 2014 at 11:16:49AM +0000, Paul Harrison wrote:
>>> ubiquity of this protocol and the ivo: and vos: just do not have
>>> the client support - if we could reinvent/reinterpret ivo: and vos:
>>> URNs via redirects off a central http://ivoa.net/ service URL  so
>>> that you could use curl to get resources, I think that it would be
>>> a very good thing?
>> 
>> I don't know about vos: yet (though my feeling is that if we can do
>> what we do with VOSpace using WebDAV+conventions, I'd find that
>> nifty), but for ivo: that central redirector (that would in principle
>> be trivial) won't work as there's not nearly a 1:1 relation between
>> ivo: and https?:  
> 
> A possible way out of the conundrum is ARK.
> 
> The Wikipedia page at <https://en.wikipedia.org/wiki/Archival_Resource_Key> is good, but fails, I think, to adequately communicate the simplicity of the idea at the heart of the approach.
> 
> An ARK is something like
> 
>    ark:/12345/my-identifier-for-a-thing
> 
> The /12345 is a centrally-registered identifier for the organisation whose identifier is listed.
> 
> The clever thing is that this is _not_ yet another URI scheme.  It's intended to be dereferenced by being appended to a 'Name Mapping Authority Host' (NMAH), such as:
> 
>    http://ivoa.net/ark-service/ark:/12345/my-identifier-for-a-thing
> 
> This seems pretty obvious, and in retrospect it is, like all the best ideas.  But...
> 
> The point is (1) The NMAH is arbitrarily replaceable, so that
> 
>    http://ivoa.net/ark-service/ark:/12345/my-identifier-for-a-thing
>    http://esa.int/ivoa-inherited-ark-service/ark:/12345/my-identifier-for-a-thing
> 
> are deemed to be equivalent.  In theory, these could also be transferred to some future HTTP replacement.
> 
> Also (2) the ark:/.... can be curated or stored separately from the lookup service (NMAH) it's appended to.
> 
> Also (3) There's a mechanism for indicating immediately how persistent this object is, or is intended/expected to be, though that's of less significance for our context in that we perhaps hope that things will be indefinitely retained.
> 
> Though I think it would be a good idea, in principle, to use 'ark:' identifiers for the IVOA, this sort of trick could be repurposed for an 'ivo:' resolution service.  That way, the IVOA gets the best of both worlds.
> 

This does seem like a simple but good idea - is the “:" in the path part actually strictly allowed by the various RFCs (as our resident standards lawyer)? - I know that you can legally put “;” as "path parameters”, but I thought that : was one of the “top level delimiters”. The only nastiness that I can see is that unfortunately IVORNs have a resource key that looks hierarchical (and must be so interpreted according to the “/" rules for URIs) - it would be cleaner if IVORNS where just ivo://authority/key with no extra hierarchical parts - which actually represents what the “registry data model”  is. It would be then much easier to be sure which parts of the string were definitely part of the IVORN and which might be part of a REST API - see below


On 2014-05 -15, at 13:20, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:

> Hi,
> 
> On Thu, May 15, 2014 at 11:16:49AM +0000, Paul Harrison wrote:
>> ubiquity of this protocol and the ivo: and vos: just do not have
>> the client support - if we could reinvent/reinterpret ivo: and vos:
>> URNs via redirects off a central http://ivoa.net/ service URL  so
>> that you could use curl to get resources, I think that it would be
>> a very good thing?
> 
> I don't know about vos: yet (though my feeling is that if we can do
> what we do with VOSpace using WebDAV+conventions, I'd find that
> nifty), but for ivo: that central redirector (that would in principle
> be trivial) won't work as there's not nearly a 1:1 relation between
> ivo: and https?:  Indeed, in VOResource things work like this:
> 
> A resource (referenced by an ivo URI)
>  has 0..n capabilities, each of which has
>    0..n interfaces, each of which has
>      0..n accessURLs
> 
> (with RegTAP, we're pushing for 1:1 between interfaces and
> accessURLs, but even then we have 1:n^2 between ivo and http).
> 
> So, a simple redirector won't cut it, and frankly I think plain HTTP
> (in the sense of "curl is all you need") just won't do as a Registry
> client protocol, even with accept: and all the other fancy stuff.
> 

I was not originally thinking of a redirector all the way to the end service that is described by the registry resource, but simply just for accessing the resource record itself - then it is only like accessing a HTML web page (which might contain further links). I am not saying that this would the only registry access protocol (you still want to be able to do searches for which RegTAP is ideal), but the ark: idea above would provide a HTTP referable location for the resource record if you already knew the IVORN.

You could then imagine a pretty standard sort of REST API that did then give you parts of the resource

http://ivoa.net/registry/ivo:authority/resourcekey - would return the whole XML resource record.
http://ivoa.net/registry/ivo:authority/resourcekey/capabilities - just returned the capabilities
http://ivoa.net/registry/ivo:authority/resourcekey/capabilities/1  - the first capability
http://ivoa.net/registry/ivo:authority/resourcekey/capabilities/1/interfaces - the interfaces etc.


Paul.