Markus,<div><br></div><div>I&#39;m on leave this week.. so just a quick reply.</div><div>This approach is basically butting an instance against a role across model boundaries, instead of defining a relationship.  This is a very different approach than the vo-dml and compliant model work has been taking over the past few years.  I don&#39;t even know how to express that in the model.  It seems a bit late in the game to be expressing this concern so urgently.</div><div><br></div><div>(Harrumph),  off to enjoy my vacation,</div><div>Mark</div><div><br></div><div><br>On Monday, February 27, 2017, Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mark,<br>
<br>
On Fri, Feb 24, 2017 at 08:50:24PM -0500, CresitelloDittmar, Mark wrote:<br>
&gt; Can you make a statement about how you think this proposed arrangement<br>
&gt; would effect<br>
&gt;   1) Validation<br>
<br>
You separately validate against each version of each DM that is in<br>
the annotation.  This is actually, I claim, what matters to clients.<br>
Say I&#39;m a simple plot program -- I&#39;m not at all concerned about<br>
PubDIDs or about objects observed, all I need is figure out which<br>
axis make up the cube in what way.  So, I need valid NDCube-1.x, but<br>
I don&#39;t break if the data provider chose to annotate with Dataset-1.0<br>
or Dataset-2.0.<br>
<br>
Say I&#39;m a component that can transform coordinates between different<br>
frames.  I&#39;m concerned about correct STC-2.x annotation, but I<br>
couldn&#39;t care less if the coordinates I&#39;m converting are axes of an<br>
NDCube or are source positions in a source DM, or yet something else,<br>
and again I don&#39;t care at all about any other DM that might be<br>
instanciated in that particular dataset.<br>
<br>
Say I&#39;m a cube analysis program.  In that case I&#39;ll use NDCube to<br>
understand the structure, STC to do reprojections and regridding,<br>
perhaps photometry to convert the units of the dependent axis, or<br>
some other DM if the cube values require it.  And for all of these, I<br>
can simultaneously support multiple versions (independently from each<br>
other and thus relatively cheaply), so I can maintain backwards<br>
compatibility for a long time.<br>
<br>
&gt;   2) Interoperability<br>
<br>
Interoperability is actually what this is about.  If we build<br>
Megamodels doing everything, we either can&#39;t evolve the model or will<br>
break all kinds of clients needlessly all the time -- typcially,<br>
whatever annotation they expect *would* be there, but because their<br>
positition in the embedding DM changed, they can&#39;t find it any more.<br>
Client authors will, by the way, quickly figure this out and start<br>
hacking around it in weird ways, further harming interoperability;<br>
we&#39;ve seen it with VOTable, which is what led us to the<br>
recommendations in the XML versioning note.<br>
<br>
Keeping individual DMs small and as independent as humanly possible,<br>
even if one has to be incompatibly changed, most other functionality<br>
will just keep working and code won&#39;t have to be touched (phewy!).<br>
<br>
I&#39;d argue by pulling all the various aspects into one structure,<br>
we&#39;re following the God object anti-pattern<br>
(<a href="https://en.wikipedia.org/wiki/God_object" target="_blank">https://en.wikipedia.org/<wbr>wiki/God_object</a>).  Ok, since we&#39;re using<br>
composition rather than a flat aggregation, it&#39;s not a clear case,<br>
but I maintain we&#39;re buying into many of the issues with God objects<br>
without having to.<br>
<br>
&gt; ???<br>
&gt; The Cube model has the following links to other models<br>
&gt;   a) Dataset - defines itself as an extension of ObsDataset<br>
&gt;   b) Coordsys - where coordinate system objects and the pattern for Frames<br>
&gt; are defined<br>
&gt;   c) Coords - where the pattern for Coordinates is defined (and implemented<br>
&gt; for several domains, but that is not important here)<br>
&gt;   d) Trans - where Transform mappings are defined.<br>
<br>
For all of these I&#39;d ask: How does it help clients to have these<br>
pulled together in one place?  What can it do that it couldn&#39;t do if<br>
these were separate annotations?<br>
<br>
That&#39;s actually my personal guideline for DM design: &quot;But does it<br>
help clients?&quot;<br>
<br>
&gt; You say that cube should not import Coords to identify what a Coordinate<br>
&gt; is.. that it simply indicates that &#39;it has Coordinates&#39;.<br>
&gt; It currently says that an Observable is a coords:DerivedCoordinate .. which<br>
&gt; is an abstract object restricted to<br>
&gt; follow the pattern defined in that model.  Any model can implement the<br>
&gt; pattern and declare itself as that type of Coordinate,<br>
&gt; and be instantly usable in a cube instance.<br>
&gt;<br>
&gt; Without this explicit link, then one cannot validate across these<br>
&gt; boundaries.<br>
&gt;<br>
&gt; An instance would have<br>
&gt;    Element with role cube:DataAxis.observable<br>
&gt;       Instance with type &lt;whatever implemented &quot;Coordinate&quot; type&gt;  ie:<br>
&gt; spec:FluxCoord<br>
&gt;<br>
&gt; But a validator cannot check if FluxCoord is actually a Coordinate... (I<br>
&gt; could put a ds:Curation  instance<br>
&gt; there.. the role and the instance would be individually valid, but the<br>
&gt; combination is nonsense).<br>
<br>
I&#39;d maintain there&#39;s far too much that might work as coordinate<br>
(Filter name, anyone?) or, even worse, observable to even hope that a<br>
static validator will provide more benefit that harm (in terms of<br>
making things hard that clients would otherwise have no issue with).<br>
In the end, people will annotate something as a Coordinate just to<br>
shut up the validator and confuse actual users of a Coordinate DM,<br>
making things worse.  And have mis-pointed axes really been a<br>
problem in any published dataset?<br>
<br>
So, I&#39;m afraid I find the use case &quot;make sure the thing referenced<br>
from an NDCube axis is derived from Coordinate&quot; too unconvincing to<br>
warrant the complication of linking otherwise independent DMs.<br>
<br>
&gt; And.. without the link, there is no binding the various implementations of<br>
&gt; Coordinate to the pattern.<br>
<br>
I have to admit that I find the current artefacts for current STC on<br>
volute somewhat hard to figure out. But from what I can see I&#39;d be<br>
unsure how that binding would help me as a client; that may, of<br>
course, be because I&#39;ve not quite understood the pattern.<br>
<br>
If this turned out to be true, I&#39;d take that as an indication that<br>
Coordinate should move into ivoa or, perhaps, a DM of its own, being<br>
so generic a concept that it actually needs sharing across<br>
&quot;sub-domains&quot;.<br>
<br>
&gt; Interoperability would suffer because there would be no guarantee of<br>
&gt; compatibility of different Coordinate types.<br>
&gt; My code that understands the Coords pattern would have no hope of<br>
&gt; understanding any portion of<br>
&gt; independently defined Coordinates.<br>
<br>
What does &quot;understand&quot; mean here?  This is not a rhethorical question<br>
-- I&#39;m actually trying to understand where the complication comes<br>
from.  What information, in addition to what you get from STC or<br>
comparable annotation, does your code require, and is there really no<br>
other way to communicate it without having to have a hard link<br>
between NDCube and STC (or any other &quot;physical&quot; DM, really)?<br>
<br>
Thanks,<br>
<br>
          Markus<br>
</blockquote></div>