James,
In our local system, we will have the option of linking a term controlled
"Role" field to our Authority controlled "Agent" field, leaving many options
open for how and what the user wants to search on.
If they wanted to search on "Macmillon", and not specify "Publisher" or
"Author" in the Role field, their hit results would include all occurrances
of Macmillon where they are listed in the Agent field.
If the user wants only those items authored by Macmillon, than they will
have to enter the term "Author" in the Role field, which would effectively
result in only those hits where Agent = Macmillon and Role=Author are both
true.
But, as far as DC goes, it doesn't work quite as straight forward as this,
does it? There is no real dynamic linking between a Name/Agent field and a
Role field, which could get very confusing when you have multiple Creators,
Contributors, Publishers, etc. for a single item/record. Tracking which
Role links with which Name could get out of hand. This is why I suggested
concatenating the Name with the Role in the DC.Role field (to retain that
link). Ideally, it would be best to have DC.Role be "term" controlled (as
much as this is possible).
But maybe, it is possible to sequentially number each separate occurrance of
an agent in a given record the following way, in order to track which Role
belongs with which Agent, and continue to use the description field to
further define who these people are:
<DC.Name.1> Adams, Ansel
<DC.Role.1> Creator
<DC.Name.2> Smith, John
<DC.Role.2> Publisher
<DC.Name.3> Allen, Deb
<DC.Name.3> Contributor
This way, we still keep all Agents in a single field for indexing and
retrieval, and offer an additional Role field to further define the search.
Maybe Z39.50 can be programmed to concatenate the two for display purposes
in the following way:
Agent: Adams, Ansel (Creator)
Agent: Smith, John (Publisher)
Agent: Allen, Deb (Contributor)
Description: Photo of Mount Rushmore, created by Ansel Adams in 1942.
Published by John Smith, 1950. Reproduction photograph by Deb Allen,
Chicago Historical Society, 1999.
************************************************************
Allison A. Smith
Retrospective Conversion Coordinator
Chicago Historical Society
312 642-5035 ext. 398
[log in to unmask]
Check out the Chicago Historical Society's website:
http://www.chicagohistory.org
************************************************************
> -----Original Message-----
> From: James Weinheimer [SMTP:[log in to unmask]]
> Sent: Friday, May 14, 1999 12:59 PM
> To: Smith, Allison
> Cc: [log in to unmask]
> Subject: Re: agent types
>
> I still do not understand the need to dispense with the possibility of
> "Publisher". It has always been a critical component of the record.
> If we think that with the onset of the web, publishers will go the way
> of the dodo, maybe this tendency would be correct, but on the contrary,
> I see a great interest on the part of publishers to stake claims in the
> Internet, and feel that they will only grow in influence.
>
> It has always been important to be able to differentiate those
> responsible for the "physical" content (be it print or electronic
> formats) from those responsible for the "intellectual" content. I see no
> reason to believe this will change in the future.
> For example, imagine trying to search for items authored by "Macmillan
> Publishing Company" if nobody had ever bothered to distinguish
> "Publisher" from "Author". In Princeton's online catalog, there are over
> 16,000 items published by Macmillan, but only 9 items authored by them.
> Doesn't this show that differentiating publishers is useful?
> Do we really want to force users to go through 16,000 items to find 9?
>
> Besides, if determining a publisher is difficult for the metadata
> creator, just leave it out. Catalogers do that all the time.
> Getting rid of "Publisher" seems rather short-sighted.
> Jim Weinheimer
> Princeton University
> [log in to unmask]
>
> "Smith, Allison" wrote:
> >
> > I am very taken by the idea of collapsing all "agents" into a single
> field,
> > and am in the process of gaining concensus on the benefits of doing this
> in
> > our local, non-MARC system, (mainly, as Bernhard points out, so that all
> > maker/contributor/publisher/manufacturer/firm names in our collection,
> can
> > be indexed in a single field). So many times, a single "entity" (mostly
> > Corporate and Architectural Firm names) in our collection will be listed
> as
> > the Creator of some artifacts, a Contributor for others, and a
> Manufacturer
> > or Firm still in others. I would like to give our users the opportunity
> to
> > search a single field for a creator or corporate name, and pull together
> all
> > artifacts, books, letters, papers, photographs, blueprints, etc., that
> > relate to their search term, no matter what role that person/corporation
> > played.
> >
> > Now, our local system, we will soon have the ability to attach a linked
> > "Role" field to the Name/Agent field, so that we do not loose the richer
> > information about the role the entity played in the manufacture or
> creation
> > of the item/collection.
> >
> > It seems to me that, if DC Creator, Contributor and Publisher get
> collapsed
> > into a singe field, DC would not have 15 elements anymore, but would
> instead
> > have 13. Does this mean we have room to add one or two more fields?
> This
> > is a joke, however, in a similar fashion to what Bernhard has proposed
> > below, I would propose the elements this way:
> >
> > DC.Name (Name of the Creator/Contributor/Publisher/Manufacturer/Firm,
> etc.,
> > in standard AACR2 format, one per tag - repeatable)
> > DC.Role (free text - concatonation of the above name, and following it
> with
> > a term chosen from a list of acceptable "Agent terms", such as Creator,
> > Contrubutor, Publisher, Manufacturer, Firm.....)
> >
> > It would look like this:
> >
> > <DC.Name> Adams, Ansel
> > <DC.Role> Ansel Adams, Creator
> >
> > Since the elements are repeatable, you could further describe
> Contributors,
> > Surrogate creators, etc.
> >
> > Please explain to me if this is not do-able, and why, because it seems
> like
> > such a simple solution to me.
> >
> > ************************************************************
> > Allison A. Smith
> > Retrospective Conversion Coordinator
> > Chicago Historical Society
> > 312 642-5035 ext. 398
> > [log in to unmask]
> > Check out the Chicago Historical Society's website:
> > http://www.chicagohistory.org
> > ************************************************************
> >
> > > -----Original Message-----
> > > From: Bernhard Eversberg [SMTP:[log in to unmask]]
> > > Sent: Friday, May 14, 1999 3:31 AM
> > > To: [log in to unmask]
> > > Subject: Re: agent types
> > >
> > >
> > > Stu writes:
> > >
> > > > I would like to see a solution that acknowledges the readily
> apparent
> > > > logical relationship among agents. Among the many who oppose the
> Agent
> > > > proposal, there are few indeed who would argue that these three
> elements
> > > are
> > > > not related. ...
> > > > Acknowledging this relationship does NOT make later acceptance of
> the
> > > agent
> > > > proposal a fait accompli.
> > > > It certainly WILL make it easier to reconcile the DC-15 with other
> > > > initiative including INDECS, but perhaps more importantly, with
> Z-39.50,
> > > > which has basically adopted DC as the cross discipline searching
> set,
> > > but
> > > > has decided to conflate the three agent elements into an abstract
> > > element
> > > > they call NAMES.
> > > >
> > > Assuming that "It" here means the acceptance of the agent proposal,
> I'd
> > > like to add one remark and suggestion:
> > >
> > > Cataloging rules have long since differentiated between descriptive
> > > elements
> > > and access point elements.
> > > If you want unified access to names on the one hand (regardless of
> > > functions) but still differentiate between different categories of
> names,
> > > this can of course be done.
> > > MARC does it by providing just one descriptive field into which you
> enter
> > > the "Statement of responsibility" in the form given on the piece being
> > > cataloged. For the access points, there are different fields for
> persons
> > > and corporate bodies, their functions can be coded in subfields and/or
> > > indicators. If unified indexing is the goal, one might downgrade MARC
> > > to have just one repeatable names field, not indicating any functions
> in
> > > it. The functions are only in the descriptive field - which does not
> and
> > > need not get indexed.
> > > This would suggest a different approach for DC: instead of the three
> > > fields
> > > there are now, one would have
> > >
> > > DC.Responsibility Text, not intended for indexing, saying who's done
> > > what,
> > > containing names as given
> > >
> > > DC.Name repeatable for all persons and bodies involved,
> > > containing the forms of names suitable for indexing
> > >
> > > B.E.
> > >
> > >
> > > Bernhard Eversberg
> > > Universitaetsbibliothek, Postf. 3329,
> > > D-38023 Braunschweig, Germany
> > > Tel. +49 531 391-5026 , -5011 , FAX -5836
> > > e-mail [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|