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 theit 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=R1522
0&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