Trouble with a deprecated default

[Markus Demleitner]

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