VO-DML registration

Fri Jan 20 16:15:51 CET 2017

Hi Markus,

thanks for the comments and for putting this together.

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.

This is relevant for, but not limited to, this use case (Let's call it UC1):

> * Ascertain that a chosen prefix is not being used by another data model

More generally, how would I search for all registered data models so to
ascertain that a prefix has not been taken yet?

 Regarding UC2:

> * Locate the specification for a data model based on either prefix or URI

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.

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:

> It does not allow the automatic resolution between prefix and DM URI
> from Registry data when a standard defines multiple data models.

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.

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.

To summarize, in my opinion we need to make sure that:
  * models are searchable in the registry, so that UC1 is fulfilled.
  * 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.
  * it should be possible to register custom models and extensions.
  * we need URIs to be part of the descriptors, by adding an identifier
field to the Model type.

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

Hope this helps and makes some sense,

Omar.

On Fri, Jan 20, 2017 at 7:50 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DM and Registry,
>
> With VO-DML we need some infrastructure to register DMs (and in
> particular their prefixes/short names).  After a short exchange with
> Gerard in response to the my (disguised as the Registry chair)
> RFC comment, here's a proposal for how we could do that, covering the
> two use cases I could find (and that are easily solved using registry
> tools).  This is designed to replace sect. 5.1 in the September PR:
>
> -----------------------8<------------------------------
> 5.1 IVOA-standardized data models
>
> A data model specified in VO-DML can be endorsed by the IVOA to become a
> standard data model.  A standard data model consists of at least three
> artifacts:
>
> * A standard text adopted by the IVOA according to the rules laid down
>   in DocStd \citep{2010ivoa.spec.0413H}.  This must at least discuss
>   use cases and the general design of the model.  The level of detail to
>   which individual data model items are discussed in the standard text
>   is up to the authors.  The authoritative source on these details
>   always is the VO-DML source.
> * The data model itself, written in VO-DML.
> * A detailed documentation in HTML format containing human-readable
>   definitions for all elements of the data model, formatted in HTML and
>   furnished with HTML-accessible anchors (a/@name or @id attributes) for
>   the vodeml-refs contained in the data model.  The intent is that the
>   data model URL with an element's vodml-id as a fragment identifier
>   will lead to element-specific documentation.  It is recommended to
>   generate this HTML document from the VO-DML using the vo-dml2html.xsl
>   script available from the IVOA document repository.
>
> When a standard data model reaches the status of Proposed Recommendation,
> the VO-DML document and the HTML are made available in the IVOA document
> repository at their final URLs.  They may, however, be modified there
> without further notice until the document reaches REC status.
>
> At the same time, a StandardsRegExt \citep{2012ivoa.spec.0508H} document
> for the standard is uploaded to (or, for updated models, updated in) in
> the Registry.
>
> In addition to the usual StandardsRegExt metadata, registry records for
> standard data models define namespaces and prefixes for all data models
> defined by the standard in StandardKey elements.  For this purpose, this
> standard defines two key names:
>
> * vodml-prefix -- the description child of the key contains a prefix
>   defined by the model.
> * vodml-dmuri -- the description child of the key contains a data model
>   URI defined by the model.
>
> Note that this allows Registry clients to support use cases like:
>
> * Locate the specification for a data model based on either prefix or
>   URI
> * Ascertain that a chosen prefix is not being used by another data model
>
> It does not allow the automatic resolution between prefix and DM URI
> from Registry data when a standard defines multiple data models.  That
> use case does not appear significant enough to warrant an extension of
> the existing registry infrastructure.
>
> A sample record for the present standard (which does not necessarily
> match what the Registry actually contains at any point) is given in
> appendix X.
> ------------------8<--------------------------------
>
> And the draft standard record (the DM URI for IVOA needs to be fixed, I
> guess) that would go into appendix X is at
>
> http://volute.g-vo.org/svn/trunk/projects/registry/Standards
> RegExt/samples/VODML.xml
>
> (and can be fixed there, too).
>
> Thoughts?  Opinions?  In particular: If there are use cases we need
> to cover that this doesn't solve, I'm not at all against defining a
> quick registry extension -- but if you think we might need that,
> please speak up now when we could still draft that without holding up
> proceedings.
>
> It would also be great if we could try the procedure for what should
> happen at PR when the next PR for VO-DML is published (including the
> ivoa DM).  I suspect we'll discover an issue or two if we do, and
> it'd be cool if that happened while the document still is in PR.
>
>           -- Markus
>

-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170120/5441441e/attachment.html>