desise format for vocabularies

[Baptiste Cecconi]

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

> 
> Mandating use of a boolean literal in future similar standards text
> might arguably also be a good idea, though it could also be misleading,
> for instance
> 
>   "deprecated": true

I think that's what should we use.

Baptiste

> 
> and
> 
>   "deprecated": "true"
> 
> both syntactically valid JSON, would have different meanings.
> 
> On Mon, 14 Oct 2024, Baptiste Cecconi wrote:
> 
>> Hi guys, 
>> 
>> just to let you know that the rest of the semantic world is doing this "deprecation" in a similar way, using OWL (Web Ontology Language).
>> 
>> Actually, it can be done in two different ways, which are logically equivalent:
>> - the term has type "owl:DeprecatedClass"
>> - the term has a "owl:deprecated" property, which is must be set to "true" (with a xsd:boolean type)
>> 
>> I would tend to try and adopt the generic semantics way of doing things. 
>> 
>> Setting the "deprecated" property to "true" (boolean true) makes things clear and obvious. No need to read the documentation to understand what it means.
>> 
>> Cheers
>> Baptiste 
>> 
>>> Le 4 oct. 2024 à 09:42, Mark Taylor via semantics <semantics at ivoa.net> a écrit :
>>> 
>>> On Fri, 4 Oct 2024, Markus Demleitner via semantics wrote:
>>> 
>>>> Hi Mark,
>>>> 
>>>> On Thu, Oct 03, 2024 at 09:40:23AM +0100, Mark Taylor wrote:
>>>>>> As the deprecated key is string typed then is
>>>>>> 
>>>>>> “deprecated” : null
>>>>>> 
>>>>>> also a true value?
>>>>> 
>>>>> I'd say yes; though the VocInVO text "present and mapped to a reserved value"
>>>>> seems a bit obscure here.
>>>> 
>>>> Now that you expose it like that, it *does* seem somewhat obscure.
>>>> What I meant to say was "do not look at the value" (and hence, yes,
>>>> null as a value would count; I'd even consider this a good choice.
>>>> Let me sidestep the question of "undefined", as I prefer to hope that
>>>> has not made it into JSON).
>>>> 
>>>> Perhaps "present and mapped to an arbitrary value"?
>>> 
>>> Yes that would be better.  I wouldn't say that an erratum is required
>>> here, but if there's a later version is should be reworded.
>>> 
>>> --
>>> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
>>> m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
>> 
>> 
> 
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/