<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi, <div><br></div><div>we should be having this conversation in public - so I have CCed the mailing list</div><div><br></div><div>It think that I agree that UCD is a good candidate - and have nothing much more to say about that.</div><div><br></div><div>The ivoa:datetime issue is more complex - it is not very well defined in the VO-DML standard exactly what this means, but my contention is that because of its name then the thing that the original authors had in mind was <a href="https://www.w3.org/TR/xmlschema11-2/#dateTime">https://www.w3.org/TR/xmlschema11-2/#dateTime</a> - and these are more or less ISO8601 timestamps. My proposal would be to firm up the definition of ivoa:dateTime so that it is basically an ISO8601 timestamp in the UTC timescale (note it *must* have a timezone designator) on a terrestrial reference frame- so pretty much the same as you are proposing for ISOTime, I believe</div><div><br></div><div>I do not see any particular problem with ivoa:jd or ivoa:mjd - although the interesting thing conceptually is are they (along with ivoa:dateTime) potentially sub-types of an abstract ivoa:timeInstant or are we just staying that they are subtypes of ivoa:real.</div><div><br></div><div>It is not this reason that I do not see any particular value in an ivoa:year as it cannot conceptually be a sub-type of ivoa:timeInstant.</div><div><br></div><div>Regards,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Paul. <br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 4 Feb 2026, at 13:59, Mireille Louys <mireille.louys@unistra.fr> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div text="#000000" bgcolor="#FFFFFF"><p>Dear Paul, </p><p>I have followed the VODML discussion yesterday at the DM running
meeting . <br>
what is not clear to me is the status of the IVOA base types used
in the template model to build new Models . </p><p>When we issued the PhotDM 1.1 (2022) we needed two extra types
to encode 1: time instant in ISOTime , <br>
and 2: ucd strings . </p><p>so these are defined like this in the Phot-v1.vodml.xml : (<a moz-do-not-send="true" href="https://ivoa.net/xml/VODML/Phot-v1.vodml.xml" class="moz-txt-link-freetext">https://ivoa.net/xml/VODML/Phot-v1.vodml.xml
</a>)</p><p>----</p><p><primitiveType><br>
<vodml-id>UCD</vodml-id><br>
<name>UCD</name><br>
<description>Specialized string type derived from
ivoa:string. UCD words belong to a controlled vocabulary. They are
used as semantics tags for the content of table columns . See the
UCD IVOA Recommendation.<br>
</description><br>
<extends><br>
<vodml-ref>ivoa:string</vodml-ref><br>
</extends><br>
</primitiveType><br>
<br>
<primitiveType><br>
<vodml-id>ISOTime</vodml-id><br>
<name>ISOTime</name><br>
<description>Time stamp, represented as a string. This
representaion is compliant to the DALI time stamp definition :
section 3.3.3 Timestamp in<br>
<a class="moz-txt-link-freetext" href="https://www.ivoa.net/documents/DALI/20170517/REC-DALI-1.1.pdf">https://www.ivoa.net/documents/DALI/20170517/REC-DALI-1.1.pdf</a><br>
This class derives from the ivoa:datetime class.<br>
<br>
It could be inserted in the ivoa: template data model for types in
a next version. </description><br>
<extends><br>
<vodml-ref>ivoa:datetime</vodml-ref><br>
</extends><br>
</primitiveType></p><p>----</p><p>I think this would help a lot if these types would be part of the
VODML basic types . <br>
<br>
The same situation occured with MANGO for time stamps as discussed
yesterday. </p><p>many thanks , Mireille</p><p><br>
</p>
<pre class="moz-signature" cols="72">--
--
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</pre>
</div>
</div></blockquote></div><br></div></body></html>