<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&nbsp;already&nbsp;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 &lt;<a href="mailto:Pierre.Fernique@astro.unistra.fr" class="">Pierre.Fernique@astro.unistra.fr</a>&gt; 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
      =&gt; <b class="">meta </b>(for meta data information associated to an
      HiPS =&gt; 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">&lt;kkicmoolebceblop.png&gt;</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&nbsp;:<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>