<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 <<a
href="mailto:msdemlei@ari.uni-heidelberg.de"
moz-do-not-send="true">msdemlei@ari.uni-heidelberg.de</a>>
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>
> > <INSTANCE type="ds:Target"><br>
> > <COLLECTION role="targetPosDef"><br>
> > <INSTANCE ref="RA"/><br>
> > <INSTANCE ref="DEC"/><br>
> > </COLLECTION><br>
> > <ATTRIBUTE role="objectClass"
value="Star"/><br>
> > </INSTANCE><br>
<br>
</blockquote>
<div> <snip></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">>
* 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>
> > <INSTANCE type="coords:Position"
id="pos1"><br>
> > <ATTRIBUTE role="ref_frame"
value="ICRS"/><br>
> > <ATTRIBUTE role="latitude" ref="DEC"/><br>
> > <ATTRIBUTE role="longitude" ref="RA"/><br>
> > </INSTANCE><br>
<br>
or<br>
<br>
> > <INSTANCE type="coords2:EquatorialPosition"
id="pos2"><br>
> > <ATTRIBUTE role="ref_frame"
value="ICRS"/><br>
> > <ATTRIBUTE role="dec" ref="DEC"/><br>
> > <ATTRIBUTE role="ra" ref="RA"/><br>
> > </INSTANCE><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>