From francois.bonnarel at astro.unistra.fr Wed Jan 5 17:13:49 2022 From: francois.bonnarel at astro.unistra.fr (BONNAREL FRANCOIS) Date: Wed, 5 Jan 2022 17:13:49 +0100 Subject: The product-type vocabulary In-Reply-To: <20211215080319.aaefidcolo56q4db@victor> References: <20211215080319.aaefidcolo56q4db@victor> Message-ID: Dear all, Le 15/12/2021 ? 09:03, Markus Demleitner 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. There are two good reasons to go in this direction at least. We have obviously new use cases where we may need more accurate (narrower) terms. - In the context of ObsCore we could always manage that with dataproduct_subtype (with the interoperability drawback that it is not supposed to contain standard terms in general) but in the context of the DataLink "content_qualifier" field (see DataLink 1.1 WD) we would not have this possibility. SO we have to extend the list of terms beyond the current ObsCore list. - Many of the new terms may show relationships with other terms which are not simply hierarchical. A good example is the new "dynamic spectrum" term which is a TimeSeries and also a spectrum. Apparently SKOS allows to manage such relationships. I have written a long email to propose a way to extend this SKOS vocabulary in a consistent way in the future on the semantics list a couple of minutes ago. (http://mail.ivoa.net/pipermail/semantics/2022-January/002948.html) As a first step I support Markus' proposal. Cheers Fran?ois > > I've published a draft of this at > , 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, > > -- 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