Time Series Cube DM - IVOA Note

[CresitelloDittmar, Mark]

DMers,

Omar and I had a long meeting to see what we can do to bring the models and
this thread closer together.
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'.

Omar is taking an independent approach with his tools, and can fill you in
on that.
I have 'mocked' the resulting model changes and generated some example
files:
  1) chandra event list (real-world cube file)
  2) timeseries example from the Note.. Figures 5, 6, 7
      with added detail about the CoordSys, Frames, etc.

This does NOT have any co-referencing concept.. as this isn't part of the
current mapping syntax.
Related to this, there is one thing I noticed in the process is not
possible with the current mapping syntax:
  The TimeSeries note example has DatasetMetadata content.
  In the Cube annotation, it specifies a PARAMref which is to provide the
VALUE of the Dataset element 'ProductType'
  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)

Otherwise, it is very similar in structure.

I want to review it again before distributing on volute (with the other
example files), but will probably do so tomorrow.

more below...

On Mon, Mar 27, 2017 at 1:55 PM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

>
> > What you can't avoid in some cases is to tightly couple two models, the
> > same way you tightly couple, just to make an example, an application to
>
> Yes.  Quantity and STC are two that need to be referenced a lot.  But
> that referencing is a liability, dictated by the fact that values and
> errors come in all kinds of contexts, many far removed from anything
> space and time. But even worse than references into data models are
> (at some point certainly incompatible) parallel implementations, so
> clearly these need referencing.
>
> That is also why I think the equation coordinate = quantity that
> Mark makes in a parallel branch of this thread means that this part
> of the model needs to move "up"; we'll have this pattern for
> temperatures and photometry as well (and whatever else), and their
> errors will be correlated as well, and people will want to represent
> their statistcal properties as well, and perhaps correlate value and
> derivative, and so on.  It would be shame if STC and photometry, say,
> had different models for their, well, quantities.
>

By move up.. do you mean be defined in a separate model?
In the examples I've produced (former and new), you will see prefixes for:
  coordsys: == Coordinate Systems and Frame specification pattern + domain
implementations
  coords:     == Coordinates specification ( value + errors )
  trans:        == Transform model
  cube:        == NDCube model elements
  ds:            == DatasetMetadata elements.

the 'coords' model is moving to a domain neutral representation from this
thread input.


>
> Our standards live a lot longer than the last new-fangled
> distributed peer-to-peer NoSQL social blockchain web glitz.  And
> therefore for us dependencies are even more expensive.
>
> > should be reduced as much as possible. Decoupling DatasetDM and CubeDM,
> for
> > instance, might work pretty well. I am skeptical that you can do the same
>
> Right, let's do that, then.
>
>
This is part of the changes that we outlined and are in the 'mocked'
examples.


> Oh, by the way, this *is* something I'd like to change in the VO-DML
> spec: I think ivoa:quantity is not very helpful while hogging the term in
> a way that might become confusing later.  Is anyone really attached
> to it?  Using it already, perhaps?
>
> What alternative would you suggest?

It is used in:
   Dataset once
   Coords many times
   CoordSys a few times


Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170327/7687f5da/attachment.html>