Job Descriptions from the Future: Director of Metadata

First in a series of jobs that don't exist today but will come into being as the interactive industry matures.

Metadata, for those of you not hip-deep in content management system (CMS) implementations, is most simply defined as 'data about data.' For example: you may have a movie file on your hard drive; its filename, "funny dog.mov" is a bit of metadata that gives you some information about what you might find in that movie. Pop open the 'get info' or 'properties' box and you'll find a field for description- a place where you can enter a longer bit of text outlining the movie contents.

Upload the movie to YouTube and someone might tag it with the word 'pets' or another descriptive term- these tags are now part of the metadata (within the environment of YouTube; they obviously won't extend back to the file on your hard drive).

Metadata is created and added to content (like video, photos, articles, etc.) in order to help organize it. It makes it possible for a system (such as a CMS) to search for it, to allow users to browse for it by some attribute, and for the system as a whole to generate reports about usage.

Metadata comes in pairs- the name of the attribute and the data itself. In my example, the 'file name' attribute is described by the data 'funny dog.mov.' Since these attributes are blank until they are filled in, they are referred to as 'fields.'

I outlined three types of metadata our video file might have- filename, description, and tag. In a typical implementation of a CMS, a video file might have thirty, sixty, one hundred or more fields of metadata, depending what the need is to categorize this content to a particular level of specificity and precision. When grouped for the use of a system, metadata is referred to as an 'ontology' or a 'schema.'

Some metadata is implicit- for instance, if you transcode the movie into a Flash streaming file, the format is 'FLV.' That's just what it is; your opinion on the file format is immaterial. Other metadata needs to be assigned- for instance, is the clip from a comedy show? You might assign 'comedy' to a field labeled 'genre.' At this point in time, a human being somewhere along the line needs to determine that the system needs to know the genre of the movie, and then make the proper assignment.

That's where our Director of Metadata comes in. This is a job position that is currently desperately needed by rarely created. Instead, this position is chopped up into multiple pieces and distributed among multiple people in an organization, each of whom has a definite interest in the metadata the business needs to operate, but not the clear ownership this gig requires.

Nowadays, you see the following disciplines saddled with one piece or another of this job:


Editorial team: These are the the most visible users of metadata, since they actually create and compose much of the information that will ultimately become metadata. However, their focus is informational and not necessarily operational- without support from other disciplines, they are likely to create extremely intricate descriptive fields and skimp on the system level fields that are needed for effective categorization and workflow control.


Operations team: Tasked with making sure that the metadata allows for day to day operations of the company, the Operations team tends to focus on fields that describe the 'state' of the item- which in some cases is not necessarily the job of the metadata, but rather should be managed by a system external to the item itself. Fleeting or temporary information like the type of ad campaign running against a piece of content shouldn't be tagged as part of the content itself since it will change frequently, but the Ops folks need somewhere to put it, and the metadata schema looks like as good a place as any.


Product team: As part of the product specifications process, the Product team will of course attempt to gather every other team's requirements for the metadata, but will not typically act as an effective filter for it; if Joe from accounting says we need to track the price in dollars, pounds, and lira, who are they to argue? What ends up happening is the Product team gathers an astoundingly long list of fields, many of them redundant or flat out unnecessary, and then watches as it's progressively whittled down by iterative review- which is fine in the end, but time consuming and ineffiecient.


Technology team: the group that actually needs to make the system happen. Their focus will typically flow toward system performance and stability, so they will be rooting for the least amount of metadata possible to make the system function, sometimes at the expense of flexibility or automation somewhere up the workflow chain. This attitude causes the other groups to try and stuff as much information in at the outset, so whatever ultimately ends up making it into the system is robust enough for their needs.

When there's no clear owner of a project or capability it typically limps along halfheartedly until deadlines or desperation shock it into frantic activity. In either case, decisions are not being made in a clear and methodical manner, and the ultimate result is not as well fashioned as it could be. Since metadata is at the core of so many operations, interactive businesses ignore this deficiency at their own peril.

There are metadata specialists today- taxonomy consultants, ontology experts- but they are typically brought in for a segment of the project, and not given the organizational heft necessary to solve the interdepartmental issues that make these projects so contentious and inefficient. What's needed is a strong internal owner for this crucial business segment- someone who can determine, define, and defend the decisions around the metadata schema that will serve as the engine for the company's information flow.


Let's start with the job description:

The Director of Metadata is tasked with managing the metadata schema for the Company's video products. DoM will work with the Business Development, Editorial Programming, Product, Operations, and Development teams to:

- Fashion metadata requirements for content partnerships
- Determine metadata needs for editorial programming interfaces
- Develop a schema that supports product capabilities for discovery and reporting
- build out the CMS and data entry methods to support the schema
- plan for future expansions and revisions of the schema as the business evolves

So now the tricky question: Where does the Director of Metadata work? In the Technology team, since that's where the development will ultimately happen? In the Product team, since their job is all about definition? In Operations or Editorial, since they're the ones that are going to have to live with it?

If there's a Chief Information Officer in an organization, I would roll the DoM up that line. Otherwise, I would drop them in the Product organization (which is cross-functional by definition) but give them a special dispensation and the independence to attach themselves to other teams in order to gain a properly broad and balanced outlook on metadata needs. Metadata is the language each internal group, and ultimately the consumer, uses to communicate with the assets of the business; it's too important a task to leave to someone who speaks only one organizational language.