Reference implementations

Gerard Lemson gerard.lemson at gmail.com
Tue May 10 16:36:07 CEST 2016


HI Matthew etal
On Tue, May 10, 2016 at 10:18 AM, Matthew Graham <mjg at cd3.caltech.edu>
 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 :)
>
> Hear hear!

Though I think that there is something more to be said about your first
email in this trail.
In particular I was responding more to the requirements on VO-DML becoming
a standard.
Turning an actual data model into a standard would require the standard
itself (which should from now on be valid VO-DML/XML+document explaining
it) and possibly two interoperable implementations of the data model
itself.
I think that an implementation of a data model is an instance of the data
model. I.e. a set of instances of types in the model. This requires a
serialization of these instances (i.e. your item 2). This could be in  a
standard/custom format, for example a  or in an annotated VOTable.
Interoperability of a data model could be a set of instances that can be
used by a common tool.
As to OMar's soft requirement, I think that would apply to the
data-model-standard issue. I think for standardizing VO-DML we must show
interoperability between different models. And in VO-DML that requires
having examples of model imports I think. I don't think that is a problem
though.


Gerard


>
>
> 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>
> 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>
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160510/4136be29/attachment-0001.html>


More information about the dm mailing list