3

EDITORIAL RULES

3.1

Hierarchical Relationships

Included in this chapter

• Parents (required)
• Sort Order (required-default)
• Historical Flag (required-default)^[1]
• Dates for relationship to parents
• Parent string (required-default)
• Facet or Hierarchy Code
• Hierarchy Relationship Type (required-default)
  
  
  • Example
    
    
  • Traveling Tea Service
    .....Teapot
    .....Tea Caddy
    .....Japanese Imari Sugar Bowl
    .....Chinese Famille- Verte Tea Bowl
    .....Silver-mounted Scent Flask
    .....Spoon
    .....Wooden Box
    

3.1.1

Parents (required)

3.1.1.1

Definition
The broader context(s) for the concept record; parents refer to Hierarchical Relationships, which are broader/narrower, reciprocal relationships between records.

3.1.1.2

Fields

• 1. Parent: The parent_key is the numeric Subject ID of the preferred parent (e.g., 100001). The records for the child and parent are linked by their ID. When an editor places a record in a hierarchy in VCS, she/he chooses the correct parent and the system makes the link using the two IDs.
  
  
• 2. Preferred Parent Flag: Indicates if this is the preferred parent or a non-preferred parent. Each concept may have only one preferred parent. Values are P[referred] and N[on-preferred].
  
  
• 3. Parent String: A display generated by the system by concatenating the descriptors of the immediate parent and other ancestors, used to give context to the concept's descriptor in horizontal displays (as opposed to vertical, hierarchical displays).

3.1.1.3

Values
Values are concatenated automatically by the system, using the preferred name, qualifier (if any), and appropriate indentation.

Sources: Warrant for hierarchical placement
A repository's hierarchical arrangement of its works is warrant for hierarchical placement in CONA.

• Lacking this, decisions regarding the employment of hiearchical whole/part relationship should be made by the editor or cataloger based on analysis of various factors discusse below.

3.1.1.5

Discussion
In the Getty vocabularies, each record is linked to its immediate parent by means of a numeric ID. The hierarchy is constructed through these links.

• Hierarchical relationships form the structure of CONA, even though the data may be displayed as a list.
  
  
• The hierarchy in CONA refers to the method of structuring and displaying the work records within their broader contexts. Relationships in the hierarchy are indicated with indentation.
  
  
• Two facets, Movable Work and Built Work, provide a basic logical division of the works.
  
  
• Hierarchical relationships in CONA generally represent whole/part relationships (rather than genus/species or instance). They are used to link parts to a whole, such as items in a group or set, parts of an architectural structure (such as a dome, that has an architect and dates separate from those of the building as a whole), prints in a volume, works in a series, etc.
  
  
• CONA is polyhierarchical, meaning that concepts can belong to more than one parent. This would most often happen when recording historical relationships (as when a print was historically part of a now dispersed volume).
  
  
• Hierarchical relationships are referred to by genealogical terms: child, children, siblings, parent, grandparent, ancestors, descendents, etc.

3.1.1.5.1

Hierarchy display
In VCS, the hierarchical relationships are visible from the Hierarchy View window and also from the Subject Edit full record window, under Hierarchies (where it displays in a horizontal string). Hierarchical relationships are created in the Hierarchy Display of VCS or by loading candidate data.

• Root of the hierarchy: CONA root, named Top of the CONA hierarchy, is the highest level of the hierarchy (the so-called root). The facets are located directly below the Root. In thesaurus displays, facets may have intervening levels and guide terms. Currently CONA does not employ these levels.
  
  
• Hierarchical displays are system-generated from the preferred title and other information comprising the Label.
  
  
• In VCS, the plus sign indicates where more levels may be visible (click on the plus sign in VCS to view the children under any level). In the online display, click on the hierarchy symbol.
  
  

3.1.1.6

RULES for creating hierarchical relationships

3.1.1.6.1

Facets and "Hierarchies"
The records for the facets of CONA may not be edited, merged, or moved without the permission of your supervisor. You may not add a new Facet, Hierarchy, or Guide Term to CONA.

