3

EDITORIAL RULES

3.1

Hierarchical Relationships

• Note: Although the hierarchical relationships in ULAN are not as evident as in AAT or TGN, it is still important to understand how they work because ULAN is structured as a thesaurus.

Included in this chapter

• Parents (required)
• Sort Order (required-default)
• Historical Flag (required-default)^[1]
• Dates for relationship to parents
• Parent string (required-default)
  
  
• Example
  [as displayed to end-users on line]

3.1.1

Parents (required)

3.1.1.1

Definition
The broader context(s) for the artist record; parents refer to Hierarchical Relationships, which are broader/narrower, reciprocal relationships between records. In ULAN, Persons have hierarchical relationships only to the facet; Corporate Bodies may have greater hierarchical depth.

3.1.1.2

Fields

• 1. Parent: The parent_key is the numeric Subject ID of the preferred parent (e.g., 500000002). The records for the child and parent are linked by their ID. When an editor places a record in a hierarchy in VCS (under Person facet or Corporate Body facet), 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 artist record may have only one preferred parent. Values are P[referred] and N[on-preferred]. It is rare in ULAN that a record will have a non-preferred parent.
  
  
• 3. Preferred Display Biography: Text field typically listing the nationality, roles, and life dates of the person or corporate bodies. Used in displays with the name to identify the person or corporate body.
  
  
• 4. Parent String: A display generated by the system by concatenating the names of the immediate parent and other ancestors. The parent string appears in VCS to provide context. It is also part of end-user displays for TGN and AAT, however, in ULAN, the preferred display biography is generally used instead.
  
  
  • Example
    [from the VCS Subject Edit window for ADAG]
    

[from the VCS Hierarchy View for ADAG]

3.1.1.3

Values

• Values are concatenated automatically by the system, using the preferred name, display biography, and appropriate indentation.

3.1.1.4

Sources: Warrant for the hierarchical divisions

3.1.1.4.1

For levels of hierarchical division
In building the hierarchy of a corporate body, look at authoritative, official sites about the corporation. For workshops, studios and other corporate bodies that are not modern corporations, use authoritative scholarly sources.

3.1.1.4.2

For the preferred names of subdivisions
For the preferred names for the subdivisions, be consistent regarding transliteration method, syntax, punctuation, capitalization, and style. If possible, use the same source for both 1) constructing the hierarchy and 2) for the determining the preferred names for the subdivisions.

3.1.1.4.3

List of Sources
Sources for the hierarchical structure may include the following:

• Encyclopedia on art history.
• Authoritative Web sites for corporations, listing their official subdivisions.

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.
  
  
• The hierarchy in ULAN refers to the method of structuring and displaying the records within their broader hierarchical contexts. Although the hierarchy is not evident in many ULAN displays, it forms the basic structure of the data.
  

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: The ULAN root, named Top of the ULAN list/hierarchy, is the highest level of the hierarchy (the so-called root). Person, Corporate Body and various candidate hierarchies are facets below the Root.
  
  
• Hierarchical displays are system-generated. Given that there are so many records at the same level in the hierarchy, the hierarchy was designed to display as an alphabetical list. Click on the letter of the alphabet to display the persons or corporate bodies at that level. Note: These alphabetical codes are not part of the hierarchical structure or in any way coded in the data; they are generated after the data is extracted from VCS and are purely for display.
  
  
  • Example

• 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.5.2

Depth of the hierarchy
The ULAN hierarchy is typically very shallow. All persons are placed directly under the Person facet. Corporate Bodies are placed directly under the Corporate Body facet, although there may be levels of administrative subdivisions for some corporate bodies.

• Example
• [partial display for a manufactory]
  

  Top of the ULAN list / hierarchy
  .... Corporate Body
  .......... Sèvres Porcelain Manufactory (French porcelain factory, active from 1756 to the present)
  .................... Eloy Brichard company (French porcelain makers, established 1740)
  

3.1.1.6

RULES for creating hierarchical relationships

3.1.1.6.1

Minimum requirements

• System rules: Subjects are arranged hierarchically through the link of each artist record to its parent; the root record has the preferred parent of itself.
  
  
• Editorial rules: It is required to position a new artist record under the Person or Corporate Body facet.
  

3.1.1.6.2

Choosing the parent
Position the individual artist under the Person facet. Position the corporate body under the Corporate Body facet, with the following exception: If the record is for a subdivision of a larger corporate body, place it under the correct level of that corporate body.

   » For Persons

Caveat: Persons may not have hierarchical relationships in ULAN, other than the link to the Person facet. Do not use hierarchical relationships to create family trees or relationships between workshops and its members. Instead, these are associative relationships in ULAN (see 3.6 Associative Relationships).

   » Consistency within a corporate body

