Vocabularising dataproduct_type

[Baptiste Cecconi]

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 <http://www.ivoa.net/documents/HiPS/20170519/REC-HIPS-1.0-20170519.pdf>, 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 <http://www.ivoa.net/documents/Notes/HiPSProg/20180525/HiPSProgenitor.pdf>).
> <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 <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 <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 <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 <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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200310/188502e6/attachment.html>