<div dir="ltr"><div><div><div><div><div><div><div>DMers,<br><br></div>Omar and I had a long meeting to see what we can do to bring the models and this thread closer together.<br></div>Much of what is requested is basically just making concrete objects of the base Pattern elements.. this lets there be a common core which enables things like 'find all coordinates'.<br><br></div>Omar is taking an independent approach with his tools, and can fill you in on that.<br></div>I have 'mocked' the resulting model changes and generated some example files:<br></div> 1) chandra event list (real-world cube file)<br></div> 2) timeseries example from the Note.. Figures 5, 6, 7<br></div> with added detail about the CoordSys, Frames, etc.<br><div><div><div><div><div><br></div><div>This does NOT have any co-referencing concept.. as this isn't part of the current mapping syntax.<br></div><div><div>Related to this, there is one thing I noticed in the process is not possible with the current mapping syntax:<br></div><div> The TimeSeries note example has DatasetMetadata content.<br></div><div> In the Cube annotation, it specifies a PARAMref which is to provide the VALUE of the Dataset element 'ProductType'<br></div><div> Presumably, this is so I can annotate my file as different data products, the dataset metadata applies to each (simply provide a different ProductType in each product's annotation)<br></div><br>Otherwise, it is very similar in structure.<br></div><div><br></div><div>I want to review it again before distributing on volute (with the other example files), but will probably do so tomorrow.<br><br></div><div>more below...<br></div><div><br><div><div><div><div><div><div class="gmail_extra"><div>On Mon, Mar 27, 2017 at 1:55 PM, Markus Demleitner <span dir="ltr"><<a target="_blank" href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-"><br>
> What you can't avoid in some cases is to tightly couple two models, the<br>
> same way you tightly couple, just to make an example, an application to<br>
<br>
</span>Yes. Quantity and STC are two that need to be referenced a lot. But<br>
that referencing is a liability, dictated by the fact that values and<br>
errors come in all kinds of contexts, many far removed from anything<br>
space and time. But even worse than references into data models are<br>
(at some point certainly incompatible) parallel implementations, so<br>
clearly these need referencing.<br>
<br>
That is also why I think the equation coordinate = quantity that<br>
Mark makes in a parallel branch of this thread means that this part<br>
of the model needs to move "up"; we'll have this pattern for<br>
temperatures and photometry as well (and whatever else), and their<br>
errors will be correlated as well, and people will want to represent<br>
their statistcal properties as well, and perhaps correlate value and<br>
derivative, and so on. It would be shame if STC and photometry, say,<br>
had different models for their, well, quantities.<br></blockquote><div><br></div><div>By move up.. do you mean be defined in a separate model? <br></div><div>In the examples I've produced (former and new), you will see prefixes for:<br></div><div> coordsys: == Coordinate Systems and Frame specification pattern + domain implementations<br></div><div> coords: == Coordinates specification ( value + errors ) <br></div><div> trans: == Transform model<br></div><div> cube: == NDCube model elements<br></div><div> ds: == DatasetMetadata elements.<br></div><div><br></div><div>the 'coords' model is moving to a domain neutral representation from this thread input.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<span class="gmail-"></span><br>
Our standards live a lot longer than the last new-fangled<br>
distributed peer-to-peer NoSQL social blockchain web glitz. And<br>
therefore for us dependencies are even more expensive.<br>
<span class="gmail-"><br>
> should be reduced as much as possible. Decoupling DatasetDM and CubeDM, for<br>
> instance, might work pretty well. I am skeptical that you can do the same<br>
<br>
</span>Right, let's do that, then.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>This is part of the changes that we outlined and are in the 'mocked' examples.<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
</span><span class="gmail-"></span><span class="gmail-"></span>Oh, by the way, this *is* something I'd like to change in the VO-DML<br>
spec: I think ivoa:quantity is not very helpful while hogging the term in<br>
a way that might become confusing later. Is anyone really attached<br>
to it? Using it already, perhaps?<br>
<span class="gmail-"><br></span></blockquote></div><div class="gmail_quote"><div>What alternative would you suggest? <br></div><div><br>It is used in:<br> Dataset once<br></div><div> Coords many times<br></div><div> CoordSys a few times<br><br></div><div> <br></div><div>Cheers,<br></div><div>Mark<br><br></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div>