Confessions first: Working with metadata is one of my favorite parts of content strategy. I’m just enough of a geek to really appreciate the nitty-gritty details and what happens behind the scenes. But I’m grounded enough to know that just the word metadata makes many people’s heads hurt.
Metadata really can have several shades of meaning. If you want to start down the technical path, the Wikipedia entry on metadata is a decent place to start, but it will quickly send you in several, far more technical, directions.
But what I’m talking about today is pretty easy to understand and to see the value of. We’re going to talk about the basics of metadata for web content.
The basics
Metadata is information about your content. Let’s think about this web post as an example.
In WordPress, the software I use to run this site, I have two main kinds of content: Pages and posts. This is a post. I could define post to mean whatever I want, but in this case, I’m using the blog convention that a post is a piece of content that could live on its own page [like this], or can exist as part of a catalog and show up in different places, all depending on how I categorize it. [On the other hand, the pages on this website are just that — single pages, whose content only exists in one place. Here’s an example.] The fact that what you’re reading right now is a post is just a piece of metadata about this content.
I’ve put this post into 3 categories on my site:
- Content strategy
- Information management
- Metadata
So those are 3 bits of “metadata,” or information, about this post. [WordPress offers the ability to create and manage categories. That’s a pretty basic feature, and unless you’re just writing your site by hand in HTML, your software should offer that, as well.]
The date I published this is part of its metadata, as are the dates I’ve updated it. The fact that I did this, and not someone else who might have a login to my server, is also part of the metadata.
You can probably guess that some of these bits of information are captured automatically by my system, and some I choose intentionally.
Using metadata
All of these are pieces of information that I can use for my own purposes. For instance, if I wanted to create a category of posts I’d written about metadata, I could easily pull those together in my system, because I’ve thought to select the “metadata” category each time I wrote a post on that topic.
Getting more sophisticated
While it’s nice to be able to easily create categories, we’re not yet talking about real power. Here are two examples that don’t exist on my site, but that do exist on sites that are just a little more complex.
If you log in when you visit a site — say, Amazon — then it’s possible for the site to begin collecting information about you along the way, that it can match up with metadata about its content, and then it can give you a really personalized experience.
For instance, did you ever wonder how Google gives you localized results when you search for “restaurant”? Did you wonder how that happens? It’s automagically matching what it knows about your location [from your web browser….read more about how Google finds and uses your location here.] to the information it has about restaurants. It’s in a restaurant’s interest to make it easy for Google to do that, of course. Which leads us to….
Metadata schemas and frameworks
When you’re ready to go beyond the basics, you need to understand the schemas that are available for metadata. A schema is just a structure that a group of people has agreed to use in common. So if you’re talking about location, or library books, or video content, there are agreed-upon structures that other people are already using. If you want your data to talk to other people’s data, or be available outside your system, or even to avoid solving problems that have already been solved by someone else, you need to consider carefully how you want to use your content, and then evaluate the frameworks that may already be available to help you do that.