<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="">I agree that the obs_core should be the baseline, as it is already in use.<div class="">The epn_core list (not the two-letter codes, but the types) is an extension of the obs_core list. So they could be merged easily.</div><div class=""><br class=""></div><div class="">Baptiste<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 10 mars 2020 à 10:01, Pierre Fernique <<a href="mailto:Pierre.Fernique@astro.unistra.fr" class="">Pierre.Fernique@astro.unistra.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 class="">
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Hi all,<br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">To keep a global view of <b class="">dataproduct_type</b>
vocabulary current usage, I just mention that in <a moz-do-not-send="true" href="http://www.ivoa.net/documents/HiPS/20170519/REC-HIPS-1.0-20170519.pdf" class="">HiPS
IVOA REC 1.0</a>, 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:</div>
<ul class="">
<li class="">dataproduct_type = <b class="">image</b></li>
<li class="">dataproduct_type = <b class="">cube</b></li>
<li class="">dataproduct_type = <b class="">catalog</b></li>
</ul><p class="">Another value are used, but not specify in the HiPS document
=> <b class="">meta </b>(for meta data information associated to an
HiPS => for accessing to the progenitors for instance - cf <a moz-do-not-send="true" href="http://www.ivoa.net/documents/Notes/HiPSProg/20180525/HiPSProgenitor.pdf" class="">HiPS
progenitors IVOA note</a>).<br class="">
</p>
<div class="moz-cite-prefix">
<div class="moz-cite-prefix">
<div class="moz-cite-prefix"><span id="cid:part3.3DBFCB94.F0FEA6A3@astro.unistra.fr"><kkicmoolebceblop.png></span></div>
<div class="moz-cite-prefix"><br class="">
</div>
</div>
</div>
<div class="moz-cite-prefix">Le 09/03/2020 à 15:56, Markus
Demleitner a écrit :<br class="">
</div>
<blockquote type="cite" cite="mid:20200309145629.bohiz2kmkvpa7ky4@victor" class="">
<pre class="moz-quote-pre" wrap="">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).
<a class="moz-txt-link-freetext" href="http://mail.ivoa.net/pipermail/dal/2019-December/008252.html">http://mail.ivoa.net/pipermail/dal/2019-December/008252.html</a>
(b) to declare the sort of data returned from SSAP services,
<a class="moz-txt-link-freetext" href="http://mail.ivoa.net/pipermail/registry/2020-February/005410.html">http://mail.ivoa.net/pipermail/registry/2020-February/005410.html</a>
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 <a class="moz-txt-link-freetext" href="http://www.ivoa.net/rdf/product-type">http://www.ivoa.net/rdf/product-type</a> .
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 <a class="moz-txt-link-freetext" href="http://www.ivoa.net/rdf/product-type#image">http://www.ivoa.net/rdf/product-type#image</a>
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
</pre>
</blockquote><p class=""><br class="">
</p>
</div>
</div></blockquote></div><br class=""></div></body></html>