<div dir="ltr"><div dir="ltr"><div>Markus,</div><div>   To minimize the nesting.. I&#39;ll address your points here:</div><div>    a) restricting the definition of the element..</div><div>        That strategy works much better for applications and protocols where you have</div><div>        more control of what the provider is giving you.  So, I agree this is not a good idea.</div><div><br></div><div>    b) annotating the original field/param (again).</div><div>        what you show in this case, is pointing to two fields which happen to have nice ID&#39;s &quot;RA&quot;/&quot;DEC&quot;.</div><div>        If the IDs were &quot;sa3t2tfdaf3&quot; and &quot;pynw44wo&quot;, it would have no meaning to the client at all.</div><div>          * which is the latitude? the longitude? the frame?</div><div>        The COLLECTION element seems to be indicating that &quot;the contents can be resolved into </div><div>        whatever type the model element Target.targetPosDef resolves to&quot;.  Unless you do a) above, </div><div>        this could be any number of things.  Which means you&#39;d need to also specify the type within </div><div>        the COLLECTION node, basically re-serializing a particular position instance.</div><div><br></div><div>    last) &quot;use-any&quot; relationship</div><div>       The model shows that Target.position has a multiplicity of 1, the serialization here has 2 instances</div><div>          * any model-aware validator would/should consider this invalid.</div><div>          * clients would need to be model-aware, to know that they should interpret this as 2 representations</div><div>             of the same instance and not as a list of positions.</div><div><br></div><div>    There <b>might</b> be a viable annotation path here.  IF you can annotate that &quot;pos1&quot; and &quot;pos2&quot; are alternate </div><div>    representations of the same instance... so clients could identify them as duplicates.</div><div>    One thought I had some time ago, on an earlier iteration through this topic, was to use the same ID</div><div>    for each instance.. obviously that doesn&#39;t validate as ID must be unique within the table.</div><div>    That would mean adding some secondary inst_id=&quot;XXX&quot; which would be the same for &quot;pos1&quot; and &quot;pos2&quot;</div><div>    to indicate that they were the same, and Target.position would reference the inst_id=&quot;XXX&quot;.</div><div>    Sounds kind-of like a substitution group.</div><div>    This seems like a lot of logic changes/work for the clients.</div><div><br></div><div>Finally.. you ask &quot;I&#39;m not sure if VO-DML allows these types of &quot;weakly-typed&quot; references already -- Gerard?&quot;</div><div>This is really important.  The objections you are raising to the MC models have little to do with the model,</div><div>and everything to do with VO-DML rules and Annotation syntax.</div><div>   * A VO-DML model identifies the models it uses.. these are explicit declarations of the model/version.</div><div>   * There is no allowance for a model to reference any &quot;version of coords:Position&quot;</div><div><br></div><div>Mark</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 18, 2020 at 3:34 AM Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">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 Thu, Sep 17, 2020 at 05:53:57PM -0400, CresitelloDittmar, Mark wrote:<br>
&gt; Taking your pseudo annotated instances another step..<br>
&gt; Here, instead of a new &quot;meas&quot; model, I made a second &quot;coords&quot; model<br>
&gt; changing the Position element.<br>
&gt; I want to use this (ra,dec) pair in my Dataset Metadata annotation as the<br>
&gt; Target.position... the pair is annotated against 2 different coords models.<br>
&gt; Which do I reference in my Target annotation?  Or, how would you want to<br>
&gt; see that?<br>
<br>
So, in my ideal world we would try to avoid such inter-model links as<br>
much as possible -- the problems ensuing from linking all these<br>
various components are so serious that accepting certain limitations<br>
is a good deal in my book.<br>
<br>
Your example:<br>
<br>
&gt; <br>
&gt;   &lt;FIELD ID=&quot;RA&quot; name=&quot;ra&quot;/&gt;<br>
&gt;   &lt;FIELD ID=&quot;DEC&quot; name=&quot;dec&quot;/&gt;<br>
&gt; <br>
&gt;   &lt;INSTANCE type=&quot;coords:Position&quot; id=&quot;pos1&quot;&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;ref_frame&quot; value=&quot;ICRS&quot;/&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;latitude&quot; ref=&quot;DEC&quot;/&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;longitude&quot; ref=&quot;RA&quot;/&gt;<br>
&gt;   &lt;/INSTANCE&gt;<br>
&gt; <br>
&gt;   &lt;INSTANCE type=&quot;coords2:EquatorialPosition&quot; id=&quot;pos2&quot;&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;ref_frame&quot; value=&quot;ICRS&quot;/&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;dec&quot; ref=&quot;DEC&quot;/&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;ra&quot; ref=&quot;RA&quot;/&gt;<br>
&gt;   &lt;/INSTANCE&gt;<br>
&gt; <br>
&gt;   &lt;INSTANCE type=&quot;ds:Target&quot;&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;position&quot; ref=&quot;???&quot; /&gt;<br>
&gt;     &lt;ATTRIBUTE role=&quot;objectClass&quot; value=&quot;Star&quot;/&gt;<br>
&gt;   &lt;/INSTANCE&gt;<br>
<br>
[id attributes added by me]<br>
<br>
is one where the win of referencing complex objects form other data<br>
models is probably worth it, though.  We ought to briefly consider<br>
the non-entangling alternatives, though:<br>
<br>
(a) saying &quot;the observations we&#39;re dealing with are always on the<br>
(Earth) sky, and thus we say there&#39;s always an RA and a Dec in ICRS,<br>
and thus we&#39;re just referencing targetRA, targetDec rather than a<br>
full position instance&quot;; I think this would make dealing with these<br>
things a good deal easier for clients, but of course you can&#39;t<br>
annotate historical data products with this, and it breaks<br>
spectacularly with solar system data.  So, for *this* particular case<br>
it&#39;s probably not a good idea.<br>
<br>
(b) saying &quot;we just reference the fields/params making up the<br>
position, in a way promoting the *annotations*&quot;.  In the concrete<br>
example, this would be:<br>
<br>
   &lt;INSTANCE type=&quot;ds:Target&quot;&gt;<br>
     &lt;COLLECTION role=&quot;targetPosDef&quot;&gt;<br>
      &lt;INSTANCE ref=&quot;RA&quot;/&gt;<br>
      &lt;INSTANCE ref=&quot;DEC&quot;/&gt;<br>
     &lt;/COLLECTION&gt;<br>
     &lt;ATTRIBUTE role=&quot;objectClass&quot; value=&quot;Star&quot;/&gt;<br>
   &lt;/INSTANCE&gt;<br>
