Trouble with a deprecated default

Baptiste Cecconi baptiste.cecconi at obspm.fr
Mon Feb 3 13:21:00 CET 2025


Hi all, 

I agree with Gilles and Markus (if I read well): option b) seems preferable 

Baptiste

> Le 3 févr. 2025 à 10:37, gilles landais via registry <registry at ivoa.net> a écrit :
> 
> Hi,
> 
> Thank you to take into account DataCite-IVOA compatibility.
> 
> I agree that "Collected" sounds enough generic to be used. So (b) sounds acceptable to reduce compatibility problem and to manage the existing.
> 
> 
> I don't know how the Date role is used in the registry. Are there exotic values ?
> According to the existent, is it possible to force the role value with a controlled vocabulary?
> 
> Regards,
> 
> Gilles Landais
> 
> 
> Le 31/01/2025 à 15:49, Markus Demleitner via registry a écrit :
>> Dear Registry,
>> 
>> During the review for VOResource 1.2 Grégory noticed (thanks!) that
>> VOResource's Date element (used to define "events" in the life time
>> of a resource, such as the dates of publication or updates) currently
>> has something like a problem: Its @role attribute defaults to a
>> deprecated term.
>> 
>> A bit of background: Originally, the legal values of the role
>> attribute were defined in the VOResource schema; you could choose
>> between creation, update, and representative, the latter being the
>> default.  In VOResource 1.1, we moved to defining the role via the
>> vocabulary http://www.ivoa.net/rdf/voresource/date_role/, and we used
>> the opportunity to align us with DataCite, which has a very analogous
>> element.  The goal was that you could directly translate vr:Date to
>> DataCite.
>> 
>> For the old #creation and #update terms, there are exact matches.
>> 
>> For the somewhat vague #representative (defined in VOResource as "A
>> rough indication of the resource's time coverage") DataCite does not
>> have anything sounding similar.  But #Collected actually has a
>> definition that is pretty close: "A (representative) date at which
>> the resource content was collected."
>> 
>> Hence, when deprecating #representative, we said "use #Collected"
>> instead.
>> 
>> We did not change the default on Date, though, and that means that
>> when you write <Date>2025-01-31</Date> that ought to produce a
>> deprecation warning.  That doesn't happen so far, at least not in the
>> RofR validator, but it should.  And that's arguably not a good thing.
>> Or perhaps it is.
>> 
>> Here's a few proposals for how to clean this up:
>> 
>> (a) We keep the current behaviour and just comment: "That the
>> Date/@role default value is deprecated is actually by design.  You
>> see, a naked date is severely underspecified and nobody knows what to
>> do with it, so just don't do it.  Give a (new-style) role."  We may
>> want to add that people ought to give coverage/temporal rather than a
>> Collected date (or in addition to it, if DataCite interoperability is
>> desired).
>> 
>> (b) We (more or less silently) change the default to #Collected.  I
>> think that's safer than it may sound, in particular because RegTAP
>> services are supposed to change #representative in #Collected on
>> ingestion anyway.
>> 
>> (c) We file a github bug against VOResource, go ahead with 1.2 next
>> Wednesday and work out the problem at our leisure.  The problem has
>> been there since 2012, so perhaps it *is* not all that urgent.
>> 
>> The longer I think about it, the more I'm leaning towards (b).  So...
>> if nobody protests, I'll probably go ahead and do it and `fess up at
>> next week's TCG.
>> 
>> Does anyone foresee major trouble with that plan?
>> 
>> Thanks,
>> 
>>           Markus
>> 



More information about the registry mailing list