 |
2
|
GENERAL GUIDELINES
|
|
|
|
2.1
|
|
General Information
|
|
|
|
|
2.1.1
|
|
|
Following the rules
Data creators: For Vocabulary editors, contributors, and other content creators, to enter or edit data for the Getty Vocabularies, follow the Editorial Rules in this document. Contributors or other users may compare their in-house rules to the guidelines in this document to gauge compatibility. Where the rules or their application are ambiguous or not applicable to a situation at hand, please consult with the Getty Vocabulary Program, vocab@getty.edu. These rules are regularly updated to reflect solutions and recommendations for new issues.
|
|
|
|
|
2.1.2
|
|
|
Required fields and minimal records
|
|
|
|
Implementers: Developers and other implementers of the Getty Vocabularies should refer to this document to extrapolate information that will aid in understanding and presenting the Getty Vocabulary data correctly.
Among the most important guidelines are the following: Do not omit references to the sources and contributors of the Getty Vocabulary data. The Getty Vocabularies are compiled from contributors' data and this contribution should be recognized. Published sources should be cited to avoid plagiarism. In implementations, please consider including all data included in the Vocabulary record ("record" meaning all data linked directly or indirectly by a given subject_id). Do not omit flags such as "unknown" or values in display fields "undetermined." For scholarship, contributors who are adding information to the records, and others, it useful to know when a value is unknown rather than left empty. An empty field means nothing. A value such as "unknown," even if it is a default value, is in itself useful information about the status of the field and can serve to identify areas requiring additional research. See also the discussion below about how catalogers deal with information that is unknown to themselves, or unknowable in the broader context of scholarship.
VCS: The custom-built editorial system used by the Getty Vocabulary Program is called "VCS" (Vocabulary Coordination System). You may find occasional references to "VCS" in this document, for the benefit of Vocabulary Program editors or others using this particular system. The Vocabulary databases comprise relational tables and allow construction of rich data in compliance with international standards for thesauri. In addition to creating polyhierarchies, linking associative relationships, creating terms and other data in multiple languages, and other typical funtions required by a thesaurus-construction system, VCS is optimized for loading contributions, merging contributions representing the same concept, citing preferences to allow alternate points of view, and tracking revision histories over long periods of time.
|
2.1.2.1
|
|
|
Minimal record
When adding new records, create a record that meets requirements for a minimal record, which
contains at minimum all required fields ("core" fields).
|
|
|
|
|
2.1.2.2
|
|
|
Fuller records
For contributions, fuller records are welcome, particularly those having useful alternate names, relationships, and coreferences. Editors: When adding records or editing existing records, if there
is additional time and the person or corporate body is important, you may create
a fuller record by filling in fields beyond the Core as time and research
warrant.
|
|
|
|
|
2.1.2.3
|
|
|
Required fields
Each record must include a name, a role, a nationality, a
display biography, and birth and death dates; in addition,
the record must be placed in the "hierarchy," under
either the Person or Corporate Body facet. The VCS will not
allow you to save a record without the required fields:
- a numeric ID identifies the record uniquely (IDs are
assigned by the system)
- a parent (generally, Person facet or Corporate Body
facet; you create the link to a parent by designating
the correct parent by the mark "DOM" (for dominant)
when you create or move a record)
- preferred name
- various associated flags: current/historical (set
to NA), vernacular/other (set to V), type (set to
NA), display/index flag, etc.
- source(s) for the name
- language, if known
- contributor of the name (automatically assigned
by VCS)
- role(s)
- nationality(ies)
- display biography
- sex
- birth date
- death date
- Other fields are strongly recommended:
- variant names
- related people or corporate bodies
- Additional fields, including the Descriptive Note, may
be included as time and editorial priorities allow.
|
|
|
|
|
2.1.3
|
|
|
Format and values
- Examples in the various sections of the editorial rules
illustrate the format of data in all fields.
|
|
|
|
|
2.1.3.1
|
|
|
Controlled vocabulary
Some fields use controlled vocabulary, meaning you must link
to a value in a controlled list. If you feel additional values
need to be added to the list, consult with your supervisor.
Controlled vocabulary includes dozens of short pull-down lists
of flags as well as long lists, such as Language and Role.
|
|
|
|
|
2.1.4
|
|
|
Capitalization and abbreviation
- Capitalize proper names appropriately. In general, data
in all fields should be expressed in mixed case (i.e.,
but not in all upper-case or all in lower case),
unless otherwise indicated. See further discussion under
each field below.
- Avoid abbreviations in all fields unless otherwise instructed
in the appropriate rules. For names, avoid abbreviations
in the preferred name, but include important abbreviations
(if any) in variant names to allow retrieval.
|
|
|
|
|
2.1.5
|
|
|
Language of the Record
|
|
|
|
|
2.1.5.1
|
|
|
Multilingual
ULAN is multilingual. This means that the names may
be flagged in multiple languages. Although names of people are only rarely represented in multiple languages (e.g., Raphael Sanzio in English, Raffaello Sanzio in Italian), names of corporate bodies may commonly be expressed in multiple languages. The notes
and other fields in the record are generally in English.
|
|
|
|
|
2.1.5.2
|
|
|
Alphabet
Names, descriptive notes, and other fields are expressed using Unicode. If terms or scope notes are contributed in a language other than English or in an alphabet or writing system other than the Roman alphabet, an English translation in the Roman alphabet must also be included.
|
|
|
|
|
2.1.5.3
|
|
|
Diacritics
ULAN is published in Unicode. However, in legacy ULAN data special codes may used to represent diacriticss (e.g., D$04urer,
Albrecht contains the umlaut code for Dürer, Albrecht). See Appendix A: Diacritics.
- Example
[name with an umlaut in display]
- Dürer, Albrecht (preferred, index, V)
Albrecht Dürer (display, V)
Duerer, Albrecht (V)
Albrecht Duerer (V)
|
|
|
|
|
2.1.6
|
|
|
Production goals
- Editors are assigned quotas for the number of records
that they should complete each day. The quota differs depending
upon the editorial task. Your supervisor will provide you
with the target quota for the task assigned to you.
- Typically, the quotas are gathered at the end of each
month and the number of records per day is averaged over
the days worked during that month. Your supervisor may tally
your quota for smaller periods of time as warranted. In
order to meet your monthly quota, it is recommended that
you meet your quota each day rather than trying to make
it up at the end of the month.
|
|
|
|
|
2.1.7
|
|
|
Leaving unfinished records overnight
- Do not leave unfinished records overnight. This is particularly
critical on nights when data extractions will be made for
the various data releases. At the end of each day, all records
in the regular, publishable sections of the hierarchy must
be ready for publication.
|
|
|
|
|
2.1.8
|
|
|
Quality control
- Avoid typographical errors at all costs. Proofread your
work carefully.
- If you have a problem with typos, for notes and other
texts, it is recommended to copy the note into Word, run
spell check, and then paste the corrected note into
VCS (but do not paste any special characters from Word).
- Pay special attention to names, because they are the most
important part of the ULAN record, yet the most difficult
in which to spot errors.
|
|
|
|
|
2.1.9
|
|
|
Avoid plagiarism
|
|
|
|
|
2.1.9.1
|
|
|
Published sources
Caveat: Do not copy texts from published sources
verbatim! Read, analyze, and rephrase the material. Do not
jump to conclusions or state more than is discussed in your
sources.
- It is permitted to cut-and-paste texts from the Web
provided you do so only as a reference. You must rewrite
any such text and cite the source.
- To avoid pasting illegal characters into VCS, first
put the Web text into Notepad, and then copy it from Notepad
before pasting it into VCS.
- It is required to cite the published source of names
and the information in notes. Include the page number
or other appropriate reference to the passage where you
found the name or other information.
- Sources may be linked directly to each Name and to the
Descriptive Note. For other information, note the source
in the overall Subject citation designation.
|
|
|
|
|
2.1.9.2
|
|
|
Contributors
It is required to include the contributor who provided Names
and the Descriptive Note. Generally, the contributor is automatically
assigned when the data is loaded and the editor need not worry
about it (other than to avoid deleting the contributor or
misrepresenting the contribution).
|
|
|
|
2.1.9.2.1
|
|
|
What is a contributor?
A contributor to VCS is an institution or occasionally
an individual person who does one of the following: 1) They
use programmers to process data files that originated in their
institution and they send us their data in our XML contribution
format, or 2) they use our online contribution form to fill
in data based on their own local data. In either case, the
contributor is handling the data; their data is not being
interpreted by the Vocabulary Program.
If an institution or
person sends us hardcopy information that we in the Vocabulary
Program enter into VCS, that institution or person is often not considered
a contributor per se. They are considered a source
for the data, but they are not a contributor because some amount of interpretation of their data may be required when it is entered
into our system. The Vocabulary Program
is the contributor in these cases.
- To avoid misrepresenting the contributor's contribution,
if you change a Name or significantly change a Descriptive
Note that had been provided by a contributor, change the
contributor to "VP" (for Vocabulary Program)
and make a link through Source to the contributor's database.
That is, you are citing the VP as the contributor,
and the original contributing database as the source.
- Caveat: Note that you may change a Name contributed
by a contributor only in special circumstances that have
been approved by your supervisor. Normally, you should
not edit a contributor's contributed artist name. If you
need to add a modified version of the name, make a new
name with contributor "VP"; do not delete or
edit the contributed name unless directed to do so by
your supervisor.
|
|
|
|
|
2.1.10
|
|
|
Uncertainty and ambiguity in display
fields
- When important information, such as birth date, is uncertain,
record the information with an indication of uncertainty
or approximation in a Descriptive Note, Display Biography,
or Display Date field (e.g., "ca." or "probably").
- Never express more certainty than warranted by your sources.
If there is disagreement among reliable sources, use terms
such as probably or otherwise express the uncertainty
(e.g., "While some scholars believe that the anonymous
Beardsley Limner is Sarah Perkins, others maintain that
stylistic differences raise doubts."). Consider
idiosyncrasies of contributed data (where data may have
been parsed incorrectly by algorithm out of various systems)
and your published sources; analyze what is true and what
is only possibly or probably true.
- Index important information in the note or display field
using appropriate indexing fields and estimating data for
retrieval. See the discussion of individual fields such
as Display Date, Display Biography, and Descriptive Note
fields below for more information.
|
|
|
|
|
2.1.11
|
|
|
Uncertainty and ambiguity in indexing
fields
- Indexing fields are intended for retrieval. Any field
that contains a controlled number (e.g., Start Date) or
values controlled by pick lists (e.g., Sex) or controlled
files (e.g., Language) are indexing fields. Consider retrieval
issues when you assign terms and values to such fields.
- When fields do not display to end users: For fields
that do not display to end users, such as the Birth Date
and Death Date indexing fields, estimate broadly the span
of time that is applicable. Estimating too narrowly will
result in failed retrieval. However, estimating overly broadly
will result in false hits in retrieval.
- When fields display to end users: Most fields in
ULAN display to end users. For such fields, do not make
wild estimations. If a specific value is in question, use
a broader value or use both of two possible values, depending
upon the circumstances.
- Knowable information: For information that
is knowable but simply unknown by you, always
use a more general term. For example, if you are uncertain
if the artist is a painter or a sculptor
because your source is ambiguous, use the more general
Role artist. The more specific information is
probably knowable in this case, if you had the time
and research materials necessary. But since you do not
know it, you should not use a specific term or terms
because it will be misleading to the end-user.
- Debated information: For information that is
unknowable because scholars disagree (often because
the historical or archaeological information is incomplete
or interpretation of the information is debatable),
you may index using multiple terms to allow good retrieval.
In such cases, you must always explain the ambiguity
or uncertainty in a Display Date, Display Biography,
or Descriptive Note. For example, if scholars disagree
regarding whether an early artist was Flemish or French,
you should explain this in the Descriptive Note and
in the Display Biography, and index the artist with
both French and Flemish as Nationalities.
- Flags: For flags, where you must choose one
value only, make the best choice based on the information
at hand. If there is any doubt, consult with your supervisor.
For example, if you cannot determine if the sex of an
artist is Male or Female, use Unknown.
See further discussion of individual fields in the relevant
chapters.
|
|
|
|
2.1.12
|
|
|
Uncertain identification of an artist
- In some cases, the identification of an artist is a matter
of conjecture and dispute. If there is debate regarding
whether an anonymous artist's appellation should be associated
with a named artist (e.g., is the Master of the Ovile
Madonna the same person as Bartolomeo Bulgarini?),
rely on general scholarly opinion to decide whether both
names should appear in the same ULAN record or in separate
records (representing separate artists). When scholarly
opinion is split, make separate records for the artists,
and note the possible connection in a descriptive note and
through an associative relationship. See also Associative
Relationships.
|
|
2.2
|
|
Merging records
- Each record in ULAN may contain information from multiple
contributors, all of which typically had records for the
artist in their own databases. Contributors to ULAN include
various Getty projects and qualified outside institutions.
The Vocabulary Program also contributes original information
to ULAN.
- If two records are contributed for the same artist, they
must be merged in VCS. The Vocabulary Program or approved
surrogates merge multiple records that represent the same
artist.
- In the merged record, the contributors' acronym appears
with the Names, Display Biography, and Descriptive Note
that they have contributed. Other fields in the database
do not link to the contributor name.
- Caveat: For corporate bodies that have hierarchical
structure, note that when you merge two records that have
children in the hierarchy, all of the children will be combined
in a list under the newly merged record. You must check
to see if any of the children in the new list should be
merged.
|
|
|
|
|
2.2.1
|
|
|
Rules for merging
|
|
|
|
|
2.2.1.1
|
|
|
When to merge
|
|
|
|
|
2.2.1.1.1
|
|
|
Matching the name, nationality, dates, and roles
Before merging, it must be ascertained that the two records
actually represent the same person or corporate body. The
artists to be merged must have the same name, same nationality,
same birth and death dates, and the same roles. Alternatively,
these fields should contain approximate or equivalent values
according to the following rules:
- Names: Names must be variants or alternate names
for the same artist (including names of various degrees
of fullness, names in different languages, nicknames, and
historical names such as a maiden names). Note that there
may be separate artists with very similar names with the
same nationality and similar life dates; do NOT merge such
records.
- Nationality: Nationalities must match or be "equivalents"
for the purposes of matching. An example of equivalent-for-matching
nationalities would be Italian and Sienese
(because any Sienese artist is also Italian).
The list of equivalent Nationalities is available in VCS.
- Dates: Birth and Death Dates as expressed in the
Display Biography must match. For uncertain dates, such
as ca. 1400-1461 or 15th century, the display
dates must be compatible with each other within a certain
range.
- Roles: Roles must match or be "equivalents"
for the person of matching. For example, if one record identifies
the artist as a painter and another record identifies
him or her as a watercolorist, these are considered
equivalent roles for the purpose of merging. The list of
equivalent Roles is available in VCS.
- Caveat re. merging: If in doubt, do NOT merge the
records!
|
|
|
|
|
2.2.1.1.2
|
|
|
Explain ambiguities
If you discover that the people should not be merged, but
that they have been historically confused in scholarly literature,
write a Descriptive Note explaining the difference and make
an Associative Relationship with the Relationship Type distinguished
from.
- Caveat: If the people merely have the same or similar
names and biographies, but there is no indication that they
have historically been confused in the literature, do NOT
write a Descriptive Note or make the relationship between
them. Many people have the same name and similar biographies.
In such cases, note your observations in the Editor Note,
which is not published for end users.
|
|
|
|
|
2.2.1.1.3
|
|
|
Facets
You cannot merge facets. Currently, the publishable facets
in ULAN are the following:
Corporate Bodies
Persons, Artists
Non-Artists
Unidentified Named People and Firms
Unknown People by Culture
Temp.parent
facets contain the candidate records. The system will not
allow you to merge facets.
|
|
|
|
|
2.2.1.1.4
|
|
|
For persons
Merge person records only if they are without a doubt the
same person. Do not merge persons with corporate bodies.
|
|
|
|
|
2.2.1.1.5
|
|
|
For corporate bodies
Do not merge persons with corporate bodies. A corporation
or other group is a separate thing from the founder or master
of the group (e.g., Richard Meier & Partners is
a corporate body, and Richard Meier is a person in
ULAN). Make an associative relationship between the firm and
the founder of the firm.
- Merge corporate body records with each other only if the
records represent exactly the same entity. Generally include
the former names as historical names in one record rather
than making two records 1) if the corporate body is a historical
studio or institution (e.g., Manufacture Royale des Gobelins
and Manufacture Nationale des Gobelins are two names
in the same record), or 2) if the primary partners have
remained the same for a modern firm.
- Generally make two separate records 1) if the function
or location of the historical corporate body changed with
the name change, or 2) if the question involves a modern
firm and legal incorporation, the primary partners have
changed, and the firm apparently prefers to clearly distinguish
its separate incarnations. Link the related corporate bodies
(see 3.5 Associative Relationships).
- Caveat: If a corporate body has changed names over
time, it is probably a new corporate body with a separate
record.
|
|
|
|
|
2.2.2
|
|
|
Procedures for merging
- After determining that the records absolutely represent
the same person or corporate body, you may "merge."
Go to the hierarchy view; mark DOM and REC. Mark the best,
primary record as "DOM" (for dominant)
and the record(s) that are to be merged into it as "REC"
(for recessive). Merge using the menu.
- Mark list: Before every merge, it is mandatory
editorial practice to look at the Mark List window in order
to double-check that you have marked the correct records
as DOM and REC.
- After merging, check the merged record and edit as necessary.
|
|
|
|
|
2.2.2.1
|
|
|
Unmerging
If, in spite of all precautions, you mistakenly merge the
wrong records and you notice this error immediately, you may
click "unmerge" from the menu. If some time has
passed before you've noticed the mistake, if you are uncertain
how to do this, or have any doubt about the "unmerge,"
consult with your supervisor before doing anything.
|
|
|
|
|
2.2.2.2
|
|
|
Practical examples
Do not merge unless you are absolutely certain the two records
represent the same person or corporate body. There seems to
be a natural inclination for editors to merge and many errors
have so resulted. Resist it, unless there is no doubt.
|
|
|
|
Should the two 18th-century artists be merged? NO, the
life dates are different. This is a common name.
|
|
|
|
|
|
|
|
Should the ébéniste be merged, given that
the roles have overlapping meaning and the one's active dates
fit within the span of the other's life dates? NO. Research
reveals that they are cousins with the same name who are often
confused. Thus the editor should add the proper associative
relationship and explain the confusion in the Descriptive
Note.
|
|
|
|
2.3
|
|
Moving records
|
|
|
|
|
2.3.1
|
|
|
Rules for moving
|
|
|
|
|
2.3.1.1
|
|
|
When to move records
You will generally be moving records in order 1) to move candidate
records that are under a temp.parent to the publishable
parts of the hierarchies, or 2) to move records from one facet to a different facet.
|
|
|
|
|
2.3.2
|
|
|
Procedures for moving
- Determine where in the hierarchy the records belong, based
on the rules in Chapter 3.1 Hierarchical Relationships.
Go to the hierarchy view; mark DOM and REC. Mark the parent
record as "DOM" (for dominant) and the
record(s) that are to be moved under it as "REC"
(for recessive). Move using the menu.
- Mark list: Before every move, it is mandatory
editorial practice to look at the Mark List window in order
to double-check that you have marked the correct records
as DOM and REC.
- After moving, check the hierarchy to be sure that the
move was accomplished as you intended.
|
|
|
|
|
2.3.2.1
|
|
|
Undoing a move
If, in spite of all precautions, you mistakenly move the record(s)
incorrectly and you notice this error immediately, you may
click "undo move" from the menu. If time has passed
before you have noticed the mistake or if you have done any
other editing, the "undo move" will not work. If
you are uncertain how to do this, or have any doubt about
the "undo move," consult with your supervisor before
doing anything.
|
|
2.4
|
|
Sample Records
|
|
|
|
|
2.4.1
|
|
|
Sample ULAN record
- The record below is presented in an arrangement suitable
for end users.
|
|
|
|
|
|
2.4.2
|
|
|
Sample ULAN record in VCS
- The record below is a sample from the VCS editorial system.
|
|
|
2.5
|
|
List of Fields
|
|
|
|
|
2.5.1
|
|
|
About the fields
- There are around 90 "fields" of information
in a ULAN record. It is unlikely that all fields of information
will be available or appropriate for all artists. However,
certain information is considered core, and is required
for each minimal ULAN record (see also Required fields
and minimal records above).
- For some required fields, the system provides a default
value, which means that this value will be used in that
field unless you change it.
- Some fields are display-only fields that are controlled
by the system. For example, the Subject_ID may not be changed
by the editor. It is supplied by the system according to
rules in the VCS program.
- To view the Data Dictionary, see Addendum Z.
|
|
|
|
|
2.5.2
|
|
|
List of VCS Fields [1]
3.1
HIERARCHICAL RELATIONSHIPS
Parents
(required)
Sort
Order (required-default)
Historical
Flag (required-default)
Dates
for relationship to parents
Parent string (required-default)
Hierarchy Relationship Type (required-default)
3.2
IDENTIFYING NUMBERS, STATUS FLAGS, AND SUBJECT SOURCES
Subject
ID (required-default)
Parent
Key (required)
Merged
Status (required-default)
Published
Status (required-default)
Review
Status (required-default)
Record
Type (required-default)
Candidate
Status (required-default)
Label
(required-default)
Contributors
for Subject Record (required)
Sources
for the Subject Record (required)
3.3
NAMES
Term
ID (required-default)
Name
(required)
Preferred
Flag (required-default)
Qualifier
Sequence
Number (required-default)
Historical
Flag (required-default)
Term
Type (required-default)
Part of Speech (required-default)
Vernacular
Flag (required-default)
Language
for Names (required-default)
Preferred
Flag for Language (required-default)
Language Status (required-default)
Contributor
for Name (required-default)
Preferred
Flag for Contributor (required-default)
Sources
for Names (required)
Page
Number for Term Source (required)
Preferred
Flag for Source (required-default)
Dates
for Names
Display
Name Flag (required-default)
LC
Flag (formerly AACR flag)
Other
Flags
Assigned
To note
3.4
DESCRIPTIVE NOTE
Descriptive
Note
Sources
for the Descriptive Note
Contributors for the Descriptive Note
Language for the Descriptive Note
3.5
ASSOCIATIVE RELATIONSHIPS
Related
People and Corporate Bodies
Relationship
Type
Historical
Flag
Dates
for Associative Relationship
3.6
BIOGRAPHICAL INFORMATION
Display
Biography (required)
Nationality
(required)
Preferred
Flag for Nationality (required-default)
Role
(required)
Preferred
Flag (required-default)
Sequence
Number (required-default)
Historical
Flag (required-default)
Dates
for Role
Birth
Date / Death Date (required)
Birth
Place / Death Place
Sex
(Gender) (required)
Preferred
Flag for Biography (required-default)
Contributor
for Biography (required)
3.7
EVENTS
Event
Type
Preferred
Flag for Event
Sequence
Number
Event
Place
Dates
for Event
3.8
ADMINISTRATIVE FLAGS, NOTES, AND REVISION HISTORY
Comment
Flag
Problem
Flag
Assigned
To
Special
Project
Facet
Legacy
ID
Class
Notation
Image
Index
Note
Not
Found Note
Status
Note
Editor
Note
Revision
History
|
|
|
|
|
[1]Required
default indicates that a default is set by the system,
but should be changed by the editor as necessary (and if possible).
Some fields, such as Subject_ID, cannot be edited.
|
|
|
|
|
Updated 2 January 2023
Document is subject to frequent revisions
|
|
 |
 |

|
 |
 |
 |
 |
 |
 |
|