The Yale Center for British Art and the Yale University Art Gallery at Yale University have moved away from using the accession# and its inherent problems in favor of a naming convention derived from the objectID field in TMS, which is just the sequential number field assigned by the database each time a new object record is added to TMS.
I'm sure all the other collection management systems use a sequential numbering system as well. This number is used by the collection management system to link the appropriate records from other tables to the object record since the number never changes. The beauty of this system is its structure, which allows you to automate file creation and retrieval by other programs other than TMS. Also, it allows you to retain a link to the TMS object even though the accession# may change over time. Besides needing a better image naming convention than the accession#, we developed this structured naming convention for use with a recently installed enterprise level DAM at Yale University. The structured image# allowed us to develop software that automated the TMS and DAM ingest of new images. Here is a breakdown of our image naming convention. I will supply further details on request. Museum - TMS module - objectID - index - image type . suffix ba-obj-60395-0003-pub.tif YCBA example (we like the idea of a 4 digit index) ag-obj-4487-001-mas.tif YUAG example (Art Gallery is happy with a 3 digit index) Museum is ba for YCBA and ag for Art Gallery. TMS module can be obj for object or exb for exhibition module. ObjectID is the sequential record# in the object table. The exhibitionID sequential# is used for exb images. Index allows us to have more than one image for an object using the naming convention. The name is always the same, just the index and image type changes. Image type; we make 3 versions of each image, master (mas), bar (color corrected with bars), pub (color corrected and cropped). Suffix is whatever the file type is. The switch to the structured naming convention has tremendously increased our productivity. Identifying an image is as simple as querying TMS on the objectID carried in the image name. My only regret is that we didn't do this sooner. David Parsell Systems Manager Yale Center for British Art 1080 Chapel Street PO Box 208280 New Haven, CT? 06520-8280 ? 203 432-9603 david.parsell at yale.edu -----Original Message----- From: mcn-l-bounces at mcn.edu [mailto:mcn-l-boun...@mcn.edu] On Behalf Of Richard Light Sent: Wednesday, June 09, 2010 11:42 AM To: Museum Computer Network Listserv Subject: Re: [MCN-L] image file names In message <AD775DE5635C2042BF1DCB7EED36A83B850A1D at jlm-net.jlm.local>, Perian Sully <psully at magnes.org> writes > >Funnily enough, I was just about to draft up a file naming standards >document and post it online. Other than some of the inherent >difficulties with trying to align the digital filenames with the >accession number (particularly when you don't have an accession number >yet), what are some other arguments in favor of using a unique >identifier instead of the accession number? One obvious argument is that it allows a single image to feature more than one object. Richard Light >-----Original Message----- >From: mcn-l-bounces at mcn.edu [mailto:mcn-l-bounces at mcn.edu] On Behalf Of >Images >Sent: Tuesday, June 08, 2010 12:03 PM >To: Museum Computer Network Listserv >Subject: [MCN-L] image file names > >We're reviewing how we name our image files and I'm hoping that some of >you may have worked through this same issue. Currently, we use our >accession number, however as this contains periods it has been >identified as potentially problematic. For example, accession # 42.3.11 >= VAG-42.3.11.jpg. One suggestion is to change the decimals to zeros but >we are concerned that this makes the image file name difficult to read. >Have any of you found a good solution to a problem like this? Any >thoughts or samples of your naming structure would be most appreciated! > >thanks very much >Danielle > > >_______________________________________________ >You are currently subscribed to mcn-l, the listserv of the Museum >Computer Network (http://www.mcn.edu) > >To post to this list, send messages to: mcn-l at mcn.edu > >To unsubscribe or change mcn-l delivery options visit: >http://toronto.mediatrope.com/mailman/listinfo/mcn-l > >The MCN-L archives can be found at: >http://toronto.mediatrope.com/pipermail/mcn-l/ >_______________________________________________ >You are currently subscribed to mcn-l, the listserv of the Museum >Computer Network (http://www.mcn.edu) > >To post to this list, send messages to: mcn-l at mcn.edu > >To unsubscribe or change mcn-l delivery options visit: >http://toronto.mediatrope.com/mailman/listinfo/mcn-l > >The MCN-L archives can be found at: >http://toronto.mediatrope.com/pipermail/mcn-l/ >No virus found in this incoming message. >Checked by AVG - www.avg.com >Version: 9.0.829 / Virus Database: 271.1.1/2926 - Release Date: >06/08/10 19:35:00 -- Richard Light _______________________________________________ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l at mcn.edu To unsubscribe or change mcn-l delivery options visit: http://toronto.mediatrope.com/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://toronto.mediatrope.com/pipermail/mcn-l/
