<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="4" face="Helvetica, Arial, sans-serif">hi Stephane &
hi Semantics members,<br>
<br>
I discuss here the VEP-UCD3.txt proposal :<br>
<br>
I guess we need to distinguish 2 uses-cases : <br>
1- an encoding of the MOC as a string as expressed in the MOC
specification : <a moz-do-not-send="true"
href="https://www.ivoa.net/documents/MOC/20191007/REC-MOC-1.1-20191007.pdf"
class="moz-txt-link-freetext">https://www.ivoa.net/documents/MOC/20191007/REC-MOC-1.1-20191007.pdf</a><br>
subsection </font><span style="font-size: 13.000000pt;
font-family: 'Arial'; font-weight: 700; color: rgb(0.000000%,
35.294000%, 61.176000%)"><font size="4" face="Helvetica, Arial,
sans-serif">2.3.2 String serialization
</font><br>
<br>
</span><font size="1"><span style="font-size: 13pt; font-family:
"Arial"; font-weight: 700;"></span><span
style="font-size: 13pt; font-family: "Arial";"></span><font
size="2" face="Helvetica, Arial, sans-serif"><span
style="font-size: 13pt;">This can be inserted as a table
column with one ucd like : </span><br>
<span style="font-size: 13pt;"><i>meta.multiordercoverage</i>
or shorter <i>meta.moc</i> </span><br>
<span style="font-size: 13pt;">then the kind of coverage axes
included in the tessellation encoding should depend on an
xtype to be defined as : </span><br>
<span style="font-size: 13pt;">S_MOC, ST_MOC, T_MOC, E_MOC if
there is one definition for energy coverage in the future.</span><span
style="font-size: 13pt;"> </span></font><font
face="Helvetica, Arial, sans-serif"><span style="font-size:
13pt;"><br>
<br>
</span></font></font><font face="Helvetica, Arial, sans-serif"><span
style="font-size: 13pt;">Here the UCD string tells that a
coverage is described in this column, the content is <i>the
string encoding of a MOC </i>.</span><br>
<span style="font-size: 13pt;">it fits to all data product types :
image , time series, eventlist , etc , catalog </span><br>
<span style="font-size: 13pt;">it encodes only the coverage of the
tessellation of the data . </span><br>
<span style="font-size: 13pt;">Data values , pixels, flux are not
here. </span><span style="font-size: 13pt;"></span><br>
<span style="font-size: 13pt;"></span><br>
<span style="font-size: 13pt;">2- data product type <br>
When we deal with a HiPS Survey , or a HiPS observation, the
data product type tells more about which axes the data vary
along.</span><br>
<span style="font-size: 13pt;">a data product is needed to
describe the collection of tiles, described in the MOC string
that contain data .</span><br>
<span style="font-size: 13pt;">This can be an image survey with
S_MOC or ST_MOC, a time series (with T_MOC or ST_MOC ), a cube
survey (with ST_MOC or only S_MOC) etc. </span><br>
<span style="font-size: 13pt;">The measurements belong to the data
products , the tesselated coverage belongs to the string encoded
MOC.</span><br>
<span style="font-size: 13pt;"></span><span style="font-size:
13pt;"><br>
</span></font><span style="font-size: 13pt; font-family:
"Arial";"><font face="Helvetica, Arial, sans-serif">And
we may want to handle image surveys with S_MOC only or ST_MOC ,
currently the tessellation coverage , and the nature of the data
collection are </font><br>
</span><span style="font-size: 13pt; font-weight: 700; color: rgb(0,
90, 156); font-family: "Arial";"></span> <font size="4"
face="Helvetica, Arial, sans-serif">independant.<br>
<br>
I hope this helps .<br>
Comments welcome, Mireille<br>
</font><br>
<br>
<div class="moz-cite-prefix">Le 29/03/2022 à 09:30, Stéphane Erard a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:E1430AA4-6CBB-431B-B00A-225436E8DB4D@obspm.fr">
<pre class="moz-quote-pre" wrap="">Hello
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Le 28 mars 2022 à 17:26, Mireille LOUYS <a class="moz-txt-link-rfc2396E" href="mailto:mireille.louys@unistra.fr"><mireille.louys@unistra.fr></a> a écrit :
Hi Stephane , Hi Markus
I would like to suggest discussions on some UCDs:
• VEP-UCD-0003 pos.moc discussed on semantics; it is not clear there is a clear purpose for this. There is a suspicion this is more an xtype thing. Additionall, moc can be T-MOC, S-MOC or ST-MOCs, so UCD's role is perhaps more to say just what exactly to MOC represents.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes, there are several things here.
1) Basically, we want a "moc" parameter in EPN-TAP to provide footprints, but not as contours (we also use ObsCore s_region).
The closest existing UCD is pos.contour and doesn’t match MOC definition, so something is missing here and I think this is of general interest.</pre>
</blockquote>
<blockquote type="cite"
cite="mid:E1430AA4-6CBB-431B-B00A-225436E8DB4D@obspm.fr">
<pre class="moz-quote-pre" wrap="">
2) Indeed we can imagine an EPN-TAP service providing geological or spectral units as MOC; or a spacecraft observation plan as ST-MOC.
In both cases, we need a relevant UCD in measurement_type.
Ideally, I’d like Aladin or whatever tool to understand this is a MOC (from a global UCD?) then to handle it correctly depending on MOC syntax which should be self-explanatory (I think this is the way it works with s_region)
Having several UCD could also help solve this.
3) The same issue is addressed on the RFM page / point#2 but this seems complicated:
"pos.moc" is in the EpnCore "measurement_type", to advertise the content of the product. Could be used with "dataproduct_type", to tell which axes are in the MOC (e.g., 'im' for classical MOC, 'mo' for STMOC, 'ts' for TMOC…)
I really don’t like the idea that a parameter needs to be interpreted as a function of another parameter…
4) Besides, we can imagine individual images associated to ST-MOC as regions, e.g., to describe an evolving target.
MOC would be provided not as the main product but in the above "moc" parameter (as in [1] ), and could be used to search for overlapping data in space and time (like: observations of a region of 67P at similar times; this also stands for events, e.g., either lunar flashes or anything on the sky).
I think this is similar to case 1, but inconsistent with 3 (although I admit this duplicates the use of time range + spatial coverage).
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> • spec.line.intIntensity
• are these part of EPN -TAP and included in your proposal Stephane ?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
This is related to another EPN-TAP extension for (spectral) band lists. What we need here is the Integrated Intensity (band area), which for us makes more sense than Equivalent Width.
Cheers
Stéphane
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Cheers, Mireille
Le 24/03/2022 à 14:42, Stéphane Erard a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hello
I can present a summary of potential vocabularies associated to EPN-TAP, and possible solutions.
Cheers
Stéphane
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Le 22 mars 2022 à 09:00, Markus Demleitner <a class="moz-txt-link-rfc2396E" href="mailto:msdemlei@ari.uni-heidelberg.de"><msdemlei@ari.uni-heidelberg.de></a>
a écrit :
Dear Semantics community,
>From April 25 through 29, there will be again in Interop (albeit
again a virtual one).
I'd like to run a session on Semantics topics, where contributions
on any of developing vocabularies, clever usage of our vocabularies,
proposals for evolving our standards, or much anything else in the
world of semantics would be welcome.
If you have a topic, please let me know by something like April 10th.
Thanks,
Markus
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
--
--
Mireille Louys, MCF (Associate Professor)
Centre de données CDS IPSEO, Images, 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>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--
Mireille Louys, MCF (Associate Professor)
Centre de données CDS IPSEO, Images, 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>