ISSUE-3: Date and Time Format

DTF

Date and Time Format

State:
CLOSED
Product:
DCAT
Raised by:
Phil Archer
Opened on:
2012-01-06
Description:
The current version of DCAT seems a little confused wrt date and time formats. We use dcterms:issued and repeat the DC range declaration of rdfs:Literal and then say it should be datatyped as xsd:date. So far so good. But then the text refers to the W3CDTF document. And they're not the same.

xsd:date requires that values be present for yyyy-mm-dd

W3CDTF is more flexible and allows any of:
yyyy
yyyy-mm
yyyy-mm-dd (and then times can be added)

The DCAT spec says that if a day and/or month are not known then one should use the value 01. This assumes:

- that the year is always known;
- that a date like 2012-01-06 is ambiguous since it includes '01'.

There may be cases in which the year is not known. For example, 'the 1980s' might be written as 198?. That breaks W3CDTF but it's an approximation. As it happens this came up just yesterday in the EU work that Christophe and I are doing so it's fresh in my mind. Taking all that on board, my proposal is therefore that:

1. Rather than specify a datatype of xsd:date we specify W3CDTF (which is what DC recommends). We can use the URI http://purl.org/dc/terms/W3CDTF to give the data type.

2. We recommend using '00' not '01' for unknown dates.

3. We explain that just giving the year or the year and month is valid.

4. Where the year is uncertain, use the ? character to express this but recognise that this breaks the model and is not W3CDTF. Therefore the data should not be so typed.

5. Where even strings like 198? cannot be provided, plain text such as "sometime in the 1970s or '80s" may be used but this should be avoided if at all possible.

Given DCAT's use cases the latter seems unlikely (it happens in public sector records for things like dates of birth) so maybe we could drop that bit, but 1 - 4 seem valid?
Related Actions Items:
No related actions
Related emails:
  1. Re: ISSUE-3 (DTF): Date and Time Format (from Bart_van_Leeuwen@netage.nl on 2012-01-30)
  2. Re: ISSUE-3 (DTF): Date and Time Format (from auguste.atemezing@eurecom.fr on 2012-01-30)
  3. Re: ISSUE-3 (DTF): Date and Time Format (from konstant@iit.demokritos.gr on 2012-01-30)
  4. Re: ISSUE-3 (DTF): Date and Time Format (from olyerickson@gmail.com on 2012-01-30)
  5. Re: ISSUE-3 (DTF): Date and Time Format (from rreck@rrecktek.com on 2012-01-30)
  6. Re: ISSUE-3 (DTF): Date and Time Format (from konstant@iit.demokritos.gr on 2012-01-30)
  7. Re: ISSUE-3 (DTF): Date and Time Format (from richard@cyganiak.de on 2012-01-17)
  8. Re: ISSUE-3 (DTF): Date and Time Format (from phila@w3.org on 2012-01-17)
  9. Re: ISSUE-3 (DTF): Date and Time Format (from richard@cyganiak.de on 2012-01-17)
  10. Re: ISSUE-3 (DTF): Date and Time Format (from phila@w3.org on 2012-01-17)
  11. Re: ISSUE-3 (DTF): Date and Time Format (from richard@cyganiak.de on 2012-01-17)
  12. Re: ISSUE-3 (DTF): Date and Time Format (from rreck@rrecktek.com on 2012-01-06)
  13. Re: ISSUE-3 (DTF): Date and Time Format (from olyerickson@gmail.com on 2012-01-06)
  14. Re: ISSUE-3 (DTF): Date and Time Format (from olyerickson@gmail.com on 2012-01-06)
  15. AUTO: Biplav Srivastava's availability is limited (from sbiplav@in.ibm.com on 2012-01-06)
  16. Re: ISSUE-3 (DTF): Date and Time Format (from olyerickson@gmail.com on 2012-01-06)
  17. ISSUE-3 (DTF): Date and Time Format (from sysbot+tracker@w3.org on 2012-01-06)

Related notes:

1. As per the recommendation <http://bit.ly/zSdpkP> SPARQL supports numeric types plus xsd:string, xsd:boolean and xsd:dateTime
2. The range of xsd date and time types includes xsd:date, xsd:time, etc, but in particular xsd:gYear. So the argument can be made that there is an XSD way to capture the formats allowed by ISO 8601 as interpreted by W3C <http://bit.ly/zMgwZD>
3. It can be argued that "forcing" providers to adopt a stricter dateTime typing system is less of a burden to adoption than forcing consumers (developers, etc) to conjure up ways to interpret types used by a variety of providers. Federation esp. requires consistency...

John Erickson, 6 Jan 2012, 19:34:34

My comment (2), "The range of xsd date and time types includes xsd:date, xsd:time, etc, but in particular xsd:gYear..." is not correct...

John Erickson, 6 Jan 2012, 19:45:52

* Sense of the discussion is that xsd:dateTime should be recommended format
* Closed as per 15 Mar 2012 GLD call

John Erickson, 15 Mar 2012, 15:15:14

Display change log ATOM feed


Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 3.html,v 1.1 2014-07-10 11:36:14 carine Exp $