Identifiers in VOSpace

[Markus Demleitner]

Hi Grid,

I've just added both my personal comments and those of the Registry
chair to the VOSpace RFC page; the one thing that I think really
needs working out are the identifiers issues, which is why I take the
liberty of bringing them to the list.


First, the identifier of the standards record should really be
ivo://ivoa.net/std/VOSpace, without any version, let alone a minor
one (that's point (2) in the RWG comments); I don't think there's a
compatibility problem here, or am I missing something?

Then, there's two other registry records referenced that didn't exist
so far, ivo://ivoa.net/vospace/core and ivo://ivoa.net/vospace/v2.0.
I have to admit I didn't try to actually figure out the separation of
concerns between the two; I've still added suggestions for the
records here to the Volute repository, and it'd be great if you could
review those, in particular with respect to completeness of the terms
and sensibility of the resource descriptions (that's RWG comment (3),
mainly).

What really needs to be resolved (or at least explained better) is
the relationship between the capability URIs in
ivo://ivoa.net/std/VOSpace/core (sect. 3.3.5) and those in
ivo://ivoa.net/std/VOSpace/v2.0 (sect. 4; that's RWG comment (10)).
I couldn't understand how they are supposed to work, i.e., how a
client is supposed to discover VOSpace services.  Is there a client
that actually does anything in that way?

In the context of these latter terms, there's
ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails
-- which I'd instinctively read as "replace job-id with an actual
job-id", which doesn't make sense as a vocabulary term.  If it is not
intended that job-id is replaced, couldn't the term be simplified?
Writing parts of URIs into the fragments (i.e., key names) is a cute
idea, but perhaps it shouldn't be taken too far, and it's ok without
the parenthesis?  Is that identifier necessary at all?

Since Brian solicited feedback to Pierre's RFC concern that
http://wiki.ivoa.net/twiki/bin/view/IVOA/VOSpacePublicShare doesn't
follow the the id patterns of the other "standard protocols" in
3.5.3: This is legal by the registry, and I think I even like the
pattern since it allows simple extensibility ("a web server is
enough").  The way I've worked things out (and I admit I've not
really tried to follow VOSpace's logic), these terms are more
vocabulary-like anyway, and I frankly have to say that for
"semi-open" vocabularies (like, e.g., the datalink one), I'd advise
*not* to use StandardRegExt keys but rather Datalink-type
vocabularies.  Which then very typically are HTTP URIs.



Going on, I'd really find it nice if there'd be another quick PR;
with this PR, you could perhaps already upload the three registry
records to the RofR (with a new Updated date in them).  This would,
in turn, allow a machine to check all the identifiers mentioned in
the document. So much has gone wrong before with in-document
identifiers in other documents, that I'd really like to add an ivoid
checker to ivoatex that will complain if there's something wrong with
ivo URIs in standards.  Which, given the sheer number and variety of
identifiers in this document, it would be an ideal use case for.

        -- Markus