Who needs metadata anyway?

Relax, take a sip of coffee or tea from your favourite mug and lean back in your office chair. Even if you’re not yet sure why you should forge ahead with a metadata concept, it’s about to get exciting for you. Hang on – lean back again, it’s not that exciting. I’ve already noted a few metadata relating to your condition (otherwise known as state metadata) – reading, under the influence of caffeine or a mixture of leaves, interested and, above all, relaxed.

So what is metadata then? In short, data about data or information about characteristics of other data. This metadata can be described in more detail, or categorised; for example, into state metadata, administrative metadata, classifying metadata, etc. The difference is not always clear cut. What you consider as classifying must be defined in a metadata concept, as administrative metadata like “created on” can, for example, also be evaluated in such a way that a dependency on product development stages is established.

We are dealing with a certain level of abstraction when we talk about data and content. If we then talk about its metadata, we move onto another level, and if we then talk about the categorisations of metadata, we move onto yet another level and if we then OK – let’s leave it there. I think you get the picture.

From the perspective of computer scientists, the differentiation of metadata into state metadata, administrative metadata and so on usually doesn’t make a difference – from a technical point of view, metadata is metadata. But for those of us in the technical documentation industry, the difference between types of metadata can be very helpful to give us an overview of the metadata relevant for us. That’s why this step shouldn’t be skipped.

So when do we need metadata? At the latest, when you want to get more from your content, have a lot of content and a certain level of automation – regardless of what form this takes – in other words, as soon as your content needs to be able to be found and interpreted by third parties who aren’t familiar with your content; for example, machines or people looking for information.

New technologies and subject areas require metadata, as they process content in an automated manner since they can’t interpret it like people. Metadata tells these technologies what the content in question is and how it should be classified.

If you use our SCHEMA ST4 Component Content Management System, content is automatically assigned metadata so that the system can interpret it. What and how much metadata is created depends on the system. What is this metadata needed for? Quite simply for administration and management, for searching and finding, and for formatting content using software.

But where do you get your classifying metadata from? Well, there are at least as many sources as systems for recording metadata. For example, your existing directory, document or file structures are all potential sources for metadata. As are product life cycle information, the composition of your product broken down by components, assemblies, type/series designations. Or target formats, source and target file types, target groups, suppliers or departments. Connected systems like PLM, DMS, ERP or even CRM can also be good metadata sources. The more precisely you describe your content with metadata, the more flexible it is later; for example, it can be used in a content delivery solution. The method or system used to classify metadata (hierarchical metadata vs. ontologies, class concept, PI class) depends to a large extent on the application.

The decision as to whether to structure your metadata descriptively or distinctively – in other words whether you have a product structure from A-Z, for example, or only define the differentiating features – also makes a significant difference. Whatever you decide, your metadata should describe the respective content as explicitly as possible so that there is no room for interpretation.

“But machine XYZ contains standard component K; everybody knows that!” No, they don’t. Unfortunately, we can’t assume that every end user can derive this implicit information as easily as that and machines absolutely can’t know or determine this if they’re not told using metadata.

It’s also important to know where metadata comes from or, to be more precise, can and should come from. Where is the source? Technical documentation is usually a subsequent process where information relating to existing information is combined. Metadata, which can be reused if necessary, therefore comes into being at the same time as the product does and before it reaches the authoring department. Guilty parties here include development and design departments, as well as marketing, warehousing and purchasing departments. This means a technical writer or terminologist may be tasked with collating and organizing existing metadata sources within the company. In the future, new roles and jobs will emerge as a result; for example, for dedicated metadata managers and officers. In principle, every individual within a company is responsible for metadata.

Enjoy another sip of your hot drink. That was quite a lot to take in all in one go!

Before you go and tap all the sources in your company like a data leech, you should first consider what you want to achieve with metadata.

Let’s assume for a start that you want to address the topic of content delivery in future. There are a few basic questions to clarify: What content do you want to distribute? What is the purpose of distributing the content? To whom do you want to distribute the content?

These are the first of a variety of questions, which we would need another blog article for.

Let’s assume that you’ve already answered these questions. For example, you want to distribute information within the company, break down knowledge silos, provide the sales department with product information, prepare information for your service technicians, etc. For each of these requirements, the right content must be provided to the right people, at the right time, on the right topic, in the right place, to the right extent. What do you need for this? You’ve guessed it – metadata.

Content delivery allows you to search through and filter large quantities of content. Classifying metadata is a prerequisite of this, as it filters out subsets of the overall content using facets until only the relevant content remains. In order to be able to determine how users filter your content, navigate through it and ultimately find what they are looking for, you therefore have to define metadata. Without metadata, content delivery is no more than a static online help tool.

Content delivery solutions attempt to take content and metadata and create the best possible added value for the end user of your information, regardless of whether this stems from one or more sources.

Just as you’ve probably emptied your favourite mug, we’re also coming to the end. So what’s next? Have a think about whether you need classifying metadata and whether introducing a well-thought-out metadata concept could bring you added value. Whatever you decide, you can rely on products, solutions and services from SCHEMA with or without classifying metadata!