Vocabularising dataproduct_type

[Stéphane Erard]

Hello


I would add that dataproduct_type in EPN-TAP is used perhaps mostly to identify visualization tools to use from the portal. So it is related to SAMP messages somehow. 
The concept can be used to search for data types but it is probably too vague to provide fine results (e.g. spectra is OK, but we really want to look for reflectance or radiance spectra - hence, UCDs are required for this). 
Our “catalogue_item"  probably includes HiPS' “meta".
We don’t have SED (even the name is not usual on our side) but rather (composite) spectra.
« measurements» would fall under EPN-TAP's catalogue I guess - a list of values related to whatever elements, either sources, features, objects (not extracted from images, e.g. asteroids) etc, which may relate to simulations rather than measurements.
At some point we decided to distinguish between many 3D data types - spectral cubes are specific and cannot be handled as volume data, for instance.


Stéphane


> Le 10 mars 2020 à 10:35, Baptiste Cecconi <baptiste.cecconi at obspm.fr> a écrit :
> 
> I agree that the obs_core should be the baseline, as it is already in use.
> The epn_core list (not the two-letter codes, but the types) is an extension of the obs_core list. So they could be merged easily.
> 
> Baptiste
> 
>> Le 10 mars 2020 à 10:01, Pierre Fernique <Pierre.Fernique at astro.unistra.fr> a écrit :
>> 
>> 
>> Hi all,
>> 
>> To keep a global view of dataproduct_type vocabulary current usage, I just mention that in HiPS IVOA REC 1.0, the properties associated to each HiPS has re-used as much as possible the obscore vocabulary, and notably the dataproduct_type keyword vocabulary. Presently the following words are specified in the HiPS document:
>> 	• dataproduct_type = image
>> 	• dataproduct_type = cube
>> 	• dataproduct_type = catalog
>> Another value are used, but not specify in the HiPS document => meta (for meta data information associated to an HiPS => for accessing to the progenitors for instance - cf HiPS progenitors IVOA note).
>> 
>> <kkicmoolebceblop.png>
>> 
>> Le 09/03/2020 à 15:56, Markus Demleitner a écrit :
>>> Hi,
>>> 
>>> With apologies for the wide crosspost, I'd suggest followups to
>>> DAL.
>>> 
>>> In the past few weeks, in two different use cases it was felt
>>> desirable to have the terms for data product types introduced by
>>> Obscore outside of Obscore:
>>> 
>>> (a) as qualifiers in media types (also beyond datalink).
>>>     
>>> http://mail.ivoa.net/pipermail/dal/2019-December/008252.html
>>> 
>>> 
>>> (b) to declare the sort of data returned from SSAP services,
>>>     
>>> http://mail.ivoa.net/pipermail/registry/2020-February/005410.html
>>> 
>>> 
>>> In this latter context I've now created a draft vocabulary from
>>> obscore dataproduct type.  It has draft status at this point, so it's
>>> still cheap to change definitions, add terms, introduce structure,
>>> etc.  Or to cancel the entire effort.
>>> 
>>> The current vocabulary on 
>>> http://www.ivoa.net/rdf/product-type
>>>  .
>>> 
>>> My current plan is have this vocabulary reviewed as part of the
>>> review of SimpleDALRegExt 1.2.
>>> 
>>> So... what do you think?
>>> 
>>> Here are a few points I'd particularly request feedback on:
>>> 
>>> (a) The vocabulary name: I went for product-type (singular), as the full
>>>     term URI then looks like 
>>> http://www.ivoa.net/rdf/product-type#image
>>> 
>>>     or so, which I find nice.  If someone calls for having "data" in
>>>     there (data-product-type or dataproduct-type or whatever), I won't
>>>     quarrel.  I still figure we won't have types of any other sort of
>>>     products and hence saving five characters seems worth the
>>>     deviation from obscore terminology.
>>> 
>>> (b) I've made the vocabulary largely flat; only "sed" quite clearly is a
>>>     "spectrum".  Do you see more structure in these concepts?
>>> 
>>> (c) I've streamlined some of the descriptions from Obscore. For
>>>     instance, I've removed the language on formats in the cube
>>>     definition, as it seems somewhat ephemeral, and I've tried to be
>>>     more precise in sed to get its primary characteristic in focus.  And
>>>     I've made the definition for visibility very short -- radio folks,
>>>     complain if you disagree.
>>> 
>>> Thanks,
>>> 
>>>             Markus
>>> 
>> 
>> 
>