Hi Andy,

On Sep 6, 2004, at 8:30 PM, Andrew E Switala wrote:

>> 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>

You can do it, but I don't believe it's semantically correct.  The role
is not internal to the name.

> 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>.

I'm not quite following you.  How does displayForm help here?  It has
no facility to encode language information, and the name element holds
that information, so it is incorrect to include alternative language
forms in the displayForm.

I've been a big advocate of MODS in the world of end-user oriented
bibliographic software in the last year and been successful in moving
developer energy towards it.  However, it's a hack to rely on an
authority file for what is pretty basic stuff, and even worse to burden
MADS with a bad design decision.

A name != a person/corporate body.

Bruce