MCT - model document delivery.

[François Bonnarel]

Hi all,

     I'm not discussing annotations there. Only the data model.

     Any annotation would have to reflect the datamodel eventually.

     So, as for the datamodel issue,  the question raised by Markus is 
something like : can we "model" our data by parallelizing (small ?) 
independant datamodels ?

     I think not, otherwise we loose any benefit of datamodelling !

      DataModels provides a logical view on the relationships between 
different subparts of our data.

      let me give an example :

                 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)

                  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 ?

                 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

                  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.

                 Any annotation would have to map this complex 
structuration of the (meta)data.

Cheers

François




Le 22/09/2020 à 16:22, CresitelloDittmar, Mark a écrit :
>
>
> On Mon, Sep 21, 2020 at 4:51 AM Markus Demleitner 
> <msdemlei at ari.uni-heidelberg.de 
> <mailto:msdemlei at ari.uni-heidelberg.de>> wrote:
>
>     Hi Mark,
>
>     On Fri, Sep 18, 2020 at 11:00:03AM -0400, CresitelloDittmar, Mark
>     wrote:
>     [the following refers to this:]
>     > >    <INSTANCE type="ds:Target">
>     > >      <COLLECTION role="targetPosDef">
>     > >       <INSTANCE ref="RA"/>
>     > >       <INSTANCE ref="DEC"/>
>     > >      </COLLECTION>
>     > >      <ATTRIBUTE role="objectClass" value="Star"/>
>     > >    </INSTANCE>
>
>  <snip>
>
>     >          * which is the latitude? the longitude? the frame?
>
>     Target does not know about them, nor should it.  A target is a
>     target, whether it is identified by a coords spherical position or
>     some other way to denote a location in.  The good thing about keeping
>     such details out of ds:Target is that it will just continue to work
>     when we're moving into the solar system (where lat and long just
>     isn't enough).  Just say which fields and params belong to the target
>     designation and leave their annotation to a specialised class.
>
>
> In your vision then, what does the model element ds:Target contain?
> I don't mean the annotation, the model.  The current model has
>  ds:Target
>     + name: ivoa:string
>     + description: ivoa:string
>     + position: meas:Position[0..1]
>     + objectClass: ivoa:string
>
>     In this particular case, that would be one of:
>
>     > >   <INSTANCE type="coords:Position" id="pos1">
>     > >     <ATTRIBUTE role="ref_frame" value="ICRS"/>
>     > >     <ATTRIBUTE role="latitude" ref="DEC"/>
>     > >     <ATTRIBUTE role="longitude" ref="RA"/>
>     > >   </INSTANCE>
>
>     or
>
>     > >   <INSTANCE type="coords2:EquatorialPosition" id="pos2">
>     > >     <ATTRIBUTE role="ref_frame" value="ICRS"/>
>     > >     <ATTRIBUTE role="dec" ref="DEC"/>
>     > >     <ATTRIBUTE role="ra" ref="RA"/>
>     > >   </INSTANCE>
>
>     (or both) -- you see that as long as a client understands any of
>     coords and coords2, they are able to fully annotate RA and DEC, *and*
>     work out that they are the position for the Target of something.
>
>
> So, the client parsing Target,
>   * sees the attribute 'targetPosDef', and because they know the 
> model, know this is some sort of Position..
>   * so they scan all the other annotation snippets for a 
> coords*:Position class or subclass which also includes references to 
> fields "RA" and "DEC".
>   * they find 2 "pos1" and "pos2" which are the same instance 
> annotated to 2 different coords model versions.
>   * they select 1, whichever they prefer, and instantiate the 
> Target.targetPosDef.
> This seems really inefficient to be doing this for every complex 
> object in the serialization.
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200922/6a19d760/attachment-0001.html>