Vocabularising dataproduct_type

[Pierre Fernique]

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


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200310/09ce9132/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kkicmoolebceblop.png
Type: image/png
Size: 103820 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200310/09ce9132/attachment-0001.png>