3.1.1.6.2

When should the parts of a work be cataloged separately?
Create a Work record for each part as well as a Work record for the whole when the information for the whole varies significantly from information for the part. The purpose is to present the information clearly and distinctly, and to provide effective access to the parts as well as to the whole.

• Background
  Works of art or architecture may be considered a single item, or they may be made up of many physical parts or arranged in separate physical groupings expressed through hierarchical relationships.

• Historical whole/part relationships
  The whole/part designation of the work may be relative and changeable. When an altarpiece is held by one owner in its entirety, it will probably be described as a single object. If it has been dismantled and dispersed, the many parts of the same original work will now be recorded as separate works. Historical whole/part relationships should be recorded as hierarchical relatonsips.

• Parts of parts
  If a work is made up of many components, the components may also have parts; these relationships should be indicated.
  
  
• Archival groups
  Use hierarchical relationships to document archival groups and their parts. Archives typically catalog (or "describe") on the group level, because they collect large bodies of objects that can be readily broken into intellectual and physical groups. A defining characteristic of group-level cataloging is that the objects in a group can be described meaningfully as an aggregate, generally because they share a common purpose or origin; however, a group often contains many different types of objects (e.g., drawings, books, models, and correspondence).
  
  
• Museums traditionally favor item-level cataloging, assigning accession numbers and other catalog information to every individual object in their collections. Libraries traditionally catalog volumes as individual items and typically do not catalog individual prints or illustrations in the pages of a volume.
  
  
• Catalog Level: Make sure that the work record has a Catalog Level designation appropriate to the hierarchical divisions: item, volume, group, subgroup, collection, series, set, multiples, component, etc.See discussion at Catalog Level.

3.1.1.6.13

Multiple parents
CONA is polyhierarchical. Records in CONA may be linked to multiple broader contexts (i.e., multiple parents), particularly when describing historical groups or components.

• In consultation with your supervisor, assign multiple parents to records in CONA as necessary.

   » Preferred parent

One parent must be flagged as preferred. Make the preferred relationship to the parent that is currently the larger context for the part. Historical relatonships should be non-preferred.

• Children displaying with a non-preferred parent are flagged with an upper-case N (for non-preferred) in square brackets in the hierarchy display.

3.1.1.6.16

Positioning under a Candidate level/Temp. parent

   » Incomplete warrant or unknown scope

If you do not have enough information to publish a work record, put the record under a candidate level (temp.parent) pending further research. The examples below have insufficient warrant.

   » Using temp.parent only when absolutely necessary

All records placed under a temp.parent are candidates; i.e., they will not be published. Therefore, if your assigned task is to place/move works in the hierarchy, endeavor to correctly position records in the publishable facet.

   » Spelling temp.parent

Note that the spelling and punctuation of "temp.parent/" MUST be consistent! This phrase is used by VCS and extraction routines to identify candidate records.

   » Candidates loaded under temp.parents

Note that the Loader positions candidate records under temp.parents. Editors then move the records from temp.parents to the correct position in the hierarchy.

• Caveat: If you create a "temp.parent" that should not be published in the Candidate Report for contributors on the Web (e.g., if the children are intended for testing, deleted records, or otherwise should NOT be visible to contributors) set the Problem flag to Yes.

3.1.1.6.17

Order among siblings

   » Alphabetical order vs. forced order

Within a given level (i.e., among siblings), records are usually arranged alphabetically by the descriptor. In some cases, however, the order may be "forced" in order to display records by chronological or another logical order. See Sort Order below.

• Caveat: Consult with your supervisor before applying a forced order.

3.1.1.6.18

Views of the hierarchy by language

   » Vernacular view

The default view of CONA will be with the preferred title, generally an English language title. Implementors could display the records by a title in another language, provided the language is flagged to support this display.

3.1.2

Sort Order (required-default)

3.1.2.1

