vo-dml in votable
Pierre Fernique
Pierre.Fernique at astro.unistra.fr
Thu Feb 12 08:09:50 CET 2015
Dear App members,
May I emphasise the Gerard's mail.
VOTable is a key element of the VO. The VODML serialization in VOTable
discussed here will have probably a big impact on our standards and
applications - for the best I hope. So please take time to look
carefully the Gerard's proposal and do not hesitate to bring your
contribution.
The fastest ways to have an clear idea of the goal is to have a look on
this example and the 2 other variants:
http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml
http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml
http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml
Thanks for your contribution
Best regards
Pierre Fernique
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/20150212/68aa8989/attachment.html>
More information about the apps
mailing list