vo-dml in votable

[Markus Demleitner]

Hi,

On Tue, Feb 17, 2015 at 01:25:57PM +0100, François Bonnarel wrote:
>     From the DAL point of view I think there is one only candidate so far to
> possibly use VO-DML in DAL protocols which is in SIAV2 future GetMetadata

Oh, IMHO having good, standard representations of complex data
structures is important throughout DAL. In particular, and I've been
lamenting this for years, defining coordinate sets and their metadata
is central to whatever we're doing.  As Pierre pointed out in Banff,
the state of matters there is an embarrassment to our entire
community, and I frankly cannot see a good way out of this without
VO-DML (rolling back to COOSYS certainly is better than nothing, but
the reasons for deprecating it in the first place still are there).

And then there's datalink (ok, we ad-hocced its serialisation now,
but development would have been much easier with a solid DM
framework).  Similar considerations apply to "AccessData", for which
PDL+VO-DML would give a nice, principled framework.

So, yes, VO-DML is highly relevant to DAL (but see below on
cross-posting), and we'd have a much easier time with our current
standards if it were already there.

>       Having in mind the coming use case of SIAV2/GetMetadata and ImageDM
> serialisation in VOTABLE I think the new VO-DML element is fine. Like Markus
> I don't quite understand the actual meaning of "type" and "role" . To me
> "role" would be more about some description of the relationshiops to other
> parts of the model while "type" is more about the internal structure or
> content of the considered VOTBALE feature.

Oh, I believe I do understand the role/type business, and indeed, I
believe your explanation basically explains things quite nicely.  But
just to be sure we're actually talking about roughly the same
phenomena, here's an example of the type we've been discussing in the
context of the tiger team:

Suppose you have a 2D position; I'm marking roles as 'role', types as
<type>:

  {'val': {'c1': 2/<float>, 'c2': 4/<float>}/<vector2D>
  }/<position2D>

Now add a derivative; this could be cartesian:

  {'val': {'c1': 2/<float>, 'c2': 4/<float>}/<vector2D>
    'velocity': {'c1': 0.1/<float>, 'c2': 0.2/<float>}/<vector2D> 
  }/<position2D>

However, maybe the velocity has been given as modulus and direction:

  {'val': {'c1': 2/<float>, 'c2': 4/<float>}/<vector2D>
    'velocity': {'v': 0.3/<float>, 'angle': 120/<float>}/<polar2D> 
  }/<position2D>

While you're at it, you could also have a cartesian velocity on a polar
coordinate:

  {'val': {'v': 3/<float>, 'angle': 340/<float>}/<polar2D>
    'velocity': {'c1': 0.3/<float>, 'c2': 0.2/<float>}/<vector2D> 
  }/<position2D>

[Please, let's not have discussions about the STC implications of toy
thing -- it's an example contrived for simplicity]

Note how the role names remained the same while the types of the
values changed. This is nothing revolutionary, it's just your good,
old-fashioned polymorphism.  There's an important corollary here,
though: The sequence of roles you've been following (essentially, the
legacy utype) cannot uniquely determine the type.  And that'll be
true as long as we allow polymorphism, which in turn has cropped up
in essentially all existing VO data models.  Attempts to deal with
polymorphism by hiding it (disclosure: I'm looking at STC's
substitution groups) have been largely considered unsuccessful,
whereas explicit polymorphism as in VOResource works like a charm.

Note that in the current mapping document (the one that doesn't
require VOTable changes), type annotations exist, too (there's a
special utype for these, and it's just another PARAM within the group
that annotates the instance).

The question, hence, is not whether we need types and roles but
rather: might we need more than one of each per instance?

[to which my tentative answer in the previous mail has been: no]

>        Eventually I support Pierre idea to export the definition of VO-DML
> element to an external document and xml schema in order to make evolution of
> this element more easy. I guess that as long as we experiment with VO-DML

I'm against that -- additional documents are, as a rule, evil.  If we
have to tell people "well, to write a VOTable with STC annotation,
read the VOTable spec, and then read this other spec," it's going to
cost us eyeballs -- the most valuable resource of all.  

Also, this other element couldn't be changed much more easily than
VOTable itself either, as changing it would again break existing
VOTables.  In effect, the interoperability problem would go from O(n)
-- match the VOTable version -- to O(n^2) -- match VOTable and VO-DML
version.  And in many settings, going from O(n) to O(n^2) means going
from practical to impractical.  I suspect this is such a setting.

Finally, I'd claim it doesn't really matter.  It has been shown that
a representation of fairly complex data structures is possible
without any changes to VOTable at all while keeping perfect backwards
compatibility (see the current mapping document draft).

Any of these new proposals is more general than that, so we can be
sure any would work for the use cases we set out to solve.  Some of
them would let us do some additional things (like role aliases or
in-document annotations of inheritance hierarchies). I happen to
believe we do not need (or even want) these, but to find out if I'm
wrong, we'll need to apply the stuff, and to do that, we finally have
to just choose one and tell people: "Try it and complain if you do
need aliases or whatever else".

As a matter of principle, I'd choose the simplest thing that can
work.  That'd be using GROUP/@utype or, if there's too much resistance to
that, <VODML role="" type=""/>


Cheers,

        Markus


PS: Oh, and of course I had forgotten about GROUP/@ref -- therefore
I formally retract my statement about wanting GROUPref in the
previous mail.

PPS: Oh, and DAL folks -- sorry for cross-posting, but as nobody
contradicted Francoise's suggestion over on apps
(http://mail.ivoa.net/pipermail/apps/2015-February/001035.html) I
suspect things won't be much different here.