about #calibration (VEP-006)

[Markus Demleitner]

François,

On Thu, Sep 16, 2021 at 12:07:29PM +0200, BONNAREL FRANCOIS wrote:
> Le 15/09/2021 à 16:50, Markus Demleitner a écrit :
> 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 !!

Perhaps, but that's easily solved once it actually turns up: We'll
just add another term (in case there are good reasons that
re-labeling #progenitor as "Part-of-Provenance" won't work, that is:
otherwise we don't even need a new term).

But for now, nobody wants to publish such datalinks, and so there's
really no reason to delay VEP-006 because of this concern, and anyway
it's largely unrelated.

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

As explained several times before: No.  We simply cannot have a
concept that is partly Part-of-Provenance (a concept I insist is
useful) and partly not: That would simply break the semantics of
rdfs:subPropertyOf.

And as usual there's nothing as practical as a good theory, as what
you'd do then...

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

...will immediately blow the tree structure that's really the only
actualy application for the semantics field that we have at this
point (at least as far as I can see).

Very concretely: Where would your #applicable sit in the trees I'm
showing in the datalinks at
<http://dc.g-vo.org/static/datalinks.shtml>?

You'd be breaking the main use case to annotate links that in 10
years of datalink nobody has found reason to create -- that's
definitely not a good deal.


> Is that something that developers of clients could admit ?

That's, by the way, mainly a DAL (and perhaps Apps) thing, and it
hasn't found traction there either when it was proposed.  For good
reasons: As I'm arguing above, it's totally unclear what the
semantics of a semantics column used in such a way would be.  How
would clients use such annotation?


Sigh... I know I'm sounding like a broken record, but: Let's solve
the problems we actually have *now*.  Try to build some grand
description of the works, try to solve many problems at once, and
we'll never get anywhere.

So: 

(a) What problem we *actually have* with #calibration and children (in
*existing* datalink documents) is *not* solved with VEP-006?

(b) Is there some *computer* operation that was previously possible
that is made impossible by VEP-006?

If the answers to (a) and (b) are None (or "None, but I have all these
other ideas that we could also discuss at the same time"), then let's
please just move on.  

You know, this is really a minor change for a term we likely
wouldn't even have if we hadn't just taken semantics out of thin air
when we started datalink (and instead had added them as we went).

And we've been discussing it now for more than a year (date on
VEP-006: 2020-09-09).  Granted, there have been two improvements in
the meantime, so it wasn't all wasted time.

But going back to deeply disrupting proposals one year into the
process, proposals on top that were discussed and rejected multiple
times in the past, obviously don't solve the problem we're trying to
solve and on top attempt to solve a (different) problem we don't even
have at this time is, excuse me for being blunt, frustrating.

Come on, François, give your heart a shove and just make your peace
with VEP-006.  It's sane, doesn't damage anything, and solves an actual
problem we've inherited from the olden days.

And if people really start pushing out datalinks that are
"Calibration applied", let's quarrel on whether or not we need to fix
anything around #progenitor.  Then.  Not now.  VEP-006 simply is
totally unconnected with that discussion.


Thanks,

        Markus

PS: Incidentally, please edit the subject lines to at least not quote
the wrong VEP (as here, where François had VEP-007).  This will help
later when people browse the mailing list archives.