vo-dml in votable

[Tom Donaldson]

Hi All,

I'll state up front that I still have not wrapped my head around all the use cases for VODML elements in VO Tables.  There are open questions in my mind about both the semantics and the syntax of these cases, but that's for another day.

The one case I think I understand at an abstract level is that for a given data type, we want to describe which columns map to which attributes of the type so that some values in a table row can be used to construct an instance of that type.  For that use case, I have a couple of observations:


  *   Only a client that understands the semantics of a data type can do anything useful with an instance of that type.
  *   We cannot express the semantics of a type in the VO Table (or in any reasonably automated way).  The table can only describe the data structure into which to put TD values.

>From a practical perspective, there will be basic generic clients that are able to provide some features with only basic knowledge of data types, and there will be more advanced clients that will be intimately familiar with the details of a focused set of data types.

For the basic clients, I think it's important to expllicitly support basic data types.  To me, this probably means standardizing some *simple* definitions of types like Position, Source and Observation (along with maybe Image, Spectrum and whatever else we feel is core to *general* interoperability).

More advanced clients might understand specific subtypes of those simple types along with other random data types.  These could be quite specific to particular data sets (e.g., ChandraSource).

To address those two cases, I think it makes sense to keep the FIELD to data type mappings separate.  So a VO Table that contained a ChandraSource would contain a VODML element that described what FIELDs map into that data structure, and it would contain a completely separate VODML element that would describe what FIELDs map into a simple Source.  In that way, basic clients would recognize the type mentioned by basic mapping but be able to freely ignore any VODML elements that described mappings to types with which they are not familiar.

So to summarize, with my limited (so far) view of the use cases, I think we'd be best off without ALTTYPE or any other structure that tries to describe a polymorphism.  Clients that understand a complex type can infer supertypes all they want since they understand the data type beyond what is described in the VO Table.  Simple clients (most clients!) can use straightforward mappings to the simple types they understand without dealing with excess syntactic complexity.

Thanks,
Tom

On Mar 9, 2015, at 7:39 AM, "Laurino, Omar" <olaurino at cfa.harvard.edu<mailto:olaurino at cfa.harvard.edu>> wrote:

Hi Markus,

At this point I believe both solutions have strengths and drawbacks. One solution (only one TYPE) puts less burden on the server side, but more on the client. The other (more than one TYPE allowed) puts less burden on the client and more on the server side.

Regarding your questions:
  - Where to draw the line? in the old mapping document (the one using UTYPEs) the line was drawn at model boundaries. You did not need to add the multiple types annotations for subtypes of types defined inside the same model. The reason is that if you assume knowledge of a model, then you don't need more help. However, after my prototyping efforts I suggested we also included explicit declaration of abstract types even within model boundaries, just to simplify discovery of relevant instances (assuming types are declared abstract for a good reason).

  - How to "compute" the leaf type? I believe in the old mapping document we suggested a specific order for the type declaration. Now that we have a specific element maybe we might add an attribute, e.g. <TYPE leaf="true">?

In any case, as I said, I don't think you can make a strong case in either direction. Both solutions have Pros and Cons. However, this does argue for 4b over 4a, as 4b can be turned in 4c easily if required.

Omar.

On Mon, Mar 9, 2015 at 6:50 AM, Markus Demleitner <msdemlei at ari.uni-heidelberg.de<mailto:msdemlei at ari.uni-heidelberg.de>> wrote:
Hi Omar, dear lists,

On Fri, Mar 06, 2015 at 11:11:48AM -0500, Laurino, Omar wrote:
> I would like to elaborate on the ALTTYPE element and why it was included in
> the design.

Thanks for the elaboration.  Since I'm a big python fan, it is
perhaps not terribly surprinsing that I still prefer duck
typing (and hence a unique type annotation, with naive clients
working on the attribute names/utypes/vodml-ids).

However, assuming we want explicit annotation of the inheritance
hierarchy, the argument

> Now, a reader can simply look for src:Source and must not rely on any kind
> of type inference. The problem with 4a and ALTTYPE is that readers need to
> explicitly look for two different XML elements to get a single piece of
> information.

convinces me to prefer

> I would then prefer something like option 4b but with an open multiplicity
> for the TYPE element, so one would have:
>
> <GROUP>
>   <VODML>
>      <TYPE>sdss:SDSSSource</TYPE>
>      <TYPE>src:Source</TYPE>
>   </VODML>
> ....
> </GROUP>

over ALTTYPE.  *If*, and here I don't see terribly clearly, we're
sure we never need the concept of "actual type" in the VODML context.
The trouble here is that with such a convention, the implementation
of a function

  type(object) -> class-of-object

would probably require inspecting all VO-DML files mentioned in the
file in order to figure out which is at the leaf of the inheritance
tree, right?

If we forsee the necessity for the type function, I hence believe we
should have ALTTYPE (if we want multiple types annotated at all).

> There is another interesting use case where alternate types can greatly
> simplify the life of the client implementor: abstract types. Let's say that

True -- but the attribute names work as abstract types, too (in your
example, you'd be following the pointer to the error role, right?)

So, the problem, as far as I can see, only exists for root-level,
global objects that are not referenced by any other VO-DML object.
Maybe that's an indication that it's not a problem of type annotation
but of data model declarations?  I'm not actually suggesting this at
this point, but something that'd be attractive for many other reasons
(and again wouldn't need VOTable changes) might be an inventory of
root objects for a given data model within each data model
declaration -- for instance, it'd also help applications find these.


>    <VODML>
>      <ROLE>stc:SkyPosition.error</ROLE>
>      <TYPE>mydm:MyEllipseError"</TYPE>
>      <TYPE>stc:EllipseError</TYPE>
>      <TYPE>stc:SkyError</TYPE>
>    </VODML>

Hmwell, yes, you see, this is what makes me skeptical.  We'll have to
formulate requirements or validity criteria, on what types VOTable
writers will have to put here.  What would that be?

"Writers MUST include one TYPE element for each class in the
inheritance chain"?  That would incur a large baggage as you have
fairly long inheritance chains even within a given model, and I'm
quite sure you wouldn't want to dump these every time you write an
annotation.

"Writers MUST include one TYPE element for each class in the
inheritance chain until an IVOA recommended data model is reached"?
That would fix the worst uglyness, but apart from difficulties while
developing such data models, I'm a bit nervous making the
serialisation dependent on something as volatile as IVOA's set of
standards (which changes roughly five times a year).


To sum up: I believe the only thing multiple types give you that
attribute names/utypes don't is allowing easy *top level* DM element
localisation for *naive clients*.  If this turns out to be a relevant
use case, I'd say let's look at object directories in the DM
declarations (which can be useful for other things, too) before
futzing with the type calculus.

Cheers,

        Markus




--
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20150309/418048b1/attachment-0001.html>