VODML base types : request for enhancement of the IVOA.1.0 template model

[Paul Harrison]

> On 16 Feb 2026, at 16:59, Gerard Lemson <glemson1 at jhu.edu> wrote:
> 
> Hi Paul
> From the abstract of the vo-dml spec: “VO-DML is a conceptual modeling language that is agnostic of serializations, or physical representations”.
> We do discuss possible serializations to XML/RDB in appendix B of the spec.
> Even such “direct” serializations need to make decisions how to map VO-DML constructs to the serialization format as generally there is some impedance mismatch.
> For example in XML how references are represented, in RDB how inheritance is dealt with, anywhere how datetime-s are mapped (which I assume should really use some STC-like stuff).

I suggest dateTimes have their definition restricted somewhat so that they are UTC timescale and CoordsDM used for more complex cases  https://github.com/ivoa/vo-dml/issues/37

I do think that dateTime is a good example of where VO-DML cannot be completely thought of as a conceptual modelling language entirely agnostic of serialisation or physical representations, as relativity does make the concept of “time instant” rather complex, and dateTime as a primitive is probably saying more about the serialisation of the value than the concept. It might be that a good way to think of primitives is that they do have a specific textual serialization.

> Laurent Bourges and I did a lot of work for the Simulation data model in VO-URP to make those things work. I think we one could create standard mappings from VO-DML to some serialization languages and should then deal with these issues there. Of course there is such a mapping for VOTable and it already had/s already ways to indicate something about serialization (XTYPE??). 
>  
The current VO-DML tools also create some self contained “direct” mappings to XML, JSON and RDB that built on your earlier work  https://github.com/ivoa/vo-dml/issues/43 - I think that this form of “direct" serialisation is worth “standardising” just as much as MIVOT was, but probably in a separate document.


> Another reason why UCDs conceptually should not be primitive types is given on page 31:
> 
> The extent of a value type, i.e. its set of valid instances/values, is self-evident from its definition. That is, from the definition one can infer exactly which values exist in the set defined by the value type. Hence one can identify the instance by its value.
>  
> According to this, as UCDs and other vocabularies have been, are and will keep on changing, UCDs should not be considered data types on their own.

the request for UCDs to be a primitive type actually came from MANGO - but I am fairly convinced by this argument that they should not be - It is, however, useful to know what the UCD should be for serialization and some thoughts are gathered in https://github.com/ivoa/vo-dml/issues/19 - I now think that the best place for the doing this is in the binding.
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20260216/6a5885c8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20260216/6a5885c8/attachment.p7s>