Skip to end of metadata
Go to start of metadata

Structured Object Management Use Cases

SMK Use Cases - Hierarchical  Relationships Between Objects

To us the hierarchical relationships between objects have priority over the simple one to one relationships between objects and it is important that there is a clear distinction between the two types of relationships – easily readable in the UI.

At SMK we have two/three main types of hierarchical relationships between objects:

1. Works of art in multiple pieces (i.e. installation art, artist's books etc.)

The use case is similar to the sample use case "chess set and pieces" diagram on the Structured Objects Management Requirements page.

When cataloguing a work of art in multiple pieces one first creates a cataloguing record for the collected work of art. This work of art gets an inventory number (object identification number) assigned to it. And from this work of art each part is created and recorded in separate cataloguing records. Each part is assigned a serial number added to the inventory number of the collected work. If required data are inherited from the collected work of art to its parts, or from one part to the next, and off course editing is possible in each record.

Regarding location and movement information, the collected work of art has no location assigned to it but each of its parts does. When moving, all parts can be moved collected (batch processing) or each part individually.

Note: A part may have a verso (back) and in that case the verso is subordinated the recto (front) part:

Work of art (inv. no.: xxxx)

      Part 1 (inv. no.: xxxx-1)

      Part 2 (inv. no.: xxxx-2)

            Part 2 verso (inv. no.: xxxx-2 verso)

      Part 3 (inv. no.: xxxx-3)


Hierarchy: Work of art in multiple parts (primary); part of (secondary); part of – verso (third)


2. Recto – Verso

For mainly works of art on paper (drawings, prints etc.) and more rarely in paintings there may be an independent work of art on the backside of another work of art. In these cases the front is called recto and the back is designated verso. The relationship between the two sides is hierarchical.

The work of art on the recto is recorded first and assigned an inventory number (xxxx) and only when the recto is recorded the verso can be recorded/created from this in a separate cataloguing record. The inventory number of the verso is the same as the recto but with "verso" added to it (xxxx verso). If required data from the recto can be inherited to the verso.

Regarding location and movement information, the recto and verso are always located and moved together.

Hierarchy: Recto (primary); verso (secondary)

3. Plaster Cast – Original

Hierarchical relationship similar to the Recto – Verso (see above), the original (work of art) is subordinated the plaster cast. Typically the cast is part of our collection while the original belongs to, or is administered by an external organization.

Regarding location and movement information, only the plaster cast will be assigned a location (the location of the original will always be an external location).

Hierarchy: Plaster cast (primary); original (secondary)

UCB sub-objects user stories for prioritization


Sub-objects: From the natural history domain, a tissue sample is taken from a fish and is subjected to (genomic) sequence analysis.  Both the original fish and the tissue will be proper objects with storage locations and so on, with the fish obviously being the parent of the tissue.

Sub-objects: From herbaria, the large fruit or cone of a dried specimen could be stored separately from the specimen sheet.

PAHMA sub-object user stories

Example 1 (simple):

• A pair of shoes is cataloged as "Object 1"

• The right shoe is made a sub-object and is called "Object 1a"

• The left shoe is made a sub-object and is called "Object 1b"

Example 2 (typical):

• In addition to the pair of shoes above, a shaman's complete outfit (including shoes) is cataloged as "Object 2"

• The jacket is made a sub-object and is called "Object 2a"

• The shirt is made a sub-object and is called "Object 2b"


• The shoes are made a sub-object and are called "Object 2g"

• The right shoe is made a sub-object and is called "Object 2g.1"

• The right shoelace is made a sub-object and is called "Object 2g.1.2"

• The shoelace has seen better days and is now in 3 non-joining parts

• The aglet of the right shoelace is called "Object 2g.1.2.2"

Example 3 (complex):

• A single male individual died and was buried in a grave

• That grave dug for the individual was dug on top of another, older grave of a female

• The two graves experienced taphonomic modification via bioturbation (i.e., burrowing animals mixed things up)

• Archaeologists later excavate the site and recover the two burials, but do not fully separate the two, partially commingled individuals

• Two sets of remains are each given their own object number when cataloged in the museum ("3" & "4")

• Upon curatorial review years later, both object numbers are found to include parts of two individuals: one male, one female.

• Each of these intra-object individuals is made a sub-object (so 4 sub-objects between the 2 object numbers: "3a", "3b", "4a", & "4b")

• There are two ways to group these: [(3a + 3b) = 3, and (4a + 4b) = 4] or [(3a + 4a) = remains of person X, and (3b + 4b) = remains of person Y]

• After further curatorial work, the individual bones are given their own numbers (3a.1, 3a.2, 3a.3, etc.) [let's say 50 each for 3a, 3b, 4a, 4b]

History of Art Visual Resource Collection

  • Significant number of work records have component relationship (10%-15%).  E.g., a Japanese screen will have multiple panels.  The screen and each panel need work records; image records will potentially be associated with the the screen, each panel, or even two panels (requiring a many-to-many relationship). Manuscript and its leaves will get work records.
  • No labels

1 Comment

  1. HAVRC complex works (works with multuiple discrete parts) are modeled very much like the SMK objects described above.  

    HAVRC manuscripts are currently modeled in the same way, except that recto and verso of the manuscript page each gets its own component_id, e.g.

    123456  work_id for the manuscript as a whole

    123456.5  work_id+component_id  for page 5 recto

    123456.6  work_id+ component_id for page 5 verso

    We could follow the SMK model for treating recto and verso if we could import and transform the existing data to reflect this model and use it going forward.