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

[Gerard Lemson]

Hi Mireille
Why do you want to indicate double precision "in the model"? How are you using the model?

Re UCD. Allowing these to be concatenations of more basic UCDs things make it sound more like you might want a objecttype.
Likely not mapped to a simple vocabulary, but imo not a primitiveType.
Would such constructs have a place in a more complex ontology? May we need an ontologyconcept or something like that?

But I think I agree with Markus that we may want to keep vocabularies external to VO-DML. Reference them but don't try to m,odel them.

Cheers
Gerard

From: Mireille Louys <mireille.louys at unistra.fr>
Sent: Monday, February 16, 2026 2:20 PM
To: Gerard Lemson <glemson1 at jhu.edu>; Data Models mailing list <dm at ivoa.net>
Subject: Re: VODML base types : request for enhancement of the IVOA.1.0 template model


      External Email - Use Caution





Hi Gerard ,

thanks for your answer .

Real type :

yes I used  the abstract 'ivoa:real ', but In my use-case , I would like to state "in the model" that it should be a double precision .
Currently the IVOA:Basetype model cannot tell this.
or did I miss anything?

ucd as <semantic_concept>:

the Semantics group is working on a representation of the UCD terms as a Vocabulary .

But a Ucd contains a concatenation of ucd terms , for which no uri are defined yet, like in a fully defined vocabulary.

so the best option , in the PhotDM use case, was to derive ucd from ivoa:string , and define it as a concatenation of members of the UCDList specification , which is/will be a vocabulary .

Cheers, Mireille
Le 16/02/2026 à 7:37 PM, Gerard Lemson a écrit :
HI Mireille
Re UCD type.
I think this does not change the comment in my previous email. Thie is precisely what the <<semanticconcept>>  stereotype is for.

Re zero point:
The ivoa:real IS NOT a 32 bit float. It represents the mathematical concept of a real number.
Is not very explicit in the data model, but that is what is intended by the "from R" in
<primitiveType>
  <vodml-id>real</vodml-id>
  <name>real</name>
  <description>A real number (from R).</description>
</primitiveType>

Again, it is a serialization choice how to represent these (16,32,64 bit floats for example, or decimal numbers)
And the same is true for integer (N or Z), rational (Q), complex (C).

Cheers
Gerard

From: dm <dm-bounces at ivoa.net><mailto:dm-bounces at ivoa.net> On Behalf Of Mireille Louys via dm
Sent: Monday, February 16, 2026 1:13 PM
To: Data Models mailing list <dm at ivoa.net><mailto:dm at ivoa.net>
Subject: Re: VODML base types : request for enhancement of the IVOA.1.0 template model


      External Email - Use Caution





Dear DM,

In order to help to stabilize on a use-case , here is an example where I needed to derive types from the IVOA:Basetypes .

it is in the PHOTDM specification , in the VODML translation from Modelio to XML.

https://wiki.ivoa.net/internal/IVOA/PhotDM11RFC/Photv1_1_PR_20220520.html#UCD

My understanding of IVOA BaseTypes, is that they should allow us to type the attributes of the classes exposed in the model.

I have derived the type UCD in PhotDM as an ivoa:string , that can be interpreted as an expression defined in the UCDList specification.

For the ZeroPoint class, I needed attributes expressed in double precision like ZeroPoint.flux.value, and ZeroPoint.referenceMagnitude.value but IVOA:Basetypes offers only ivoa:real .

So I wish the IVOA BaseTypes could be extended to contain the basic types that are used , in VOTable serialisation and XML basic types for instance.

In this use-case , I undertand I stick to the initial XML oriented VO formats and that documents serialized in JSON would need a mapping .

I hope this helps ,

Mireille
Le 16/02/2026 à 11:23 AM, Markus Demleitner via dm a écrit :

Dear DM,



On Mon, Feb 16, 2026 at 09:39:55AM +0000, Paul Harrison via dm wrote:

I think that if a particular model element have a constant UCD then

it should conceptually by modelled with the SemanticConcept - but

it seems that the type of "topConcept" means that it cannot be used

to express the UCD string and there is possibly no conventional

value for the vocabularyURI for UCDs. (see

https://github.com/ivoa/vo-dml/issues/19)

First off, VO-DML predates the current vocabulary spec, and therefore

limits itself to SKOS.  That limitation should be lifted

independently of the UCD business.  I'd be happy to review the

language on vocabulary usage for VO-DML 1.1, but I'd need some

poking.  Perhaps we should even have an RDF serialisation for the

instances?



For the UCD question, however, all that iss not terribly helpful.

The reason is that UCDs have syntax.  Modelling the UCD atoms as a

proper vocabulary is probably possible, and there's even a draft PR

for that <https://github.com/ivoa-std/Vocabularies/pull/31><https://github.com/ivoa-std/Vocabularies/pull/31>, but

you'd want ("compound") UCD words here, and RDF can't (really) do

that.



Me, I'm still skeptical that VO-DML should say a lot about UCDs

beyond mentioning that Quantity-s can be adorned with them in

sufficiently capable serialisations.  But *if* there is a strong

reason to say "this must be a valid UCD", that'll need extra logic

beyond RDF.



Thanks,



            Markus











--

--

Mireille Louys, MCF (Assistant Professor)

Centre de données Astronomiques (CDS)       Equipe Images, ICube

Observatoire de Strasbourg                  Telecom Physique Strasbourg

11, rue de l' Université                    300, Bd Sebastien Brandt CS 10413

F-67000 Strasbourg                          F-67412  Illkirch Cedex

--

--

Mireille Louys, MCF (Assistant Professor)

Centre de données Astronomiques (CDS)       Equipe Images, ICube

Observatoire de Strasbourg                  Telecom Physique Strasbourg

11, rue de l' Université                    300, Bd Sebastien Brandt CS 10413

F-67000 Strasbourg                          F-67412  Illkirch Cedex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20260216/2ddf2a34/attachment-0001.htm>