<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Just a small addition here (after comments received off-list): I don't propose to use the 2-letter code in the vocabulary, but I let you know the list of dataproduct_types we use. <br class=""><div><br class=""></div><div>Cheers</div><div>Baptiste</div><div><br class=""><blockquote type="cite" class=""><div class="">Le 10 mars 2020 à 09:06, Baptiste Cecconi <<a href="mailto:Baptiste.Cecconi@obspm.fr" class="">Baptiste.Cecconi@obspm.fr</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class="">Hi Markus,</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">In EPNcore, we have a slightly more extended list of dataproduct_types as compared to Obscore. You can check the list here (we currently use a 2 letter code but the plain names are given, with some detailed statements):</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""></div><div dir="ltr" class=""><ul style="border: 0px; font-family: sans-serif; font-size: 17px; margin: 1em 0px; outline: 0px; line-height: 1.42; padding-left: 30px; caret-color: rgb(23, 43, 77); color: rgb(23, 43, 77); letter-spacing: -0.014109999872744083px; background-color: rgb(255, 255, 255);" class=""><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">im </strong>(= image): scalar field with two spatial axes, or association of several such fields, e.g., images with multiple color planes, from multichannel or filter cameras. Preview images (e.g. map with axis and caption) also belong here. Conversely, vectorial 2D fields are described as spatial_vector (see below).</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">ma </strong>(= <span class="inline-comment-marker" data-ref="e396789d-6014-486a-b015-09a3a25ce8c9" style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px;">map</span>): scalar field / rasters with two spatial axes covering a large area and projected either on the sky or on a planetary body, associated to <span style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px;" class="">spatial_coordinate_description and </span><span class="inline-comment-marker" data-ref="2093b833-846d-4265-96f5-624abf293d20" style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px;">map_projection parameters</span>(with a short enumerated list of possible values); each pixel is associated to 2D coordinates. This is mostly intended to identify <span style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; letter-spacing: 0px;" class="">radiometrically calibrated and orthorectified images with </span>complete coverage that can be used as reference basemaps. </li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">sp </strong>(= spectrum): measurements organized primarily along a spectral axis, e.g., radiance spectra. This includes spectral aggregates (series of related spectral segments with non-connected spectral ranges, e.g., from several channels of the same instrument, various orders from an échelle spectrometer, composite spectra, etc).</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">ds </strong>(= dynamic_spectrum): consecutive spectral measurements through time, organized primarily as a time series. This typically implies successive spectra of the same target / field of view.</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">sc </strong>(= spectral_cube): sets of consecutive spectral measurements with 1 or 2D spatial coverage, e.g., imaging spectroscopy. The choice between image and spectral_cube is dictated by the characteristics of the instrument (which dimension is most resolved & which dimensions are acquired simultaneously). The choice between dynamic_spectrum and spectral_cube is related to the uniformity of the field of view and by practices in the science field.</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">pr </strong>(= profile): scalar or vectorial measurements along 1 spatial dimension, e.g., atmospheric profiles, atmospheric paths, sub-surface profiles, traverses…</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">vo </strong>(= volume): measurements with 3 spatial dimensions, e.g., internal or atmospheric structures, including shells/shape models (3D surfaces).</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">mo </strong>(= movie): sets of chronological 2D spatial measurements (consecutive images)</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">cu </strong>(= cube): multidimensional data with 3 or more axes, e.g., all that is not described by other 3D data types such as spectral cube or volume. This is intended to accommodate unusual data with multiple dimensions. This can be used for 3D ancillary data associated to spectral cubes, e.g., providing the coordinates or illumination angles for each spectrum.</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">ts </strong>(= time_series): measurements organized primarily as a function of time (with exception of dynamical spectra and movies, i.e. usually a scalar quantity). Typical examples of time series include space-borne dust detector measurements, daily or seasonal curves measured at a given location (e.g. a lander), and light curves.</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">ca </strong>(= catalogue): applies to a granule providing a catalogue of object parameters, a list of features, a table of granules in another TAP service, a list of events... The result metadata table of a service can be considered as a catalogue. Catalogues can be provided as VOtable (possibly containing multiple tables, although this is not supported by SAMP). It is good practice to describe the type of data included in the catalogue using a hash-list (e.g., a table of spectra should be described by ca#sp, so that it will respond to a query for spectra).</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">ci </strong>(= catalogue_item): applies when the service itself provides a catalogue with entries described as individual granules, in particular when there is no associated file (e. g., a list of asteroid properties or spectral lines). Catalogue_item can be limited to scalar quantities (including strings), and possibly to a single element. This organization allows the user to search inside the catalogue from the TAP query interface.</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">sv</strong> (= spatial vector): vector information associated to localization, such as a spatial footprints, a GIS-related element, etc — e. g. a klm or geojson file (STC-S strings are provided though the s_region parameter, though). This includes maps of vectors, e.g., wind maps.</li><li style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; word-wrap: break-word;" class=""><strong style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; max-width: 100%;" class="">ev</strong> (= event): introduces individual VOevents formatted according to IVOA standard (or possibly events with other formatting, TBC)</li></ul><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class="">Looking at your proposed list, we don’t have Visibility, nor SED. I think our CatalogueItem is close to your Measurement. Then we have extra terms. All the terms listed here are used in at least 1 EPN-TAP service.</span></font></div><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class=""><br class=""></span></font></div><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class="">The reason the our choice to use a 2-letter code rather than an explicit name is the following: we have several examples of composite derived products, containing, e.g., a series of times series and dynamic spectra (various spectral intégrations and various polarizations). In this case the dataproduct_type is set to ts#ds. We can also use this for services providing catalogues of images, which would then described as ca#im</span></font></div><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class=""><br class=""></span></font></div><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class="">Baptiste</span></font></div><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class=""><br class=""></span></font></div><div class=""><font color="#172b4d" face="sans-serif" class=""><span style="caret-color: rgb(23, 43, 77); font-size: 17px; letter-spacing: -0.014109999872744083px;" class=""><br class=""></span></font></div><blockquote type="cite" class="">Le 10 mars 2020 à 08:28, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> a écrit :<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><span class="">Hi,</span><br class=""><span class=""></span><br class=""><span class="">With apologies for the wide crosspost, I'd suggest followups to</span><br class=""><span class="">DAL.</span><br class=""><span class=""></span><br class=""><span class="">In the past few weeks, in two different use cases it was felt</span><br class=""><span class="">desirable to have the terms for data product types introduced by</span><br class=""><span class="">Obscore outside of Obscore:</span><br class=""><span class=""></span><br class=""><span class="">(a) as qualifiers in media types (also beyond datalink).</span><br class=""><span class=""> <a href="http://mail.ivoa.net/pipermail/dal/2019-December/008252.html" class="">http://mail.ivoa.net/pipermail/dal/2019-December/008252.html</a></span><br class=""><span class=""></span><br class=""><span class="">(b) to declare the sort of data returned from SSAP services,</span><br class=""><span class=""> <a href="http://mail.ivoa.net/pipermail/registry/2020-February/005410.html" class="">http://mail.ivoa.net/pipermail/registry/2020-February/005410.html</a></span><br class=""><span class=""></span><br class=""><span class="">In this latter context I've now created a draft vocabulary from</span><br class=""><span class="">obscore dataproduct type. It has draft status at this point, so it's</span><br class=""><span class="">still cheap to change definitions, add terms, introduce structure,</span><br class=""><span class="">etc. Or to cancel the entire effort.</span><br class=""><span class=""></span><br class=""><span class="">The current vocabulary on <a href="http://www.ivoa.net/rdf/product-type" class="">http://www.ivoa.net/rdf/product-type</a> .</span><br class=""><span class=""></span><br class=""><span class="">My current plan is have this vocabulary reviewed as part of the</span><br class=""><span class="">review of SimpleDALRegExt 1.2.</span><br class=""><span class=""></span><br class=""><span class="">So... what do you think?</span><br class=""><span class=""></span><br class=""><span class="">Here are a few points I'd particularly request feedback on:</span><br class=""><span class=""></span><br class=""><span class="">(a) The vocabulary name: I went for product-type (singular), as the full</span><br class=""><span class=""> term URI then looks like <a href="http://www.ivoa.net/rdf/product-type#image" class="">http://www.ivoa.net/rdf/product-type#image</a></span><br class=""><span class=""> or so, which I find nice. If someone calls for having "data" in</span><br class=""><span class=""> there (data-product-type or dataproduct-type or whatever), I won't</span><br class=""><span class=""> quarrel. I still figure we won't have types of any other sort of</span><br class=""><span class=""> products and hence saving five characters seems worth the</span><br class=""><span class=""> deviation from obscore terminology.</span><br class=""><span class=""></span><br class=""><span class="">(b) I've made the vocabulary largely flat; only "sed" quite clearly is a</span><br class=""><span class=""> "spectrum". Do you see more structure in these concepts?</span><br class=""><span class=""></span><br class=""><span class="">(c) I've streamlined some of the descriptions from Obscore. For</span><br class=""><span class=""> instance, I've removed the language on formats in the cube</span><br class=""><span class=""> definition, as it seems somewhat ephemeral, and I've tried to be</span><br class=""><span class=""> more precise in sed to get its primary characteristic in focus. And</span><br class=""><span class=""> I've made the definition for visibility very short -- radio folks,</span><br class=""><span class=""> complain if you disagree.</span><br class=""><span class=""></span><br class=""><span class="">Thanks,</span><br class=""><span class=""></span><br class=""><span class=""> Markus</span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>