Definition
Number indicating the order in which a subject record will sort among siblings in the hierarchy.

3.1.2.2

Values
Numbers.

3.1.2.3

RULES

• For alphabetic sorting, leave the Sort Order as 1 for all siblings.
  
  
• For forced sorting, move the siblings up and down the list so that they will sort in the correct order. Numbers must be sequential.

3.1.3

Historical Flag: Current or Historical parents and other flags (required-default)

3.1.3.1

Definition
Flag indicating the historical status of the parent/child relationship, or another characteristic of the relationship.

3.1.3.2

Values
Hierarchical relationships are usually current or historical (flagged C or H), although others may occasionally apply.

• C - Current, H - Historical, B - Both, N/A - Not Applicable, U - Undetermined

3.1.3.3

Sources
Values are chosen by the editor from a controlled list.

3.1.3.4

Discussion
In CONA, the default is set to Current.

3.1.3.5

RULES

• Choose the flag appropriate to the relationship. The default flag for the relationship is Current. If the relationship is not current, change it to the appropriate flag, which will typically be Historical.
  
  
  • Current: For relationships that still exist, even though they may have been established long ago, use Current. Most records in the AAT have the flag set to Current.
    
    
  • Historical: For a historical relationship that no longer exists. Consult with your supervisor before using this flag.
    
    
  • Both: For a relationship that existed in the past, the relationship was severed, and then established again. Consult with your supervisor before using this flag.
    
    
  • N/A: Consult with your supervisor before using this flag.
    
    
  • Undetermined: This flag is used primarily for data that is loaded into VCS.

3.1.4

Dates for relationship to parents

3.1.4.1

Definition
Dates delimiting the relationship between the child and its parent. There are three fields: Display Date, Start Date, and End Date.

3.1.4.2

Values
Display Date is a free-text field; values may be any ASCII character; no special characters or diacritics are allowed; diacritics must be expressed according to the codes in Appendix A.

• Start Date and End Date must contain valid years, validated by VCS.

3.1.4.3

Sources
The dates should be determined using the same standard reference works that supply other information in the record.

3.1.4.4

Discussion
The Display Date usually refers to a period or date, however, it may sometimes contain notes that do not explicitly make reference to a date. In such cases, the note should implicitly refer to a date or datable condition or event, because you are required to include a Start Date and End Date with every Display Date.

• Display dates are indexed with Start Date and End Date. Start and End Dates are controlled by special formatting; dates BCE are represented by negative numbers.

3.1.4.5

RULES

• Dates are not required. However, if you enter data in any of the three fields, you must enter data in ALL three of the fields.
  
  
• The dates appear on reciprocal links. That means that the same dates will appear in BOTH records. Write the Display Dates and assign Start and End Dates so that they will be correct and unambiguous in both records. Repeat the names of the places in the Display Date when necessary to avoid ambiguity.
  
  
• A brief set of rules for Dates appears below. See also Appendix B and Dates for Names in Chapter 3.3 Titles/Names.

3.1.4.5.1

Display Date
A short set of rules appears below. For further discussion of Dates, see Appendix B.

• Follow the style of Display Dates in Appendix B.
  
  
  • Example
    
  • Display Date: added as a base to this work ca. 1875
    Start Date: 1875 End Date: 9999
    
    
• Do not use an initial capital, unless the word is a proper name.
  
  
• Do not use full sentences; do not end the display date with a period or any other punctuation.
  
  
• Ideally, the display date should refer, explicitly or implicitly, to a time period or date associated with the link between child and parent.
  
  
• If a date is uncertain, use a broad or vague designation (e.g., ancient) or words such as ca. and probably.
  
  
• In some cases, the Display Date may be used to record unusual or important information about the hierarchical relationship (see the example below), not even referring explicitly to a date. However, dates should be implicit in the condition or event mentioned and you should have a period or date in mind, because - if you record a Display Date - Start and End dates are required.

3.1.4.5.2

