Blog

Blog

About ContextNext, Updates, and thoughts on data and knowledge

About ContextNext

David Louis Hollembaek 09-01-2022

The vision and backstory behind ContextNext.

Document Metadata

Metadata in Microsoft Office

David Louis Hollembaek 31-05-2020

Challenges and opportunities with metadata in the Office ecosystem.

About ContextNext

ContextNext's mission is to make simple high-value add-ins for Office that have some common characteristics:
1. Content stays in the Office App
(i.e.: document contents are not transferred to a server)
2. App saves time by automating or streamlining a common task
3. App functionality is not already available "in the box"

For decades I have been working with enterprises with problems large and small and frequently I find myself wondering, "why is this not in the box?"
In the last several years making Office Add-ins has gotten substantially easier, and the scope has grown as well. ContextNext's opportunity is to fill some of the old gaps with simple apps, freely available in the Office Store.

How does this make money? As of this writing, it does not. But I am happy to license code access so that you can deploy a copy at your own enterprise and manage your own SLA's (and security), or to host a private single-tenant service for your organization for fixed price. Just reach out for details.

Metadata in Microsoft Office

Have you ever worked in Office and wondered where some of the Properties or other document metadata come from?
Have you ever applied a “tag” or keyword to a file and thought, “will anyone ever see or benefit from this?” Have you searched on your company intranet, or somewhere else in your working environment, and wondered where those tags or refinement categories came from, or who gave those labels to the records or documents?
Metadata gets into your content experience in one of two ways:

01.

Natively in the document or record

02.

As a part of the Content Management System or other app experience

Most of the tags we are familiar with, like the tags on this page, are a part of the document itself. The Office ecosystem provides ways to write metadata directly into documents which can be read by other systems- or by you! A lot of metadata also gets created and stored in platform systems like SharePoint, Documentum, or Google Drive.
This post focuses on the first option to get metadata directly into a document.
There are a few ways to get metadata into an Office document.

01.

As native Properties in an Office-client UI

This is the process most people have seen before, and it usually goes like this:
View or change the properties for an Office file in an Office app.

02.

As native Properties through Office APIs

Usually setting properties through a Document Managment System.

03.

Injected into Office Open XML (OOXML)

Usually also through an Office API, but as custom OOXML, not native properties.

Once applied, native Properties can turn up in lots of places, but usually somewhere in the Office ecosystem when they are used for content organization, retention policies, and navigating services like Search. OOXML allows you to put very specialized information into documents, but if you add something in this way only you or other users of your App or Code will be able to utilize it.

Several years ago I was experimenting with Microsoft Office document properties in Word and PowerPoint with the new(ish) Office.js and Word.js Libraries. These interfaces provided a programmatic way to work with files in Office clients, and directly inject metadata as Office Open XML (OOXML), the file in your file. This model offered a new way to write specialized “custom XML" that went beyond simple tagging and allowed things like the creation of deep links back to formal ontologies. Experimenting with this model led to interesting tests, like looking up document terms in MeSH and creating corresponding "concepts" objects in OOXML which could be read or written like in this example leveraging MetaMap for reading:

Protoype Word Add-in with MeSH reader

Wikipedia text read by Metamap(MeSH)

As interesting as it was, these tags were only useful when someone knew that they were there, and nothing else in the workplace ecosystem was looking for these „custom tag“ OOXML feilds. For tags and metadata to be useful, they need to feed valuable experiences.
A short time later Microsoft added support for native Document Properties in their JavaScript libraries which created new opportunities to edit and create Properties directly in Office documents which moved with Office documents and could be consumed across the Office ecosystem.

CTX leverages current Office Javascript APIs to work with native Properties.