A couple of things; first, the numbering that Cathryn is talking about wouldn't typically ever be used as a file name. The CMS would almost certainly parse this number in some reasonably effective and sortable way.
Second, since what Cathryn describes is what we do at my institution, I'll assume it's pretty typical, and vouch that it works fine for the lion's share of circumstances. The second method described (assigning separate numbers and defining relationships among the records) is probably better, for reasons I'll mention below, but leaves you with that business of creating a record for the group. And, since the only kind of record most CMS's are going to let you create is an accession group, you have to choose a number that represents an accession.
We've been struggling with this concept at my workplace too. The problem is that an accession number is supposed to describe a transaction, not a collection of related items. The fact that in 9 out of 10 cases, the related items are part of the same accession tends to disguise this problem. But what if the various parts of the tea set come from different sources at different times? A group accession record isn't going to help very much with that. Will's question interested me in particular because he speculated about using some manuscripts cataloging techniques and that's exactly what we're gearing up to institute here. There's a concept in manuscripts cataloging called a "Reference Code" which is defined in ISAD(G) as a numbering system designed primarily to identify your institution, but also allows you to use the same numbering system to define collections or "themes" within your holdings in a hierarchical fashion. The top level record would describe the collection scope and the children are defined by "pointing-out" the numbering. That leaves you free to use the accession numbering for what it's supposed to do (and this makes audit time a lot
easier) at the same time that you can define multiple themes or formal collections within your holdings.
Sounds complicated Mr. Goodwrench! We aren't there yet, but our software let's us do this and that's the plan!
Chuck Patch
Historic New Orleans Collection
I am curious to see if there is any consensus in the museum community regarding the cataloguing of objects with part/whole relationships. I realize there are countless permutations of this situation, but the prototypical example in our institution is a tea set. The tea set contains various components--teapot, cups/saucers, sugar bowls--which themselves are composed of parts--the sugar bowl lid and the bowl itself; the cup and its saucer, the teapot and its stand, etc.
We are about to implement a new collections management system (KE EMu) and currently our strategy is as follows:
1. Catalogue the various components as individual items--the pot, the bowl, the cups/saucers, all with unique numbers (2001.2.1, etc.). The components would be linked to eachother in the database as Related Objects 2. Catalogue the parts of a component in a Child relationship to that component's record--the bowl and lid, the cup and saucer, etc., all designated with letters (2001.2.1.A, etc.)
We are not sure what to do about the ensemble of all the components--the tea set as a whole. It currently does not have a catalogue number, but we can imagine the usefulness of having a record for the set, in a Parent relationship to each individual component. If we do this, we have to give the set itself a unique number, or refer to it by the range of numbers it includes (2001.2.1-10), or employ a totally new (for our institution) cataloguing level, more like a scope note or folder-level record, as might be typical in a catalogue of archival material, for example.
Perhaps this is a query for the AAM Registrar's Committee listserv (is anyone out there a member who would be willing to post it on my behalf?). However, if any of you have some ideas on the matter we would be interested to hear them.
William Real
Director of Technology Initiatives
Carngie Museum of Art
412-622-3267
---
You are currently subscribed to mcn_mcn-l as: [email protected]
To unsubscribe send a blank email to [email protected]
You are currently subscribed to mcn_mcn-l as: [email protected]
To unsubscribe send a blank email to [email protected]
