1. They have different types. The authority record represents a person
or organization; <name> in MODS is a person or organization in relation
to a work. In particular, <affiliation> in the authority record, a
person's work history, is different from <affiliation> in MODS <name>, a
contributor's affiliation as it appears in the work. Also, <role> and
<displayForm> do not appear in an authority record.
2. That's true; in this scheme there would only be one name type.
3. It would actually require two attributes: role-text and role-code.
And unlike attributes, the <role> element is repeatable, since one
contributor may have more than one role.


>>> [log in to unmask] 02/18/05 8:27 PM >>>
I guess this gets us back to earlier issues with namespaces.  I would
be fine with the example I posted in reply to Ray, but ...

On Feb 18, 2005, at 7:28 PM, Andrew E Switala wrote:

> So the alternative would be to ditch <name> in MODS
> entirely in lieu of a <mads> record, although some element would have
> to
> replace <name> syntactically to bind the name with its role and
> displayForm, e.g.
> <contributor>
>     <mads:mads xlink:href="naf.xml#z0001"/>
>     <displayForm>Bob Smith</displayForm>
>     <role>
>         <roleTerm type="text">translated from the Klingon</roleTerm>
>     </role>
> </contributor>

... ideal would be something like the above, except:

1)  I'm not why one would need to ditch name to add a wrapper
2)  I still hold to the feeling that putting mads in a separate
namespace is unnecessary/limiting
3) I still think -- and this is more trick for backward-compatibility
arguably -- that role would be better as an attribute on contributor

So something like:

<contributor role="info:marcrelator/author" xlink:href="naf.xml#z0001">
     <displayForm>Bob Smith</displayForm>

<contributor role="info:marcrelator/author" xlink:href="naf.xml#z0001">
     <name type="personal">
       <namePart type="given">Jane</namePart>
       <namePart type="family">Doe</namePart>
     <name type="personal" script="A">
       <namePart type="given">XXX</namePart>
       <namePart type="family">YYY</namePart>

Anyway, some alternatives to consider.

In any case, I think unifying the namespaces is likely to make for
greater flexibility.