Time Series Cube DM - IVOA Note

[Laurino, Omar]

Hi Markus,

On Thu, Feb 23, 2017 at 4:46 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Now, my appeal is to have the same property across DMs: We should
> build things so that a document can be valid NDCube-1.0 regardless of
> whether it uses Dataset-1.0 or Dataset-2.4 or both, or even none
> of them.  The point of my previous mail was that that's feasible;
>

The problem with this is that it would depend on how *exactly* the
importing model imports and uses the imported model.

If a TimeSeries *is* a Dataset (the example is arbitrary), then it is
important to know what version of a Dataset it is, because Dataset-1.0 and
Dataset-2.0 may be, by design, not compatible. Your point is still relevant
for minor increments, though. Depending on the type of parser, it might not
really matter if a TimeSeries is expressed in terms of Dataset-1.0 or
Dataset-1.2, because by design a Dataset-1.2 valid annotation is also a
valid Dataset-1.0 annotation, and vice versa. A validator would still be
able to validate the instance, for example.

In any case an importing VODML model MUST say what models it is importing,
otherwise it cannot refer to their elements, not even to state that
"something" has "such and such" datatype, e.g. that a ts:TimeSeries is a
special kind of ds:Dataset: "such and such" would require a vodml
reference, i.e. the prefix identifying a major version of a model (ds) plus
the ID of the data model element (Dataset).

Now, the designers of the importing model can be wise and reduce the number
of references to an imported model if the coupling between the models is
inherently loose. This might involve using object composition over type
inheritance, if this makes sense from a modeling point of view. Still, if
they want to enable compatibility with a new major version of a model, they
need to create a new xml descriptor that describes the relationship with
the new model. It could be trivial to do so, but this depends on the
inherent relationship between the models and how they were designed. Could
this be done bumping only the minor version of the importing model? I have
to say I don't know, we never thought about this.

Most likely, if we wanted to enable this (new) requirement we would need to
make some tweaks to the VODML spec, and possibly to the mapping spec. One
might say that TimeSeriesDM imports the Dataset type from any version of
DatasetDM, and the binding is done at serialization time, i.e. when a
provider materializes an instance of a TimeSeries. Some mechanism must
allow clients (e.g. validators) to know what versions are being bound
together. Again, this was not an explicit requirement, so no thought went
into it.

However, I could see a model (probably not DatasetDM) removing a type
between major increments, possibly leaving importing models with dangling
references to non-existent types, e.g. ad absurdum DatasetDM-2.0 might
remove the Dataset type altogether, so TimeSeries would be left with a
dangling reference to a Dataset type that does not exist anymore.

The only way I can see this working at this point is by removing the link
altogether. It could be that TimeSeries is just an additional layer of
metadata that can be added to a file on top of the existing ones. So
something might be annotated as being both a Dataset (of any version) and a
TimeSeries (of any version), hopefully with minimal overlap. Whether this
makes sense, or it's convenient, depends on the models.

None of the above means you cannot annotate a file with two different
(major) versions of a model. You still can.

Hope this helps,

Omar.

P.S. I still owe you a couple of replies about models registration, I'll do
it asap.

-- 
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/20170223/7d1bf2cc/attachment.html>