desise format for vocabularies

[Markus Demleitner]

Dear Colleagues,

On Tue, Oct 15, 2024 at 11:20:52AM +0200, Baptiste Cecconi wrote:
> > Le 14 oct. 2024 à 21:26, Mark Taylor <m.b.taylor at bristol.ac.uk> a écrit :
> >
> > It sounds reasonable, but requiring that the desise "deprecated"
> > member has the value 'true' in desise presents a backward compatibility
> > issue, so it would be disruptive.  Recommending the value 'true',
> > for the purposes of human readability, might make sense.
>
> Since Semantics controls the vocabularies, there is no fundamental
> issue to update the deprecated property implementation rule.
>
> The compatibility issue would be with the tools using the
> "deprecated" property. Do we know who is using this ?

I am certainly not concerned about existing clients; they will
certainly check for the presence of the key, and that is robust.

I am more worried about future clients.  If we were to require

  "deprecated": true

(and that's already tricky and requires extra code), people will be
tempted to read the key and see if it's a true value.  Which means
we'd have to say what a false value means (if anything; and the
backward-compatible thing would be to say "even deprecated: false
means it's deprecated"; ugh!).  Which means a lot of extra language
and a few lines of extra code.

I still maintain that's a bad deal, because I cannot see how this
would improve anything practical.  *Perhaps* we are somewhat more in
line with OWL, but since our ivoasem:preliminary and
ivoasem:deprecated have very special meanings defined by VocInVO2, I'd
be reluctant with sameAs-relationships with anything else, and then
that being-in-line again does not buy us anything (and we'd be
not-in-line any more with something else).

In short: I don't think that's a worthwhile effort.  If someone else
writes a solid spec, I'd probably not block it.  But I don't see
myself put any resources into this.

            -- Markus