ivoa: DM type system

[Laurent Michel]

Hello,

Below is my understanding of the issue discussed in this tread:

The VO-DML mapping mechanism has a built-in restriction which must be kept in mind:
It can be seen as a bridge connecting model elements with VOTable data.
The model is designed to fulfill some use-case whereas the data are as provided by the service.
There is not reason why each model element can ever be populated with VOTable values (Field or Param).
The value may not exist or it may have an inconsistent type/format/unit.
This kind of inconsistencies will occur while the mapping does not handle data transformations (and ever after); they have to be 
managed by the client.

Let's focus on the inconsistent type issue.
There are currently 3 different ways for the mapping the get a value:
1- <LITERAL>: The value is hard coded in the child element and typed with @dmype
2- <COLUMN>: The value is taken out from the referenced data column
3- <CONSTANT>: The value is taken out from the referenced PARAM

In the current version, these 3 elements are typed with @dmtype which has a different vocabulary from VOTable @datatype
The question is to know how to merge those 2 definitions.
1- If we use @datatype everywhere, we loose the compatibility with the ivoa VO-DML package (where @dmtype is defined)
2- If we keep both or even just @dmtype , we will have to run a tricky business to compute the match or to do some inference 
when there is no match.
3- We can also hide @dmtype because it is already defined in the model.

Since model types (@dmtype) do not necessarily match data type (@datatype), there is no perfect solution, but #3 has the 
advantage of not presenting 2 facets of the same type.

A PROPOSAL
----------
One can observe that all of these 3 elements have the same role : picking out data values.
So, why not using one single element, namely <PICKEDVALUE> (waiting for better), to do the job?
It would have 2 attributes at least: @source = {param|field|value} and @ref, and it would support a subset of the PARAM and 
FIELD attributes (datatype, arraysize and xtype e.g.).
If @source="value", the value is read out of the child element, otherwise it is taken out from the element pointed by @ref.
This solution avoids mixing VOTAble elements in <VODML>. All meta data necessary to interpret the values can either be found in 
the local attributes or in those of the referenced element.
This swiss knife element is not pretty at all but well suited to stand the interface between the VOMDL world and the VOTable world.

Comment?

Laurent


Le 20/04/2017 à 10:40, Markus Demleitner a écrit :
> Hi Gerard,
>
> On Wed, Apr 19, 2017 at 05:02:37PM -0400, Gerard Lemson wrote:
>> On Wed, Apr 19, 2017 at 3:56 AM, Markus Demleitner <
>> msdemlei at ari.uni-heidelberg.de> wrote:
>>> I'd much prefer, too, if PARAMrefs and FIELDrefs could make a return
>>> there.  Later implementors will not give a damn about the history of
>>> the annotation.  They'll just curse us for having multiple elements
>>> (PARAMref and CONSTANT, FIELDref and COLUMN) that do the same thing,
>>> just in different places.
>>>
>>> I am actually against reusing these VOTable types in the VODML annotation
>> as their content is quite different.
>> Wrt CONSTANT and ParamRef, and COLUMN and FieldRef, apart from dmtype, the
>> vodml mapping versions inherit OPTIONMAPPING from VODMLPrimitive. The
>> votable elements have ucd and utype which we explicitly have no place in a
>> VODML annotation.
>
> Well, I believe @utype should be deprecated everywhere once we've
> figured this DM buisness out, and just because @ucd *can* be there
> doesn't mean it has to be used or has any meaning.  That's for the
> mapping document to define, no?
>
>> I still think that anyone who starts coding against the VODML annotation
>> part of the VOTable will write completely new code and should not be scared
>> that there are new names on elements that may superficially seem similar.
>
> I certainly hope that's not going to be the case.  As I said,
> according to the current plan, the VODML element will contain very
> basic annotation, and essentially all existing code will have to deal
> with it one way or another if it wants to stay relevant going away
> from J2000.
>
> So, migration matters.  A lot.  We've botched the migration from
> COOSYS to STC annotation for a number of reasons, the indication that
> STC annotation somehow "isn't part of the spec" being a major one.
> Let's not make that mistake again and make it clear that VOTable
> without these annotations simply is not going to usefully work in the
> future.
>
>> I think one might reverse the argument, expecting(well, hoping?) that
>> future implementors will not have to deal with GROUPs and their paramrefs
>> and fieldrefs anymore, because VODML will replace their use.
>
> We *could* deprecate and replace them, but is a simple re-christening
> and getting rid of @ucd actually worth the ensuing maintenance
> trouble?
>
>> So, so far my conclusion is that
>> 1) We SHOULD add VOTable features identifying the datatype of LITERALs in a
>> VODML independent manner. The consequence of this is that we likely have to
>> add the VODML annoatation elements inside the VOTable schema.
>
> Since we certainly cannot deprecate PARAM to replace it with LITERAL,
> I'm starting to be even more firmly convinced that the mapping should
> use PARAMs instead of LITERALS.
>
> If you say there's too many required attributes on PARAM -- well,
> that's @datatype, @name, and @value.  @datatype and @value you need
> anyway, and as for @name, I suppose VOTable could easily be changed
> to not require it (though I think there'd be nothing wrong to come up
> with a sensible rule to generate a name).
>
> That PARAM can do a lot more isn't an actual problem; if the mapping
> spec doesn't give any meaning to it, that's it (and perhaps these
> things might come in handy later; there's a reason they're in).
>
>> 2) We MAY wish make the dmtype attribute optional on all instances.
>
> I'm pretty sure that's a good idea.  It makes the annotation more
> compact (always a good thing) without taking away information for
> non-validating clients.  Validating clients will have to have the
> VO-DML anyway, so they can, in the non-cast case, work out the dmtype
> without noticable extra effort.
>
>
> So, I guess my main message here is: Either re-use PARAM, PARAMref
> and FIELDref (preferred) or deprecate them in favour of your new
> elements (not so sure about GROUP, though).  If both are in the same
> spec, it'll look odd, feel bad, and thus hinder takeup.
>
>          -- Markus
>

-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg