NamePractices
From oaibp
Main Page >> Shareable Metadata
Note: Summary of best practices added. Jenn Riley 10/12/05
Contents |
[edit] Name(s) in OAI Records
[edit] Summary of Best Practices
- Include all known names expected by your community of practice in OAI records.
- Format names consistently within an OAI set or repository, according to authority files or standards expected by your community of practice.
- Provide as granular an encoding of a name as possible in the metadata schema being used.
- Express multiple names in repeated fields.
[edit] Use of Name(s)
The name(s) in a metadata record are a critically important component. Names are most likely to appear as creators of and/or contributors to the intellectual content of the resource, but may appear also in subjects, as rights holders, as publishers or in other contexts. Names in metadata may be used to:
- provide proper citations for the resource
- determine the intellectual property issues that may accompany uses of the resource
- provide useful sorting of resources
- relate one resource with another by having the same name associated
The name(s) of the creator(s) of the resource should be included in the OAI metadata record whenever they are known, and should be clearly distinguished from names of persons or corporate bodies who are subjects of the resource being described or other named entities in the metadata record.
The guidelines below generally apply to all uses of personal and corporate names in a metadata record.
[edit] Choice of Name(s)
Determination of the importance of a name, and how many should be included in a metadata record about a particular resource should be based on the practice or expectation of the domain or community providing the data. For example, if the community expects all authors to be listed as creators, this should determine practice. If a content standard like the Anglo-American Cataloging Rules (AACR2), Describing Archives: A Content Standard (DACS), or Cataloging Cultural Objects (CCO) is used to determine practice in this area, it should be documented by the provider. See Providing Supplemental Information to Service Providers.
[edit] Format of Name(s)
Names should be entered consistently within an OAI set or repository, based on the content practices of the domain or community providing the information. Consistency is important because it allows the OAI service provider to more easily process the metadata.
In traditional library practice, personal names are rendered "surname, forename" and literary warrant is used to determine appropriate fullness of name. In that community, external authority files (such as the Library of Congress Name Authority Files) control the format of names, determined according to standard content rules (generally AACR2). In a context where names are text values, "surname, forename" practices allow more appropriate sorting.
In other communities with different content standards (or lacking content standards) direct order names are acceptable, but should be applied consistently. Some communities traditionally use only forename initials rather than full forenames, and, although this practice complicates the determination of whether "Smith, A." who publishes about chemistry is the same as "Smith, A." whose topic is golf, this practice is also acceptable for records created by and intended to be used in these communities.
Corporate names are complicated by issues of hierarchical ordering and frequent changes. Traditional libraries follow fairly complex rules about order of hierarchy and whether all levels must be expressed, but in other communities such considerations are not relevant. In general, best practice mandates only that acronyms for organizations be consistently spelled out, so that communities not familiar with the acronyms can make use of the data.
[edit] Additions to Name(s)
In some communities, titles, dates or academic affiliation of the person names are included in the name element in order to reduce ambiguity. Before including extra information within a name element data providers should ask whether the addition to the name can reasonably be considered an extension of the name itself. Using this criteria, a date or title is normally acceptable, but an affiliation is not, since the affiliation is actually the name of a separate entity.
It is important, when considering what information to add to a name in the context of resource description, to limit the addition of information that serves to describe the person, rather than the resource. In an ideal world the person or body would be described unambiguously somewhere else, and the relationship between them expressed in the metadata description for the resource, but that world is not yet ours.
[edit] Encodings of Name(s)
The metadata schema in use will often prescribe the granularity of encoding of a name.
In MODS, for example, a name heading for a creator can be broken into several parts:
<mods:name type="personal">
<mods:namePart type="family">Cushman</mods:namePart>
<mods:namePart type="given">Charles Weever</mods:namePart>
<mods:namePart type="date">1896-1972</mods:namePart>
<mods:role>
<mods:roleTerm authority="marcrelator" type="text">photographer</mods:roleTerm>
<mods:roleTerm authority="marcrelator" type="code">pht</mods:roleTerm>
</mods:role>
</mods:name>
See MODS IU Charles Cushman Collection 1 for the complete record from which this example was taken.
In Dublin Core, the entire name heading must be entered into a single creator, contributor, publisher, or subject element, as appropriate:
<dc:creator>Cushman, Charles Weever, 1896-1972</dc:creator>
See DC IU Charles Cushman Collection 1 for the complete record from which this example was taken.
Multiple names should be coded in separate fields. (Needs example.)
Note that choosing to expose metadata formats that provide for more granular encodings of names will allow more robust use of this data by OAI service providers.
