<div dir="ltr">
Hi Markus, Grid,<br><br>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.<br><br>There are two general forms of identifiers in the document:<br><br>1. ivo://<a href="http://ivoa.net/std/VOSpace/v">ivoa.net/std/VOSpace/v</a><version><br><br>and<br><br> 2. ivo://<a href="http://ivoa.net/vospace/core#">ivoa.net/vospace/core#</a><thing><br><br>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:<br><br>2.0 synctrans: ivo://<a href="http://ivoa.net/std/VOSpace/v2.0#/synctrans">ivoa.net/std/VOSpace/v2.0#/synctrans</a><br>2.1 synctrans: ivo://<a href="http://ivoa.net/std/VOSpace?synctrans-2.1">ivoa.net/std/VOSpace?synctrans-2.1</a><br><br>The 2.1 format is different as we're moving towards the recommendations of VO Identifiers 2.0.<br><br>So, can the standardID of VOSpace now be ivo://<a href="http://ivoa.net/std/VOSpace">ivoa.net/std/VOSpace</a>? 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.<br><br>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.<br><br>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:<br><br> - ivo://<a href="http://ivoa.net/vospace/core#vospace-1.0">ivoa.net/vospace/core#vospace-1.0</a> SHALL be used as the capability URI for a VOSpace 1.0 service<br> - ivo://<a href="http://ivoa.net/vospace/core#vospace-1.1">ivoa.net/vospace/core#vospace-1.1</a> SHALL be used as the capability URI for a VOSpace 1.1 service<br> - ivo://<a href="http://ivoa.net/vospace/core#vospace-2.0">ivoa.net/vospace/core#vospace-2.0</a> SHALL be used as the capability URI for a VOSpace 2.0 service<br> - ivo://<a href="http://ivoa.net/vospace/core#vospace-2.1">ivoa.net/vospace/core#vospace-2.1</a> SHALL be used as the capability URI for a VOSpace 2.1 service<br><br>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?<div><br></div><div>More comments below...<br><div><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 12, 2017 at 1:39 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:</div><div class="gmail_quote"><br></div><div class="gmail_quote">[...]<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
First, the identifier of the standards record should really be<br>
ivo://<a href="http://ivoa.net/std/VOSpace" rel="noreferrer" target="_blank">ivoa.net/std/VOSpace</a>, without any version, let alone a minor<br>
one (that's point (2) in the RWG comments); I don't think there's a<br>
compatibility problem here, or am I missing something?<br></blockquote><div><br></div><div>Raised again above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Then, there's two other registry records referenced that didn't exist<br>
so far, ivo://<a href="http://ivoa.net/vospace/core" rel="noreferrer" target="_blank">ivoa.net/vospace/core</a> and ivo://<a href="http://ivoa.net/vospace/v2.0" rel="noreferrer" target="_blank">ivoa.net/vospace/v2.0</a>.<br>
I have to admit I didn't try to actually figure out the separation of<br>
concerns between the two; I've still added suggestions for the<br>
records here to the Volute repository, and it'd be great if you could<br>
review those, in particular with respect to completeness of the terms<br>
and sensibility of the resource descriptions (that's RWG comment (3),<br>
mainly).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What really needs to be resolved (or at least explained better) is<br>
the relationship between the capability URIs in<br>
ivo://<a href="http://ivoa.net/std/VOSpace/core" rel="noreferrer" target="_blank">ivoa.net/std/VOSpace/<wbr>core</a> (sect. 3.3.5) and those in<br>
ivo://<a href="http://ivoa.net/std/VOSpace/v2.0" rel="noreferrer" target="_blank">ivoa.net/std/VOSpace/v2.<wbr>0</a> (sect. 4; that's RWG comment (10)).<br>
I couldn't understand how they are supposed to work, i.e., how a<br>
client is supposed to discover VOSpace services. Is there a client<br>
that actually does anything in that way?<br></blockquote><div><br></div><div>Raised again above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In the context of these latter terms, there's<br>
ivo://<a href="http://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails" rel="noreferrer" target="_blank">ivoa.net/std/VOSpace/v2.<wbr>0#/transfers/(job-id)/results/<wbr>transferDetails</a><br>
-- which I'd instinctively read as "replace job-id with an actual<br>
job-id", which doesn't make sense as a vocabulary term. If it is not<br>
intended that job-id is replaced, couldn't the term be simplified?<br>
Writing parts of URIs into the fragments (i.e., key names) is a cute<br>
idea, but perhaps it shouldn't be taken too far, and it's ok without<br>
the parenthesis? Is that identifier necessary at all?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Since Brian solicited feedback to Pierre's RFC concern that<br>
<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/VOSpacePublicShare" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/<wbr>bin/view/IVOA/<wbr>VOSpacePublicShare</a> doesn't<br>
follow the the id patterns of the other "standard protocols" in<br>
3.5.3: This is legal by the registry, and I think I even like the<br>
pattern since it allows simple extensibility ("a web server is<br>
enough"). The way I've worked things out (and I admit I've not<br>
really tried to follow VOSpace's logic), these terms are more<br>
vocabulary-like anyway, and I frankly have to say that for<br>
"semi-open" vocabularies (like, e.g., the datalink one), I'd advise<br>
*not* to use StandardRegExt keys but rather Datalink-type<br>
vocabularies. Which then very typically are HTTP URIs.<br><br></blockquote><div>Okay. I also like the openness of this use of protocols. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Going on, I'd really find it nice if there'd be another quick PR;<br>
with this PR, you could perhaps already upload the three registry<br>
records to the RofR (with a new Updated date in them). This would,<br>
in turn, allow a machine to check all the identifiers mentioned in<br>
the document. So much has gone wrong before with in-document<br>
identifiers in other documents, that I'd really like to add an ivoid<br>
checker to ivoatex that will complain if there's something wrong with<br>
ivo URIs in standards. Which, given the sheer number and variety of<br>
identifiers in this document, it would be an ideal use case for.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Brian</div></div></div></div></div></div>