The Getty
Research Home Search Tools & Databases Learn about the Getty Vocabularies Editorial Guidelines Union List of Artist Names Online
Art & Architecture Thesaurus Online
3. Editorial Rules, continued
 
 

3

EDITORIAL RULES, CONTINUED

   

3.8

 

Administrative Flags, Notes, and Revision History

Included in this chapter

 

 

 

 

3.8.1

   

Comment Flag

   

 

3.8.1.1

 

 

Definition

Flag indicating if a critical comment is applicable to the record, including if the record represents a special case among similar or homographic names, or if a contributed record is an additon or revision to an existing record, as distinguished from a new record.

       

3.8.1.2

 

 

Values
Values are controlled by a list.

    Famous / Noted
    Comment Candidate Record
    Not a Comment Candidate
    Not Applicable

 

 

 

3.8.1.3

 

 

Discussion

This field is used for contributions, to flag records that are comments on existing records (thus requiring merging) as distinct from new records.

Famous/Noted
In ULAN this field may be used to flag records for people and corporate bodies that may be assumed to be intended in texts or databases when only the name is referenced without additional information, including the nationality or dates. Examples of place names used without broader context or other information are in places of publication and current or former locations of architecture or art.

Implementors seeking automated matches between such texts or data and ULAN names may assume that, when multiple matches for the name are found in the ULAN, the ULAN record flagged famous/noted is intended if no other information is given. Examples are Michelangelo and Hokusai.

If a record is flagged famous/noted, it should assume priority only in matches using the record-preferred name or a name having Other Flag = Common (e.g., Michelangelo is the common name for the artist having the record-preferred name Buonarroti, Michelangelo). Do not make the comparison for famous/noted using other names in the compared records.

       

3.8.1.3

 

 

RULES for Comment Flag

       

3.8.1.4.1

 

 

Minimum Requirements

Required-default: This flag for Comment or Not a Comment is typically set in the data load. Editors generally should not change the flag, other than to flag Famous / Noted.

       

3.8.1.4.2

 

 

How to apply the Comment Flag

    Apply the comment flag as necessary using the definitions below.

  • Famous / Noted: For Records having names that are homographs with other works, and for which the identification may be confused, if one of the records is extremely well known and often referred to by name alone, flag it as Famous / Noted.

    The purpose of this flag is to distinguish the well known people and corporate bodies from others having the same or similar name for the purposes of matching and in retrieval.

    Caveat: Be very circumspect when applying the Famous/Noted flag. It should be used only in the rare cases where the name is typically used in texts and databases without additional information and always intended to refer the same place.

  • Comment Candidate Record: For new contributions, indicates records that were submitted as "comments" on existing records; that is, they are requests for additions to or changes to an existing vocabulary record. When this flag is set to "C," the record typically should be merged with an existing record.

  • Not a Comment Candidate: For new contributions, indicates that the record is a new record to be included with a new subject_id in ULAN, not as a comment on an existing record.

  • Not Applicable: Default value indicating that the Comment Flag is not applicable for this record.

 

 

 

 

3.8.2

 

 

Problem flag

 

 

3.8.2.1

 

 

Definition
Flag indicating if there is a problem requiring editorial attention.

       

3.8.2.2

 

 

Values
Controlled by a list.

    Yes
    No

 

 

.

3.8.2.3

   

RULES for Problem Flag

 

 

 

3.8.2.3.1

 

 

Minimum Requirements

Optional: Use Problem Flag as necessary.

 

 

 

3.8.2.3.2

 

 

When to use Problem Flag

  • For People and Corporate Body Records
    This flag is most often used to flag a record placed under a temp.parent that is not yet published. Such records should be omitted in the Candidate Report for contributors.

    Do not flag Problem Flag = Yes for records that are in the published hierarchies.

  • For temp.parent levels
    Additionally, for temp.parent records themselves that are created for as a level for testing, deleted records, or otherwise should not be visible to contributors, set the Problem flag to Yes.

    Do not publish children of Problems
    In reports and other methods of revealing candidates to contributors or other users, do not include the record having Problem = Yes nor any children of that record.

  • Describe the problem
    If the problem flag is set the flag to Yes, describe the problem in the Editor Note, including your initials and the date.

    • [Blank]: No value. Currently many records in TGN are set to Blank. When records are loaded, they are not automatically set with Problem = No.

    • Yes: Indicates there is a problem with the record.

    • No: Indicates that there perhaps was an earlier problem, but it has been resolved.

 

 

 

 

