After 18 months of trying to develop a DAM system I eventually did develop an approach that had many of the same attributes documented by Peter in his book (Sidebar note: I didn't call it such until recently, although I somtimes called my system by the other use of the word) . Of course Peter's was better thought out, better documented (he wrote a book after all), and provided a whole new vocabulary for me to use (DAM, derivatives, buckets, scalability etc).
Independent of Peter, I too came to the conlcusion to use buckets sized to match write once media, and to separate originals from derivatives (I used to call them masters and outputs, case specific). My naming convention for buckets has some slight variations from Peter's. I put these out for comment.
I call my original buckets ORG_<year>_<3 digit seq no.>_<media type>
I find the media type attribute to be quite useful. I can immediately see what size I am targetting. Right now I only use DVD for write once media, however, if I had started my bucket brigade a few years back, I would have had CD as a valid type. In the next few years I suspect that I will be using HD-DVD or Blu-ray. By having the media type in the bucket name, I can distinguish DVD's from future bucket types. It may make it easier when I have to re-terget old DVD's to new media down the road, and of course continuing this for many years and media changes. By putting the media tag at the end of the name it doesn't affect the bucket sequencing. I am not sure if the year code adds value or not, but it is what I have been using for the past 18 months so I do not want to change.
I have a new naming convention for the derivative bucket (now that I use the term derivative) and I am now using write once media for derivatives as well as hard disk (backed up, of course). My derivative bucket name name is identical to originals other than replacing ORG with DRV.
For filenames, I have one deviation from Peter's strategy. I append the camera body code to the filename (e.g. D2X, D70). This requires keeping track of which memory cards are used in which bodies. The reason I do this is because there are a few steps in my workflow where the body influences the parameters. Examples of this are:
- Different ACR calibrate settings (courtesy of Tom Fors script)
- Different noise profiles (when running Noise Ninja, which is not too often)
- Different sharpening parameters (driven by senor resolution) although I am looking to eliminate this somewhat.
Anyway, this is food for though for those who may be interested.
Cheers ... Alan