vo-dml in votable

[Pierre Fernique]

Dear App members,

The study of the 3 VODML Gerard's proposals leads me to raise these 3 
points, and a suggestion.

For App WG point of view, first of all, we have to assure that this DM 
effort *(1) keeps the VOTable backward compatibility.* And in a second 
point, I would like that*(2) the VOTable standard keeps a relative 
simpleness*. Otherwise, it will become more and more difficult to sell 
it to data producers. So *VODML must stay as simple as possible and 
optional***otherwise the real result will be the emergence of new basic 
formats (JSON, ASCII, FITS or whatever) with poorer or divergente 
metadata description than a basic VOTable without VODML (cf. coordinate 
STC note usage). And in third point, I would like to (3) *keep VOTable 
standard manageable*. I'm not sure that we have time and energy for 
re-opening a full VO discussion each time we need to adjust VODML XML 
element/attribut (VODML, TYPE, ROLE, ALTTYPE, ...).

My idea would be to *suggest**the addition of just one optional new 
element <VODML>* in GROUP, PARAM, FIELDref, PARAMref (and why not 
GROUPref), but for which, its XML definition (sub-types, attributs...) 
would be described not in VOTable document itself but in a separated  
IVOA standard managed by the DM group (through the classical IVOA 
standardization process - may be directly insert in the VODML standard 
itself). By this way the DM effort could follow is own way and time with 
a relative freedom.

Best regards,
Pierre



Le 11/02/2015 17:02, Gerard Lemson a écrit :
> Dear all
> It would be nice if we could quickly agree how to annotate VOTable 
> elements with metadata pointing to VO-DMl data models.
> 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.
> The detailed design of this element was still left open and I sent out 
> an email shortly after the interop in which I made some suggestions, 
> which I thought I had adequately illustrated with examples of the 
> possible XML schema snippets. Maybe this was not clear, so I have 
> updated the contents of
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable
> It now contains for three possible designs, labeled 4a, 4b and 4c, 
> full VOTable schemas and three corresponding versions of a VOTable 
> following these schemas and showing the different ways to annotate the 
> same tables.
>
> E.g. 
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable-1.3_vodml4a.xsd 
>
> is a possible new schema and
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml
> an annotated VOTable following that design.
>
> Note that in the three different proposals only the *content* of the 
> <VODML> elements, as described by the structure of the VODMLAnnotaiton 
> complexType definition, is different. Their association to PARAM, 
> GROUP, PARAMref and FIELDref elements is the same.
>
> Please let me know if this is still not clear or comment on the design 
> possibilities.
>
> Cheers
> Gerard
>
>
>
> On Wed, Oct 15, 2014 at 5:47 PM, Gerard Lemson 
> <gerard.lemson at gmail.com <mailto: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
>     <https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab%0Ale/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
>
>

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