Thanks for the message--I think it cleared up several problems for me.

Actually, if your examples are correct, I may have to conclude that I am against
the idea of role in DC altogether. And my re-reading of:

"Element Qualifiers must refine the semantics of the element (that is, narrow
the definition of the element). For example, an illustrator (narrower) is a type
of Creator (broader)."

does--indeed--seem to disallow even the possibility of adding dates. I do not
see how the example:
DC.Creator=Shakespeare, William
DC.Creator.DateRange=1564-1616
can possibly follow this rule. The date *cannot* narrow the meaning of the
creator. (Or can it?!)

If our only choices are qualifiers such as:
"DC.Creator.Sculptor18thCenturyGerman" the number of roles would multiply
exponentially even beyond what I had considered earlier. If this is the result,
I really believe we should drop the entire idea.

But let me take the other side. How does Agent.Link/Identifier fit into this?
DC.Creator=Shakespeare, William
DC.Creator.Link=http://---
or Agent.Affiliation
DC.Creator=Weinheimer, James
DC.Creator.Affiliation=Princeton University

Do any of these "refine the semantics of the element"?

James Weinheimer
Princeton University
[log in to unmask]

> Message from Stephen Hearn,

> Since there are a number of us new to this list, maybe some review of the
> definitions of DC qualifiers would be useful.  I get a sense from some of
> the recent comments that some people are thinking of DC qualifiers as
> comparable to MARC subfields-e.g., the $d date subfield in a personal name
> heading, or the $e relater subfield.  I think this is problematic.
>
> The definition of DC qualifiers I'm working from is at:
>
> http://www.mailbase.ac.uk/lists/dc-general/1999-11/0029.html
>
> It indicates that qualifiers always apply to the element as a whole.
> "Element" qualifiers narrow the definition of an element (e.g., creating a
> qualified element name for "illustrators"). "Value" qualifiers apply to the
> content of an element by specifying an encoding scheme (e.g. an ISO date
> format scheme) or a controlled vocabulary (e.g., LCSH, AAT, NAF) which
> interprets, controls, or offers context for the value (i.e., the data) in
> the element.
>
> The proposals for Agent qualifiers are presented as "value" qualifiers, but
> the controlled lists of values referred to do not correspond to the data
> that would be present in the DC element.  The name in a DC agent field
> won't be found in the MARC relator term list, for example, so I don't see
> how that list could be a value qualifier for the DC agent fields.  If the
> agent element is multiplied with qualifiers to be come a set of related
> elements each describing an aspect of the agent, then there needs to be
> coding or syntax to specify which qualified element (e.g., specifying a
> "role") goes with which named agent.
>
> The proposals make more sense as element qualifiers. This means that a date
> range element qualifier would narrow the meaning of the agent element
> chronologically, e.g., "Creator.19thCentury".  It would not be capable of
> specifying the dates of individuals, as the MARC X00 $d does.  A role
> element qualifier would define a role-based class of agents, e.g.,
> "Creator.Painter."  The list of MARC relator terms might be a source for
> these classes, but the terms themselves would probably be incorporated into
> the qualified element.  They would likely not be qualifying terms added to
> individual names, like the MARC X00 $e.
>
> I find nothing to indicate that DC elements can have multiple qualifiers.
> I suppose this means that attempting to define role on two or more
> dimensions could result in a very long and complex list of qualified
> element names, e.g., "Creator.Painter19thCentury,"
> "Creator.Sculptor18thCenturyGerman," etc., which is still working with
> fairly broad categories.
>
> I'd be more interested in seeing how value qualifiers could be used to
> control and better articulate the data in DC elements.  If the USMARC
> national authority file (or some derivitive of it) could be specified with
> a value qualifier as controlling the content of an element , e.g.,
> "Creator.NAF", then all the data necessary should theoretically be present
> to access the authority record, with its specification of dates and other
> individuating data for names, and the other kinds of information
> authorities can carry.  The same case could be made for any number of
> available online directories and indexes of names.  If the DC record
> creator is authorized to create records in the specified controlled
> vocabulary, or in a local controlled vocabulary also specifiable either as
> a stand-alone vocabulary or as a supplement to the larger vocabulary, then
> the record creator's ability to articulate aspects of named entities will
> be significantly extended.  Lastly, the controlled vocabulary records could
> be defined to permit searching of individual entities based on the various
> classes (chronological, national, ethnic, professional, etc.) to which they
> belong.  The possibilities for using such linked files to enable greater
> definition and refinement of both data and searches are many. This is what
> I understand to be the promise of the resource description framework (RDF).
>
> Many of the qualifiers proposed for agents seem to me to belong in a
> different element set.  The DC element set is intended for describing
> network-accessible materials.  The data being articulated in most of the
> proposals is more about the agents themselves.  Shouldn't we be looking to
> design a generalized element set for records describing agents, rather than
> trying to articulate all the data about agents within DC? In that context,
> the proposals for value qualifiers for Agents would make a lot of
> sense-e.g., the Agents element set would include a Role element, for which
> the MARC relator term list could be the value qualifier. But as they
> currently stand, I find the proposals for agent qualifiers very problematic.
>
> If I am wrong on this, please tell me so on the list, so that any one who
> shares my confusion can get the benefit of your answer.
>
> Stephen



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%