VOSpace vs WebDAV

[Markus Demleitner]

Hi Walter, hi Grid,

Let me briefly pull up this thread from before the Interop again,
lest the questions linger in the archive unanswered:

Followup (if any) to registry, I'd say; this isn't really grid
matter.

On Sun, May 18, 2014 at 09:44:23AM -0700, Walter Landry wrote:
> Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> > 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 must be missing something.  URI's can be hierarchical.  Why can
> there not be a 1:1 match between interface and URI?  We do have to
> make a conscious decision to do it, but I am missing the technical
> issue.

First, a resource records contains much more than just access URLs --
information on who to contact if things go bad, the authors of the
resource itself, subjects, a description, the input parameters, the
table schema, and so on.  All access urls share that kind of
metadata, which means it shouldn't be tied to them, but to something
else.

It would be possible to expose that metatdata somewhere higher up a a
hypothetical URL hierarchy, and with VOSI, a bit of this
(capabilities and table metadata are at standard URLs) has eventually
happened.  But giving people the freedom to have URL schemes of their
liking (or register things like jabber interfaces that don't
naturally map to http URLs) falls out of the registry concept
essentially for free, so I'd suggest prescribing URL schemes at this
point wouldn't be worth the effort.

On that registry concept itself, you quip

> In general, I do not understand why a new central registry is going to
> work any better than the http URL's.  Yes, URL's go bad and require

-- and indeed, why not just use google?  I'd have much to say why we
should not build any of our infrastructures on commercial providers,
least of all when the infrastructure isn't actually defined by a
standard [as a case in point: is it just me or has google indeed
pulled XMPP support from their chat clients just recently?]

But that's beside the actual point here: What we're dealing with in
the Registry are "resources", and generations of librarians have
worked out ways to handle and describe those.  In the registry, we're
basically just building on what they thought up for us.  This is by
no means a "new central registry" -- it's adopting established
standards how to interchange bibliographic information across
discipline boundaries, together with some local conventions and
interfaces that let, e.g., TOPCAT list and query cone searches, SPLAT
query all servers delivering spectra, and Aladin look for images
in a defined region of the sky.

So, URL stabilitiy as in:

> I see a URL like
> 
>   http://example.org/VO/TAP/
> 
> and it stops working, I can eventually figure out that
> 
>   http://example.org/TAP/

is not really what this is about (although the freedom to change URLs
can certainly come in handy).

> They are far more reliable than anything we could hope to build.  For
> example, properly registering our Simple Cone Search is still mired in
> confusion.  In contrast, Google found out about it almost as soon as

It is true is that publishing toolkits should provide better support
for coming up with registry records, even more so since they already
have a good part of the information required to do this properly.
And it is true that even those that have OAI-PMH built in could do
better in asking the right kinds of questions.

But that's a different thing from suggesting google's
bag-of-words-plus-warding-off-spammers approach might be the way to
go forward.

Cheers,

          Markus