<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 1:55 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:2g1" class="gmail-a3s gmail-aXjCH gmail-m15b11113762648a7">I agree with Omar that concrete serialisations is what we should now<br>
look at; let's do some!</div></blockquote></div><br>I am working on them. I got stuck home sick, unfortunately, but hopefully I'll have something to share by the end of the week.<br><br><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">That is also why I think the equation coordinate = quantity that<br></span><span style="font-size:12.8px">Mark makes in a parallel branch of this thread means that this part<br></span><span style="font-size:12.8px">of the model needs to move "up"; we'll have this pattern for<br></span><span style="font-size:12.8px">temperatures and photometry as well (and whatever else), and their<br></span><span style="font-size:12.8px">errors will be correlated as well, and people will want to represent<br></span><span style="font-size:12.8px">their statistcal properties as well, and perhaps correlate value and<br></span><span style="font-size:12.8px">derivative, and so on. It would be shame if STC and photometry, say,<br></span><span style="font-size:12.8px">had different models for their, well, quantities.</span></blockquote><div><br></div><div>Agreed. Which is one of the reasons why I think this conversation has been very constructive and productive.</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">Our standards live a lot longer than the last new-fangled<br></span><span style="font-size:12.8px">distributed peer-to-peer NoSQL social blockchain web glitz. And<br></span><span style="font-size:12.8px">therefore for us dependencies are even more expensive.</span></blockquote><div><br></div><div>I can't disagree with this one, but I wonder if we really agree in practice. We'll see when we get to the concrete implementations.</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">Well, yes. But of course when someone does a major version of a<br></span><span style="font-size:12.8px">model you depend on, you'll have to issue a new major version of your<br></span><span style="font-size:12.8px">own data model (and break *your* clients in turn) where otherwise you<br></span><span style="font-size:12.8px">could probably have just left your DM alone. So, my urging is<br></span><span style="font-size:12.8px">exactly to avoid having to build a lot of major DM versions<br></span><span style="font-size:12.8px">just because a new major version was necessary for one DM (ivoa,<br></span><span style="font-size:12.8px">quantity, and STC excepted).</span></blockquote><div><br></div><div>At the same time, I think we should make sure that when such an update is really necessary, our framework makes it easy to update the downstream model. It's always a trade-off. The easier it is to adopt healthy patterns, the easier it is to fall into disruptive anti-pattern pits.</div><div><br></div><div>In the time series example, more than a time series *data model* I think time series can just be seen as *instances* of a common, more generic data model, that is itself a lightweight one. A client could specialize into dealing with a simpler serialization (e.g. my app only deals with time series, for some reason) while at the same time a more general client (a plotting app, a fitting app) should be able to recognize there are axis, their generic properties, and so on. This is part of my example(s).</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">Oh, by the way, this *is* something I'd like to change in the VO-DML<br></span><span style="font-size:12.8px">spec: I think ivoa:quantity is not very helpful while hogging the term in<br></span><span style="font-size:12.8px">a way that might become confusing later. Is anyone really attached<br></span><span style="font-size:12.8px">to it? Using it already, perhaps?</span></blockquote><div><br></div><div>VO-DML's "quantity" maps, by design, to VOTable's PARAM and FIELD, i.e. it has a value, a unit, and implicitly a data type. I am not particularly attached to the name, but I think we are dealing with two different things: one is the (value, unit, data type) tuple, one is a more complex thing that can have possibly multiple values, possibly a complex error object associated to different kinds of errors, e.g. statistical, systematic, etc. In simple cases, this is just "3.5 +- 0.3 microns". In my mind, the first thing is named "quantity" and the second one is named "measurement". I am not attached to the names themselves, but let's make sure we are on the same page on the meaning before we, possibly, change the signifier. </div><div><br></div><div>We might also need an ivoa:NumericQuantity and an ivoa:number types that abstract all numeric quantities and their values, to simplify both the modeler's and the client's life.</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"> <GROUP vodml-type="stc:Coordinate"><br></span><span style="font-size:12.8px"> <PARAMref vodml-role="value" vodml-type="Coord2" ref="pt"/><br></span><span style="font-size:12.8px"> </GROUP><br></span><span style="font-size:12.8px"> <PARAM ID="pt" xtype="POINT" datatype="real"<br></span><span style="font-size:12.8px"> arraysize="2" value="23.3 41"/></span><br style="font-size:12.8px"><span style="font-size:12.8px"> <GROUP vodml-type="stc:Coordinate"><br></span><span style="font-size:12.8px"> <GROUP vodml-role="value" vodml-type="Coord2"><br></span><span style="font-size:12.8px"> <PARAMref vodml-role="C1" ref="ra"/><br></span><span style="font-size:12.8px"> <PARAMref vodml-role="C2" ref="dec"/><br></span><span style="font-size:12.8px"> </GROUP><br></span><span style="font-size:12.8px"> </GROUP><br></span><span style="font-size:12.8px"> <PARAM ID="ra" value="23.3"/><br></span><span style="font-size:12.8px"> <PARAM ID="dec" value="41"/></span></blockquote><div><br></div><div>Would you have both annotations in the same file? How should a client (unaware of the enclosing model) know this is two different representations of the same coordinate rather than two distinct coordinates? I would rather be in favor of specific mapping rules for certain types, if that makes sense, which is what we already do for ivoa:Quantity. Coord2 would be serialized as a DALI POINT, if that makes sense. Admittedly, I haven't given this possibility enough thought, so I am not sure how convenient that would be or what repercussions it might have down the road.</div><div><br></div><div>Omar.</div><div><br></div><div><br></div>-- <br><div class="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></div>