Anytime you decide to re-post that article hot off the virtual press from a site like nyt.com or Endgadget to your social network of choice, odds are strong that its content crosses the news-media-to-social-media gap via a metadata standard called the Open Graph Protocol, or OGP. OGP facilitates grabbing the article's title, its content-type, an image that will appear in the article's post on your profile, and the article's canonical URL. It's a simple standard based on the usual HTML metadata tags that actually predate Facebook and Google+ by over a decade (OGP's metadata tags can be distinguished by the "og:" prefix on each property name, e.g. "og:title", "og:description", etc.) And despite its Facebook origins, OGP's success should strongly inform enterprise metadata policies and practices in one basic, crucial area.
The key to OGP's success on the public internet lies largely in its simplicity. Implementing OGP requires the content creator to fill in just the four aforementioned metadata fields:
- the content's URL (og:url)
- its title (og:title)
- its type (og:type)
- a representative image (og:image)
A great number of other OGP metadata fields certainly do exist, and should absolutely be taken advantage of, but only these four need to be defined in order for a page to be considered OGP-compliant.
What can we immediately learn here from OGP that applies to metadata in the enterprise? The enterprise content-creation and/or content-import process should involve a clearly-defined and standardized minimum set of metadata fields that should be present in every document *before* that document is added into CMS and/or indexed for search. NYT.com certainly doesn't push out articles without proper OGP, and enterprise knowledge workers need to be equally diligent in producing documents with the proper metadata in place to find them again later! Even if practical complications make that last proposition difficult, many Content Management Systems can be setup to suggest a basic set of default values automagically for the author to review at submission time. Just having a simple, minimum spec in place for the metadata fields that are considered absolutely mandatory will generally improve base-line metadata quality considerably.
What should this minimum set of metadata fields include for your specific enterprise content? It's hard to make exact recommendations, but let's consider the problem that OGP's designers were trying to solve in the case of web-content metadata: people want a simple preview of the content they're sharing from some content source, with sufficient information to identify that content's basic subject-matter and providence, and (perhaps most importantly!) a flashy image that stands out on their profile. OGP's four basic requirements fit exactly these specs. What information do your knowledge workers always need from their documents? Perhaps the date-of-creation is a particularly relevant data-point for the work they're doing, or perhaps they often need to reference a document's author. Whatever these fields might actually be, spending some time with the people who end up using your enterprise documents' metadata is the best way to find out. And even if their baseline needs are dead simple, like the problem OGP manages to solve so succinctly, your default policy should be to just say NO to no metadata. Your search engine will thank you.
A natural question might arise from this case-study: should you actually just start using OGP in the enterprise? It's not necessarily the best option, since intranet search-engine spiders and indexers might not know about OGP fields yet. In any case, you'll definitely still want to have a regular title, description, etc. in your documents as well. As of the time-of-writing, OGP is still best suited to the exact niche it was desinged to operate in: the public internet. Replicating the benefits it provides within the enterprise environment is an important goal.