3.8.3

 

 

Assigned To

 

 

 

3.8.3.1

 

 

Definition
Note indicating to which editor the record was assigned.

       

3.8.3.2

 

 

Values
Free text. Unicode characters and numbers.

 

 

3.8.3.3

   

RULES for Assigned to

 

 

 

3.8.3.3.1

 

 

Minimum Requirements

Optional: Use this field as necessary.

  • The supervisor or her delegate will fill in this field. Values should be the initials or user name of an editor (e.g., PHarpring).

  • If your name appears in this field, you are responsible for editing the record and all children under it.

 

 

 

 

3.8.4

 

 

Special Project

     

3.8.4.1

   

Definition
Indication of a special project for which the record is a part, including projects having to do with a given theme or discipline.

       

3.8.4.2

   

Values

Values are controlled by an extensible list. The list comprises a code and description.

  • Examples
  • AH - Auction houses project
  • ART - ARTstor
  • SAH - Society of Architectural Historians
  • NAm - Native American artists project
  • VRA - Visual Resources Association

   

3.8.4.3

   

Discussion
This flag may be used during the editorial processing of the record and also in the retrieval of the record.

For retrieval, this flag may be used to gather a significant set of records having to do with a particular project, theme, or discipline.

An example of usage of this flag could include a project by scholars of Native American art to submit records for names of artists required for their cataloging. Although such a flag could not be assumed to capture all ULAN records relevant to Native American art, it may provide a useful set of records that have been so far considered and approved by that community.

Another example of usage could include a project initiated by the Visual Resources Association to contribute new records for patrons' names needed by their community.

How is this field related to the Contributors fields linked to Terms/Names, Scope/Descriptive Notes, and the overall record? Each contributor represents the institution that made the contribution, but Special Project identifies the project of which this effort was a part.

       

3.8.4.3

   

RULES for Special Project

       

3.8.4.4.1

   

Minimum Requirements

Optional: Designate special projects as necessary.

       

3.8.4.4.2

   

How to designate a Special Project

  • Use codes that have been authorized by your supervisor and available in the list.

  • If the record has been designated as a subset for a particular special project (e.g., VRA), the code will have been loaded with a contribution. Alternatively, the code may be entered by hand by a Vocbulary Program editor.
       

 

3.8.5

   

Sequence Number for Special Project

       

3.8.5.1

   

Definition
The Display Order number (or Sort Order number), indicating priority, order of contribution, or alphabetical order.

       

3.8.5.2

   

Values
Values begin with 1 and are numbered sequentially; there is no upper limit imposed by the system

       

3.8.5.3

   

RULES for Sequence Number

       

3.8.5.3.1

   

Minimum Requirements

Required-default: If there is a special project, Sequence Number is required. If there is only one special project, the default value is 1. If there are multiple images, sort them in an appropriate sequence by priority, by order of contribution, or alphabetically.

       

 

3.8.6

   

Facet Code

       

3.8.6.1

 

 

Definition
Facet code is used to indicate the facet to which the record belongs. This is a legacy indicator, currently retained only in the AAT.

   

3.8.6.2

   

Values
Unicode characters and numbers.

       

3.8.6.3

   

Discussion
This field is system-generated. In ULAN, it currently contains no values..

     

 

3.8.7

   

Legacy ID

   

 

3.8.7.1

   

Definition
Numeric or alphanumeric identification that was used for this record in previous systems.

   

3.8.7.2

   

Discussion

The purpose of this field is to provide implementers with a means to map older ULAN data having old IDs with new releases.

In ULAN, it is anticipated that the currently assigned IDs will be persistent.

IDs for contributors records
Note that in the ULAN data, the contributors original, internal or local ID for a record is retained for comparison and reference for the additon of new contributions in future. That field is separate from the currently-discussed Legacy ID field, and is invisible to VCS editors.

       

3.8.7.3

   

RULES for Legacy ID

   

 

3.8.7.3.1

   

Minimum Requirements

Optional: The field is system-generated. Editors cannot change it.

   

 

 

3.8.8

   

Class Notation

   

 

3.8.8.1

   

Definition
Brief justification or explanation of the classification or hierarchical placement of the record.

       

