<div dir="ltr"><div dir="ltr"><div>Markus,</div><div> To minimize the nesting.. I'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's "RA"/"DEC".</div><div> If the IDs were "sa3t2tfdaf3" and "pynw44wo", 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 "the contents can be resolved into </div><div> whatever type the model element Target.targetPosDef resolves to". Unless you do a) above, </div><div> this could be any number of things. Which means you'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) "use-any" 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 "pos1" and "pos2" 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't validate as ID must be unique within the table.</div><div> That would mean adding some secondary inst_id="XXX" which would be the same for "pos1" and "pos2"</div><div> to indicate that they were the same, and Target.position would reference the inst_id="XXX".</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 "I'm not sure if VO-DML allows these types of "weakly-typed" references already -- Gerard?"</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 "version of coords:Position"</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 <<a href="mailto:msdemlei@ari.uni-heidelberg.de">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 Thu, Sep 17, 2020 at 05:53:57PM -0400, CresitelloDittmar, Mark wrote:<br>
> Taking your pseudo annotated instances another step..<br>
> Here, instead of a new "meas" model, I made a second "coords" model<br>
> changing the Position element.<br>
> I want to use this (ra,dec) pair in my Dataset Metadata annotation as the<br>
> Target.position... the pair is annotated against 2 different coords models.<br>
> Which do I reference in my Target annotation? Or, how would you want to<br>
> 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>
> <br>
> <FIELD ID="RA" name="ra"/><br>
> <FIELD ID="DEC" name="dec"/><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>
> <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>
> <INSTANCE type="ds:Target"><br>
> <ATTRIBUTE role="position" ref="???" /><br>
> <ATTRIBUTE role="objectClass" value="Star"/><br>
> </INSTANCE><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 "the observations we're dealing with are always on the<br>
(Earth) sky, and thus we say there's always an RA and a Dec in ICRS,<br>
and thus we're just referencing targetRA, targetDec rather than a<br>
full position instance"; I think this would make dealing with these<br>
things a good deal easier for clients, but of course you can't<br>
annotate historical data products with this, and it breaks<br>
spectacularly with solar system data. So, for *this* particular case<br>
it's probably not a good idea.<br>
<br>
(b) saying "we just reference the fields/params making up the<br>
position, in a way promoting the *annotations*". In the concrete<br>
example, this would be:<br>
<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>
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 "use-any" relationships (perhaps<br>
represented by giving an ATTRIBUTE multiple times for a given role?):<br>
<br>
<INSTANCE type="ds:Target"><br>
<ATTRIBUTE role="position" ref="pos1" /><br>
<ATTRIBUTE role="position" ref="pos2" /><br>
<ATTRIBUTE role="objectClass" value="Star"/><br>
</INSTANCE><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'm not sure if VO-DML allows these types of "weakly-typed"<br>
references already -- Gerard?<br>
<br>
-- Markus<br>
</blockquote></div></div></div>