<div dir="ltr">Markus,<div><br></div><div>at some point I thought you were arguing that a model should be able to import another model without caring about its version. I think I now understand you weren't. Rather, you are arguing that modeling should be done in such a way as to reduce the amount of importing and reuse, at least in some instances. If that's the case, then indeed we are on the same page.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="font-size:12.8px">> Still, if<br></span><span class="gmail-im" style="font-size:12.8px">> they want to enable compatibility with a new major version of a model, they<br></span><span class="gmail-im" style="font-size:12.8px">> need to create a new xml descriptor that describes the relationship with<br></span><span class="gmail-im" style="font-size:12.8px">> the new model. It could be trivial to do so, but this depends on the</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">Uh -- you lost me at the part with the compatibility with new<br></span><span style="font-size:12.8px">major versions of a model. Can you try to come up with an example?</span></blockquote><div><br></div><div>Again, I was responding to something you probably weren't arguing in the first place. What I meant is that if ModelA-1.0 imports ModelB-1.0 today, and a year from now the DM group decides to support ModelB-2.0, they should create a new VODML description file (and a new version) of ModelA that explicitly imports ModelB-2.0. I was wondering (and doubting) this could be done with a minor increment of ModelA. If there is no link, i.e. ModelA does not import ModelB to begin with, a valid annotation could indeed follow ModelA-1.0, ModelB-1.0, and even ModelB-2.0 in the same file. Which is what you were pointing out in the first place, right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Just to be sure we're on the same page: Within one instance, since<br></span><span style="font-size:12.8px">we've agreed on a fixed mapping from prefixes to minor DM versions,<br></span><span style="font-size:12.8px">you can only "use" one minor version (i.e., it's impossible (and<br></span><span style="font-size:12.8px">would be silly) to have annotations for both NDCube-1.0 and<br></span><span style="font-size:12.8px">NDCube-1.2). Agreed?</span></blockquote><div><br></div><div>Yes.</div><div><br></div><div>Thanks for the clarifications,</div><div><br></div><div>Omar.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 3:56 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Omar,<br>
<span class=""><br>
On Thu, Feb 23, 2017 at 09:47:30AM -0500, Laurino, Omar wrote:<br>
> On Thu, Feb 23, 2017 at 4:46 AM, Markus Demleitner <<br>
> <a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a><wbr>> wrote:<br>
><br>
> > Now, my appeal is to have the same property across DMs: We should<br>
> > build things so that a document can be valid NDCube-1.0 regardless of<br>
> > whether it uses Dataset-1.0 or Dataset-2.4 or both, or even none<br>
> > of them. The point of my previous mail was that that's feasible;<br>
> ><br>
><br>
> The problem with this is that it would depend on how *exactly* the<br>
> importing model imports and uses the imported model.<br>
<br>
</span>Exactly -- this is why I'm making all the noise here. I'm<br>
advertising a model in which we minimize dependencies, and I argue<br>
that's the big dividend of all the pain we've gone into with VO-DML<br>
and proper annotation.<br>
<span class=""><br>
> If a TimeSeries *is* a Dataset (the example is arbitrary), then it is<br>
> important to know what version of a Dataset it is, because Dataset-1.0 and<br>
> Dataset-2.0 may be, by design, not compatible. Your point is still relevant<br>
<br>
</span>Right. And I'm arguing that we should keep inheritance and embedding<br>
at an absolute minimum, using it only when technically necessary. In<br>
your example, I don't believe there actually should be a type<br>
TimeSeries (what would it convey?). There's Dataset (and that would<br>
have an attribute dataproduct_type="timeseries" as in obscore).<br>
<br>
Time series clients would then know it's something for them. They'd<br>
then look for annotation they know. Typically, they'll look for an<br>
NDCube annotation, but that's independent of the fact that we have<br>
time series here. And in particular, things remain time series<br>
whether there's NDCube-1.0 or NDCube-2.4 annotation in there, or<br>
both.<br>
<br>
Finally, the time series will contain a time, so we need STC<br>
annotation, and there are dependent axis that could have STC<br>
annotations (for time series over positions), or photometry, or may<br>
have spigot annotation. Neither NDCube nor Dataset need to know<br>
anything about the details here.<br>
<span class=""><br>
> for minor increments, though. Depending on the type of parser, it might not<br>
> really matter if a TimeSeries is expressed in terms of Dataset-1.0 or<br>
> Dataset-1.2, because by design a Dataset-1.2 valid annotation is also a<br>
> valid Dataset-1.0 annotation, and vice versa. A validator would still be<br>
> able to validate the instance, for example.<br>
<br>
</span>Well, I'd argue that by definition, Dataset-1.2 and Dataset-1.0 must<br>
be interchangable (with 1.2 being able to express a bit more, of<br>
course). That, I claim, is the definition of a minor update, and<br>
that's what we're trying to reflect on the schema side (RFC still<br>
open: <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/XMLVersRFC" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/<wbr>bin/view/IVOA/XMLVersRFC</a>).<br>
<span class=""><br>
> In any case an importing VODML model MUST say what models it is importing,<br>
> otherwise it cannot refer to their elements, not even to state that<br>
> "something" has "such and such" datatype, e.g. that a ts:TimeSeries is a<br>
<br>
</span>True. Which is why this should be avoided, except for a well-defined<br>
set of well-thought-out, rarely changing basic classes. Well, of<br>
course, there's the other application, where individual institutions<br>
take an IVOA data model and adapt it to their needs.<br>
<br>
Even then multiple imports should, by extension, be strongly<br>
discouraged, so the Academy of Sciences of Paraphernalia would<br>
separately extend NDCube to paraph-ndcube: and STC to paraph-stc: if<br>
they absolutely have to.<br>
<br>
As I said a few mails back, four points with three connections each<br>
result in a completely rigid tetrahedron in which you can't move<br>
anything any more.<br>
<span class=""><br>
> Now, the designers of the importing model can be wise and reduce the number<br>
<br>
</span>s/can/should/<br>
<span class=""><br>
> of references to an imported model if the coupling between the models is<br>
> inherently loose. This might involve using object composition over type<br>
> inheritance, if this makes sense from a modeling point of view. Still, if<br>
> they want to enable compatibility with a new major version of a model, they<br>
> need to create a new xml descriptor that describes the relationship with<br>
> the new model. It could be trivial to do so, but this depends on the<br>
<br>
</span>Uh -- you lost me at the part with the compatibility with new<br>
major versions of a model. Can you try to come up with an example?<br>
<span class=""><br>
> Most likely, if we wanted to enable this (new) requirement we would need to<br>
> make some tweaks to the VODML spec, and possibly to the mapping spec. One<br>
> might say that TimeSeriesDM imports the Dataset type from any version of<br>
> DatasetDM, and the binding is done at serialization time, i.e. when a<br>
<br>
</span>No, I don't think anything needs to change in the draft specs to<br>
accomodate this. There should simply be as few imports as<br>
possible, and as I said above I'm pretty sure there's no need for<br>
imports of DMs like DatasetDM at all. STC *might* be a slightly<br>
different matter if we keep a Characterisation DM, but even there I'd<br>
advocate (until someone shows me an example where that paradigm<br>
breaks) there char: should only talk about generic "limits", and the<br>
actual physical annotation of these limits can be kept out of char: and<br>
just live in STC, phot:, or spigot:, keeping char: nicely generic.<br>
<span class=""><br>
> However, I could see a model (probably not DatasetDM) removing a type<br>
> between major increments, possibly leaving importing models with dangling<br>
> references to non-existent types, e.g. ad absurdum DatasetDM-2.0 might<br>
> remove the Dataset type altogether, so TimeSeries would be left with a<br>
> dangling reference to a Dataset type that does not exist anymore.<br>
<br>
</span>Yes, obviously, such references cannot go across major versions;<br>
that's what major versions are about: They break compatibility, and<br>
the big art is to make that possible without breaking clients. I<br>
think VO-DML and out annotation plans have all it takes to pull off<br>
this trick.<br>
<br>
Whether references to and within DMs contain minor versions or not is<br>
orthogonal to this discussion, but since we've touched it I take the<br>
liberty of mentioning that I've argued in<br>
<a href="http://mail.ivoa.net/pipermail/dm/2017-January/005458.html" rel="noreferrer" target="_blank">http://mail.ivoa.net/<wbr>pipermail/dm/2017-January/<wbr>005458.html</a> they<br>
should not.<br>
<br>
Just to be sure we're on the same page: Within one instance, since<br>
we've agreed on a fixed mapping from prefixes to minor DM versions,<br>
you can only "use" one minor version (i.e., it's impossible (and<br>
would be silly) to have annotations for both NDCube-1.0 and<br>
NDCube-1.2). Agreed?<br>
<span class=""><br>
> The only way I can see this working at this point is by removing the link<br>
> altogether. It could be that TimeSeries is just an additional layer of<br>
> metadata that can be added to a file on top of the existing ones. So<br>
> something might be annotated as being both a Dataset (of any version) and a<br>
<br>
</span>Yes! Except, as I said:<br>
<br>
TL;DR: I don't think we need the notion of TimeSeries except as<br>
a term in the values of dataproduct_type at all: it's just a Dataset,<br>
and NDCube; and if you look, you'll see that there's just one<br>
independent axis that happens to be a time in STC).<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div></div>
</div>