MCT - model document delivery.

[CresitelloDittmar, Mark]

Markus,
   To minimize the nesting.. I'll address your points here:
    a) restricting the definition of the element..
        That strategy works much better for applications and
protocols where you have
        more control of what the provider is giving you.  So, I agree this
is not a good idea.

    b) annotating the original field/param (again).
        what you show in this case, is pointing to two fields which happen
to have nice ID's "RA"/"DEC".
        If the IDs were "sa3t2tfdaf3" and "pynw44wo", it would have no
meaning to the client at all.
          * which is the latitude? the longitude? the frame?
        The COLLECTION element seems to be indicating that "the contents
can be resolved into
        whatever type the model element Target.targetPosDef resolves to".
Unless you do a) above,
        this could be any number of things.  Which means you'd need to also
specify the type within
        the COLLECTION node, basically re-serializing a particular position
instance.

    last) "use-any" relationship
       The model shows that Target.position has a multiplicity of 1, the
serialization here has 2 instances
          * any model-aware validator would/should consider this invalid.
          * clients would need to be model-aware, to know that they should
interpret this as 2 representations
             of the same instance and not as a list of positions.

    There *might* be a viable annotation path here.  IF you can annotate
that "pos1" and "pos2" are alternate
    representations of the same instance... so clients could identify them
as duplicates.
    One thought I had some time ago, on an earlier iteration through this
topic, was to use the same ID
    for each instance.. obviously that doesn't validate as ID must be
unique within the table.
    That would mean adding some secondary inst_id="XXX" which would be the
same for "pos1" and "pos2"
    to indicate that they were the same, and Target.position would
reference the inst_id="XXX".
    Sounds kind-of like a substitution group.
    This seems like a lot of logic changes/work for the clients.

Finally.. you ask "I'm not sure if VO-DML allows these types of
"weakly-typed" references already -- Gerard?"
This is really important.  The objections you are raising to the MC models
have little to do with the model,
and everything to do with VO-DML rules and Annotation syntax.
   * A VO-DML model identifies the models it uses.. these are explicit
declarations of the model/version.
   * There is no allowance for a model to reference any "version of
coords:Position"

Mark


On Fri, Sep 18, 2020 at 3:34 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200918/cec85dea/attachment.html>