3

EDITORIAL RULES, CONTINUED

3.8

Administrative Flags, Notes, and Revision History

Included in this chapter

• Comment Flag
• Problem Flag
• Assigned To
• Special Project
• Sequence Number for Special Project
• Facet Code
• Legacy ID
• Class Notation
  
• Media / Image
  
• Sequence Number for Image
  
• Index Note
• Not Found Note
• Status Note
• Editor Note
  
  
• Revision History fields (required-default)^[1]

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 works, 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
This field is also used to flag records for works that may be assumed to be intended in texts or databases when only the title is referenced. In rare cases, a work of art or architecture is so famous that only its title is used in discussions or data. Other data items typically required for disambiguation, such as name of the artist or current location, may be omitted.

Implementors seeking automated matches between such texts or data and CONA may assume that, when multiple matches for the title are found in CONA, the CONA record flagged famous/noted is intended if no other information is given. Examples include Mona Lisa and Willis Tower.

Note that if a record is flagged famous/noted, it should assume priority only in matches using the record-preferred title/name or the title/name having Other Flag = popular. Do not make the comparison for famous/noted using other titles in the compared records. For example, Night Watch is a title flagged Other = popular in a record flagged Famous/Noted. If a text or database refers simply to Night Watch without any additional information, such as artist or location, it may be assumed to refer to this painting. However, in CONA this painting has other titles, such as Officers and other civic guardsmen of District II of Amsterdam. These other titles should not assume priority in a match, because they are not necessarily unique references to this one painting that is flagged famous/noted.

3.8.1.4

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: In TGN, the flag reads Noted rather than Famous. It is used for Records having titles or 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 title alone, flag it as Famous / Noted.
  
  The purpose of this flag is to distinguish the well known work from others having the same or similar title or 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 title or name is typically used in texts and databases without additional information and always intended to refer the same work.
  
  
• 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 CONA, not as a comment on an existing record.
  
  
• Not Applicable: Default value indicating that the Comment Flag is not applicable for this record. Most records in CONA are currently set to N/A.

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 Work 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 most records in CONA are set to Blank.
    
    
  • 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

Inication of any 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
  
• Arc - Archaeology: Records added for the discipline of archaeology
  
• ART - ARTstor
  
• SAH - Society of Architectural Historians
  
• 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 the archaeology community to submit records of prominent sites as built works, and the artifacts associated with the sites as movable works. Although such a flag could not be assumed to capture all CONA records used for archaeology, 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 prominent works needed by their community.

How is this field related to the Contributors fields linked to Titles, Scope Notes, the Creator Display, 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.4

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., ARTstor), 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 used only in the AAT.

3.8.6.2

Values
Unicode characters and numbers.

3.8.6.3

Discussion
This field is system-generated. It is currently not applicable to CONA.

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 CONA data having old IDs with new releases. As of this writing, given that CONA has never had IDs other than those currently assigned and it is anticipated that these IDs will be persistent, the Legacy ID is rarely if ever used in CONA.

In the future, this field could possibly be used to record IDs where a Used For term (variant title) was deleted from a work record because it was not truly syononymous, and then used in a new record.

IDs for contributors records
Note that in the AAT 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.

Class Notation formerly had a different function in another Getty vocabulary, the AAT. 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.9

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 the work. 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 images of the works, as time and editorial priorities allow. Contributors should include a link to an image, if one is available.

3.8.9.3.2

How to link to an image

• Persistent URL
  Link only to persistent URLs for an image.
  
  
• Sources for images
  Sources for images should be the following:
  
  
  • Official 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 represent the image well.
  
  The first priority should be to include an overall view of the work.
  
  Additional images may include details or historical views of the 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: 2013-05-08, JPGM; 2015-01-29, independent scholar Hal Bruckings comments;

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 work, however the work is not included. Do not include minor sources or journal articles that fail to mention the work.
  
  
• 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: BRUS: Janson, History of Art (1997); De Goncourt, Catalogue raisonné de P. P. Prud'hon; JPGM: Boime, Academy and French Painting (1971);

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.

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-10-09, holding status, all children of this volume are detached and dsipersed, must be associated with current repository prior to publication;

3.8.14

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: VP PH July 2010, preferred attribution reflects repository preference; various scholars disagree, but these attributions are non-preferred in CONA.

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 some 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, 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., JWARD).
  
  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-JPGM), 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.
  
  
  • Examples
    
  • Public Note: Old Parent: Book of Hours (700002334);
    
  • Public Note: GCI Source and Contributor added
    
    
  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: Apulian Black Hydria with Gilding and Black Stand (1000010924);
    
    
  For Associative Relationship
  The Public Note is used to indicate the linked records and the relationship type between them.
  
  
  • Example
    
  • Public Note: Le d$00ejeuner sur l'herbe (700000419) 'depicts' Le D$00ejeuner sur l’herbe (700008412);
    
    
  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, not enough warrant for attribution discussion

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 10/03/2010: Alert contributors of Associative Rels links to this multiples record at the next ITWG meeting;

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

Last updated 17 January 2016
Document is subject to frequent revisions