vo-dml in votable

Thu Feb 12 14:41:39 CET 2015

Hi Gerard,

Since we are virtually colocated, let's get together in person to chat about this.  Any such discussions could be opened to a wider audience as needed, but let's meet first and decide the next step from there.  I'm available Friday and most afternoons next week.

Here are some items I think would be helpful to go over:

  *   Interactively review the proposals, making sure that I fully understand the content along with any nuances you may think of.

  *   Implications on data providers:
     *   Is it practical to create unambiguous representations of your data?

  *   Implications on data consumers (apps):
     *   Is it practical to parse the VO Table?
     *   Is it practical to determine the semantics of the VO Table?
     *   To what extent is it necessary for simpler clients to determine the semantics of the new annotations?

  *   From both the data provider and consumer sides:
     *   Are there use cases that have been implemented to help demonstrate this?
     *   What use cases would be good candidates for demonstration/prototype implementations?

  *   Identify the next step(s) to move this forward and make a rough timeline.

  *   Any other topics you're interested in.

As may be obvious from some of those bullets, I think it will be very important to have as many sample implementation attempts as possible from the both the provider side and the consumer side.  Such vetting is the only way to isolate the practical problems that exist within solid theoretical approach.

I'm not suggesting that we need implementations for all the proposals, just that before any new approach is fully approved, it should have been vetted by implementing some real world use cases.  I will be enthusiastic about helping with some sample implementations, but will be time-limited.

Thanks,
Tom

On Feb 12, 2015, at 4:49 AM, Francoise Genova <francoise.genova at astro.unistra.fr<mailto:francoise.genova at astro.unistra.fr>>
 wrote:

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<mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20150212/26935e55/attachment.html>