I think this should be controlled by an Authority, and Object Packages may have multiple values. For instance, our Conservation Department have and share multiple Object Packages with each other, but that Object Package may be involved with a particular project, so there would be a desire to have that package available in both groupings.

Chad Petrovay  |  Collections Database Administrator
MIM-Musical Instrument Museum | 4725 E. Mayo Boulevard  | Phoenix, AZ 85050
480.478.6000 main  |  480.478.6058 direct | 480.471.8690 fax  | www.themim.org

Blog: www.petrovay.com/tmsblog


From: The Museum System (TMS) Users [mailto:[log in to unmask]] On Behalf Of Jay Hoffman
Sent: Friday, July 30, 2010 11:41 AM
To: [log in to unmask]
Subject: Re: Object Package Names

I was thinking the same thing. It could be organized by owner, project (a new field), global, etc.  How do you see the hierarchy groupings?

From: The Museum System (TMS) Users [mailto:[log in to unmask]] On Behalf Of Ryan Donahue
Sent: Friday, July 30, 2010 11:27 AM
To: [log in to unmask]
Subject: Re: Object Package Names

We are actually looking at this problem now, folders would be a really welcome addition to object packages (that is to say, a hierarchical organization for object packages).

Our present plan is to expose a web interface for un/archiving object packages on demand (we already have such an interface for transferring object packages to our DAM).

My other thought was to treat global object packages like a communal fridge -- periodically (2x year?) turning all global object packages (with some exception) non-global, and letting people bug my department when they need it (or use the web interface) to turn object packages back on.

-Ryan Donahue
George Eastman House