Reference implementations

Mireille Louys mireille.louys at unistra.fr
Tue May 10 18:32:06 CEST 2016


Hi Gerard, Hi all,

Le 10/05/2016 18:04, Gerard Lemson a écrit :
> HI Tom
> I think that writing a model in VO-DML is *not* an implementation of 
> the model, but its definition. It *is* an implementation of VO-DML,
>
Yes, I agree.
> An *instance* of the model is a valid implementation of the model, but 
> we have no generic standard way (yet) for representing instances of 
> data models. The mapping document will fit that, but protocols can 
> also do that.
> Showing interoperability of the data model could be an application 
> that uses two or more independent instances of the data model 
> serialized in some standard way.
> One way this might happen is that votables annotated with the same 
> data model are interpreted as instances of the data model.
> And it would be nice if something interesting is done with them. 
> Ieally this could be an implementation of a use cases the model was 
> supposed to support.
The different scenarios  proposed in the use-cases should be checked , I 
guess.
This is sometimes difficult if the model tries to encompass many 
different situations  ( as Char tried, and ND-Cube will probably) .
Could we envisage a partial validation where the main scenarios are 
checked first and the secondary ones later.

In other terms , should we be happy with a 75% validation rate for 
serialisations obtained from a new data model?

my 2c, Mireille.

> Gerard
>
>
> On Tue, May 10, 2016 at 10:46 AM, Tom McGlynn (NASA/GSFC Code 660.1) 
> <tom.mcglynn at nasa.gov <mailto:tom.mcglynn at nasa.gov>> wrote:
>
>     If you feel that data models are not subject to the requirement of
>     two reference implementations, that's fine but then this
>     discussion is moot regardless.  If you think they are then you are
>     quibbling about my choice of words. Feel free to substitute
>     whichever you like for 'protocol'.
>
>         Regards,
>         Tom
>
>     Matthew Graham wrote:
>
>         But a data model is not a protocol.
>
>         -- Matthew
>
>         On May 10, 2016, at 4:37 PM, Tom McGlynn (NASA/GSFC Code
>         660.1) wrote:
>
>             This kind of using the fact that you have written a
>             definition of the model counting as an implementation of
>             the model sounds awfully incestuous. I have always read
>             the requirement as having two different groups using the
>             protocol in some service, ideally one that supports doing
>             astronomy.
>
>                 Tom McGlynn
>
>             Matthew Graham wrote:
>
>                 So once we have a mapping standard with reference
>                 implementations any DM model specified in VO-DML could
>                 automatically have a reference implementation
>                 (according to these criteria) which would make life
>                 easier. Time to get that mapping spec out :)
>
>                 -- Matthew
>
>
>
>                 On May 10, 2016, at 4:00 PM, Laurino, Omar wrote:
>
>                     Hi,
>
>                     I agree with Gerard that items 1) and 2) look like
>                     the same, unless one brings in a standard for
>                     instance serializations. Since we can have
>                     standardized mapping strategies (as different
>                     recommendations) that map instances of valid
>                     VODML/XML models and their standard
>                     serializations, I don't think a valid
>                     serialization of an instance should be required
>                     for data models: this should be guaranteed by the
>                     mapping standard(s) and their reference
>                     implementations.
>
>                     As for the ModelImport requirement, it makes sense
>                     for "low level" models but not for "high level"
>                     ones, plus there is no way to guarantee that all
>                     types defined by a model are extendable/usable by
>                     other models. It gets too complicated.
>
>                     I would suggest we include the "model import"
>                     evidence as a "soft requirement", to be evaluated
>                     on a case-by-case basis depending on the use cases
>                     of the model. For STC, it makes a lot of sense to
>                     require this additional proof of interoperability,
>                     because the model is intended to be a building
>                     block for other models.
>
>                     Or, we might be to *require* that at least one
>                     reference implementation is a
>                     mission/archive/service-specific model that
>                     extends the standard one. So, if we had a model
>                     for Sources/Catalogs, at least one reference
>                     implementation should be a
>                     mission/archive/system-specific model that proofs
>                     the model can be meaningfully extended by actual
>                     specializations. Other than properly validating as
>                     VODML/XML, this model should be evaluated for its
>                     domain-specific content, and that's probably not
>                     something you can automate. This should also be a
>                     good way to involve implementors from the
>                     community, so it's probably my preferred one.
>
>                     Omar.
>
>
>                     On Tue, May 10, 2016 at 9:38 AM, Gerard Lemson
>                     <gerard.lemson at gmail.com
>                     <mailto:gerard.lemson at gmail.com>
>                     <mailto:gerard.lemson at gmail.com
>                     <mailto:gerard.lemson at gmail.com>>> wrote:
>
>                         Hi
>                         What is meant by item 2, "An XML serialization
>                     of the DM".
>                         The standard representation (serialization?)
>                     of a VO-DML data
>                         model is VO-DML/XML, i.e. XML. And that is the
>                     representation
>                         that can be validated (step 1?) using
>                     automated means, for
>                         example using XSLT scripts in the vo-dml/xslt
>                     folder on volute at gavo.
>                         If 2) is meant to imply an XML serialization
>                     of an *instance* of
>                         the model, that we can only do once we have a
>                     standard XML
>                         representation of instances of models. That
>                     does not yet exist.
>                         The original VO-URP framework does contain an
>                     automated XML
>                         Schema generator for its version of VO-DML,
>                     that has not yet been
>                         ported to VO-DML.
>                         And of course the mapping document describes
>                     how one can describe
>                         instances serialized in VOTable, but that is a
>                     different standard.
>
>                         For what it's worthy, I think that an
>                     "implementation of VO-DML"
>                         is a data model expressed using that language
>                     (in VO-DML/XML to
>                         be precise) and validated using software. The
>                     latter enforces
>                         that the language should allow automated
>                     validtion.
>                         I think interoperable implementations of
>                     VO-DML are two or more
>                         valid models that are linked by "modelimport"
>                     relationships.
>                         I.e.one model "imports" the other(s) and uses
>                     types from the
>                         other as roles or super types in the
>                     definition of its own types.
>                         This is supported by the VODMLID/VODMLREF
>                     meachanism of the language.
>
>                         Cheers
>                         Gerard
>
>
>                         On Tue, May 10, 2016 at 9:04 AM, Matthew Graham
>                         <mjg at cd3.caltech.edu
>                     <mailto:mjg at cd3.caltech.edu>
>                     <mailto:mjg at cd3.caltech.edu
>                     <mailto:mjg at cd3.caltech.edu>>> wrote:
>
>                             Hi,
>
>                             We're trying to define specifically what
>                     would satisfy the
>                             reference implementation requirement for
>                     an IVOA Spec in the
>                             context of a data model. The proposal is that:
>
>                             (1) If the DM has been described using
>                     VO-DML it can be
>                             validated as valid VO-DML
>
>                             (2) An XML serialization of the DM can be
>                     validated
>
>                             so therefore is the combination of the two
>                     sufficient to
>                             demonstrate the validity and potential
>                     interoperability of
>                             the data model (which is the purpose of
>                     the reference
>                             implementations).
>
>                                     Cheers,
>
>                                     Matthew
>
>
>
>
>
>                     -- 
>                     Omar Laurino
>                     Smithsonian Astrophysical Observatory
>                     Harvard-Smithsonian Center for Astrophysics
>                     100 Acorn Park Dr. R-377 MS-81
>                     02140 Cambridge, MA
>                     (617) 495-7227 <tel:%28617%29%20495-7227>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160510/d20ef80b/attachment-0001.html>


More information about the dm mailing list