When this first came up a while back, in the thread "mods:name is
broken," Bruce's idea seemed like overkill, embedding an authority
record inside a MODS record. I have reconsidered. Any sane human user
would probably not replicate an authority record everywhere s/he needed
it--xlink:href would be used instead. For automated bibliography
generation, the reverse is true. It's easier for the machine to copy the
authority record every time it's referenced, rather than construct a
<mods:name> element (with variants as proposed) out of bits and pieces
of the MADS record. 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>
--Andy
>>> [log in to unmask] 02/18/05 4:27 PM >>>
This could get complicated. The semantics of having x name elements is
x
entities. It is not x variations on the name of single entity, or
worse, y
entities (y<x) with (x-y) variations (with flags, and links to the
various z
entities). Let's consider an alternative approach.
If we want to support this capability, to provide alternative forms of
a
name, we should explicitly bundle all variations of a name for the
same
entity together, distinguished from names of other entities. There are
probably a number of ways to do this; one that comes to mind (that
would
have little impact) is to add an element <alternativeForm> type
nameType
(recursive), within the definition, in the "choice" i.e. along with
namePart, displayForm, etc.
--Ray
