Identifiers in VOSpace

[Brian Major]

 Hi Markus, Grid,

I'll describe my understanding of the various identifiers that are declared
in VOSpace.  It would be beneficial if some of the other authors and
implementors could support or reject these claims.

There are two general forms of identifiers in the document:

1. ivo://ivoa.net/std/VOSpace/v<version>

and

 2.  ivo://ivoa.net/vospace/core#<thing>

The first form is for the standard itself.  Thus far, all versions have had
their own ID with the version number at the end.  However, I think you're
right, Markus--the version number can probably be dropped.  Once a client
discovers a VOSpace service through the registry, the version of the
specific capabilities of the VOSpace service can be determined from the
VOSI capabilities of that service.  For example, synctrans support can be
declared with either (or both) of these identifiers:

2.0 synctrans:  ivo://ivoa.net/std/VOSpace/v2.0#/synctrans
2.1 synctrans:  ivo://ivoa.net/std/VOSpace?synctrans-2.1

The 2.1 format is different as we're moving towards the recommendations of
VO Identifiers 2.0.

So, can the standardID of VOSpace now be ivo://ivoa.net/std/VOSpace?  I
don't believe there are currently any clients that use the VO Registry to
lookup services, so compatibility should be okay.  Let me know if this is
wrong.

The second form is for the internally name-spaced identifiers.  They are
used to identify, node properties, node capabilities, node views, and
transfer protocols.  It is recommended that these also be registered to
inherit the goodness of registry records, but it's not necessary.

It should be made clear that the capabilities described in the document are
different than the capabilities described in VOSI.  They probably should
have been named something else.  Node capabilities indicate the operations
that a particular node can perform in a VOSpace instance.  So, if you have
a node URI in the wild, you can (via the steps in section 2.1) turn it into
a getNode() URL, make the call, and see what operations that node supports
through its list of node capabilities.  However, the capabilities section
of the document also says that these standard Node capabilities also exist:

    - ivo://ivoa.net/vospace/core#vospace-1.0 SHALL be used as the
capability URI for a VOSpace 1.0 service
    - ivo://ivoa.net/vospace/core#vospace-1.1 SHALL be used as the
capability URI for a VOSpace 1.1 service
     - ivo://ivoa.net/vospace/core#vospace-2.0 SHALL be used as the
capability URI for a VOSpace 2.0 service
     - ivo://ivoa.net/vospace/core#vospace-2.1 SHALL be used as the
capability URI for a VOSpace 2.1 service

I don't understand what value these bring.  The version(s) the service
supports can be determined by the VOSI capabilities endpoint, and
presumably these apply to all nodes.  Maybe not?  Would there be use to
having one area of your tree of nodes support an alternate version than the
others?  I don't think so, because to make the getNode() call to find the
node capabilities you are already making use of a certain "nodes" VOSI
capability.  What more could adding a standard version to a particular node
add?

More comments below...

On Mon, Jun 12, 2017 at 1:39 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

[...]
>
>
> 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?
>

Raised again above.


>
> 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).
>

Okay, thanks for creating those.  At a quick glance they look to be roughly
on target, but I'll have to have a closer look and they'll probably have to
be updated to fit the outcomes of this conversation.


>
> 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?
>

Raised again above.


>
> 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?
>

Yes, clients can insert the jobID into (job-id) of that URL and see the
details of the transfer.  Really, it is saying that transfer details can be
found under the UWS result name 'transferDetails', and perhaps that is
enough.


>
> 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.
>
> Okay.  I also like the openness of this use of protocols.

>
> 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.
>

There have been quite a few changes since the beginning of this PR and will
be more to come, so a second PR seems like a good idea.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20170620/0688bec9/attachment.html>