Vocabularising dataproduct_type

[NEBOT GOMEZ-MORAN Ada (OBS)]

Markus,

Thanks ! I like this proposal a lot, I find it simple and clean. 

Naïve question 
« find spectra » = « find spectrum » ? 
Maybe that is not worth mentioning ... but just to be sure I understand how this is supposed to work at the registry level. 

Cheers,
Ada


----- Mail d’origine -----
De: Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
À: dal at ivoa.net, registry at ivoa.net, semantics at ivoa.net
Envoyé: Mon, 09 Mar 2020 15:56:29 +0100 (CET)
Objet: Vocabularising dataproduct_type

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