Time Series Cube DM - IVOA Note

[CresitelloDittmar, Mark]

Markus,

Thanks for the response.. this is good.!

On Tue, Apr 18, 2017 at 4:35 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

>
> I'd say the main things I'm currently doing differently include:
>
> (1) I'd *much* prefer if value+error weren't part of STC and rather
> could be pulled out of STC to have a DM of their own (in my example,
> that's the fake ivoa:Measurement type).
>
>
I'm getting mixed feedback about this from different parties.
The earlier version had separated Measurement (coords)  from Frames et al.
(coordsys).
Combined makes for easier presentation of the 'domain' extensions..

I'm open for (and personally lean a bit toward) separation.  Some of the
other parts (below) may
help sway the organization one way or the other.



> (2) I never liked the separation of frames from the remaining
> annotation in STC; I believe the original idea has been that you
> could somehow re-use tuples of frames on the various axes, and I
> doubt any savings (or functionalities?) possible with this are
> proportional to the complication of having to go through references.
> Hence, in my draft, the coordinates simply have a frame attribute,
> done.  I'd even propose that just based on the type of the thing you
> find in frame, clients should figure out the nature of the axis, and
> you could get rid of verything in coordsys:domain except the frames
> themselves.
>
>
couple comments:
  a) I don't see the 'frame' connection for your Measurements (mag, df)
      ie: the 'value' should be a Coord type.. with relation to 'frame'

  b) on Coords and Frame relations
      Frame is an ObjectType, so it can only be in Composition or Reference
relations to Coord.
      Since a Coord does not own the Frame, and multiple Coord-s may be in
the same Frame,
      the relation is Reference.  So, the modeling of this should not
change, and I hope this then
      becomes a Mapping concern.

      What you are doing here is similar to something I did in an early
serialization, but changed
      because it is not legal annotation.   I tried serializing the
Reference inline.. since it was only
      in one place.

        <ATTRIBUTE dmrole="time">
          <INSTANCE ID="ndgtniuabtea" dmtype="stc2:Coord">
            <ATTRIBUTE dmrole="loc">
              <COLUMN ref="hjd"/>
            </ATTRIBUTE>
            <REFERENCE dmrole="frame">
              <INSTANCE ID="ndgtniuabtha" dmtype="stc2:TimeFrame">
                <ATTRIBUTE dmrole="kind">
                  <LITERAL dmtype="ivoa:string">JD</LITERAL>
                </ATTRIBUTE>
                <ATTRIBUTE dmrole="refPosition">
                  <LITERAL dmtype="ivoa:string">BARYCENTER</LITERAL>
                </ATTRIBUTE>
                <ATTRIBUTE dmrole="timescale">
                  <LITERAL dmtype="ivoa:string">UTC</LITERAL>
                </ATTRIBUTE>
              </INSTANCE>
            </REFERENCE>
          </INSTANCE>
        </ATTRIBUTE>

     Basically saying that the element is a Reference to this thing right
here.. rather than that thing over there.
     I'm not advocating that this is a good way to go with the annotation,
simply stating that I tried a similar thing.

  c) on Coords and Frame relations - part 2
      This IS a model concern.

      I notice that you are linking the Coord to Frame, where the
models/examples we've been putting out are
      linking each Coord value to it's AXIS in the Frame.   Arnold will be
happy to see this!  However, it presents
      two problems (which is why the relation was put on Axis).
       1) a Coord is a value along a particular axis, so this allows you to
know which axis the value is.. (x or y for example)
           For some applications, they may be more interested in the Frame
particulars, but for others, they may be more
           interested in knowing what the legal value range is
(domainMin/Max).  I prefer to keep the relation where it
           conceptually belongs, and the user can access the info they want.

           As reference to Frame, there is no way for the user to really
know which is 'RA' and which is 'DEC' in an ICRS
           Frame, you can only say there is a value pair associated with an
ICRS frame, and assume the ordering.
           This may be 'obvious' in this instance, but what if you have
CARTESIAN frame [x,y,z] and are only providing
           values along a plane [x,z], [y,z], or  [x,y]?   Or a single 'ra'
or 'dec' value without the other?  How do you know
           which one-s are being provided?

       2) this doesn't play well when we consider Coord-s which are in
different domains, but have co-dependent errors.
           (eg. [ t, x, y ] with ellipsoid error.)
           There is no single frame to point at.
           I think this could still be accommodated, but I really think the
relation to Axis serves more applications better.


   d) on "I'd even propose that just based on the type of the thing you
find in frame, clients should figure out the nature of the axis, and you
could get rid of everything in coordsys:domain except the frames"
       From the 'read' point of view, this is probably true.. but for the
models, I want to be able to say
       This element should be a TimeMeasure  ( value associated with Time
Frame + error )... which requires the domain specialization.
       For the TimeSeries example, don't you want to require that the
independent axis is Time related?

       Similar for Target.pos  .. I really want a spatial Position there...
nothing else.

       I don't seem to have this as a specific requirement (on the twiki),
but have been treating it as one.


(3) In ndcube:Cube, I'm using sequences of dependent and independent
> rather than somehow packing them into Observable instances, and
> I'm directly annotating the columns rather than other DM annotations.
>

We are looking at this bit in the modeling, there is a relation I'm not
quite comfortable with, but the
general structure is, I think OK as is.. a collection of DataAxis with
attribute for 'dependent' and a value (Measurement).
In your annotation, are you still trying to cross ref information?  The
in/dependent_axes specify particular columns
which are NOT the Measurement objects.. I'd expect these to BE the
Measurement objects, which are
composed of >1 COLUMN (value + error)



> There are quite a few differences in the actual annotation, too (my
> most ardent wish is to have dmrole just contain the role name to
> preserve readability), but that's for mapping discussions.
>
> Having said all this, I'm totally in favour of deciding on a "current
> version" of STC and the ancillary DMs and putting them up...
> somewhere :-)  Perhaps one could have a temporary section on the DM
> wiki page with links to the current generated HTML docs for the bunch
> of the DMs?
>
> Omar has suggested something similar... and it is a good idea, just
something else to maintain.
The URLs have been pretty static, until we start consolidating/cleaning up
the 'alternates'.
Will see what we can do.

Thanks for all the work!
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170420/2fb9925d/attachment.html>