3.8.8.2

   

Values
Free text. Use Unicode characters and numbers

   

3.8.8.3

   

Discussion
In some cases, it is useful for users to know why a certain classification or hierarchical position was chosen. If the choice is does not require explanation, do not use this field.

In the AAT, the analogous Class Notation field formerly had a different function. The field may be seen in legacy AAT records as a string that was formerly used to build hierarchies in the 1980s.

       

3.8.8.4

   

RULES for Class Notation

       

3.8.8.4.1

   

Minimum Requirements

Optional:
If necessary, enter brief justification of classification or hierarchical placement of the record, or for broader contexts, for the children of the record. It may repeat information in the Public Note of Revision History, if pertinent.

   

 

 

3.8.8

   

Media / Image

   

 

3.8.9.1

   

Definition
Link to a persistent URL that illustrates the work

       

3.8.9.2

   

Discussion
Includes only persistent URLs that illustrate representative works of the artist or a portrait of the person. Formerly, image files also were collected in VCS, but the overhead for storing images and ascertaining copyright permissions has been deemed impractical.

   

 

3.8.9.3

   

RULES for Media / Image

       

3.8.9.3.1

   

Minimum Requirement

Optional: It is optional but highly recommended to include links to representative works by the artist or portraits of the person represented by the record, as time and editorial priorities allow. Contributors should include a link to works or a portrait, if one is available.

     

3.8.9.3.2

   

How to link to an image

  • Persistent URL
    Link only to persistent URLs for the images.

  • Sources for images
    Sources for images should be the following:

    • Museum or other repository sites.

    • Images in Open Content or in the Public Domain having a persistent URL.

    • Avoid dot-com sites; however reliable online dot-com data bases may be used. Check with the Vocabulary Program before linking to a dot-com site.

  • How to choose an image

    Choose images that are of good quality and are representative of the artist's work. Do not try to comprehensively list all works by an artist. Limit the number of links to 6 or fewer.

    The first priority should be to include an image or images that best represents the overall oeuvre of the artist.

    Portraits of people represented in the ULAN record are also welcome.

    Additional images may include details or historical depictions of the artist's work.

     

   

 

3.8.10

   

Sequence Number for Image

   

3.8.10.1

   

Definition
The Display Order number (or Sort Order number), indicating the sequence of the images in displays.

   

3.8.10.2

   

Values
Values begin with 1 and are numbered sequentially; there is no upper limit imposed by the system.

   

3.8.10.3

   

RULES for Sequence Number

   

3.8.10.3.1

   

Minimum Requirements

Required-default: If there is an image, Sequence Number is required. If there is only one image, the default value is 1. If there are multiple images, sort them in an appropriate sequence.

   

 

   

3.8.11

   

Index Note

   

3.8.11.1

   

Definition
Information about the data load or sources of the data.

       

3.8.11.2

   

Values
Free text field. Use Unicode characters or numbers.

   

 

3.8.11.3

   

RULES for Index Note

   

 

3.8.11.3.1

   

Minimum Requirements

Optional: It is optional to include the index note.

   

 

3.8.11.3.2

   

How to record Index Note

  • For data loads, the system administrator should include the date, contributor, and other information relevant to a major data load.

  • Given that this note is not repeatable, separate individual comments with semi-colons. For each comment, include the contributor Brief Name to identify to which contribution the comment applies.

    • Example
    • Index Note: 2008-08-16, WL-Courtauld: Birthplace: Caprese,Arezzo,ITA.; Deathplace: Firenze,ITA.; 2008-08-21, CL-Courtauld: Birthplace: Caprese,Arezzo,ITA.; Deathplace: Firenze,ITA.; 2009-06-02, AVERY: 2010-11-13, Grove Art: 2011-02-14, GRL:

   

 

 

3.8.12

   

Not Found Note

     

3.8.12.1

   

Definition
Note listing sources that were consulted but that did not contain information about the work.

       

3.8.12.2

   

Values
Free text field. Use Unicode characters or numbers.

     

3.8.12.3

   

RULES for Not Found Note

   

 

3.8.12.3.1

   

Minimum Requirements

Optional: It is optional to include the not found note.

   

 

3.8.12.3.2

   

