> > Or just not use dc:date anymore? Allow for it but treat it as
> > deprecated?
>
> No I don't think we can do that, the RSS 1.0 DC module is one of the
> few approved 'Standard' modules and if people use any of the date
> refinements then this should be in _addition_ to using dc:date,
> IMHO.

Then at the very least a mention of dc:date being meant for a specific sort of
date so that anyone consuming a channel or an item would be able to depend on it
being unambiguous. That being made as a best practice or even addendum to the
existing specification.

> I think we could suggest this as best practice, I'd be wary of
> saying that the use of dcterms:created is required when
> dcterms:modified is present.

My point about getting into "requirements" is to stress to developers the need
to create content that consumers will be able to use in a predictable fashion.
Seeing a modified date would, IMHO, lead a developer of a reader to want to
possibly correlate that with an creation date. Thus the idea that one element
might introduce the requirement of anothers existence.

> > Hmmm, perhaps a breakdown here is in order:
> > Created: Date of creation of the resource
> > Valid: Date (often a range) of validity of a resource
> > Available: Date (often a range) that the resource will become or did become
available
> > Issued: Date of formal issuance (e.g., publication) of the resource
> > Modified: Date on which the resource was changed

These were the statements as shown in the documentation, they're not my wording.

> For some applications dcterms:issued might make more sense than
> dcterms:created (for example it might be easier to capture or the
> created date might be for internal use only) -- we should try to
> point people in the right direction but not make our own rules up
> (lets leave that to the DCMI!).

I'm in favor of not taking the namby-pamby route as seen in MUCH of the DCMI
documentation. Leaving it all so ambiguous has meant disaster for anyone hoping
to do any kind of real interoperabilty. I'm not talking about overriding what
might be a sensible set of variations. I'm speaking more toward the idea of
saying "if you're going to use element X then consider this definition as the
accepted best practice for it's contents". That way anyone wandering outside of
the best practice for use of the element within the context of an RSS file is
going to have a really GOOD chance of interoperability. The fact that some
external RDF-oriented system might be able to do "more" with the contents of a
field is largely irrelevant. The content is coming *from* a controlled
environment targeted toward being an RSS file, not the other way around. And
should anyone have need to pull data from an evironment expecting to do "more"
with a given element's content then this spec (or best practice) will be their
guide on how to reform the data.

> > documents? I'd like to see a way to 'marshall the troops' here in
> > a way that leaves as many as possible feeling that consideration
> > has been given to the various past usages.
> That sounds like a very good idea :-)

Cool, I'd really like to see an effort put into showing folks not motivated to
use namespaces the real possible benefits. That and to spur a bit of
investigation into using, if only in an optional sense, some of the RDF
concepts. Right now they *are* being treated as optional in a great many cases
so it's not like I'm suggesting any sort of backsliding from the standard that
doesn't already exist.

> BTW we can't use dc:created, we have to use dcterms:created:

Yeah, getting my prefixes jumbled, thanks for the correction.

> Recommendation 6. Element refinements should be treated in the
> same way as other properties. For example, use
> <dcterms:available>2002-06</dcterms:available>
>
> rather than <dc:date refinement="available">2002-06</dc:date>
> or <dc:date type="available">2002-06</dc:date>
> or <dc:date><dcterms:available>2002-06</dcterms:available></dc:date>

I *totally* agree with you here. While those may certainly be valid, RDF-wise,
they'd be a bitch for the pseudo-parsing environments to handle. Better to get
folks tuned into the concepts slowly with a predictable set of element names.
While the idea of being able to search for a dc:date element and then for
refinements is a very powerful idea, I'm not sure how many environments bent on
consuming RSS are going to *care* about it. The simplicity of what RSS attempts
to provide seems like it isn't going to glean the same sort of benefits as that
functionality offers. Being able to "find everything" at the price of making
the code utterly impossible to parse with perceived efficiency is going to
rankle many developers. Especially when they feel they're NEVER going to want
to go looking to "find everything" in ways the extra refinements might offer.
This is a terrific "third party opportunity" for someone else to go about mining
the data having pulled it apart using a predictable set of best practice rules.

Anyway, excellent momentum!

-Bill Kearney