innovation in metadata design, implementation & best practices

Title: Encoding Scheme "ISO8601"
Identifier: http://dublincore.org/usage/meetings/2004/10/ISSUES/iso8601/
See also: http://dublincore.org/usage/meetings/2004/10/ISSUES/
Created: 2004-09-14
Agenda frozen: 2004-10-02 07:25, Saturday
Archived: 2004-11-10
Maintainer: Tom Baker
Note: If any of the links below are broken, please refer to 
                   the meeting packet
                   (http://dublincore.org/usage/meetings/2004/10/Meeting-packet.pdf) 
                   for copies of the key documents discussed at the meeting.

Shepherd: Rebecca

In Bath [1], Rebecca was assigned the action to finalize the
decision text [2]. This was to involve two things:

1) including links to W3C documents [3,4], and

2) including (both in the decision and in the announcement)
   text to the effect that this will potentially be the last
   new DCMI term declared with reference to an ISO standard
   unless ISO decides _not_ to name such things within their
   own namespace.

In September, however, it was noticed that such a statement
about the use of non-DCMI URIs as DCMI Encoding Schemes was
closely related to the issue raised at the Bath meeting with
regard to reusing MODS terms in a Dublin Core metadata context.

At issue is the nature of what, in any given case, is
actually identified by a URI and whether the entity identified
really fits into the DCMI Abstract Model.

In Shanghai, therefore, we will aim at finalizing the revised
description of the term "ISO8601" so that it can be added
to the DCMI term sets (Point #1 above). And we will discuss
the assignment of DCMI Encoding Schemes to non-DCMI standards
(such as ISO standards) in the context of a broader discussion
of the use of non-DCMI terms and term URIs in Dublin Core
metadata (Point #2 above).

Some relevant email is appended below.

[1] http://dublincore.org/usage/meetings/2004/03/ISSUES/registration-proposals/
[2] http://www.bi.fhg.de/People/Thomas.Baker/public/2004-03.ISO8601.txt
[3] http://www.w3.org/TR/NOTE-datetime
[4] http://www.w3.org/TR/xmlschema-2/#isoformats
[6] http://dublincore.org/usage/meetings/2004/10/registration/
[7] http://dublincore.org/usage/meetings/2004/10/nlm/
[8] http://dublincore.org/usage/meetings/2004/10/iso8601/

------------------------------------------------------------------------
Date: Tue, 14 Sep 2004 10:49:50 +0100
Reply-To: DCMI Collection Description Group <DC-COLLECTIONS@JISCMAIL.AC.UK>
Sender: DCMI Collection Description Group <DC-COLLECTIONS@JISCMAIL.AC.UK>
From: Pete Johnston <p.johnston@UKOLN.AC.UK>
Subject: Re: ISO8601 vs W3CDTF
To: DC-COLLECTIONS@JISCMAIL.AC.UK
------------------------------------------------------------------------

Douglas,

I'll try to respond to your other points later, but just on this
specific point:

> 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.

Apologies, this is my fault, and I should have made it clearer what was
going on with the ISO8601 encoding scheme.

I completely agree with you that DCAPs must not redefine encoding
schemes.

My understanding is that the Usage Board has already (in June 2003)
accepted ISO8601 as an encoding scheme, and indicated their intent to
create a corresponding class http://purl.org/dc/dcterms/ISO8601 in the
DCterms vocabulary. See

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0307&L=dc-usage&P=R15220&I=-1

and subsequently

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402&L=dc-usage&P=R1278&I=-1

I understand that there has been some delay in _publishing_ that
decision and actually including an RDFS description in the DCMI schemas,
but that decision _has_ been made.

So what I really wanted to do in DC CD AP was just reference this DCMI
term (as we do for the other DCMI encoding schemes) and reproduce the
DCMI description. But that description doesn't exist for me to reproduce
:-( so I just did a quick one myself, essentially as a placeholder so
that we could get the reference to ISO8601 into this draft - and maybe
prompt the UB into publishing their decision! ;-)

There is some current dialogue about this on the UB list

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0409&L=dc-usage&T=0&F=&S=&P=1454

but it really deals with a broader debate about when DCMI-created URIs
are required and when URIs coined by other parties can be cited.

I don't think there is any indication that UB are going to reverse their
decision that ISI8601 has been adopted as a DCMI encoding scheme,
though, and I see Tom has just posted a message seeking to separate out
that issue and get the ISO8601 decision finalised

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0409&L=dc-usage&T=0&F=&S=&P=2083

which is good. ;-)

> 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.

And I had always understood that W3CDTF does not cover date ranges, and
we have been stretching that spec by labelling date ranges as conforming
to W3CDTF ;-)

So....

> 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.

.... yes, that was intentional on my part, because the expectation is
that these will always be date ranges and (IMHO!) W3CDTF does not cover
date ranges.

But yes, I agree with you that this is something - probably, as you say,
the single issue! - that I would have liked to see the DC Date WG
clarify, as it is a permanent source of ambiguity and confusion, and
just about every implementer goes over the same ground.

FWIW, Andy and I also highlighted to UB recently that the definition of
dc:date itself is ambiguous :-(

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0407&L=dc-usage&T=0&F=&S=&P=1346

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0407&L=dc-usage&T=0&F=&S=&P=1464

Pete

------------------------------------------------------------------------
Date: Tue, 14 Sep 2004 11:17:10 +0100
Reply-To: DCMI Collection Description Group <DC-COLLECTIONS@JISCMAIL.AC.UK>
Sender: DCMI Collection Description Group <DC-COLLECTIONS@JISCMAIL.AC.UK>
From: Andy Powell <a.powell@UKOLN.AC.UK>
Subject: Re: ISO8601 vs W3CDTF
To: DC-COLLECTIONS@JISCMAIL.AC.UK
------------------------------------------------------------------------

On Tue, 14 Sep 2004, Pete Johnston wrote:

> > 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.
>
> And I had always understood that W3CDTF does not cover date ranges, and
> we have been stretching that spec by labelling date ranges as conforming
> to W3CDTF ;-)

There is nothing in

http://www.w3.org/TR/NOTE-datetime

to indicate that ranges are supported. I.e. none of the supported formats
is a range. My personal view is that your 'rest of ISO8601 still applies'
argument is unlikely to be the case - i.e. only the exact formats listed
in the profile are allowable. But I agree that your view may be correct!
:-)

Note that this isn't an issue over which DCMI has any control. The
W3CDTF profile is "owned" by the W3C. Therefore I would suggest that an
email to the original authors (both listed at the top of the profile spec)
is the best course of action at this time??

Andy