Hi there,
I've been pretty vocal on my thoughts about components. I'm the opposite of what you are looking for - we do not use them and we do not love them. They were more trouble than they were worth, for us anyway. There are too many limitations on components, and it seems like any time we try to create a component, we end up needing a feature that components do not have. You can't give them separate values, and there's an issue with including them in loans - it might be crating, I honestly can't remember.
A lot of this has to do with the nature of our collection. You might think creating a component record for the lid of a teapot is a safe bet - who in their right mind would do an exhibition of just teapot lids? Trust me, someone is going to do that exhibition and they're going to try to borrow that teapot lid from us. Or perhaps a more believable example - what if the teapot lid is broken and needs to go out for conservation? And that's when components go wrong for us.
Another issue with components is that the user now has to look in multiple places to figure out exactly what comprises a full object. A tea service is a great example. Maybe you have object records for the teapot, cups and saucers, etc., and you use parent/child records to build the relationships between the objects. But then you also have the teapot lid buried under components. Someone has to know to look at the related objects tab as well as the components tab.
And as you pointed out, there's the issue of components vs. reports. For us to use components in TMS would mean creating more work for ourselves in terms of writing reports (and cleaning up old ones).
For us, our collection, and our staff, sticking with parent/child records has been the easiest. It's cleaner, more obvious, and doesn't really take any extra effort as opposed to creating components. It means we always have the full usability of an object record for anything we catalog.
I'm sure there are museums out there that use and love components. There are pros and cons. Obviously in my experience it's been mostly cons. I'm not trying to cut down a feature of TMS, but if anyone out there hasn't implemented components yet, you might want to consider some of these issues and whether or not they'd be a challenge for your particular institution.
Best regards,
Amber
the warhol:
Amber E. Morgan
Collections Manager
117 Sandusky Street
Pittsburgh, PA 15212
T 412.237.8306
F 412.237.8340
E [log in to unmask]
W www.warhol.org<http://www.warhol.org/>
The Andy Warhol Museum
One of the four Carnegie Museums of Pittsburgh
Email newsletter http://members.carnegiemuseums.org/email
Membership http://members.carnegiemuseums.org/SupportCMP
warhol: facebook<http://www.facebook.com/thewarholmuseum> | warhol: twitter<http://www.twitter.com/thewarholmuseum>
From: The Museum System (TMS) Users [mailto:[log in to unmask]] On Behalf Of Marin J. Lewis
Sent: Wednesday, February 11, 2015 3:50 PM
To: [log in to unmask]
Subject: Parent/child records vs. components
Hello TMS users!
We're in the process of reviewing our cataloging procedures surrounding components. Our internal conversations end up in an infinite loop between when to create component records and when to create a series of parent/child records. We're wondering where other institutions stand, and how you make decisions between creating multiple object records vs. components in a single object record? From tea service sets, to contemporary installations with a dozen different pieces, to simply things stored on different shelves ... we're wondering about it all.
We'd especially like to hear from those that use and love components as their primary way to track multiple pieces of objects. Can you share (offline) your cataloging guidelines, and also samples of reports that display component information? A big struggle with us has been how to handle components on reports and we'd would love any feedback.
Many thanks!
Marin & Maddie
Princeton University Art Museum
[log in to unmask]<mailto:[log in to unmask]>
[log in to unmask]<mailto:[log in to unmask]>
To unsubscribe, send an email to [log in to unmask]<mailto:[log in to unmask]> with the following commands in the body of the email:
signoff TMSUSERS
// eoj
You will receive a confirmation that your subscription has been removed.
The information contained in this message and/or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. Any views expressed in this message are those of the individual sender.
To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:
signoff TMSUSERS
// eoj
You will receive a confirmation that your subscription has been removed.