about #calibration Re: VEP-007: datalink-core#detached-header

[BONNAREL FRANCOIS]

Dear Markus, all,
Le 15/09/2021 à 16:50, Markus Demleitner a écrit :
>
>> 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.
> 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.

What is exactly my concern about VEP-006*as it is now *?

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)

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.

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

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.

So my proposal to modify VEP-006 and tackle both use cases. Can we 
combine terms in the semantics field ?

Can we have a single #calibration branch for calibration stuff and 
combine it with a relationship term like "#applied", #applicable ?

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.

Is that something that developers of clients could admit ?

Cheers

François




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210916/2ba01633/attachment.html>