<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Times New Roman, Times, serif">Hi DMers, <br>
</font><br>
<font face="Times New Roman, Times, serif">Some requirements for
corrections in the ObsCore DM specifications have been adressed
during Alberto's talk in Apps , <br>
</font><font face="Times New Roman, Times, serif">and circulated on
the dm list since last interop .</font><br>
<font face="Times New Roman, Times, serif"> We will collect the requirements
for changes and I can , as editor of the spec , propose an Errata
Page for ObsCore v1.1 to be evaluated by TCG before next Interop .
<br>
</font><br>
<font face="Times New Roman, Times, serif">Currently the wish list
is : <br>
</font><br>
<i><font face="Times New Roman, Times, serif">Alberto Micol: correct
obs_publisher_id corresponding UCD in table 6 p. 56</font></i><br>
<font face="Times New Roman, Times, serif">Answer : I have two suggestions
to resolve this:</font><br>
<font face="Times New Roman, Times, serif"> 1- to update this UCD
with <b>meta.ref.ivoid</b>, as stated in the model item
definition ; this was what was considered when the spec appeared</font><br>
<font face="Times New Roman, Times, serif">2- just write<b> meta.id</b>
, which will relax the requirement on the way archives want to
choose an ID for the publisher DID . <br>
</font><br>
<font face="Times New Roman, Times, serif">For instance, some
publishers are </font><font face="Times New Roman, Times, serif"><font
face="Times New Roman, Times, serif">currently </font>examining
DOIs instead of Ivoa Ids. Will this make the definition of an IVOA
ID evolve ? Not sure. <br>
this leaves the door open for some redefinition on ids without
breaking the ObsCore spec. <br>
<br>
<i>Marco Molinaro feedback from implementation <br>
see <a moz-do-not-send="true"
href="http://mail.ivoa.net/pipermail/dm/2017-August/005604.html">http://mail.ivoa.net/pipermail/dm/2017-August/005604.html</a><br>
</i></font>1 - pol_states
<div>This field is listed as mandatory in §3.2 (Table 1, page 21)
but then, Appendix B page 42, in Table 5 the MANdatory column says
NO. After that, Table 6 on page 57 lists pol_states again among
the mandatory fields.</div>
<div>This looks like simply a typo.</div>
<div><br>
#answer : I agree it is a typo --> to mention as errata </div>
<div><br>
2 - t_refpos</div>
<div>This field is listed in Table 5 (Appendix B) page 41 as an
optional one, but has no other entry in the specification, e.g. it
has no entry in Table 7 (Appendix C.2) so that no Utype or UCD is
defined for it.</div>
<div>This one looks like a simple forgetfulness.<br>
<br>
#answer : as we are considering Time series to be handled by
ObsCore for discovery, this reference for the time system has to
be re worked. <br>
Feedback from the dm list is welcome for this <br>
</div>
<div><br>
</div>
<div>3 - units for strings</div>
<div>Table 5 (pagg. 40-43) reports units for the various fields.
However it defines string-type fields to be unitless except for
s_region (no value is reported) and proposal_id (which is set as
unit=string).<br>
<br>
#answer : I agree it is a typo --> to mention as errata <br>
<br>
Your comments welcome . These will be taken into account and
discussed with author's of the spec in order to feed the Errata
page.<br>
<br>
The dm list is the place to discuss improvements and errata for
IVOA standards. <br>
Many thanks , <br>
<br>
Mireille Louys <br>
</div>
<pre class="moz-signature" cols="72">--
--
Mireille Louys
CDS IPSEO, MIV, Laboratoire 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
tel: +33 3 68 85 24 34</pre>
</body>
</html>