<br>
The extra indirection may seem a bit clumsy at first, but if you<br>
think of a client just accumulating annotations on the column objects<br>
it has (and then figuing out which of those it understands), this<br>
style becomes quite natural.<br>
<br>
<br>
<br>
But there are certainly cases when you cannot avoid referencing other<br>
complex objects.  The only flag-day-avoiding pattern I can see here<br>
is to let such references be &quot;use-any&quot; relationships (perhaps<br>
represented by giving an ATTRIBUTE multiple times for a given role?):<br>
<br>
   &lt;INSTANCE type=&quot;ds:Target&quot;&gt;<br>
     &lt;ATTRIBUTE role=&quot;position&quot; ref=&quot;pos1&quot; /&gt;<br>
     &lt;ATTRIBUTE role=&quot;position&quot; ref=&quot;pos2&quot; /&gt;<br>
     &lt;ATTRIBUTE role=&quot;objectClass&quot; value=&quot;Star&quot;/&gt;<br>
   &lt;/INSTANCE&gt;<br>
<br>
The client would then go through the various fillers for position,<br>
inferring their types from the instances referenced, and use whatever<br>
it understands and/or prefers.<br>
<br>
I&#39;m not sure if VO-DML allows these types of &quot;weakly-typed&quot;<br>
references already -- Gerard?<br>
<br>
          -- Markus<br>
</blockquote></div></div></div>