It seems clear from Rebecca's fourth point that the MADS record is intended
to have an authorizing function--i.e., it makes an essential distinction
between an authorized <name> form and variants, which go into <ref> tags.
The whole point is to label the two forms as functionally distinct, not
equivalent. The fact that different users or different systems may prefer
different forms of names has led librarians to model methods to link
between separate authority files, so that the French or Japanese authorized
name form for an identified entity in a French or Japanese authority file
can be found from the English authority record in its file, which in turn
is linked to bib records to which that entity is related.
So, from the perspective of the AACR/MARC model that underlies MODS/MADS
and current library thinking and as an alternative to Rebecca's point 5,
developers who want to be able to switch between forms of name for
presentation could be considering having multiple MADS files, one for each
authorized <name> form needed, with each MADS record having its appropriate
array of <ref> variants (e.g., a kana variant for the kanji in Japanese)
and with all MADS records for the same entity linked together some way or
At 09:26 AM 9/8/2004, you wrote:
>I would like to make a few general points about MADS in response to
>various messages that have gone out on the list.
>1. There is no assumption that we have to have round-trip mapping between
>MARC authorities and MADS and back. As with MODS, the information that
>doesn't map well probably won't be lost, but some of the specificity in
>coding might, because MADS is a subset and derivative of MARC. If you want
>something in XML that is fully round-trippable, use MARCXML.
>2. In using the tag <name> we were grouping together various entities that
>had similar characteristics, that is, people, organizations, and events.
>We hadn't come up with a better word. I have heard many argue that they
>don't care what sort of name/entity it is (i.e. person or organization),
>that they should be all grouped together. Thus we used <name> in MADS as
>an entity described in the record that has a name (person, organization or
>event) and in MODS as an entity used in the record that has a name and is
>associated with the work in some way.
>3. We specifically didn't want to use <contributor> in either MODS or MADS
>because its definition would conflict with the Dublin Core definition. In
>Dublin Core, a contributor is defined as "An entity responsible for making
>contributions to the content of the resource." Because there is also a DC
>element Creator defined in terms of primary contributions to the resource,
>it has been used for those entities playing a secondary role. So we did
>not want to be making the distinction between primary and secondary role,
>nor did we want to limit it to contributions to the content of the
>resources, since there may be other roles that an entity plays where we
>want to give access from a person/organization's name. So we wanted
>something more neutral. Thus <name>. Maybe there's a better tag, but we
>didn't come up with one.
>4. In terms of the necessity to be using AACR2 or some other body of
>cataloging rules, what we wanted to bring that is inherited from rules is
>the notion that there is an authoritative form of the name that is chosen
>for some reason (maybe because of a body of rules, maybe because of local
>convention, etc.) and other alternative forms are given as variants. The
>institution creating the record could choose an English form in Roman
>script or a Russian form in Cyrillic script; this would be indicated by
>the language attribute on <name> under either <authority> or <ref>. It is
>also possible that another institution could create a MADS record for what
>is the alternate form in the other record. The language attribute would
>distinguish them and xlink could be used to point from one to the other
>(as a related record).
>5. In the MODS record, xlink could be used to point to the MADS record,
>which includes the variant forms of the name and other information
>identifying the entity. You could use this MADS record in various ways.
>For instance, the MODS <name> may or may not have additional elements; it
>could have just xlink and then your system could display whatever form you
>want (for example, the variant with lang="fre" if you wanted to display
>I'll try to address some of the specific points raised in the latest
>flurry in further messages.
>On Mon, 6 Sep 2004, Andrew E Switala wrote:
> > >>> [log in to unmask] 09/06/04 4:52 PM >>>
> > > It should be possible to xlink the MODS author/creator/contributor to
> > > its MADS authority file. Strictly speaking, you cannot do this now
> > > because while role indicates a relationship between an entity and the
> > > work in question (and so is contextual), mods:name wrongly assumes
> > that
> > > role is internal to that entity. This is going to be a mess as a
> > > consequence.
> > Cannot do this? I've been doing it since before MADS (with MODS
> > pseudo-authority records). What's the problem with:
> > <mods>
> > ...
> > <name xlink:href="auth.xml#smith.john">
> > <role>
> > <roleTerm authority="marcrelator" type="code">aut</roleTerm>
> > </role>
> > </name>
> > ...
> > </mods>
> > In an authority record, by my understanding, <role> should only appear
> > in name/title combinations, where there *is* a context for the role. An
> > authority record representing a person would not have <role>.
> > For the case of multiple forms of the same name on the same work, that
> > sounds like a job for <displayForm>:
> > <mods>
> > ...
> > <name xlink:href="auth.xml#ichiro.suzuki">
> > <displayForm>Ichiro Suzuki/ $BNkLZ (B< $B0lO) (B</displayForm>
> > </name>
> > ...
> > </mods>
> > The parsed forms of the name, in both scripts, would be in the MADS
> > record, one in <authority> and one in a <variant>.
> > --Andy
Authority Control Coordinator
Database Management Section Head
University of Minnesota
160 Wilson Library Voice: 612-625-2328
309 19th Avenue South Fax: 612-625-3428
Minneapolis, MN 55455 E-mail: [log in to unmask]