Needed by whom and when
Basic statements about who needs the functionality and by when.
PAHMA and HAVRC have some critical requirements due to data in their current system (components are children of objects and are used extensively by PAHMA) and generally because many objects need to be modeled with complex parent-child relationships. UCJEPS would also use this but does not have information about children currently.
Overview
PAHMA and HAVRC collections need to be modeled with a object/sub-object parent-child capability. Chess pieces are parts of chess sets. Shoes are part of costumes. But also, a box of objects left on the step is the parent of contents that are described later. A Japanese scroll has three screens that require separate work (object) records; the scroll does as well of course. Question: Should the box-of-objects example (related perhaps more to information workflows) be modeled in the same way as chess pieces? Perhaps not, but initially at lot of PAHMA records will look like this (so we might as well get used to it).
Children should inherit some information from their parent records. Question: Is inheritance only a matter of simplifying data entry (so that some fields are automatically populated when you create a child from a parent)?
An important complexity of this is related to counting and searching expectations. Is it fair to assume that we can justify one way of counting parents and children? Does search need to offer the ability to show or hide child records? Is it OK to assume that you find any successful match (whether the match is a parent or child), and then if you go to the object, you can see if there are related records? You could end up double-counting some things (the chess set and its chess pieces) but most systems probably behave like this anyway.
Susan: This special object-object relation needs to be modeled so that loans, storage, etc. is of the more granular subobjects and searching for objects and subobjects does good things. Needs special functionality rather than just relating. Need user stories here.
Michael: Sub-objects have all of the same information associated with them as objects (because they are objects), and they should be treated as full objects in their own right. A sub-object is a child of another object (the relationship should be symmetrical), and should by default inherit nearly all properties, associations, and values that the parent has (one exception would be dimensions), although all of these inherited values should be overridable. A sub-object cannot merely be an object related to another object with an association type of "child" because of problems that would arise with object counts, other collection statistics, and the presentation of search results. CSpace will need to intelligently handle sub-objects and objects.
UCB sub-objects user stories for prioritization
UCJEPS
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.
Prioritization of user stories
As definitions and priorities are clarified, the user stories above should be moved into relative order below.
Must have for 1.x-MUSEUM (when they go live in system)
Placeholder for required functionality. As a general rule, functionality that you need and use now should go here or where you have existing data. However, this is up to the museum. We will have to balance requirements against resources and timelines.
Placeholder
MUSEUM could wait six to twelve months
What could wait? These will be re-prioritized at a later date.
Placeholder
MUSEUM would like to have this eventually
These are nice to have but not a near term requirement.
Placeholder