vo-dml in votable

[Francoise Genova]

Hi Markus,

In view of the potential consequences on Apps I strongly suggest that 
the debate is kept on the two lists, dm AND apps. VOTable is Apps and 
this is a VOTable topic.

Cheers

Francoise

Le 12/02/2015 10:38, Markus Demleitner a écrit :
> 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