The product-type vocabulary

[Stéphane Erard]

Hello


As you may know, EPNCore uses extra datatypes, mainly:
- spectral_cube (which may be 2D), in addition to volume (3D space) and cube which can have other dimensions (e.g., 1D/2D angular; also pointing information associated to a spectral_cube)

The other ones resolve (in our case) the issue of a generic "measurement" type: 
- map (2D spatial — orthorectified image or mosaic, including HiPS)
- profiles: along 1 spatial dimension (atmospheric profiles, or traverses)
- photometric_function, which doesn’t belong anywhere else (X= angular quantity)
- movies (consecutive images or maps - yes, a sort of cube)
- catalogue (a 2D list of scalar values)
- catalogue_item (one row of a catalogue)
- spatial_vector (footprints and contours, but also vector maps)

The rationale of course may be different - this is intended in particular to identify tools whiçch can handle/plot the data correctly.

Regards
Stéphane


> Le 15 déc. 2021 à 09:03, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> a écrit :
> 
> Dear Semantics, Dear DAL,
> 
> The current Datalink WD
> (http://ivoa.net/documents/DataLink/20211115/index.html) needs a
> vocabulary of product types (images, spectra,...), mainly to satisfy
> the "figure out a client suitable as a SAMP target" use case.
> 
> While there are other use cases (of course, dataproduct_type in
> obscore, but perspectively also searching by the sort of data
> products coming out of a service in the Registry), because of the
> Datalink WD review I'd say it's up to DAL to bring this vocabulary
> into shape.
> 
> I've published a draft of this at
> <http://www.ivoa.net/rdf/product-type>, which basically reflects the
> word list used by obscore, plus #dynamic-spectrum at the request of
> the SSIG.
> 
> I had talked about that re-design at the last Interop,
> <https://wiki.ivoa.net/internal/IVOA/InterOpNov2021Sem/product-type.pdf>
> -- if you've not been there, briefly skimming the notes might help
> understanding where this is going.
> 
> By Vocabularies rules, as long as the vocabulary is preliminary,
> terms can be easily added and removed (though in this case I'd say we
> shouldn't remove anything coming from obscore, although I have to say
> I'd rather not have #measurements in its current shape).  If you have
> proposals in either direction, feel free to bring them forward here.
> 
> Thanks,
> 
>          Markus