In the past I have questioned the use of ISO8601 as opposed to W3CDTF.
I understand ISO8601 is being proposed in DC CD AP to allow date ranges
to be specified, whereas I have always just used W3CDTF for date ranges
based on old DC-Arch discussions [1]. This of course is a question
DC-Date aims to resolve once-and-for-all, except that the WG appears to
have stalled...
DC-Lib AP also includes an ISO8601 encoding scheme, but they are
specifically after other ISO8601 functionality such as BCE dates,
non-hyphenated date formats, etc. I feel more comfortable with DC-Lib's
use, but less with ours (using it just to allow slashes for date
ranges). ISO 8601 is an extremely complicated encoding scheme to handle
- I fear what will turn up in DC-Lib data (I would prefer DC-Date came
up with a new profile of ISO8601 so we don't have to deal with
_everything_ in ISO 8601).
But back to DC CD AP - It doesn't feel right to be re-defining an
encoding scheme as we have done in the current draft - either you are
using ISO 8601 or you're not! A side issue is using the "dcterms"
namespace is anticipating DCMI will endorse it.
I think we should propose DC-Date make their top priority decision be:
"Does the W3CDTF encoding scheme include date ranges, and what types are
included (eg. open ended)?". [NB: I will be pushing strongly on DC-Date
that it _does_ include ranges.] This is probably the longest-standing
issue around W3CDTF dates, and potentially could be resolved reasonably
quickly.
Then we could remove the dcterms:ISO8601 encoding scheme (and I could
sleep at nights ;-) ).
A small extra note - the AP summary document omits W3CDTF from
dcterms:created and cld:dateContentsCreated.
Thanx,
Douglas
[1]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402&L=dc-collections&P=R572&D=0&I=-1&T=0
|