Start Date and End Date
Use dates that most broadly delimit the span of time of the relationship referred to in the display date. In many cases, the years will be approximate years. When in doubt, it is better to estimate too broad a span rather than too narrow a span. See the Date Authority in Appendix B for approximate dates of historic events and entities.

• Dates must be expressed in the proleptic Gregorian calendar, which is the Gregorian calendar projected back in time before it came into existence.
  
  
• Express dates BCE by negative numbers, using a hyphen before the number. Do not use commas or any other punctuation.
  
  
• For current relationships, use the End Date 9999.
  
  
• For very ancient dates, expressed as years ago or before present in the Display Date, translate these dates into approximate years in the proleptic Gregorian calendar for the Start and End Dates.
  
  

3.1.5

Parent String (required-default)

3.1.5.1

Definition
A listing of parents that may be used in displays to give context for parts, enclosed in parentheses following the title and other information.

3.1.5.2

Values
Preferred name and other names from the parents' records.

3.1.5.3

Sources
Values are automatically generated by the system.

3.1.5.4

Discussion
The Parent String is automatically concatenated by VCS or another application by an algorithm. Although the editor does not directly create parent strings, note that the choices you make for the preferred name, preferred English name, and Display Name affect the way in which parent strings are created.

3.1.5.5

RULES

• The rules for creating the Parent String and Label are applicable to the automated process only. Editors need be concerned only with creating records that will have the correct data required for the algorithm to create parent strings and labels.
  
  

3.1.6

Facet or Hierarchy Code

3.1.6.1

Definition
A special thesaurus code; not used in CONA.

3.1.6.2

Values
Empty in CONA.

3.1.7

Relationship Type for Hierarchy

3.1.7.1

Definition
Indicates the type of relationship between a hierarchical child and its parent, expressed in the jargon of controlled vocabulary standards. An example of a whole/part relationship is View of Siena is a part of Album of Drawings of Italian Hill Towns (CONA); Tuscany is a part of Italy (TGN). An example of genus/species relationship is calcite is a type of mineral (AAT). An example of the instance relationship is Rembrandt van Rijn is an example of a Person (ULAN).

3.1.7.2

Values
G=Genus/Species (generic), P=Whole/Part (partitive), I=Instance

3.1.7.3

Sources
Automatically generated by the system; edited by Vocabulary editor if necessary.

3.1.7.4

Discussion

• All values in CONA should be whole/part, unless otherwise indicated by your supervisor. Below are definitions of all types, for your information.

• Whole/part relationships: Also called a partitive relationship. A whole/part relationship is a hierarchical relationship between a larger entity and a part or component. In the context of cataloging art, it typically refers to a relationship between two work recordsor two records in a thesaurus (for example, Florence is part of Tuscany).
  
  Whole/part relationships are typically applied to works of art, geographic locations, parts of corporate bodies, parts of the body, and other types of concepts that are not readily placed into genus/species relationships. Each child should be a part of the parent and all the other ancestors above it.
  
  
• Genus/Species relationships: The genus/species or generic relationship is the most common relationship in the AAT, and in other many other thesauri and taxonomies, is the Genus/Species relationships.  All children in a genus/species relationship should be a kind of, type of, or manifestation of the parent (compare instance relationships below). The placement of a child may be tested by the all/some argument. In the example of bronze below, all architectural bronze is bronze, but only some bronze is architectural bronze.
  
  
• Instance relationships: In addition to the whole/part and genus/species relationships, some vocabularies may utilize a third type of hierarchical relationship, the instance relationship. This is most commonly seen in vocabularies where proper names are organized by general categories of things or events, for example, if the proper names of mountains and rivers were organized under the general categories mountains and rivers in a geographic database (TGN does not organize places in this way). The instance relationship may be utilized in the facets of the ULAN.

3.1.7.5

RULES

• Alter the default whole/part only in consultation with your supervisor..

^[1]Required-default" indicates that a default is automatically set, but should be changed by the cataloguer as necessary.

Last updated 16 September 2010
Document is subject to frequent revisions