MCT - model document delivery.

[Markus Demleitner]

Hi Mark,

On Thu, Sep 17, 2020 at 05:53:57PM -0400, CresitelloDittmar, Mark wrote:
> Taking your pseudo annotated instances another step..
> Here, instead of a new "meas" model, I made a second "coords" model
> changing the Position element.
> I want to use this (ra,dec) pair in my Dataset Metadata annotation as the
> Target.position... the pair is annotated against 2 different coords models.
> Which do I reference in my Target annotation?  Or, how would you want to
> see that?

So, in my ideal world we would try to avoid such inter-model links as
much as possible -- the problems ensuing from linking all these
various components are so serious that accepting certain limitations
is a good deal in my book.

Your example:

> 
>   <FIELD ID="RA" name="ra"/>
>   <FIELD ID="DEC" name="dec"/>
> 
>   <INSTANCE type="coords:Position" id="pos1">
>     <ATTRIBUTE role="ref_frame" value="ICRS"/>
>     <ATTRIBUTE role="latitude" ref="DEC"/>
>     <ATTRIBUTE role="longitude" ref="RA"/>
>   </INSTANCE>
> 
>   <INSTANCE type="coords2:EquatorialPosition" id="pos2">
>     <ATTRIBUTE role="ref_frame" value="ICRS"/>
>     <ATTRIBUTE role="dec" ref="DEC"/>
>     <ATTRIBUTE role="ra" ref="RA"/>
>   </INSTANCE>
> 
>   <INSTANCE type="ds:Target">
>     <ATTRIBUTE role="position" ref="???" />
>     <ATTRIBUTE role="objectClass" value="Star"/>
>   </INSTANCE>

[id attributes added by me]

is one where the win of referencing complex objects form other data
models is probably worth it, though.  We ought to briefly consider
the non-entangling alternatives, though:

(a) saying "the observations we're dealing with are always on the
(Earth) sky, and thus we say there's always an RA and a Dec in ICRS,
and thus we're just referencing targetRA, targetDec rather than a
full position instance"; I think this would make dealing with these
things a good deal easier for clients, but of course you can't
annotate historical data products with this, and it breaks
spectacularly with solar system data.  So, for *this* particular case
it's probably not a good idea.

(b) saying "we just reference the fields/params making up the
position, in a way promoting the *annotations*".  In the concrete
example, this would be:

   <INSTANCE type="ds:Target">
     <COLLECTION role="targetPosDef">
      <INSTANCE ref="RA"/>
      <INSTANCE ref="DEC"/>
     </COLLECTION>
     <ATTRIBUTE role="objectClass" value="Star"/>
   </INSTANCE>

The extra indirection may seem a bit clumsy at first, but if you
think of a client just accumulating annotations on the column objects
it has (and then figuing out which of those it understands), this
style becomes quite natural.



But there are certainly cases when you cannot avoid referencing other
complex objects.  The only flag-day-avoiding pattern I can see here
is to let such references be "use-any" relationships (perhaps
represented by giving an ATTRIBUTE multiple times for a given role?):

   <INSTANCE type="ds:Target">
     <ATTRIBUTE role="position" ref="pos1" />
     <ATTRIBUTE role="position" ref="pos2" />
     <ATTRIBUTE role="objectClass" value="Star"/>
   </INSTANCE>

The client would then go through the various fillers for position,
inferring their types from the instances referenced, and use whatever
it understands and/or prefers.

I'm not sure if VO-DML allows these types of "weakly-typed"
references already -- Gerard?

          -- Markus