vo-dml in votable

[Markus Demleitner]

Hi,

To avoid excessive crossposting, I'd suggest to move this discussion to
dm at ivoa.net exclusively.

Then:
On Wed, Feb 11, 2015 at 11:02:29AM -0500, Gerard Lemson wrote:
> It would be nice if we could quickly agree how to annotate VOTable elements
> with metadata pointing to VO-DMl data models.

Yes!  Please!

> In the votable/vo-dml session in Banff we came to a decision to add a new
> element to VOTable that would represent this mapping and would take the
> place of the utype attributes we had assumed to use for that in the current
> mapping document in
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx

If any of the opponents of using utypes have reconsidered in the
meantime, this would be an excellent opportunity to speak up and save
us the trouble of having to change VOTable -- I still maintain
utypes-only would be perfectly workable, and it definitely has a much
cleaner migration path.

Assuming utype's not going to happen, here's my takes on Gerard's
proposals (note: I've not even tried implementation with any of
these, contrary to a utypes-only approach; hence, this may miss
extremely important points or be plain wrong).



(1) http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml

    <PARAM name="name" datatype="char" arraysize="*" value="ivoa">
      <VODML type="ivoa:string" role="vo-dml:Model.name"/>
    </PARAM>

I like this for its relative simplicity.  I cannot quite see the
consequences of  allowing mutiple such annotations (see also below),
but allowing the declaration of both type and role actually helps
compared to a utypes-only situation (but IMHO only with atomic types;
if this attribute were a complex type, I believe the type annotation
should be there and *not* in the reference).  I could definitely live
with this.

(2) http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4b.xml

          <VODML>
            <TYPE>src:source.AlignedEllipse</TYPE>
            <ROLE>src:source.Source.positionError</ROLE>
            <ALTTYPE>src:source.SkyError</ALTTYPE>
          </VODML>

I'm not so sure I'm too hot about enabling multiple types, let alone
in a single annotation -- of course, this sounds nifty as it seems to
facilitate best-effort parsing (which I'm always a fan of); this would
let a generic client work out that a FancyPhotPoint (which it doesn't
know) actually is-a PhotPoint with some additional information, so
the generic client can still make a PhotPoint out of what it found
and ignore the rest in a safe fashion.

Of course, by inspecting VO-DML documents it could work that out by
itself, but it'd need to look at all these external documents, and
enabling best-effort without having to manage external resources
(which keep breaking) would clearly be preferable.

But then having TYPE *and* ALTTYPE at the same time intutively seems
wrong to me; I'd have to read up on type theory to figure out if
there's a useful type concept that would allow sensible statements
like these.  I'd be less worried about BASECLASS.

FWIW, my strong preference would be for something like duck typing
anyway, where best-effort parsing would be enabled through fixed,
well-known role names (that, in contrast to current utypes, would
still have a formal definition and meaning; that's the all-or-nothing
thing).  For instance, a program could rely on phot:zeroPost to be a
photometric zero point, and whatever object that's in could serve as
a means to figure that out, even if the client didn't know the actual
type that thing has (e.g., because it was extended to contain
provenance information and thus has a new type).

In the example cited above, incidentally, I'd have to say an error to
me is a role and not a type; with that, the problem doesn't even turn
up, as you'd have somethign like

<GROUP id="890">
  <VODML>
    <TYPE>src:source.AlignedEllipse</TYPE>
    <!-- no role, no additional type -->
  </VODML>
  ...
</GROUP>

<GROUP id="position">
  <GROUPref ref="somethingelse">
    <ROLE>src:value</ROLE>
  </GROUPref>
  <GROUPref ref="890">
    <ROLE>src:error</ROLE>
  </GROUPref>
</GROUP>

In addition, if we agree that within a given structure, role is
unique, an attribute on GROUPref would do would make this a lot more
compact.

And yes, if we muck around with VOTable anyway, then let's add
GROUPref.  It makes whatever annotation we decide upon a whole to
more straightforward.

(3) http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4c.xml

          <VODML>
            <TYPE>src:source.AlignedEllipse</TYPE>
            <TYPE>src:source.SkyError</TYPE>
            <ROLE>src:source.Source.positionError</ROLE>
          </VODML>

In contrast to (2), the difference is that there's no "preferred"
type any more.  Again, I'd have to read up on type calculus before I
stop being skeptical about two types, regardless of whether or not
there's an explicit preference.



Summing up:  Without having implemented anything at this point
(meaning: it wouldn't take much to convince me of something else), I
believe 4a can do everything we need to do.  It's also the most
straightforward and compact option (probably even more compact than
just using utype).  Assuming utype's really out, it gets my vote.

But if we touch VOTable, I want a GROUPref element in addition to
VODML (and it'd not be so easy to convince me otherwise).

Cheers,

        Markus