vo-dml in votable

[Laurino, Omar]

Hi All,

During the Banff Interop discussion on the VOTable changes there was a
question regarding the use case behind the "alternative type"
representation. Here is a detailed description of such use case and the
requirements related to it.

Please let me know if you have any further questions.

Cheers,

Omar.

It is rather common for data providers to have specific data models for
their datasets, and such models can usually be represented as extensions of
a standard one (two examples are the NED SED service w.r.t. SpectrumDM and
the SVO Filter Profile Service w.r.t PhotometryDM).
On the other hand, a strong requirement we had for the UTYPEs, and that
still applies with any alternative to UTYPEs (I am referring to these
strings as "vodml references" in the following), was that "naive" clients
had to be able to find the metadata they are looking for by just assuming
knowledge of the data model they are interested in (*).

Referring to the examples we have made so far, assume you have a Source DM,
where a Source has a position of type SkyCoordinate, defined in the STC2
model, one has these vodml references defined:

src:Source (type)
src:Source.position

stc2:SkyCoordinate (type)
stc2:SkyCoordinate.longitude
stc2:SkyCoordinate.latitude

A naive client must be able to find these vodml references in the
serialization, so they cannot be obfuscated by extensions.

Let's say a specific provider extends the Source class by adding a
mission-specific or datacenter-specific attribute. We will have a MySource
DM that introduces two new vodml-ids:

my:Source
my:Source.custom_attribute

A naive client must still be able to identify a my:Source instance as a
src:Source without having to parse the vo-dml/xml document.

Thus, here is how the serialization would look like in VOTable according to
the current UTYPEs mapping document (omitting the unnecessary VOTable
attributes):

<GROUP utype="vo-dml:Instance.root">
   <PARAM utype="vo-dml:Instance.type" value="my:Source" />
   <PARAM utype="vo-dml:Instance.type" value="src:Source" />

   <GROUP utype="src:Source.position">
      <PARAM utype="vo-dml:Instance.type" value="stc2:SkyCoordinate" />
      <PARAM utype="stc2:SkyPosition.longitude" value="..." />
      <PARAM utype="stc2:SkyPosition.latitude" value="..." />
   </GROUP>

   <PARAM utype="my:Source.custom_attribute" value="..." />
</GROUP>

Despite the fact that a naive src:Source client does not know anything
about my:Source (and doesn't care, in this use case), it can still find all
the vodml references it needs without having to parse the VO-DML/XML
document. This is true because the root instance is declared as both
my:Source and src:Source:
   <PARAM utype="vo-dml:Instance.type" value="my:Source" />
   <PARAM utype="vo-dml:Instance.type" value="src:Source" />

So, the naive src:Source client can query for a
GROUP[PARAM[@utype="vo-dml:Instance.type" and @value="src:Source"]] and
then get all the attributes it needs in order to build an instance of a
src:Source.

In other terms, one can safely upcast representations of VO-DML instances
without having to parse the VO-DML/XML description, so the original use
case (and attached requirements) is fulfilled.

Notice that this extensibility problem was one of the main drivers of the
whole UTYPEs effort, as we had big issues in implementations of the SED
Builder case, and we were foreseeing the same issue for the Cubes effort.
As we didn't want to employ unsustainable ad-hoc solutions for each data
provider we designed a generic framework that works in many different
scenarios.

(*) The definition of "naive" client is provided in the Mapping document.
In a nutshell, a naive client assumes knowledge of a Data Model in the form
of a bunch of utypes (vodml references) and does not need, or want, to
parse the data model standard description files, i.e. VO-DML/XML.
A "naive" client is only "naive" when it comes to DMs, not VOTable parsing,
obviously.
VO-DML and the Mapping documents are designed to make simple things
consistent and not ad-hoc while enabling many advanced use cases.
In this sense, it is not like "naive" clients are "stupid", but they are
distinguished from clients that harvest the full potential of the VO-DML
framework and can just ignore it, focusing on the few utypes they are
really interested in.

On Wed, Oct 15, 2014 at 5:47 PM, Gerard Lemson <gerard.lemson at gmail.com>
wrote:

> Dear all
>
> During the VO-DML-in-VOTable discussion at the last interop we decided to
> go
> with (something like) proposal 4 on the wiki at
>
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab
> le/VOTable_Prop4.xml  Other options can be found in the same folder.
> What we now need is to finalize the design for the XML tag(s) to add to
> VOTable.
> I have created a mockup of an XML schema with a complexType definition
> reflecting the new element.
> The design used in proposal 4 above is represented by proposal 4a in the
> schema. It has attributes for role and actual type, and elements for
> alternative types. Proposals 4b and 4c vary on this theme. All use a
> simpleType definition reflecting the model-prefix+':'+vodml-id pattern used
> to refer to VO-DML elements. See the mapping document for more detailed
> descriptions (taking into account the fact that that document will have to
> be updated with the choice to be made here).
>
> Note, I am not making statements on whether these two types must be in the
> VOTable targetnamespace. Andreas had some thoughts on this that I hope he
> will send to the list in reply.
>
> And obviously the final design may differ from these proposals if
> necessary,
> but let's please converge on an acceptable design soon so Omar and I can
> update the mapping document.
>
> Cheers
> Gerard
>
>


-- 
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/20141016/75e88400/attachment-0001.html>