desise format for vocabularies

[Paul Harrison]

> On 1 Oct 2024, at 10:37, Markus Demleitner via semantics <semantics at ivoa.net> wrote:
> 
>> I feel that it would be nice if the desise format did in fact make
>> these keys mandatory and boolean in type to reduce the amount of
>> interpretation code needed by clients.
> 
> Well... if you look at 3.2.2, the pattern for "see if a term is
> deprecated" is (IMHO) simply:
> 
>  "deprecated" in voc["terms"][term]
> 
> (ok, that's for Python, but a is-key-present test ought to be rather
> straightforward in any language/library expressive enough to make
> working with JSON fun).  The alternative you propose
> 
>  voc["terms"][term]["deprecated"]
> 
> does not seem so dramatically simpler to me than that to justify a
> breaking change in desise.

This is really a difference between the statically typed and not statically typed approach. In the statically typed approach
you might create an object with members and initially think that the deprecated member be typed as boolean from its description - however, when you try instantiate this object from theJSON using your favourite JSON library you get a type error - so then you realise that it should be typed as a string, but then you end up with code that is checking nulls which is never that nice. However, it is liveable with. So in Python there is really no difference in the client code complexity/ elegance between the two, but in Java there is.

> 
> Changing the pattern in desise would also introduce another asymmetry
> with the "proper" RDF serialisations, which have triples with the
> #deprecated and #preliminary properties in the same way, with RDF
> blank nodes as objects.  Sure, you could re-define these properties,
> too, and make them "boolean" (in some sense).  But again I doubt that
> would have substantial practical benefits.

I appreciate that changing the underlying RDF might be a step too far which was why I was arguing for just making changes to desise…

> 
> Convincing enough?

Given where we are, I guess so - if I had been paying attention when this was originally decided I would have argued fairly forcefully for the boolean typing…

Cheers,
	Paul.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20241001/3cb0efbc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20241001/3cb0efbc/attachment-0001.p7s>