On Tue, 1 Oct 2002, Sigfrid Lundberg, NetLab wrote:
> An example of another kind of dumb-down could be this: Usually you want to
> keep the number of 'fields' in a user interface to a minimum, hence you
> may want to search contributor and creator as one thing, while you present
> them as being different. My experience is that, from a user interface
> point of view, it is OK to be able to search for both 'Shephard' and
> 'Milne' as creators, and in a result set present them as illustrator and
> author, respectively.
>
> Please, consider the case that you're collecting metadata from
> heteroegenous sources. Then after some computing (involving mapping,
> string matching, inferencing based on schemas or ontologies, or something
> else) you should have a pull-down menue for selecting a search field. And
> that menue should be possible to understand for an ordinary google user. A
> search should yield a result that can be understood.
>
I think Sigge's exploration of how elements might be used wrt searching
and display of fields is very useful. I find it helpful to think
about the instance metadata and how it is presented to end-users.
I believe that it is controversial to suggest that dc:creator is treated
as a refinement of dc:contributor. Ann Wrightson's mail [1] has shown
examples of instance metadata which does not fit well with this model.
As regards dumb-down from dc:creator to dc: contributor:
In my view the ordinary end-user understands the distinction between the
'creator(s)' of a resource who hold main responsibility and minor
contributors. It will not aid interoperability to put in one 'bucket' both
sets of names.
As regards need to repeat qualifiers for both dc:creator and
dc:contributor:
If one distinguishes the primary party responsible for a resource as
creator, and others with minor responsibility as contributors, then there
are few cases where there will be a need for the same role to be used as
refinements for both surely?
An editor is a creator of a resource.
An illustrator contributes to a resource (if the resource is an
illustration then they are a creator.... illustrations should be bought
together in retrieval by type of resource).
If there are some examples of a qualifier being required for both elements
then I suggest 2 separate qualifiers are created. The cumbersome names can
be hidden from end-users.
Finally I am getting unclear as to what is driving the proposal to
consider dc:creator as an element refinement of dc:contributor? In Andy's
mail [2] in which he outlines what DCMI should do he mentioned:
<quote>
I.e. that dc:creator
>becomes one of a potentially long list of dc:contributor
>element refinements and simply sits alongside things like
>dcterms:author and dcterms:illustrator.
/quote>
I think it is reasonable to contemplate one or two UB approved qualifiers
such as 'editor', but I agree with Carl, really DCMI should not be in the
business of re-inventing detailed roles as in the MARC relator list.
Surely we would not contemplate putting 'author' in dc:terms?? If people
want that detail they can use the MARC relator codes list [3].
I understood Steven's original request on this thread [4] as asking for
guidelines as to how to associate a local non-DCMI element refinement with
a DCMI element.
2 kludges were suggested:
<quote>
I've thought of two kludges:
(i) partition our refinements between creator and contributor
(ii) drop the creator/contributor distinction since its partially
redundant given our refinement.
</quote>
Assuming one can associate the local namespace metadata with DC (otherwise
it really does not matter does it?) then I would suggest that for the sake
of interoperability (i) would be best as it would dumb down to DCMI
existing elements. Alternatively use a third possibility i.e.
creatorEditor, contributorEditor (non-DCMI terms) etc
It seems to me that (ii) works against interoperability because you are
*not* using a DCMI distinction which would at least 'partially' provide
the distinction you want, and indeed are mixing content in one bucket that
should go into two (or be left out of the record altogether).
fwiw :-) .... just trying to clarify what is driving this discussion !
Rachel
[1]
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0209&L=dc-architecture&T=0&F=&S=&P=8087
[2]
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0209&L=dc-architecture&T=0&F=&S=&P=5693
[3] http://www.loc.gov/marc/relators/relahome.html
[4]
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0209&L=dc-architecture&T=0&F=&S=&P=4625
---------------------------------------------------------------------------
Rachel Heery
UKOLN
University of Bath tel: +44 (0)1225 826724
Bath, BA2 7AY, UK fax: +44 (0)1225 826838
http://www.ukoln.ac.uk/
|