<div dir="ltr"><div><div><div><div><div>Markus,<br><br></div>In this and Mark's mail, I'm seeing a distinction which maybe has been missed?<br></div>There is nothing preventing one from annotating a cube with 'alternate' content and this could be widely usable by clients who don't care about validating the cube. <br><br>My objection is to the statements that the model itself should not facilitate validation for the times when it IS desired. With the loose-non coupled modeling scheme, one could literally put ANYTHING in the CoordSys element and it would be 'valid' so long as it is has a vo-dml representation. I'll note that this behavior is only true at the model boundaries.. if the elements are in the same model then the vo-dml must resolve to a specific - defined element.<br></div></div><br></div><div><div><div><div><div><div><div><div class="gmail_extra">more below:<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 22, 2017 at 9:20 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"><span class=""><br>
</span>I'm not strictly arguing against saying in an appropriate place<br>
(e.g., a DAL protocol, an endorsed note, or perhaps even a short REC<br>
containing mainly examples): "A fully-compliant spectrum-1 instance has to<br>
have valid annotations for STC-2 (spectral axis; for the record, I still<br>
think the spectral axis should have a separate DM), photometry-1 (flux<br>
axis), Dataset-1, and NDCube (axis organisation). For observed spectra,<br>
additionally, the Dataset-1 target position annotation and an<br>
Observation-1 annotation".<br>
<br></blockquote><div>IMO - that is the job of the model... then if you annotate to the model, it is valid.<br></div><div>if you don't annotate to the model, it is not.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that the last clause also provides a nice solution to what were<br>
discussing back in the Spectrum DM 2.0 days, where SDM made the<br>
target position required and it was unclear what to do with<br>
theoretical spectra.<br></blockquote><div><br></div><div>Yeah.. in one of the earlier mails, I agree that we probably want to change this relation so that different types of Dataset could be used.<br></div><div>My favorite being:<br></div><div> NDCubeDataset<br></div><div> + reference to Dataset ( could be ObsDataset, or SimDataset, or whatever )<br></div><div> + reference to NDCube DataProduct<br></div><div> which defines the required pieces, but allows more flexibility.<br><br></div><div> <snip><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""></span><span class=""><br>
> The ownership relations are there for various applications which<br>
> implement the model. When implementing a library, I would want to<br>
> know when it is safe to free the memory space for particular<br>
> elements. I think this is most true for database applications, but<br>
> that is outside my wheelhouse.<br>
<br>
</span>Hm -- I think memory management, whether reference counting as<br>
proposed here, a conventional garbage collector, or whatever else is<br>
so far removed from data modelling that I doubt the concept of<br>
ownerwhip in data model elements will actually help implementations<br>
in memory management.<br></blockquote><div><br></div><div>My understanding is that defining memory management is one of the primary uses of data models.<br></div><div>That information is not used in all cases, and elements may be flattened/combined on implementation, but the model defines the fundamental relations between objects.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> > > >> If I have a 3D cartesian Space, with coordinate axes x,y,z.. there is<br>
> > 1<br>
> > > >> DataAxis referring to a Position3D in that space.<br>
> ><br>
> > Uh -- that sounds... dangerous. In the spirit of my preference to<br>
> > ideally reference native entities (i.e., FIELDs here): How does this<br>
> > DataAxis grouping help a client? What is it supposed to do with it?<br>
> > How does the grouping help it over just having three axis (that, of<br>
> > course, might still be related through one or more separate STC<br>
> > annotations, but I'd like that to be uncorrelated if at all<br>
> > possible).<br>
> ><br>
> ><br>
> 1 FIELD -> 1 DataAxis (Coordinate) works fine only for the simplest<br>
> case (1D value with no errors). For the 2D/3D cases, the errors<br>
> may be correlated, so the bundle of FIELDs for the value must be<br>
> grouped above the errors. And then there is the errors... A '2D<br>
> Coordinate' with 2 sources of error, both symmetric.. would have 4<br>
> FIELDs feeding the DataAxis/Coordinate content ( x, y, xy_staterr,<br>
> xy_ranerr ).<br>
<br>
</span>Yes, correlations are a bit of a challenge, but you'll have<br>
correlated errors in all kinds of contexts, so I'd argue that's for<br>
quantity again, not for coordinates themselves.</blockquote><div>The Quantity you outline above (value + error) IS what is called Coordinate in these models. With the distinction that 'value' includes the axis/frame reference.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Since doing this<br>
kind of advanced annotation right is difficult, my preference would<br>
be to postpone their definition until we have some experience with<br>
the simple cases. You can compatibly add things later, but taking<br>
them away will probably mean a new major version, which would be<br>
painful even without lots of links between DMs.<br></blockquote><div> </div><div>I think the way we have modeled errors will facilitate growth/change on a minor-version level.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having said that, I think these correlated errors are a case where DM<br>
objects need to be referenced; but that would be references *within*<br>
(hopefully) quantity, not between different DMs.<br>
<br>
I admit that I don't really look forward to defining quantity (i.e.,<br>
modelling errors, ranges, and that kind of thing) either, but I<br>
maintain it's much better to do this once properly (and then<br>
carefully evolve it in this single place) than to solve these<br>
analogous problems in each DM and/or domain separately.<br>
<span class="HOEnZb"></span></blockquote><div><br></div><div>Agreed.. again, since your Quantity == my Coordinate, the 'coords' model would be that place.<br></div><div>If we agree on consolidating out the 'domain' aspect of that model, it becomes a single set of objects which can be evolved as you suggest.<br></div><div>(the 'domain' variations move entirely to the coordsys model.. 'values + axis refs' are domain savvy)<br></div><div> <br></div><div>Mark<br><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div>