Creating Digital Workflows using Metadata or How to make your files Self-Aware
My company, E-Spec has been using Adobe XMP metadata for over 8 years now. I began following Digital Asset Management (DAM) groups when I joined LinkedIn a few years ago. I continue to be amazed at how perception of the same technology can vary based on your background. The DAM view seems to be that metadata is primarily a tool for retrieval of assets (in most cases images) with a historical tilt towards an archive solution. E-Spec views metadata as a means for system integration and reducing redundant data entry in the business process. I would like to solicit some discussion — how can these different views can work together to create more robust DAM and integration solutions.
Keywords vs. Attributes
Our mantra for process improvement is “collect the data at the source and eliminate redundant data entry between systems”. The data of interest is “attribute” data whether it is product attributes, image attributes or file attributes. As the user “publishes” their content for collaboration, they know certain attributes. The goal is to capture these attributes just as the users share their files. Most corporate creative departments allow each user a personal workspace (still on the network so IT maintains the backups) and provide “share” locations where users can collaborate together on this content. In the shared locations, we find “attributes” are maintained using folder/sub-folder structures and specific “coding” in the actual file names (did you bring your Dick Tracy decoder ring?). The types of attributes might be the consumer/customer of the content, the type of content or other product information; for example in the fashion world: season, collection, product type, gender, size range, etc.
What I have observed from the DAM discussions is more of a content emphasis; the keywords represent the visual content in the file; the image is of a “dog”, a “retriever”, a “golden retriever” and it is in a “fenced yard”, in the “mountains”, etc. Back to the fashion example, the keywords might include; “dress”, “knee-high”, “floral pattern”, “sleeveless” – things that anyone looking at the file can see. Note that some of these keywords might also be considered attributes, but many attributes could not be derived by observing the contents of the file. From looking at the dress, I cannot tell that it belongs to a particular season (Fall 2015) or is intended for a particular customer (Macy’s) or a marketing collection (Martha Stewart). So while attributes and keywords are related and even overlap, their methods of collection may be different.
Attached vs. Embedded
Another distinction I have observed in the different approaches is how the data is captured. The DAM system catalogs the files and keywords are entered in a database with links to the file (asset). Some of the data may or may not be embedded in the file but a large portion of the data is only contained in the database (a general observation – varies by system/vendor). If the asset is checked out the linked data may or may not travel with the asset. Our approach has been to immediately embed attribute data in the file; if the file is moved or copied the attributes still exist in the file (the asset has become “self-aware”). If I make a copy of the file and send it to another department for use in their business system, the attribute data is available to integrate the file with other existing business data. If I place the file in a shared “drop box”, the recipient still has access to the attributes in his copy of the file. And if I provide the file to a DAM system, the attributes can be extracted and included with the keywords already being entered. Embedding attributes in the file means the file knows to whom and where it belongs, it knows which external data elements are relevant to it and it can be a conduit for system/data integration.
Self-aware Documents
The optimum approach is to create the attribute taxonomy and vocabulary to match the business applications used in the enterprise workflow. A sub-set of the attributes can be used to identify a key to a single record in a particular database; different sub-sets for different systems. The creative user is creating an image to be used in producing the previous discussed dress. As they save their work to the shared location, they know some of the attributes; season, customer, collection, gender, product type. As other users work with them, other attributes become known; size range, color, target price, etc. At some point an ID is assigned (prototype #, style #, etc.). Sending a copy of this file to a product development database, a unique record can be created for this style using the embedded attributes. The product development system will then collect additional data about our dress as it progresses through the product workflow (sampling, sourcing, production). This data might be related to the fit of the dress, the required components to make the dress and even the cost. If another copy of the file is sent to an inventory/production system, a unique record can be created there as well. Additional data will be collected regarding factories, ship dates, quantities, etc. Other copies of the file might be sent to e-commerce websites, sourcing systems, etc. The file is provided to our DAM system as well. A user can use the DAM system to find the dress and knowing the attributes, can query the other business systems to get information such as status, sales results or any other data in those databases related to our dress. The dress image has become self-aware!
This does not replace or interfere with the traditional DAM approach; it simply provides some data (attributes) earlier in the cycle. Keywords can still be added to our dress (“floral print”, “roses”, etc.) at any point.
The integration doesn’t stop with business systems. At some point a photo is taken of our dress to be used in a catalog. If we embed the same attributes in the photo, then later when customer service gets a call about the pink floral dress in the catalog, the metadata can be used to look up in the inventory system how many size 6’s are in stock; they can look up in the product system if the dress fits the same as last season’s model, etc. The photo can take me to the original sketch and from there to the rest of the enterprise.
The point is the taxonomy and vocabulary requirements are different when using metadata for integration and need to be included in your DAM implementation planning – it can’t be added after the fact.
In creative and graphic-intensive enterprises, the DAM system can become the hub of data integration by using “self-aware” images.
About E-Spec, Inc.
E-Spec, Inc. (founded in 2001) offers a suite of Adobe extensions and other tools to establish a digital media workflow within the creative process. Free yourself from the mundane work of identifying, converting, publishing and tracking of media files and focus on what you do best, create!
Dan Hudson, President E-Spec, Inc. dan@e-spec.net
We provide our customers with a tool to create the metadata fields. We use Adobe’s XMP metadata standard to create custom XMP fields; these can be text, memo (multi-line text), date, combo boxes (pick lists) and check box fields. The field definitions look very similar to XML.
