[VO-semantics- UCD updates ]VEP-UCD-003.txt - "pos.moc" proposal and discussion

[Mireille LOUYS]

hi Stephane & hi Semantics members,

I discuss here the VEP-UCD3.txt proposal :

I guess we need to distinguish 2 uses-cases :
1- an encoding of the MOC as a string as expressed in the MOC 
specification : 
https://www.ivoa.net/documents/MOC/20191007/REC-MOC-1.1-20191007.pdf
subsection 2.3.2 String serialization

This can be inserted as a table column with one ucd like :
/meta.multiordercoverage/ or shorter /meta.moc/
then the kind of coverage axes included in the tessellation encoding 
should depend on an xtype to be defined as :
S_MOC, ST_MOC, T_MOC, E_MOC if there is one definition for energy 
coverage in the future.

Here the UCD string tells that a coverage is described in this column, 
the content is /the string encoding of a MOC /.
it fits to all data product types : image , time series, eventlist , etc 
, catalog
it encodes only the coverage of the tessellation of the data .
Data values , pixels, flux are not here.

2- data product type
When we deal with a HiPS Survey , or a HiPS observation, the data 
product type  tells more about  which axes the data vary along.
a data product is needed to describe the collection of tiles, described 
in the MOC string that contain data .
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.
The measurements belong to the data products , the tesselated coverage 
belongs to the string encoded MOC.

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
independant.

I hope this helps .
Comments welcome, Mireille


Le 29/03/2022 à 09:30, Stéphane Erard a écrit :
> Hello
>
>> Le 28 mars 2022 à 17:26, Mireille LOUYS<mireille.louys at unistra.fr>  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.
> 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.
>
> 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).
>
>
>> 	• spec.line.intIntensity
>> 	• are these part of EPN -TAP and included in your proposal Stephane ?
> 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
>
>
>> Cheers, Mireille
>>
>> Le 24/03/2022 à 14:42, Stéphane Erard a écrit :
>>> Hello
>>>
>>> I can present a summary of potential vocabularies associated to EPN-TAP, and possible solutions.
>>> Cheers
>>> Stéphane
>>>
>>>
>>>> Le 22 mars 2022 à 09:00, Markus Demleitner<msdemlei at ari.uni-heidelberg.de>
>>>>   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
>>>>
>> -- 
>> --
>> 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
>>

-- 
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20220329/97cf962f/attachment.html>