In a prior post, I discussed the pros and cons of a bicameral and unicameral taxonomies for identifying revisions in an asset management system. In production, at my current studio, we have two user provided fields that can be anything. In that post, I had one user provided field. Since then, I’ve come to the conclusion that the correct number of user provided fields is zero.
Why zero?
Consider the following hypothetical situation. You need to query your asset management system to view a render in context. For every shot renders from various roles – story, previs, layout, animation, lighting, comp, final, etc.
If you have a user provided field, it means for any role, there may be more than one version stack. Which one do you use? If you expect a standard name in the user field, what happens if there’s not a version stack with that name? How do you fallback to another stack? By date?
If you have no user provided fields, then it means for any role, there is zero or one version stacks. There is no ambiguity about which one to use. You can use version tags to mark specific versions as important, like “latest” or “approved”.
But what about the users? What if they need to do an alt, or wedges, or a one off? Well, that’s just another version. You can use notes and/or machine tags as metadata for the revision, but these values are not required to uniquely identify it.
tl;dr – Don’t let artists name things. Let the pipeline name things.
Yantor3d 