Reference implementations
Pierre Fernique
Pierre.Fernique at astro.unistra.fr
Tue May 10 18:47:06 CEST 2016
I just bring my 2c
I think we have to keep in mind that the goal of having two independent
implementations for validating a new IVOA proposal is not only to
demontrate that the idea is well defined and coherent, but also to check
that this idea fulfill a real need. Finding two independent institutes
implementing a protocol, ideally as a provider & consumer, has always
been an excellent method to check this real need. Otherwise, you will
just have one - from the author of the idea.
So, do we have to validate this real need in the case of DM ? and if
yes, how to do it ? So I would share the Gerard idea that the validation
of the DM should be based on the implementation of the use cases for
which de DM has been defined. And ideally by two independent institutes
as provider & consumer.
Cheers
Pierre Fernique
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,
>
> 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.
>
> 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/20b69bfe/attachment.html>
More information about the dm
mailing list