<div dir="ltr"><div>Markus/All,<br><br></div>This is getting very Coords specific, so we may want to spawn a new thread for discussion on this.<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 7:03 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><GROUP vodml-type="ivoa:Quantity"><br>
<!-- all measurements (can) have errors, min/max vals, etc, so<br>
there's no point separately modelling this in cube, stc,<br>
photometry, etc.; let's have ivoa:Quantity for that. --><br>
<FIELDref vodml-role="value" ref="obs_date"/><br>
<FIELDref vodml-role="standard-<wbr>deviation" ref="err_time"/><br>
<PARAM name="minimum" value="56493.339"/><br>
<PARAM name="maximum" value="56498.341"/><br>
<!-- which also does much of char:, without introducing 1000s of<br>
utypes --><br>
</GROUP><br>
<br></blockquote><div><snip> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What's really missing at this point as far as standards are concerned<br>
is, as far as I know, ivoa:Quantity (or perhaps we should have a DM<br>
of its own? I suspect Quantity will go through several revisions as<br>
it starts getting used).<br>
<br>
Can anyone summarise the state of Quantity modelling? I always get a<br>
bit lost in all the artefacts in volute's dm branch...<br>
<br>
Cheers (and with apologies if this indeed comes a bit late),<br>
<br>
Markus<br>
</blockquote></div><br></div><div class="gmail_extra">As I mentioned in the last mail, this object corresponds to the coords pattern ( value + errors ).<br></div><div class="gmail_extra">So.. IF we agree that a measurement is a measurement, and there is no need to specialize by domain, then that model can be greatly simplified.. leaving the 'domain' specialization to the coordsys model (frames and 'values' within the coordinate space).<br><br></div><div class="gmail_extra">I mocked this model change and re-generated the sparse cube example using this model spec.<br>see: <a href="https://volute.g-vo.org/svn/trunk/projects/dm/CubeDM-1.0/examples/chandra_events_annotated_alt.vot" target="_blank">https://volute.g-vo.org/svn/trunk/projects/dm/CubeDM-1.0/examples/chandra_events_annotated_alt.vot</a><br></div><div class="gmail_extra">you can compare with the non '_alt' version.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The change is:<br></div><div class="gmail_extra"> coords model:<br></div><div class="gmail_extra"> + take the implementation under "Spatial" domain, where the 1,2,3D implementations exist<br></div><div class="gmail_extra"> + make the coord value type 'coordsys:AbsoluteCoordinate'<br></div><div class="gmail_extra"> + rename it Coordinate1D, Coordinate2D, Coordinate3D<br></div><div class="gmail_extra"> + strip the entire domain package (all specializations of the DerivedCoordinate by domain)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">This change makes all derived/measured coordinates (value+error) equivalent, with a specialized 'value' by domain.<br></div><div class="gmail_extra">They are specialized in the sense that they have specific primitive/Quantity values, and refer to specific flavors of Frame axis... that is all in the coordsys model.<br><br></div><div class="gmail_extra">By doing this, it enables the usage that Markus mentioned. A 'coords' savvy user can find all coordinates in the serialization regardless of the product in which they reside (like cube or timeseries). <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">IF you think this is a valid usage of the annotated dataset, then I would add it to the requirements for cube/stc and formalize this change. Again, personally, I think this would be a good move... it simplifies the coords model without too much cost and enables what appears to be a reasonable use-case.<br><br></div><div class="gmail_extra">Let me know what you think!<br></div><div class="gmail_extra">Mark<br><br></div><div class="gmail_extra">PS: This set of objects... Quantity, DerivedCoordinate, AbsoluteCoordinate gets down to the level of Quantity vs Measurement which has been a long-discussed topic with little resolution. In my view of things<br></div><div class="gmail_extra"><div class="gmail_extra"> + Quantity (DataType) is a 'physical value', when you don't really care what the Frame association is.<br></div> + AbsoluteCoordinate (DataType) is essentially the primitive/Quantity types when you care which Frame/axis is involved<br></div> + DerivedCoordinate (ObjectType) is a 'measured' or 'calculated' value ( value + error ). With these, we typically care about the Frame/axis associations so it uses AbsoluteCoordinate for the 'value', and Quantity in the Errors since the assumption is that the errors are in the same frame as the value, though not necessarily in the same units.<br><div class="gmail_extra"><br><br></div></div></div></div></div>