>Pete Johnston wrote:
>
>>But within the DC model, elements are _not_ buckets: they are
>>properties, which express types of relationships betweeen resources.
Yes, I understand that, but for most people the notion of
"properties" is not particularly helpful in a training context. In my
experience, it's important to deal with where folks are, not where
you wish they were, particularly when attempting to teach them to do
something new.
>Also the conversation a few months back about dc:coverage and the
>confusion over whether it merged together "about-ness" and
>"applicability" (at least on the "spatial" side) highlighted the
>problems which arise if the broad bucket approach is applied loosely.
But this implies that we are entirely in control about how people
understand and use metadata definitions, which we certainly aren't.
This is not to say that we shouldn't try to clarify some of the
ambiguity of the past (and avoid it in future), but we do need to be
realistic about what to expect from that exercise. Even if we had
gone the other way on that decision, I don't think it would have
materially changed what people did with the element.
>A statement using the dc:coverage property and having a place as
>value is more or less useless because I don't know if it means the
>resource is "about" the place or "applicable to" the place.
It is only useless if you require and expect the metadata you receive
from others to be entirely predictable and consistent. My experience
is that it's usually neither, so I've adjusted my expectations
accordingly. I'd be happy if all the providers I worked with managed
to put place names in Coverage (bonus if they spell them correctly!)
and used an identifier that could get me to the resource.
Your mileage may vary, of course ... ;-)
Diane
|