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)
• Hierarchy Relationship Type (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. There are five facets in ULAN: Persons, Artists; Corporate Bodies; Non-Artists; Unidentified Named People; and Unknown People by Culture. In ULAN, most facets have hierarchical relationships only to the facet; Corporate Bodies facet 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 a 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; biographical dictionaries, archives and other original documentation.
  
  
• Museums sites, 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). Persons, Artists; Corporate Bodies; Non-Artists; Unidentified Named People and Firms; Unknown People by Culture; 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

Major Subdivisions: The Facets

>>Corporate Bodies

Records under this level represent corporate bodies, defined as two or more people working together. The primary focus of this facet are groups that create or produce art or architecture.

Corporate bodies must be organized, identifiable groups of individuals working together in a particular place and within a defined period of time, including legally incorporated entities, such as a modern architectural firm (e.g., Adler and Sullivan) as well as entities that are not incorporated, such as a 16th-century sculptors' studio or family of artists may be recorded as a corporate body (e.g., della Robbia family).

A workshop may be included if the workshop itself is a distinct personality collectively responsible for the creation of art (for example, the 13th-century group of French illuminators, Soissons Atelier). Also included here are museums and most other repositories. Additional corporate bodies required to catalog art may be included here.

Built works are not included here, even if they have the same name as the corporate body housed within them (e.g., National Gallery of Art). The built work named "National Gallery of Art" should be recorded in CONA, not ULAN.

>>Persons, Artists

Records under this level represent individuals involved in the creation or production of works of fine art or architecture, for example painters, sculptors, printmakers, and architects. Included are individuals whose biographies are well known (e.g., Rembrandt van Rijn (Dutch painter and printmaker, 1606-1669)) as well as anonymous creators with identified oeuvres but whose names are unknown and whose biography is surmised (e.g., Master of Alkmaar (North Netherlandish painter, active ca. 1490-ca. 1510)).

Craftsmen, artisans, engineers, and others who create visual works are included here, even if their works are not considered fine art per se. People whose primary life roles were other than "artist" or "architect," but who created or designed art or architecture in a professional or amateur capacity, are included here with a non-preferred link to this facet (e.g., Thomas Jefferson (American statesman, architect, 1743-1826)). Performance artists are included here.

>>Non-Artists

Records under "Non-Artists" comprise personal names and biographies required for cataloging art and architecture, but where the people are not artists who produced art or architecture. Included in this facet are important donors, patrons, rulers, sitters, art historians, and others whose names are required for indexing art works but who are themselves not artists.

Although the occasional non-artist patron had always been included in ULAN, separating these records into a separate facet became necessary when ULAN was used to control values in CONA, which covers not just artists but also sitters and patrons.

>>Unidentified Named People and Firms

Records in this facet represent people named in original documents, but where the reference is ambiguous and thus no biography or secure identification of the person may be made. May also include records for firms that are named but the identity is unknown. The name has usually been found in archival documents. Often the document may mention only a first or last name, thus hampering or prohibiting identification. For the people in this facet, no scholarly appellation has been attributed and no assessment of their oeuvre has been made (if either of these criteria is met, the record would be for an anonymous master who should be included in ULAN “Persons, Artists” facet).

The names in the “Unidentified Named People” facet are often flagged as for "local use": due to the ambiguous nature of their identity, they should be omitted when ULAN is used for indexing or incorporated in a broad retrieval application.

>>Unknown People by Culture

"Unknown people people by culture" comprise appellations referring to generic culture or nationality designations that are typically used in cataloging to record unidentified creators with unestablished oeuvres, such as unknown Mayan or simply Mayan. (The terms in this facet may also be used for anonymous people other than artists.) The appellation for creation in this context refers to the culture in which the work was created, not necessarily to the nationality or culture of the individual artist (who is by definition unknown).

The generic "unknown" designation does not refer to one identified, if anonymous, individual; but instead the same heading refers to any of hundreds of anonymous, unidentified artistic personalities. Although ULAN includes designations for these unknown artists, in this case each ULAN record does not represent a single individual.

"Anonymous" creators, who according to CCO and CDWA represent one person and have established oeuvres and estimated life dates, are recorded with pseudonyms or other appellations (e.g., Boucicaut Master) in the ULAN Person facet. Note that some repositories call "unknown" artists "anonymous"; thus a variant name for unknown artists in ULAN include the word "anonymous," even though "anonymous" is defined differently in ULAN and related standards (CCO, CDWA).

3.1.1.5.3

Depth of the hierarchical relationship
The ULAN hierarchy is typically very shallow. All persons are placed directly under the Persons, Artists; Non-Artists; Unidentified Named People; or Unknown People by Culture facets. 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. 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.

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; text may be expressed in Unicode and numbers representing dates.
  
  
• Start Date and End Date must contain numbers representing 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.
  

3.1.6

Relationship Type for Hierarchy

3.1.6.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 Tuscany is a part of Italy (TGN); a department is part of the larger museum (ULAN). 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.6.2

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

3.1.6.3

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

3.1.6.4

Discussion

• Whole/part relationships: Also called a partitive relationship, is used for relationships between parts of institutions and their broader context in the corporate body facet of ULAN. A whole/part relationship is a hierarchical relationship between a larger entity and a part or component. In ULAN, an example is that the Department of French Paintings is part of the larger National Gallery of Art.
  
  Whole/part relationships are typically applied to 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.
  
  
• Instance relationships: This is the most common type of relationship in ULAN, existing between all immediate children of a facet. The instance relationship is most commonly seen in vocabularies where proper names are organized by general categories of things or events, for example, if the proper names people or corporate bodies are placed under generic headings, such as the facets Person and Corporate Body.
  
  
• 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.

3.1.6.5

RULES

• Values we automatically supplied when the data is loaded. If the type is incorrect, correct it.

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

Last updated 28 September 2015
Document is subject to frequent revisions