Voc in the VO 2 / remarks

[François Bonnarel]

Hi all,

Sorry for the delay.

Le 03/06/2020 à 09:27, Markus Demleitner a écrit :
> 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?

Well the VEP as you proposed in the document is a formal process.

My experience with DataLink convinced me it is too formal to drive the  
use-case/term matching discussion.

My proposal was to try to use the VEP basic structure and relax a little 
bit the constraints

The important point is that the process allow the discussion of all 
issues related to  the use-case.

Any solution allowing this before we concentrate on validating a single 
term by "yes or no" would be fine.

>
>>        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.

Well, VOC 2.0 section 2.1.7 states


> 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). 

I agree that it is somewhat in conflict.

and 2.2.10 reads

> In use case 2.1.7 
> <http://www.ivoa.net/documents/Vocabularies/20200612/WD-Vocabularies-2.0-20200612.html#uc:simplereview>, 
> 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. 
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.

A mechanism (specific URI ?) to mark the preliminary status of the term 
should be proposed in the spec.

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.

Cheers

François



>
> Thanks,
>
>          Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200619/a0985d32/attachment.html>