<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>Sorry for the delay.<br>
</p>
<div class="moz-cite-prefix">Le 03/06/2020 à 09:27, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20200603072704.oiy2xymttliiuyqe@victor">
<pre class="moz-quote-pre" wrap="">Hi François,
Thanks for your feedback.
On Tue, Jun 02, 2020 at 07:32:46PM +0200, François Bonnarel wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 1 ) VEI instead of VEP : "Vocabulary Enhancment Issue", instead of
Vocabulary Enhancment Proposal : The issue will be centered on a rationale
and not on a single term. Some discussions have shown that a term can be
preferred to another one with the same rationale and definition. A term can
also become the head term of a whole hierachy during the discussion
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Frankly, that would rank rather high on my pain scale. We don't do
bug tracking with VEPs (perhaps there's a place for that, too, but
I'm pretty sure that needs a different tool). No, each VEP
*proposes* a very specific action, and that's by design: discussions
should be exactly to the point, being able to assess concrete
consequences.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">For example the "VEP" I proposed on May the 22nd at 8:40 UTC could become
the "VEI" written as below. rationale will come first and prposed
Alternative terms and possible child terms belong to the same VEI. The end
of the process would be to converge on one single hierarchy of terms.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'd say the right place for this sort of discussion would be the
semantics list, a live meeting, or perhaps one of the ~bimonthly
Semantics telecons I'd like to start soon. Or, really, any other
informal setting that works for forging the proverbial rough
consensus.
So... why would you want a formal process for this kind of thing?</pre>
</blockquote>
<p>Well the VEP as you proposed in the document is a formal process.</p>
<p>My experience with DataLink convinced me it is too formal to
drive the use-case/term matching discussion.</p>
<p>My proposal was to try to use the VEP basic structure and relax a
little bit the constraints</p>
<p>The important point is that the process allow the discussion of
all issues related to the use-case.</p>
<p>Any solution allowing this before we concentrate on validating a
single term by "yes or no" would be fine. <br>
</p>
<blockquote type="cite"
cite="mid:20200603072704.oiy2xymttliiuyqe@victor">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 2 ) for the same reason (incomplete discussion) "Preliminary" terms
should not be set in the "official" vocabulary list even with the
"preliminary" tag. Examples using those terms should be provided in
prototype services or realistic example files.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That would be a bit lower, but still high on my pain scale. I've
designed the "preliminary" mechanism in order to discourage the
definition of terms just because we believe they might one day be
useful. Experience shows that such beliefs quite regularly turn out
to be wrong, and cleaning up the resulting mess isn't fun.
Instead, I'd like to have a mechanism where something comes into
being when it is required in a *live* service (or interpreted by a
non-trivial client) -- that, in my view, is a necessary condition for
something to be a good idea (of course, it's not a sufficient
condition, which is why we're still discussing after a VEP).
Plausible examples IMHO aren't enough -- if there's no immediate need
for a term, we should wait until that immediate need comes up, at
which point we probably better understand the problem we're trying to
solve.
Now, as someone whose Registry endpoint is invalid more or less all
the time because there's always some record in which I prototype new
stuff, I'd like to make this process easy and non-disruptive on the
service operators, meaning: Their documents should not become invalid
for extended periods of time.
Since I'd like recommendations to be able to say "attribute X MUST
come from vocabulary Y", this means that proposed terms need to enter
the vocabulary fast. The ~day of invalidity between the submission
of a VEP and the update of the vocabulary in the current scheme seems
acceptable to me.
I'll readly admit that I don't like the whole concept of
"preliminarily valid" documents much either. But since I consider
the define-as-required principle rather important, I don't see much
of a way around it.
Note, though, that by 5.2.2, "Deprecation or modification VEPs have
no immediate effect." I suppose tree-modifying VEPs might profit
from being tried out widely before being deployed, but then such
modifications can quickly be undone if they turn out to have
unforseen side effects without impacting the validity of anything.</pre>
</blockquote>
<p>Well, VOC 2.0 section 2.1.7 states</p>
<p><br>
</p>
<p>
<blockquote type="cite">As vocabularies evolve, new terms are
being added to
vocabularies. To facilitate their review and enable rapid uptake
of the proposed terms, it is desirable that new terms and even
new vocabularies are immediately visible to users and tools.
Note that since terms under review might be modified or removed
later,
this use case is somewhat in conflict with the basic requirement
of stable vocabularies (i.e., a document valid once will not
become invalid later because of changes in vocabularies).
</blockquote>
</p>
<p>I agree that it is somewhat in conflict.</p>
<p>and 2.2.10 reads<br>
</p>
<p>
<blockquote type="cite">In use case <a
href="http://www.ivoa.net/documents/Vocabularies/20200612/WD-Vocabularies-2.0-20200612.html#uc:simplereview">2.1.7</a>,
it is desirable to admit
"preliminary" vocabularies and terms. For these, both humans
and machines must be able to discern a temporary status, and
their use implies that the general rule "once valid, always
valid" does not apply. Validators and similar software could
then add notices to that effect in their outputs.
</blockquote>
My point is : how is this achieved ? There is no technical
proposal there and I know services where preliminary terms are jus
added as if they were adopted. <br>
</p>
<p>A mechanism (specific URI ?) to mark the preliminary status of
the term should be proposed in the spec.</p>
<p>In addition I think adding terms which may be changed later in
operational services maybe a large constraint to service
mainteners. That's why I think it should be admitted that a
prototype (for example a partial clone of your operational
service) should be sufficient to show the benefit of the term. </p>
<p>Cheers</p>
<p>François<br>
</p>
<p><br>
<br>
</p>
<blockquote type="cite"
cite="mid:20200603072704.oiy2xymttliiuyqe@victor">
<pre class="moz-quote-pre" wrap="">
Thanks,
Markus
</pre>
</blockquote>
</body>
</html>