On Fri, 4 Oct 2002, Rachel Heery wrote:
> I have been following discussion of this proposal on the Usage Board list
> http://www.jiscmail.ac.uk/lists/DC-USAGE.html
>
> I think it would be useful to include in this proposal some reasoning as
> to why the terms in the MARC relator list are being considered as element
> refinements of contributor rather than as a scheme. In fact it might be
> helpful to rehearse that argument on this list?
The argument goes something like this...
DCMI encoding schemes say something about the *value* of an element (or
the value of an element refinement) - typically either that the value is
formatted in a particular way, or that it is taken from a particular
enumerated list.
The terms in the MARC relator list are never going to be the *value* of an
element or element refinement, i.e. it would be meaningless to say
<dc:contributor>illustrator</dc:contributor>
The MARC relator terms say something about the relationship between two
resources (e.g. between an information resource and an "agent") - in RDF
terms they are properties. In DCMI terminology they are therefore
elements or element refinements (*).
> The sheer number and detail of the roles in the MARC relator list indicate
> to me that they are not at the 'generic' level which is the business of
> DCMI. I am aware that the Library world may want to use these terms (and
> in particular that the Library Application Profile discussions have
> reached consensus on the need for these terms in that context).... however
> it might seem that such 'domain specific' usage might be dealt with by
> registering a scheme??
See above... this cannot be handled by a scheme within the current DCMI
model. As Tom indicates, it can be handled in a domain specific way by
using terms (properties) from a non-DCMI namespace.
> Are we in effect now allowing the DCMI terms list to 'grow' with
> registering of domain specific refinements?
Not if these are being added to/taken from a non-DCMI namespace.
(*) Note: as was pointed out on this list recently [1] by Roland,
'illustrator' (to take the example used above) is shorthand for the
relation 'hasIllustrator', just as 'creator' is shorthand for
'hasCreator', 'contributor' is shorthand for 'hasContributor' and
'publisher' is shorthand for 'hasPublisher'.
[1]
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0209&L=dc-architecture&T=0&F=&S=&P=8317
Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
|