Be consistent. If you enter one subdivision of a corporate body, you must enter them all.

• Example
• Top of the ULAN list / hierarchy
  .... Corporate Body
  ....... National Gallery of Art
  ........…..Center for Advanced Research in the Visual Arts
  ............. Department of American and British Paintings
  ............. Department of Exhibition Programs
  ............. Department of French Paintings
  ............. Department of Italian Paintings
  ............. Department of Modern and Contemporary Art
  ............. Department of Northern Baroque Paintings
  ............. Department of Old Master Drawings
  ............. Department of Old Master Prints
  ............. Department of Photographs
  ............. Department of Sculpture and Decorative Arts

3.1.1.6.3

Multiple parents
ULAN is polyhierarchical. Corporate Bodies in ULAN may be linked to multiple broader contexts (i.e., multiple parents). In rare cases (e.g., with historical relationships), a corporate body may have multiple broader contexts. Consult with your supervisor before assigning multiple parents.

   » Preferred parent

One parent must be flagged as preferred. Make a preferred relationship to the parent that best fits the criteria as described in the cases below.

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

3.1.1.6.4

Positioning under a Candidate level/Temp. parent

   » When the specific level cannot be determined

If a record does not have enough information to be published, put the record under a candidate level (temp.parent), pending further research. This typically happens with contributed records, not with records that you are creating from scratch.

• Example

   » 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 entities in the hierarchy, do research and endeavor to move records to publishable parts of the hierarchy, as far as time, priorities, and editorial priorities allow.

   » 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

   » 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 you create a temp.parent for children intended for testing, deleted records, or otherwise should NOT be visible to contributors), set the Problem flag to Yes.
  

3.1.1.6.5

Order among siblings

   » Alphabetical order vs. forced order

Within a given level (i.e., among siblings), divisions of corporate bodies are nearly always arranged alphabetically by the preferred name. However, the order may be "forced" in order to display the divisions by another logical order (e.g., chronological) if necessary. If you feel this is necessary, consult with your supervisor.

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 set to "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 (required-default)

3.1.3.1

Definition
Flag indicating the historical status of the parent/child relationship.

3.1.3.2

Values
Hierarchical relationships are usually current or historical (flagged C or H), although others may occasionally apply. In the list below, the three last relationships (Part/Whole, Genus/Species, Generic ) are temporarily being stored here; in the future, they should be placed in a separate field.

• C - Current, H - Historical, B - Both, N/A - Not Applicable, U - Unknown
  
  
• Part/Whole, Genus/Species, Generic
  
  
  • Example
    [for the Foundation for Documents of Architecture]

3.1.3.3

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

3.1.3.4

Discussion
The primary purpose of this field is to flag historical relationships. It should also be used to flag any rare genus/species relationships in ULAN (most relationships in ULAN are part/whole and need not be flagged). For examples, see Dates below.

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.
  
  
• Historical: For a historical relationship that no longer exists, typically because the broader entity or child is no longer extant, use Historical.
  
  
• Both: For those rare relationships where a corporate body was part of a larger entity for a while, was separated from that entity, and at a later time was again part of the larger entity, use Both.
  
  
• N/A: Use N/A if Current or Historical are not appropriate to the situation. This would be a very rare circumstance. Consult with your supervisor before using this flag.
  
  
• Unknown: This flag is used primarily for data that is loaded into VCS. Editors should avoid using Unknown because whether the relationship is current or historical is typically knowable (even if it is currently unknown by the editor due to lack of proper information). If you feel that Unknown is appropriate in a given situation, consult with your supervisor; it would be highly unusual for an editor to know enough to make the relationship, but not enough to know if it is current or historical.
  
  
• Part/Whole, Genus/Species, Generic: Do not use these flags, unless you have a genus/species relationship, which is very unusual. Consult with your supervisor before using this flag.
  

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. See example above.

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, as in the example below.
  
  
• Brief rules appear below. For additional rules regarding Dates see Appendix B and Dates for Names in Chapter 3.3 Names.

3.1.4.6

Display Date

• Follow the style of existing Display Dates.
  
  
  • Example
    [between child Pietra Dura studio and parent Gobelins]

• 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, in the example below) 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.6.1

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; you should also consult other, related records in ULAN to establish dates.

• Start and End 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 using negative numbers, using a hyphen before the number. Do not use commas or any other punctuation.
  
  
• For current relationships, use the End Date 9999.
  

3.1.5

Parent String (required-default)

3.1.5.1

Definition
A listing of parents.

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. In ULAN displays, the Display Biography is often substituted for the Parent String.

3.1.5.5

RULES

• The rules for creating the Parent String and Label are applicable to the automated process only.
  

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

Last updated 28 March 2006
Document is subject to frequent revisions