vo-dml in votable

François Bonnarel francois.bonnarel at astro.unistra.fr
Tue Feb 17 13:25:57 CET 2015 

Hi all,
     About this discussion, I think it has been admitted that VO-DML is 
a common topic between DM, APP and DAL so I added "dal" mailing list in 
the recipient list.
     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 feature based on emerging ImageDM . Probably a revised 
version of SSA spectrum retrieval could be a future candidate. I don't 
really know about future versions of TAP but use cases aree not obvious 
for me at the moment.
      "Query reponses" used for datadiscovery are single tables in SSA, 
Obstap and emerging SIAV2 query. They rely on classical (pre VO-DML) 
definition of utypes and this utype usage should perfectly work by 
implementing client actions on top of FIELD contents by reading the spec 
which perfectly defines where the utype is situated in the underlying model.
       VO-DML will be usefull in the future to map the complete 
structure of a complex model on Table contents.

       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.
I need some enlightments on this before chosing amon the various options.

        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 some internal complexity could be added and it's 
nice to keep that evolution outside the VOTABLE document.

Best regards
François


Le 13/02/2015 17:12, gerard.lemson at gmail a écrit :
> Hi Pierre and others
>
>> -----Original Message-----
>> From: glemson1 at jhu [mailto:glemson1 at jhu.edu]
>> Sent: Friday, February 13, 2015 9:30 AM
>> To: 'Pierre Fernique'; apps at ivoa.net; dm at ivoa.net
>> Subject: RE: vo-dml in votable
>>
>> Dear all
>> 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.
> I do want to make clear here once more that it was *not* our (i.e. people working on vo-dml and mapping docs) idea to change VOTable at all.
> We had a proposal that used existing VOTable elements only and hence preserved backwards compatibility perfectly.
> I think the current proposals are more explicit and make VOTables easier to parse if you want to infer VODML mapping information. I think it should be quite trivial to update existing parsers to ignore the VODML elements if that is desired. But itf that were deemd to be too much than we can always go back to our original proposal. I would just like this decision to be made soon so we can go ahead with our work.
> In any case, I believe Andreas Wicenec had an idea that we could preserve this backwards compatibility even whilst introducing this new element. By putting it in its own namespace or so? Andreas, please expand.
>
>> 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).
> I think each of the three proposals conform to this desire. But as they only concern VOTable schema change, I do not understand your concern re JSON etc.
> Please expand a bit on this if it is something to take into account in the design of the mapping spec (which again only concerns VOTable at the moment).
>
>> 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, ...).
>>
> Indeed I want to have this discussion asap, hence the three proposals.
> No reason why this should change a lot. I think that dividing the responsibilities can be discussed. Though the possible repercussions of a VODML change will have to be evaluated by the apps group as well of course, as it is still something VOTable parsers will have to be able to deal with if they want.
>
>> 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.
>>
> Good, having one<VODML>  element is precisely what the proposals say.
> We do not ask for a GROUPref, as a<GROUP ref="">  can play that role in our mapping approach.
> I guess it's a matter of policy and sorting out some technical details to decide where the definition of the VODML part would reside. I personally think that removing it from the VOTable schema itself is not a good idea.
> The current proposal adds the VODML element to GROUP etc which will create an explicit dependency between the two parts. Putting the two new types in a separate document is only confusing in my opinion.
> In this regards it is different for example from the STC note, which "only"
> defines a way to use the existing schema. This was the approach we originally took as well, using the utype attributes.
>
> Cheers
> Gerard
>
>> 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
>>
>>
>>
>>

More information about the apps mailing list