> Well, yes, we did attempt to write this down. In the "old"
> version of the process document was a decision tree that
> asked the following of those considering a proposal for a new element:
>
> 1. Can the need be solved with a vocabulary encoding scheme
> for an existing DCMI Element or Element Refinement?© 2. Can
> the need be solved through an application profile that
> references an element or element refinement from an existing
> and recognized non-DCMI namespace?
> 3: Can the need be solved with a new refinement for an
> existing DCMI element?
> 4: Create a new DCMI Element (and, if necessary, Element and
> Vocabulary Encoding Scheme) to meet the need
Points 1 and 2 of these guidelines help in those cases where a WG is adding something that is closely related to stuff that already exists in DC. But they don't help much where WGs are moving into semantically new areas. In such cases one just falls thru to 4, which doesn't provide guidance on the 'property' vs. 'vocab' balance.
> I have to admit that when I teach, I express this as the "Big
> Bucket" approach: generalized elements, specific
> vocabularies.
Hmmm... interesting. That's pretty much the opposite of what I've been arguing on the dc-accessibility list :-(
On the other hand, I think we have a sliding scale here... what does "generalised elements" mean in practice. One logical conclusion of your argument is that we should only have one "general element", dc:description, and do everything else with "specific vocabularies". But we don't do this... and the reason we don't is because not everything can be expressed thru controlled vocabularies. If we just had
dc:description = text
dc:description = plumbing
dc:description = bath
dc:description = bristol
we've lost a significant part of the information carried by
dc:type = text
dc:subject = plumbing
dc:coverage = bath
dc:coverage = bristol
So, we do choose appropriately narrow elements - the question is, what is appropriately narrow!? :-) I think part of the answer lies in how far we can reasonably expect the values of any newly proposed property to come from a controlled concept space (a controlled vocab) and how far we expect the values to be less structured statements.
Very braod buckets, with unstructured statements as values do not lead to any interoperability.
There's a tension in the adaptability proposal because the new element is defined as "a statement ..." but all the examples provided tend to look like controlled vocabs. Part of the difficulty with the proposal as it stands is that the extent to which the expected values are statements is not very clear.
> I'm all for writing this down in some way that's useful, but
> I'd go further and suggest that we recommend, and even
> STRONGLY recommend, the general buckets, specific
> vocabularies strategy.
Yes, I think I probably agree with this. But only
- where controlled vocabs are a possibility
- where the norm is that values will be taken from vocabs
- where any proposal for a general property is accompanied by a reasonably full set of proposed vocabs
- where the relationship between the resource being described and *all* the suggested vocab terms can be expressed in a reasonable way
Andy
--
Head of Development, Eduserv Foundation
http://www.eduserv.org.uk/foundation/
[log in to unmask]
+44 (0)1225 474319
|