I would like to propose an alternative declaration for the name, subject
and title elements that tackles the various issues raised with the
current implementation. It requires the general design philosophy that
if an element may contain sub-elements, it should not also contain
regular content. To make an analogy to MARC, you can have fixed fields
that only have data content and you can have variable fields that only
contain subfields, but you cannot mix the two models. This philosophy
should be applied throughout the MODS schema and will lead to data that
is much easier to process with standard software components (including
relational databases).
----------
NAME FIELD
----------
For the name field, I propose renaming it to "creator" with the
following structure:
creator
ID (attribute)
role (attribute)
authority (attribute)
link (attribute)
typeAuthority (attribute)
typeLink (attribute)
affiliation (element)
displayForm (element)
name (element)
type (attribute)
description (element)
type (element)
All attributes are optional (to make record creation as easy as possible
but to allow for more sophisticated cataloging if desired) and there
must be at least one "name" element which is repeated for each level of
a hierarchical (structured) name. Dashes are not permitted and all names
must be broken out according to their hierarchical structure. The
"description" element is used for cases like "Abrams, Michael (American
artist, 20th c.)":
<creator>
<type>personal</type>
<name>Abrams, Michael</name>
<description>(American artist, 20th c.)</description>
</creator>
A corporate name would look like this:
<creator>
<type>corporate</type>
<type>government</type>
<name>Library of Congress</name>
<name>National Digital Library Program</name>
<displayForm>Music Division, Library of Congress</displayForm>
</creator>
The "link" attribute would allow a link to an authority record for the
whole name. This would satisfy Andrew's concerns about typo's in the
"name" elements and also allow for cases where the authority entry does
not match exactly the version in this field (because of additional
authority subheadings, punctuation, etc.).
You will notice that I have made "type" an element and it is also
repeating. This allows for a multi-level approach to describing the
type of name without limiting an implementation to a fixed number of
levels.
The "type" element would support the following values: "personal",
"corporate", "conference", etc. The list would not be closed and users
would be free to add to it. Subtypes could be defined by adding a second
"type" field that might include the following values for a "corporate"
type name: "profit", "nonprofit", "government", etc.). Subtypes could
also be used to distinguish between forms of a personal name
("forename", "surname", "family name") but I have another suggestion for
that problem, below.
The "typeAuthority" and "typeLink" attributes allow for the definition
of an authority list for a hierarchy of type terms and a link to a
particular entry.
There is also a "type" attribute for the "name" element for cases where
a user would like to make some sort of distinction here. This has
greater applicability in the subject field.
The "name" field would always be entered as it should be sorted. If
this is different from how it is displayed, a "displayForm" element
should be included. This solves the first name, last name debate and
also allows for other language related sorting situations that we have
not accounted for. For example, in Dutch phone books, the "van" at the
start of a last name is ignored in the sorting sequence because so many
people in Holland have a last name starting with "van". This is not
unlike non-filing characters in titles. My point is, this proposed
technique is the most flexible in terms of user needs without having to
anticipate what those needs are. It also avoids having to sub-divide
names any more than necessary.
----------
SUBJECT FIELD
----------
The subject has an identical design, except the "name" element is called
"term", as follows:
subject
ID (attribute)
role (attribute)
authority (attribute)
link (attribute)
typeAuthority (attribute)
typeLink (attribute)
affiliation (element)
displayForm (element)
term (element)
type (attribute)
description (element)
type (element)
All attributes and elements are optional except for "term", of which
there must be at least one. The "type" element might include the
following values: "personal", "corporate", "conference", "topic",
"title", "geographic", "temporal" and "classification". Subtypes might
include those needed for each of the main types. For "geographic" this
might include: "city", "continent", "country", "county", "island",
"province", "region", "state" and "territory". For "classification" it
might include: "lcc", "ddc", etc.
It is in the subject field that the utility of a multi-level type
becomes apparent. It illustrates why even two levels of types will be
insufficient for some users. In the case of Dewey numbers, there might
be three type elements, as follows:
<type>classification</type>
<type>ddc</type>
<type>Edition 19</type>
The "part" element contains an optional "type" attribute to distinguish
between different types of terms, if desired. For example:
<subject authority="lcsh">
<term type="topic">Journalism</topic>
<term type="topic">Political aspects</topic>
<term type="geographic">United States.</geographic>
</subject>
----------
TITLE FIELD
----------
With regards to the title field, it needs to be redesigned to support
non-sorting characters in a manner that would be easy to implement with
off-the-shelf software. The idea of a pair of non-sorting character
codes as defined in MARC-21 is an interesting solution but one that is
highly specific to the library market. I would like to suggest an idea
that would have worked just as well in pre-MARC-21: a separate subfield
for the leading article. Thus the title field would be defined as
follows:
title
ID (attribute)
role (attribute)
authority (attribute)
link (attribute)
typeAuthority (attribute)
typeLink (attribute)
part (element)
nonsort (element)
type (element)
The "title" element contains most of the same attributes as the "name"
and "subject" fields with the same meanings. The "part" element is
required and every title must contain one or more "part" elements. The
"nonsort" element is used to surround the non-filing portion of the
title as in the following example:
<title>
<nonsort>The</nonsort>
<part>Unbearable Lightness of Being</part>
</title>
Notice how easy it is to sort titles in this format -- you just sort the
"part" elements. However, when displaying the title, you don't suppress
this data. Notice also, that you can sprinkle the "nonsort" element
throughout a title (although I can't think of an application for this
yet).
An alternative definition for the title field would use a "displayForm"
element (as in the name and subject fields) instead of the "nonsort"
element. This would have the advantage of consistency, if nothing else,
and will also support other strange sorting situations we cannot
anticipate.
----------
UNIVERSAL FIELD
----------
A final possibility would be to create a single field definition for
creators, subjects and titles as follows:
creatorSubjectTitleType
ID (attribute)
role (attribute)
authority (attribute)
link (attribute)
typeAuthority (attribute)
typeLink (attribute)
affiliation (element)
displayForm (element)
part (element)
type (attribute)
description (element)
type (element)
There would still be separate "creator", "subject" and "title" elements
but they would all share the same list of attributes and elements. Note
that I have use the generic term "part" to contain the name, subject, or
title, as in:
<creator>
<type>corporate</type>
<part>United States</part>
<part>Dept. of Agriculture</part>
<part>Economics, Statistics, and Cooperatives Service</part>
</creator>
<title>
<part>Asia agricultural situation; review and outlook</part>
</title>
<subject authority="lcsh">
<part type="topic">Agriculture</part>
<part type="topic">Economic aspects</part>
<part type="geographic">Asia</part>
<part type="topic">Periodicals</part>
</subject>
Whether you like this proposal or not, would you please comment on it.
LC can't gauge the popularity of any of the comments on the MODS list
without more participation.
Thank you.
Geoff Mottram
[log in to unmask]
