Voc in the VO 2 / remarks

[Markus Demleitner]

Dear François,

On Fri, Jun 19, 2020 at 09:40:19AM +0200, François Bonnarel wrote:
> > > 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.

Yes, but it is a formal process for a different thing: Not forging a
rough consensus on where we'd like to go but to design the most
concrete, well-defined concepts we can come up to solve a specific
problem.

> 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

But why define a process for this kind of thing at all?

My feeling is that the wide range between an (informal) mail to the
mailing lists (as in
http://mail.ivoa.net/pipermail/semantics/2020-June/002735.html),
informal chats at meetings (as the #sibling discussion at the
Interop), perhaps an Interop talk, or a roadmap-style Note is just
fine and flexible enough to cater to the various cases that may come
up.

What would we gain by formalising such preparatory work?

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

Well, even VEPs are not just Yes or No -- as the WD says in 5.2.3:

  During the process, all parts of the VEP may be changed except the
  term(s) proposed.

I personally would expect at least changes to the definition to the
rule rather than the exception in VEP approval.

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

-- which is why I think we have to live with "preliminarily valid".
At least I've not come up with a better way to deal with this conflict
(which of course doesn't mean there is no such alternative; I'm
grateful for ideas).  

By the way, this conflict is by no means unique to vocabulary work.
When evolving standards, it is often hard to say whether a use case
is actually solved by some proposal because of missing
implementations, and people don't implement when their services
become invalid because of the evolution (or, even worse, their
clients start behaving diffently from what their users have come to
expect).

I'd like to think Vocabularies 2.0 proposes a relatively
straightforward method to mitigate that vicious circle at least a bit
and for this limited problem.

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

That is the design, yes.  It is, in my view, the only way to find out
if a proposal actually works.

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

That's the ivoasem:preliminary property; for desise clients, it's (in
python syntax) "preliminary" in voc["terms"].

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

The reason I think we can get away with having preliminary terms in
operational services is, as 5.2 says:

  Clients should therefore be designed such that they gracefully deal
  with terms that have not been part of the vocabulary at build time,
  typically by exploiting information in the vocabulary, perhaps by
  falling back to wider, known terms, or by presenting their users
  labels and descriptions for terms not explicitly handled.

(and that I think clients can in general be written in such a way;
specifically, desise's purpose is to make that... well, dead simple).

       -- Markus