<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Markus, Gerard, all,<br>
<ul>
<li> From a DAL point of view, I would like to keep the
complexity embedded in the right place where it is necessary.</li>
</ul>
<br>
We have a DAL roadmap which has been discussed <br>
- Publish or push DataLink 1.0, SIAV2.0 and AccessData
1.0<br>
- Immediatly after that upgrade to DataLink1.1,;
SIAV2.1, and AccessData 1.1<br>
- maybe revisit SSA according to new version of
spectral data model (although it's not identified yet)<br>
- Upgrade Obscore/Obstap according to new needs for
cube dataset description<br>
- Be carefull about convergence with TimeDomain and
Theory protocol developments<br>
- upgrade TAP and ADQL according to discussions held in
Madrid and Banff. With a lot of basic needs and demands from
developpers/providers which do not require DataModel Mapping.<br>
<br>
Dataset discovery is and will be for a while based on SSA,
SIAV2 and Obstap. Definition of fields using "legacy utypes" in SSA,
SIAV2 and names and "legacy utypes" in Obstap is unambiguous and
fulfill the needs. The coordinate system issue has been solved in
two different ways. SSA has a couple of columns where the CoordSys
can be defined, mapping the stc structure. SIAV2 and Obstap choosed
to fix the CoordSys to ICRS.<br>
<br>
Mapping DataModels on TAP responses, and advanced responses
from SIAV2 (and possibly later from a new version of SSA) are the
areas where I see a clear use case for mapping datamodels on
VOTABLE. Otherwise I think we dont'have to make the things more
complex than they are.<br>
<ul>
<li> About the point considering where we should define the
VO-DML element with his content (potentially in evolution ?) I
think this is important for people developping this kind of
applications to be able to make it change rather independantly,
without blocking version of VOTABLE for all developpers who will
ignore it (see also above who will need it and who will not
according to DAL rodamap).</li>
<li>Considering the question of ROLE and TYPE, (and ALTTYPE) and
the best way to code that in VO-DML element. I Think I
understand Gerard's and Markus's explanation which were
basically what I had in mind. After looking at the examples
however I see that we always implement a single Role/type
combination at each level of the VO-DML hierarchy. right or
wrong ? So why is solution 4a not sufficient ? </li>
</ul>
Best regards<br>
François<br>
Le 17/02/2015 17:31, gerard.lemson@gmail a écrit :
<blockquote cite="mid:1c9b401d04acf$38852540$a98f6fc0$@gmail.com"
type="cite">
<pre wrap="">Hi
May I add my few cents to Markus' comments.
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:apps-bounces@ivoa.net">apps-bounces@ivoa.net</a> [<a class="moz-txt-link-freetext" href="mailto:apps-bounces@ivoa.net">mailto:apps-bounces@ivoa.net</a>] On Behalf Of
Markus Demleitner
Sent: Tuesday, February 17, 2015 9:04 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:apps@ivoa.net">apps@ivoa.net</a>; <a class="moz-txt-link-abbreviated" href="mailto:dal@ivoa.net">dal@ivoa.net</a>; <a class="moz-txt-link-abbreviated" href="mailto:dm@ivoa.net">dm@ivoa.net</a>
Subject: Re: vo-dml in votable
Hi,
On Tue, Feb 17, 2015 at 01:25:57PM +0100, François Bonnarel wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">I think the proposal can relevant to DAL also when annotating TAP repositories with VO-DML metadata. In the mapping document we suggest this be done by wrapping a TAP database with a VOTable having one <TABLE> per TAP_SCHEMA.tables table and following that document's definitions.
And if a TAP implementation is very smart it may even be able to annotate query results with proper VO-DML metadata.
In fact, any new DAL protocol built around a data model could simply use the mapping document to define its serialisations, no need at all to invent something arbitrary and providing explicit prescriptions how to infer the original data model form the custom serialisation.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">
Oh, I believe I do understand the role/type business, and indeed, I believe your
...
</pre>
</blockquote>
<pre wrap="">An alternative to Markus' comments that I think is somewhat simpler.
Mapping the concepts to Java, a role is an attribute in a class, a type a class/type name.
When declaring an attribute I give it a name and a type.
But when instantiating a class, I can assign to the attribute a value that is of a type that is a sub-class of the declared type.
A VOTable document annotated with VO-DML elements corresponds to a bunch of instances of types.
IF one understands a data model exactly, one could infer from the 'role' attribute in the VODML element what 'type' to expect. But if the actual type is a sub-type of the declared one, one can use the VODML/@type to define the exact type. Similar to a casting.
Another use case for this is to assist what some people like to call a "naïve client". This is one that does *not* parse VO-DML documents when encountered with VODML annotations, but is coded to understand a particular model. Say TOPCAT, which could understand STC and use this to whenever it encounters a Position2D (or whatever name is given to it in proper STC). By having the actual type of the attribute stated in the VODML element, TOPCAT could now know that this attribute is something it understands without being required to parse the VO-DML document where it is defined.
Note, the ALTTYPE elements try to make the world even easier for such naïve clients. Namely by stating types in the super type hierarchy as well.
So when you define in your MySTC model a 'MyPosition2d extends stc:Position2d', then indicating that a certain position attribute is of type MyPosition2D does not help clients who only understand the actual STC model.
I think one should say that forcing data providers to give a complete list of all the types by which a certain role can be known is ugly.
And Markus argues that in fact this may not be necessary. Naïve clients that are STC aware SHOULD know not only the stc:Position2D type, but also know that the roles stc:Position2d.c1 and stc:Position2D.c2 are part of that type and therefore when encountering these should be able to infer that they know the type.
So Markus argues that the type hierarchy for which the ALTTYPE elements are intended, is not needed even for naïve clients.
And I support this argument. The consequences of this are that we would only need to vote between the following patterns:
<VODML type="yyy" role="xxx"/>
and
<VODML><type>yyy</type><role>xxx</role></VODML>
The former being smaller, but having the possible disadvantage that any future evolution to a more complex description of role or type leads to more disturbance of the schema. I don't see any such change on the horizon, but there you are.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> 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
</pre>
</blockquote>
<pre wrap="">
I'm against that -- additional documents are, as a rule, evil. If we have to tell
people "well, to write a VOTable with STC annotation, read the VOTable spec,
and then read this other spec," it's going to cost us eyeballs -- the most valuable
resource of all.
Also, this other element couldn't be changed much more easily than VOTable
itself either, as changing it would again break existing VOTables. In effect, the
interoperability problem would go from O(n)
-- match the VOTable version -- to O(n^2) -- match VOTable and VO-DML
version. And in many settings, going from O(n) to O(n^2) means going from
practical to impractical. I suspect this is such a setting.
</pre>
</blockquote>
<pre wrap="">I still agree with Markus' position.
Cheers
Gerard
</pre>
</blockquote>
<br>
</body>
</html>