<div dir="ltr">Mireille,<br><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 10:17 AM, Louys Mireille <span dir="ltr"><<a href="mailto:mireille.louys@unistra.fr" target="_blank">mireille.louys@unistra.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<i><br>
Hi Mark, hi all, <br>
<br>
<br>
Many thanks for the update and corrections in the document which
improves in clarity , namely for the observation , dataset Ids . <br>
Only minor suggestions below.<br>
My comments in slanted font:<br>
<br>
stdRefPosition: appears first in 3.10 and is defined in 6.4 in the
datatypes. </i><i><br>
</i><i> that would help to have a reference link to the definition
on the first occurences in the text. </i><br>
<br></div></blockquote><div>That is true for many elements of the model, I think that would be a good addition to the newer documents<br></div><div>(DatasetMetadata and NDCube), which are earlier in the process.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
p67.<br>
<i>Dataproducttype enumeration list contains one literal equals to
'MIXED Some combination of the other options'.</i><i><br>
</i><i>Are there any service implementations currently using this
kind of data product type?<br>
<br>
The problem of </i><i>combined , and or complex datasets is not
supported by this Spectrum model. <br>
There will be a discussion in Sesto In DAL on the use of DataLink
and existing models to tackle these situations .<br>
</i></div></blockquote><div><br></div><div>The 'MIXED' value was removed in the Dataset Metadata document.. where we resolved the set shown here, and the set in ObsCore.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><i> </i><br>
p65.<br>
The concept of the ”nu L-nu” or ”lambda L-lambda” luminosity flux,
or equivalently the<br>
luminosity per logarithmic energy interval L(log nu), is a distinct
concept in the world of spectral<br>
energy distributions - and it’s a di erent concept from the
bolometric luminosity, ff which has the<br>
same units. The UCD board has not yet approved a UCD expressing this
concept; we have to<br>
use phys.luminosity and infer the concept from the units.<br>
<br>
<i>is this an implicit request for a new UCD </i><i>? this can be
taken into account in Semantics </i><i>, I sent a request for
that.</i><br></div></blockquote><div><br></div><div>Yes, I suppose it is.. I don't know if a formal request was ever submitted to the Semantics group.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
p97. <br>
• A Photometry Filter may not be serialized in the same file as the
photometric sequence.<br>
There is no mechanism for serializing a reference to another
extension within the same file.<br>
It may be referred to via the keyword holding the reference URI.<br>
<br>
<i>I am not sure I understand this paragraph : do we need an example
here to show </i><i><br>
</i><i>how to link an example of a spectrum (spectrumDM2.0 ) to a
filter description from Filter in PhotDM?</i><br>
<br></div></blockquote><div><br></div><div>In the FITS serialization, one cannot serialize the filter in the same file as the spectrum because<br></div><div>there is no FITS standard for referring to another extension of the same file. So, one must use the<br></div><div>keyword which maps to the URI pointer. (PHID, I think).<br><br></div><div>The example serializations in the file are limited to the required set, mainly because a complete serialization would be very large.. but yes, that would be helpful.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div bgcolor="#FFFFFF" text="#000000">
<i>RefPos vs referencePosition:</i><i><br>
</i><i>all Frame in the text use the attribute name
'referencePosition' but the utype list uses 'RefPos' like in
CoordSys.FluxFrame.RefPos</i><i><br>
</i><i>if the utype string does not matter why not homogeneise and
use 'referencePosition'in the Utype string. </i><i><br>
</i><i>This will be generated this way </i><i>in both cases : VODML
serialisation or legacy utypes </i><i>, I suppose.</i><br>
<br></div></blockquote><div><br></div><div>The UType with 'RefPos' is consistent with the other frames, and earlier 'old-style' utype lists for the spectral model. Its true, the migration to a vodml representation will result in vo-dml tags that are more consistent with the attributes. <br><br></div><div> </div></div></div></div></div>