How to record Not Found Note

  • Which sources to include
    Record well known sources in which information could be expected to be found on the person or corporate body, however the person or corporate body is not included. Do not include minor sources or journal articles that fail to mention the person or corporate body.

  • Who records the Not Found Note
    Various contributors record this information; it is loaded into this field.

    Vocabulary Program editors may also enter values in this field.

  • Content of the Note
    Given that this note is not repeatable, separate individual sources with semi-colons. For each source, comments may also be included.

    Include a reference to the contributor (the Brief Name for the contributor) of information before each source or set of sources.

  • Use the VCS Sources file Brief Citation to refer to the source.

    • Example
    • Not Found Note: BHA: Bolaffi, Dizionario dei pittori italiani (1972-1976); Dizionario Biografico degli Italiani [online] (2013-);

     

 

3.8.13

   

Status Note

   

 

3.8.13.1

   

Definition
Note elaborating upon special circumstances regarding the status of the records.

       

3.8.13.2

   

Values
Free text field. Use Unicode characters or numbers.

       

3.8.13.3

   

RULES for Status Note

       

3.8.13.3.1

   

Minimum Requirements

Optional: It is optional to include the status note.

     

3.8.13.3.2

   

How to record Status Note

  • The Status Note is often a note explaining the Review Status of the record.

  • For data loads, the system administrator could include a note relevant to the status of the record.

  • Vocabulary Program editors may note a particular status of a record or for a broader context for multiple records.

  • Given that this note is not repeatable, separate individual comments with semi-colons. For each comment, include the contributor Brief Name or editor name to identify to which status comment applies. Include the date when the status was analyzed.

    • Example
    • Status Note: PH: 2013-02-11, holding status, confirm with contributor that children of this corporate body are valid;
     

 

3.8.12

   

Editor Note

     

3.8.14.1

   

Definition
Note for editorial problems or decisions associated with the record.

       

3.8.14.2

   

Values
Free text field. Use Unicode characters or numbers.

       

3.8.14.3

   

RULES for Editor Note

       

3.8.14.3.1

   

Minimum Requirements

Optional: It is optional to include the editor note.

     

3.8.14.3.2

   

How to record Editor Note

  • Record information about issues, problems, or other information important for the ongoing editorial work editorial history of the record.

    Include reasons for editorial decisions where questions could arise.

  • This note will not be visible to end-users.

  • Explain circumstances regarding designations of Problem Flag.

  • Include your initials and the date of your comment.

    • Example
    • Editor Note: PH March 2014, choice of preferred name based on shorter name, not LOC heading (used by several contributors) which is too long in this case;

   

 

 

3.8.15

   

Revision History fields (required-default)

     

3.8.15.1

   

Definition
Audit trail of editorial work on the record, including action, editor, and date.

     

     

3.8.15.2

   

Values
Use Unicode characters or numbers. Certain flags are controlled, while others are note fields.

     

3.8.15.3

   

Discussion
The Revision History is, for the most part, system-generated. Each individual field is not treated as a separate section in this manual. Instead, brief explanations of what the fields mean are included here.

     

3.8.15.4

   

Rules for Revision History

     

3.8.15.4.1

   

Minimum Requirements

Required-default: System-generated values should not be edited or deleted, except for certain note fields, as described below.

     

3.8.15.4.2

   

How to interpret and edit Revision History

  • Interpret the fields in the Revision History according to the definitions below.

  • Editors should add or edit information in the Public Note and Private Note as indicated below.

  • The fields in each row are linked, repeatable as a row.

     

3.8.15.4.3

   

Revision History Type

  • Type: Refers to the part of the record that was affected by the Action. Types include the following values:

      S = Subject: Refers to changes or additions made to the record as a whole or to any field other than Term/Name, Associative Relationships, or Note, which have separate Type flags.

      T = Term/Name: Refers to changes made to a term, title, or name in the record. The value of the term, name, or title added or changed, and an indication if it is a new term is noted in the associated Public Note.

      A = Associative relationships: Refers to new Associative Relationships added to the record. An identification of the linked subject record and the relationship type are listed in the linked Public Note.

      N = Note: Refers to additions or changes made to the Scope Note/Descriptive Note. The language of the note is listed in Public Note.

     

3.8.15.4.4

   

