Diane I. Hillmann wrote:
> I have to admit that when I teach, I express this as the "Big Bucket"
> approach: generalized elements, specific vocabularies. It's an approach
> that is far more interoperable than the proliferation of more and more
> specific elements, and pushes implementors into more investment into
> controlled vocabularies that can be more responsive to changing needs
> without the overhead of change at the element/refinement level.
>
> I have to admit that as I'm following the accessibililty discussions it
> is an approach that suggests itself as I hear the problems defined. For
> instance, if there are several categories of accessibility statements or
> criteria, one could envision a separate vocabulary for each, which could
> all be used within the same element. The fact that the vocabularies are
> separate gives you, to a great extent, the "structured" piece that many
> are looking for in DCSV, but again, without the overhead or potential
> for creating messes.
>
> 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.
But within the DC model, elements are _not_ buckets: they are
properties, which express types of relationships betweeen resources.
I agree it's fine to use a single property to express the _same_ type of
relationship between one resource and two other resources (values) of
quite different types
e.g. if I want to talk about a concept being the subject of a book, and
a person being the subject of a book, then it is fine to use
book:B has-subject concept:C
book:B has-subject person:P
Yes, I agree we don't want to go coining new properties for
person-as-subject, physical-object-as-subject - well, assuming that the
definition of our has-subject property permits this range of values: for
some properties, the "range" of the property is indeed constrained by
the owner, and if our value is outside that range then in that case we
may need to define a new property.
But (it seems to me) the accessibility example shows a case where not
only are the values of widely different types, but the relationships
between the subject and those values are also of different types.
See Liddy's example here
http://dublincore.org/architecturewiki/MoreCarefullyThought
where the single proposed property a4a:adaptability is used with the
following different value strings (I think Liddy's first statement with
a4a:adaptability should be five separate ones)
visual
auditory
keyboardOnly
structuredPresentation
peerInteraction
textual
replacesVisual
As I said here
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0603&L=dc-accessibility&P=2167
we have to think in terms of simple statements, and I can not envisage a
coherent definition for a single property which could be used to form
statements in which all of those values are used, apart from one which
says something like:
resource:r
is-related-in-some-undefined-manner-something-to-do-with-adaptability-to
value:v
And I can't understand what use that property is to anyone. If we want
to say something so vague, we could just use dc:relation ;-)
Pete
--
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/
|