VO-DML registration

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri Jan 20 13:50:27 CET 2017


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/StandardsRegExt/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


More information about the dm mailing list