- DC2007MeetingMinutes

Dublin Core Date Encoding Task Force Session Minutes, DC-2007, Singapore, 29 August 2007

Consider scope - only include existing known DCMI requirements, or include wider requirements to make it relevant to more communities?
Consider who should create the required encoding format(s), eg. DCMI, ISO, W3C?
Investigate whether "dates as subjects" should be in scope
Determine whether the DCMI Libraries Application Profile requires more than just 'YYYYMMDD' in a short date format

1. Short Date Format Note Proposal

2. Date and Time Representation Requirements

3. Determine strategy to develop and formalise Date Encoding Format(s)

Short Format Note

b). Decide if want to pursue the note - working on this may take resources away from the wider requirements track work

Format mostly OK, would need to make time zone optional (for MARC 005 tag)
There are still outstanding issues noted in document
Motivator was DC-Libraries Application Profile - need to confirm if the proposal meets their requirements
Maybe put out to the DCMI community to decide if useful
Process

Confirm requirements of DC-Libraries AP
Announce to DC-General thinking of putting proposal out for public comment (to get pre-comments from interested parties)
Public comment period
Identify W3C member to put out note
Identify namespace to use

Date and Time Representation Requirements

Working draft out August 2007
Clarification given - intention is "inline markup", ie. all date information is encoded within a single character string (unlike MODS which places some information in separate attributes such as qualifier="questionable")
Need to decide if DCMI should do this date work or another agency like ISO, options:

Risk that if DCMI put out a format it will be ignored (as considered only suitable for the DCMI community)
W3CDTF’s main problem was its silence on whether ranges are supported. W3C may be interested in taking on dates work, but some DCMI requirements may not be of interest to them as considered of low value in their community, eg. non-Gregorian dates or questionable dates
Noted ISO 8601's strength is dates for computer systems, not strong on cultural dates
Are the use cases in the document real, or just potentially real? For example, elapsed time requirement may be of use to corporates encoding project timelines or oral history.
Need to decide scope of the requirements, eg:

Limit to existing, known requirements
Or include anticipated requirements that would make the encoding format usable in more domains (which are not currently represented in the DC-Date Task Force)?

TEMPER presentation - John Kunze