|1. It is unacceptable to have an element in the Dublin Core that
|must be qualified to have meaningful semantics. I thought this was
|obvious until I read a number of e-mail messages that implied or clearly
|stated that the DATE field must be qualified to have meaning.
Hear hear.
|2. Any qualifying of an element must not alter the semantics of the
|item. This is what we decided in Canberra, so nothing new here.
I agree with what I *think* this means --- that qualifiers should not
be used to entirely subvert the meaning of the thing qualified ---
rather than what it actually says (which is that qualifiers should not
alter the semantics of the thing qualified, in which case what use are
they?). My favourite example of a qualifier which should be illegal by
this rule is ".not"
|The clearest, and least ambiguous date that we can attach to an object
|(and that is useful for resource discovery) is the date of creation of
|the content. I am not saying that this is unambiguous, but certainly
|less ambiguous than starting to talk about "put in its current form", or
|"issued", or "last modified", which may be extremely confusing to the
|resource discoverer.
I don't think I agree with this at all. The date that something got
put into its curent form is usually a lot clearer than the date it was
(hypothetically) created. Why do people spend so much time agonizing
about the date of King Lear (to steal Peter Graham's excellent
example) if it's so clear? For resource discovery purposes, I agree
it's handy to have a coarse-grained notion of date (sort of "temporal
provenance") but if that's what's required here, it needs a better
name.
|If we wish to have other date semantics in the DC then we need another
|date field OTHER_DATE whose definition is "other dates in the lifecycle
|of the resource that the creator or manager deems important. Then we
|could have OTHER_DATE.scanned, OTHER_DATE.indexed and all the rest.
Hear hear again.
Lou
|