PAHMA poem on objects, parts, sets, and their parent child etc relationships
On Mar 18, 2010, at 11:22 AM, Marlita Kahn wrote:
Hi all,
Michael and I have been corresponding about collection events and the way PAHMA and other museums deal with objects, parts, sets, and their parent/child/etc relationships particularly as they pertain to tracking sets of objects collected and catalogued over time. I am forwarding Michael's eloquent rendition of the challenge and desired solution.
Begin forwarded message:
From: "Michael T. Black" <mtblack@berkeley.edu>
Date: March 17, 2010 1:08:51 PM PDT
Subject: Re: [confluence] CollectionSpace > Collecting Event Authority Schema
I'm so glad you asked about objects and sub-objects in relation to the schema. This is a critical area for PAHMA and, I'd guess, many other museums.
In the biological sciences, specimen [=object] numbers are usually assigned in accordance with any sort of available natural (=biological) organization. So rather than give each bone (or set of bones) found its own object number, the scientists, collectors, or curators responsible for assigning numbers will group together any pieces that are almost certainly from the same biological individual. Even if one of the bones to a skeleton was recovered a year or more later, if it clearly belongs to an already cataloged specimen, it gets that already assigned object number (albeit with its own suffix).
There are many cases, though, in which determining what goes with who is not a straight-forward matter, so each bone found is assigned its own object number. Then, at some later point, scientists may determine that AT-1006 belongs to the same individual as AT-537 and AT-23, and they will often create a grouping construct called "Individual 4" that brings these pieces together, at least in a printed manuscript, if not in the collection management system.
In our Museum, we have all sorts of unorthodox (but common across museums) hanky-panky going on in the cataloging, for any number of reasons, but usually because the person assigning the object numbers wasn't an expert or experienced with the type of material being cataloged. Thus, we have single catalog numbers that comprise large numbers of questionably (or non-) associated objects (grouped together because they came in on the same day or were collected by one person at one site, or whatever). In these cases (for instance, with bones), we may find that the arm bones found in one object number belong to the same individual as the shoulder bone in another catalog number, or we may find that what was thought to be one skeleton is actually parts of multiple skeletons.
In the case of one object number containing commingled, but separate, individuals or items, we want to distinguish the individuals or items from each other. In the past, we've sometimes done that by assigning new catalog numbers to those objects, but that often just creates as many problems as it solves, given that the objects now have two numbers written on them and our collection management system doesn't do a great job of tracking what used to be numbered what and why it was changed.
What we do now is suffix the object numbers to create sub-objects. This works as long as there's only one level to sort out below the object number. What happens when you get three commingled skeletons all called PAHMA 12-34501, though? Call one "12-34501A", another "12-34501B", and another "12-34501C" (or, as some have done, leave one called "12-34501" and then create a "12-34501A" and a "12-34501B"). But then you have three numbered skeletons, each of which have hundreds of fragments which constitute many dozens of separate bones? Do you call the humerus of one "12-34501A-7"? What if the humerus is in seven pieces? Is the fourth piece "12-34501A-7-4"? It's a mess.
The approach I'd like to see CollectionSpace take is to allow an infinite number of sub-objects and levels of sub-objects, as well as an infinite number and levels of grouped objects. We have an "object" in our collection that is cataloged as something like "150 mounted, signed, and titled photographic prints by Xxxxxxx" (fine for an accession, but horrid for a cataloged object). In TMS, we have this one object that has a general name, general description, general title, etc., and then we've made each of the individual suffixed prints into a "component" object with their own specific names, descriptions, titles, dimensions, etc. The problem with components in TMS is that they are not handled in the same fashion as objects. They should just be sub-objects of a parent object, entitled to all the fields that any object is entitled to (that's what I'd like to see in CSpace). Instead, the components table is a separate table, so any search for a object name has to be done on Objects.ObjectName *and* Components.ComponentName. Additionally, the Components table has less than 10% of the fields that Objects does, so you can't enter a title for a component in a proper Title field; you have to enter it in the general description or notes fields, making searches even harder. Besides these two major problems, there can be no sub-components [or super-objects]. Only objects and components, period. A deeply flawed approach that I hope CSpace will not adopt.
There should just be an objects "table" and an 'Associations' "table" that says that Object 1 is the [fill in the blank: parent, child, sibling, etc.] of Object 2 (with symmetry, of course). Then you could have an object that is really the sub-object of a sub-object of a sub-object of another object. And when you search, you can choose [or set a default for] whether you want to return only relevant [sub-]objects, relevant [sub-]objects with their [preferred?] parent object, or just [preferred?] parent objects.
On Mar 15, 2010, at 3:43 PM, Michael T. Black wrote:
Two examples [of an object having mulitple field collection methods] that I've encountered are:
1) You're walking along the outcrops and see a part of a fossil monkey skull. It's a nice diagnostic fossil in good condition, so you make your collection notes and collect the fossil, noting that the collection method is "survey". When picking up the fossil, you notice fresh breaks that indicate that there be more of the fossil to be found. A little crawling yields a few more pieces of the cranium (still listing "survey" as the collection method), but you notice that these pieces also have fresh breaks and that none of the breaks on the pieces match up to any of the other pieces you've found so far. Given the number of fragments you've collected and the number of unaccounted-for fresh breaks, you decide that a limited excavation is warranted. In the process of excavation, you find most of the rest of the skeleton of what turns out to be a single monkey skeleton. The field collection method on these latter pieces is "excavation." One individual, so one object number, but two different field collection methods.
2) While excavating his assigned square a little too quickly, your student finally realizes that he's just blasted through a beautiful example of a refittable cluster of core preparation flakes. He calls you over and you tell him to slow the hell down and be more careful and to excavate the remainder of the cluster in situ (field collection method: "excavation"). A bit too late for the first parts of the cluster he encountered, but no huge worries, as they'll come up in the screening of the soil from his level (field collection method: "dry screening"). Again, one [reassembled] object, but two different field collection methods.