Revision History Action

  • Action: Refers to the Action taken by the editor or system administrator, including the following values and definitions:

      created: Used with Type = Subject or Note, incating when and by whom (usually the Loader or a Vocabulary Program Editor) a record was created or a Scope Note/Descriptive note was created.

      updated: Used with Type = Subject, Term, Note, or Associative Relationship, indicating a change has been made to that entity.

      moved: Used with Type = Subject, indicates when a record is moved from one parent to another. Old Parent is listed in the Public Note.

      merged: Used with Type = Subject, indicates when two records are merged. The identification of the records are listed in the Public Note.

      parent added: Used with Type = Subject, indicating when a subject record had the addition of a non-preferred parent.

      added: Used with Type = Term, Note, or Associative Relationship, indicating the type of entity has been added to the record.

      deleted: Used with Type = Term, Associative Relationship, or Note, noting when an element was deleted from the record. The identity of the deleted entity is recorded in the Public Note.

      published: Used with Type = Subject, indicating the record was published in the annual publication release, on a certain date. The publication as APIs, LOD, and in the online search mechanism every two weeks is not noted by this flag; as of this writing, it refers to only the annual publications.

      noncandidate: Used with Type = Subject, indicating the record was moved from candidate status to non-candidate status, meaning it is processed and available for publication.

     

3.8.15.4.5

   

Revision History User Name

  • User Name: An indication of the editor or system activity that is responsible for the action. As of this writing, values include the following:

      Editor login: Login name of the editor (e.g., RJOHNSON).

      SYSADM: Refers to the system administrator, meaning an action was done globally by programming instead of editing manually.

      LOADER: Refers to the automated loading of records, done through programming rather than manually. LOADER-<NAME> (e.g., LOADER-GRL), includes the brief name of the contributor from whom the loader data was acquired.

     

3.8.15.4.6

   

Revision History Date Time

  • Date Time: Refers to the time and date when an action occurred.

    Format: The time stamp is expressed by month, day, year, hour, minute, and second in the following format: MM/DD/YYYY HH:MM:SS. It is expressed according to the time zone in which the action was taken, Pacific Standard Time (PST).

     

3.8.15.4.7

   

Revision History Public Note

  • Public Note: Note containing specific information or comments regarding the action indicated in the row. The Public Note is published.

  • Added by the system
    Most comments are, added by the VCS system as editorial work is done. In rare situations, the editor may alter the Public Note.

    If multiple comments are applicable to one row, the comments are separated by semi-colons.

      For Subject
      Notes details about when a subject was created, moved, acquired a non-preferred parent, etc.

      • Example
      • Public Note: Dominant: Buonarroti, Michelangelo (500010654) Recessive: Michelangelo Buonarroti (500342676)

      For Term/Name/Title
      The Public Note is used when an action was done to a Term/Name, this field describes which term (value and term_id) was Added or Updated.

      • Example
      • Public Note: Michelangelo di Ludovico Buonarroti (1500029817);

      For Associative Relationship
      The Public Note is used to indicate the linked records and the relationship type between them.

      • Example
      • Public Note: Buonarroti, Michelangelo (500010654) 'collaborated with' Venusti, Marcello (500004451);

      For Scope/Descriptive Note
      The Public Note is used to indicate the language of the note that was created.

      • Example
      • Public Note: English (70051)

  • Added by the editor
    If notable changes are made by the editor, of such significance that translating projects or other major contributors will require changes to their contributed data (which by policy is not edited by the Vocabulary Program), an indication is made to Public Note.

    If the editor makes such a notation, insert it before the automated note content of the pertinent row, preceding the notation with NB (for Nota Bene) as the first word in the Public Note.

    Contributors may do queries on the Revision History periodically to discover changes that should be made to their data.

    • Example
    • Public Note: NB: SN adjusted, had contained information about anonymous Alcira Master, who is now in separate record 500036290;

     

3.8.15.4.8

   

Revision History Private Note

  • Private Note: Note for internal editorial use only, containing comments regarding the action indicated in the row. The Private Note is not published.

    • Example
    • Private Note: PH 11/15/2011: Loads for all contributions by BRUS should be checked for inclusion of sources that are authoritative;

     

 

   

1In this chapter, "required-default" indicates that a default is automatically set by the system.

       

Last updated 19 January 2016
Document is subject to frequent revisions

 




Back to Top

The J. Paul Getty Trust
The J. Paul Getty Trust
© J. Paul Getty Trust | Privacy Policy | Terms of Use