<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Dear Markus, all,<br>
    </div>
    <div class="moz-cite-prefix">Le 15/09/2021 à 16:50, Markus
      Demleitner a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:20210915145053.iv4xsin4vv6rdgr2@victor"><br>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">This is a point where I have a major disagreement with Markus I'm
afraid.

If we want to build a consistent vocabulary we have to think a
little bit ahead and also around the specific use case we are
dealing with.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
It would certainly be nice to do that, but frankly, all experience
has shown that it's hard to get that right.  The current debate on
#calibration is an example: I'll be the first to admit that the
VEP-006 solution isn't great, but it's the best we can do given
decisions passed when we didn't yet understand the problems as well.
</pre>
    </blockquote>
    <p>What is exactly my concern about VEP-006<b> as it is now </b>?</p>
    <p>The previous definitions of #calibration, #bias, #dark and #flat
      were perfectly correct for use case A (calibration stuffed already
      applied to obtain #this, see my previous email)</p>
    <p>Sincerely when we created this datalink semantics vocabulary in
      2014, I always understood that is was for use case A and that we
      all had that in mind. And the old definition was pretty good for
      that.<br>
    </p>
    <p>In VEP-006 the new definition moves from "use case A" to "use
      case B" (calibration stuff we want to apply to #this) and let "use
      case A" orphan !!</p>
    <p>The trick is that even if we could duplicate the #calibration
      tree with different terms for each of these use cases, most of the
      definition will be the same. Except the tense.</p>
    <p>So my proposal to modify VEP-006 and tackle both use cases. Can
      we combine terms in the semantics field ?</p>
    <p>Can we have a single #calibration branch for calibration stuff
      and combine it with a relationship term like "#applied",
      #applicable ?</p>
    <p>Instead of having #calibration_applicable and
      #calibration_applied (and children) as terms to check in the
      vocabulary list for the client, we would have
      #calibration;#applied and #calibration;#applicable. And there the
      client has to check a combination of two terms available in the
      vocabulary list.</p>
    <p>Is that something that developers of clients could admit ?</p>
    <p>Cheers</p>
    <p>François<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
  </body>
</html>