<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi all,</p>
    <p>    I'm not discussing annotations there. Only the data model.</p>
    <p>    Any annotation would have to reflect the datamodel
      eventually.</p>
    <p>    So, as for the datamodel issue,  the question raised by
      Markus is something like : can we "model" our data by
      parallelizing (small ?) independant datamodels ?<br>
    </p>
    <p>    I think not, otherwise we loose any benefit of datamodelling
      !<br>
    </p>
    <p>     DataModels provides a logical view on the relationships
      between different subparts of our data.</p>
    <p>     let me give an example : <br>
    </p>
    <p>                Obscore is a flat datamodel with quasi-unicity 
      of attribute for each quantity. But potentially we can imagine
      extensions much more complex (eventually towards full dataset
      metadata and Cube maybe ? but even simpler extensions may be
      considered)</p>
    <p>                 Imagine we want to include in an OBscore
      extension the target position (which we do not have at the moment
      although we already have the target name). It is different from
      the so called "spatial location" (= s_ra and s_dec), which is
      intended to be the typical position of the "centroid" of the
      dataset. I think everybody agrees it could be different from the
      actual "target" position of the observation providing the dataset,
      no ?</p>
    <p>                In this example although we have two positions
      (same ucds) we still are in a "flat model" stituation we could
      solve by differentiating names/utypes. But the model structure
      will encompass two "positions" anyway<br>
    </p>
    <p>                 But  to go a little further if we want to
      introduce a time or spectral "support" made of a list of intervals
      beside the coarse-grained "bounds" : em_min/em_max, t_min/t_max we
      will end with a lot of spectral coordinates and time slots which
      only a structured datamodel can allow to describe.</p>
    <p>                Any annotation would have to map this complex
      structuration of the (meta)data.</p>
    <p>Cheers</p>
    <p>François<br>
    </p>
    <p><br>
    </p>
    <p>          <br>
    </p>
    <p>          <br>
    </p>
    <div class="moz-cite-prefix">Le 22/09/2020 à 16:22,
      CresitelloDittmar, Mark a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH4enyOyEBz_rroTpxZYcGSdw0uXAUruTY85tVoOGxFAqA4QZg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 4:51
            AM Markus Demleitner &lt;<a
              href="mailto:msdemlei@ari.uni-heidelberg.de"
              moz-do-not-send="true">msdemlei@ari.uni-heidelberg.de</a>&gt;
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi
            Mark,<br>
            <br>
            On Fri, Sep 18, 2020 at 11:00:03AM -0400, CresitelloDittmar,
            Mark wrote:<br>
            [the following refers to this:]<br>
            &gt; &gt;    &lt;INSTANCE type="ds:Target"&gt;<br>
            &gt; &gt;      &lt;COLLECTION role="targetPosDef"&gt;<br>
            &gt; &gt;       &lt;INSTANCE ref="RA"/&gt;<br>
            &gt; &gt;       &lt;INSTANCE ref="DEC"/&gt;<br>
            &gt; &gt;      &lt;/COLLECTION&gt;<br>
            &gt; &gt;      &lt;ATTRIBUTE role="objectClass"
            value="Star"/&gt;<br>
            &gt; &gt;    &lt;/INSTANCE&gt;<br>
            <br>
          </blockquote>
          <div> &lt;snip&gt;</div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">&gt; 
                     * which is the latitude? the longitude? the frame?<br>
            <br>
            Target does not know about them, nor should it.  A target is
            a<br>
            target, whether it is identified by a coords spherical
            position or<br>
            some other way to denote a location in.  The good thing
            about keeping<br>
            such details out of ds:Target is that it will just continue
            to work<br>
            when we're moving into the solar system (where lat and long
            just<br>
            isn't enough).  Just say which fields and params belong to
            the target<br>
            designation and leave their annotation to a specialised
            class.<br>
          </blockquote>
          <div><br>
          </div>
          <div>In your vision then, what does the model element
            ds:Target contain?</div>
          <div>I don't mean the annotation, the model.  The current
            model has</div>
          <div> ds:Target</div>
          <div>    + name: ivoa:string</div>
          <div>    + description: ivoa:string</div>
          <div>    + position: meas:Position[0..1]</div>
          <div>    + objectClass: ivoa:string</div>
          <div> <br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">In
            this particular case, that would be one of:<br>
            <br>
            &gt; &gt;   &lt;INSTANCE type="coords:Position"
            id="pos1"&gt;<br>
            &gt; &gt;     &lt;ATTRIBUTE role="ref_frame"
            value="ICRS"/&gt;<br>
            &gt; &gt;     &lt;ATTRIBUTE role="latitude" ref="DEC"/&gt;<br>
            &gt; &gt;     &lt;ATTRIBUTE role="longitude" ref="RA"/&gt;<br>
            &gt; &gt;   &lt;/INSTANCE&gt;<br>
            <br>
            or<br>
            <br>
            &gt; &gt;   &lt;INSTANCE type="coords2:EquatorialPosition"
            id="pos2"&gt;<br>
            &gt; &gt;     &lt;ATTRIBUTE role="ref_frame"
            value="ICRS"/&gt;<br>
            &gt; &gt;     &lt;ATTRIBUTE role="dec" ref="DEC"/&gt;<br>
            &gt; &gt;     &lt;ATTRIBUTE role="ra" ref="RA"/&gt;<br>
            &gt; &gt;   &lt;/INSTANCE&gt;<br>
            <br>
            (or both) -- you see that as long as a client understands
            any of<br>
            coords and coords2, they are able to fully annotate RA and
            DEC, *and*<br>
            work out that they are the position for the Target of
            something.<br>
            <br>
          </blockquote>
          <div><br>
          </div>
          <div>So, the client parsing Target, </div>
          <div>  * sees the attribute 'targetPosDef', and because they
            know the model, know this is some sort of Position.. </div>
          <div>  * so they scan all the other annotation snippets for a
            coords*:Position class or subclass which also includes
            references to fields "RA" and "DEC". </div>
          <div>  * they find 2 "pos1" and "pos2" which are the same
            instance annotated to 2 different coords model versions.</div>
          <div>  * they select 1, whichever they prefer, and instantiate
            the Target.targetPosDef.</div>
          <div>This seems really inefficient to be doing this for every
            complex object in the serialization.</div>
          <div><br>
          </div>
          <div>Mark</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
  </body>
</html>