<div dir="ltr">Hi Markus,<div><br></div><div>thanks for the comments and for putting this together.</div><div><br></div><div>One of the main use cases for VODML was allowing providers to create custom extensions of standard data models, and to provide such extensions in a standardized format that clients can use or ignore according to their own use cases. I would find it useful for these extensions to be registered as well. It is not clear to me if your proposal implicitly allows this or not. One way to read it is that standard IVOA-RECommended data models MUST be registered, while custom ones CANNOT. Another way to read it is that recommendations MUST be registered, while the others can. If that's the case, though, I think custom data model authors should be explicitly encouraged to publish their models.</div><div><br></div><div>This is relevant for, but not limited to, this use case (Let's call it UC1):</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">* Ascertain that a chosen prefix is not being used by another data model</span></blockquote><div><br></div><div>More generally, how would I search for all registered data models so to ascertain that a prefix has not been taken yet?</div><div><br></div><div> Regarding UC2:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">* Locate the specification for a data model based on either prefix or </span><span style="font-size:12.8px">URI</span></blockquote><div><br></div><div>The current approach is that DMs should be versioned so that backward compatible fixes and updates result in a new minor version, without a change of prefix, while major changes should result in a new major version and a new prefix.</div><div><br></div><div>Matched against your proposal this means that for each version (minor or major) one should create a new URI and add a registry entry, right? There is some ambiguity here, because the proposal talks about data models, but then in the example and in this sentence:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">It does not allow the automatic resolution between prefix and DM URI<br></span><span style="font-size:12.8px">from Registry data when a standard defines multiple data models. </span></blockquote><div><br></div><div>it looks like an entry corresponds to a standard document, which in turn might define multiple DMs. In that case you would have to define multiple prefixes and multiple URIs for the same entry, and the entry would fall short on both the main use cases. To me, unless I am missing something in your proposal, it would seem more natural and useful to have a clear mechanism for mapping URIs to VODML descriptors in a 1-to-1 fashion in the registry. I don't know enough about the registry to formalize this in a concrete proposal, though. The point is that in serializations URIs will need to uniquely identify VODML/XML descriptors, not the documents that describe them.</div><div><br></div><div>Somewhat related to this, we should probably add a URI to the Model type in VODML. A VODML description document should be aware of its URI, analogously to what happens with XML schemata and namespaces. So, the URI should be defined before the REC and included in it. Custom extensions/models should also provide a unique identifier for each model descriptor.</div><div><br></div><div>To summarize, in my opinion we need to make sure that:</div><div> * models are searchable in the registry, so that UC1 is fulfilled.</div><div> * URIs can be resolved to the VODML/XML descriptors, possibly for all versions and certainly for all major versions, so that UC2 is fulfilled, given the current agreement on prefixes and versions.</div><div> * it should be possible to register custom models and extensions.</div><div> * we need URIs to be part of the descriptors, by adding an identifier field to the Model type.</div><div><br></div><div>I claim some significant ignorance when it comes to the registry standards. As far as I can tell you can probably do all of the above without requiring a custom extension. The question to me is more whether it's more convenient to introduce a simple extension rather than relying on the standard Resource and patch a solution together, e.g, to reduce potential clutter in the registry. One might try and decouple the registration from the VODML standard per se, but I believe the way URIs are defined could depend on the selected approach (e.g. a possible approach, not necessarily one I would advocate for, might be to to assign a unique URI and registry entry to a major version of a DM, while minor versions might be identified by fragments inside that document...).</div><div><br></div><div>Hope this helps and makes some sense,</div><div><br></div><div>Omar.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 20, 2017 at 7:50 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.<wbr>de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear DM and Registry,<br>
<br>
With VO-DML we need some infrastructure to register DMs (and in<br>
particular their prefixes/short names). After a short exchange with<br>
Gerard in response to the my (disguised as the Registry chair)<br>
RFC comment, here's a proposal for how we could do that, covering the<br>
two use cases I could find (and that are easily solved using registry<br>
tools). This is designed to replace sect. 5.1 in the September PR:<br>
<br>
-----------------------8<-----<wbr>-------------------------<br>
5.1 IVOA-standardized data models<br>
<br>
A data model specified in VO-DML can be endorsed by the IVOA to become a<br>
standard data model. A standard data model consists of at least three<br>
artifacts:<br>
<br>
* A standard text adopted by the IVOA according to the rules laid down<br>
in DocStd \citep{2010ivoa.spec.0413H}. This must at least discuss<br>
use cases and the general design of the model. The level of detail to<br>
which individual data model items are discussed in the standard text<br>
is up to the authors. The authoritative source on these details<br>
always is the VO-DML source.<br>
* The data model itself, written in VO-DML.<br>
* A detailed documentation in HTML format containing human-readable<br>
definitions for all elements of the data model, formatted in HTML and<br>
furnished with HTML-accessible anchors (a/@name or @id attributes) for<br>
the vodeml-refs contained in the data model. The intent is that the<br>
data model URL with an element's vodml-id as a fragment identifier<br>
will lead to element-specific documentation. It is recommended to<br>
generate this HTML document from the VO-DML using the vo-dml2html.xsl<br>
script available from the IVOA document repository.<br>
<br>
When a standard data model reaches the status of Proposed Recommendation,<br>
the VO-DML document and the HTML are made available in the IVOA document<br>
repository at their final URLs. They may, however, be modified there<br>
without further notice until the document reaches REC status.<br>
<br>
At the same time, a StandardsRegExt \citep{2012ivoa.spec.0508H} document<br>
for the standard is uploaded to (or, for updated models, updated in) in<br>
the Registry.<br>
<br>
In addition to the usual StandardsRegExt metadata, registry records for<br>
standard data models define namespaces and prefixes for all data models<br>
defined by the standard in StandardKey elements. For this purpose, this<br>
standard defines two key names:<br>
<br>
* vodml-prefix -- the description child of the key contains a prefix<br>
defined by the model.<br>
* vodml-dmuri -- the description child of the key contains a data model<br>
URI defined by the model.<br>
<br>
Note that this allows Registry clients to support use cases like:<br>
<br>
* Locate the specification for a data model based on either prefix or<br>
URI<br>
* Ascertain that a chosen prefix is not being used by another data model<br>
<br>
It does not allow the automatic resolution between prefix and DM URI<br>
from Registry data when a standard defines multiple data models. That<br>
use case does not appear significant enough to warrant an extension of<br>
the existing registry infrastructure.<br>
<br>
A sample record for the present standard (which does not necessarily<br>
match what the Registry actually contains at any point) is given in<br>
appendix X.<br>
------------------8<----------<wbr>----------------------<br>
<br>
And the draft standard record (the DM URI for IVOA needs to be fixed, I<br>
guess) that would go into appendix X is at<br>
<br>
<a href="http://volute.g-vo.org/svn/trunk/projects/registry/StandardsRegExt/samples/VODML.xml" rel="noreferrer" target="_blank">http://volute.g-vo.org/svn/tru<wbr>nk/projects/registry/Standards<wbr>RegExt/samples/VODML.xml</a><br>
<br>
(and can be fixed there, too).<br>
<br>
Thoughts? Opinions? In particular: If there are use cases we need<br>
to cover that this doesn't solve, I'm not at all against defining a<br>
quick registry extension -- but if you think we might need that,<br>
please speak up now when we could still draft that without holding up<br>
proceedings.<br>
<br>
It would also be great if we could try the procedure for what should<br>
happen at PR when the next PR for VO-DML is published (including the<br>
ivoa DM). I suspect we'll discover an issue or two if we do, and<br>
it'd be cool if that happened while the document still is in PR.<br>
<span class="m_4569548251017827HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_4569548251017827gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div></div>
</div></div>