Voc in the VO 2 / remarks
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Wed Jun 3 09:27:04 CEST 2020
Hi François,
Thanks for your feedback.
On Tue, Jun 02, 2020 at 07:32:46PM +0200, François Bonnarel wrote:
> 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
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.
> 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.
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?
> 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.
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.
Thanks,
Markus
More information about the semantics
mailing list