Reference implementations

Tue May 10 17:10:38 CEST 2016

data models don't necessarily fit 1-1 into a project which can be generated
and shared by data providers in a 'service'.
We are in a mode where we are generating component models which are used
like legos to build a product which satisfies IVOA requirements.

  For example, we are now working the Cube model.. to satisfy requirements
of describing/sharing NDCube data (Images, event lists, etc) and will
provide the 'source' of information which will populate SIAV2 query
responses (regarding image size/shape and transforms).

  To do this, we are working several component models  (Dataset, STC ) and
(Char is also pulled in).

   None of these individually satisfy the use case, but the combination..
headed by NDCube, will.  I think we need a means that we can show that STC,
Dataset, Char and other component models are built properly, and satisfy
*their* requirements which does not require sending data from Archive A to
Tool B.

Mark

On Tue, May 10, 2016 at 10:46 AM, Tom McGlynn (NASA/GSFC Code 660.1) <
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>> 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>> 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/e3e521f8/attachment.html>