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
the French).

I'll try to address some of the specific points raised in the latest
flurry in further messages.

Rebecca

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
>