Meta data is the set of data describing a piece of content. The content can be a video, image, blog post, you, your mobile, or really anything. The meta data can include location (IP or physical), date created, date modified, keywords, tags, genre, author, and so forth.
Meta data has been present and used for years. You probably use Microsoft Word or Open Office, and you can edit a document's meta data via the File menu. Operating systems use date, name, and other information intensely.
While meta data is very useful, it requires constant vigilance to retain its usefulness. Perhaps the most immediate example of this is the recent major push for desktop search, such as Apple's Spotlight, that looks at the content of files and not just their name and meta data. Web search engines tend to look at content more than meta data in the page's header, since it's so easy to stuff irrelevant data there.
This post was triggered by my use of iTunes. I like to subscribe to podcasts and sometimes download audiobooks. iTunes treats podcasts, music, and audiobooks separately . . . but only if the meta data is correct.
Keep in mind that people consume these three types of content differently. Apple's iPod designers appear to know this, but the desktop designers don't. An iPod, for example, will not play podcasts in shuffle mode, nor will it automatically populate the device from podcasts. It will happily do these things for music, because they make sense for music.
The current state of iTunes:- many audiobooks, including every free one I've ever seen, are categorized as podcasts
- iTunes U content has the genre as the school name, creating new playlists but NOT listing in podcasts; they are categorized as music
- university lectures through other mechanisms are usually podcasts but sometimes music
- if the user changes the genre, the application doesn't care. It leaves the content in the unwanted location.
To fix this on my own machine, I have created a fairly complex smart playlist to put everything I consider to be "podcast content in my inbox" into one place. This is pretty ridiculous and also requires ongoing tweaking on my part.
When a system does not have control over its meta data, things get more complex still. Groups who want to share pictures on Flickr really have to pre-agree on a tag. "momolondon" gets you Mobile Monday London shots. "daveandpip" gets you pictures for a specific couple. What if a potential contributor doesn't know the secret code?
Flickr is at least a single repository. I use a set of pretty bizarre tags on del.icio.us, based on what I want to do with the bookmarked page. "to_n800" is stuff I've found somewhere and want to use from my N800. "modbook" is stuff I think will be useful when I finally get my new ModBook. Does this make any sense to anybody else? Hardly. I also generally find other folks' tags not particularly helpful, because they are built on a different context.
Perhaps most immediately relevant to me is the tags on this site. Every last post is related to mobile and user experience. The entire site needs these two tags; it certainly doesn't help somebody navigate this site for me to add these tags to every last bit of content. Yet for your feed reader or for Technorati, mobile is a key descriptor. Only when you use the keywords in the meta tag on the page as well as the tags I add to the posts do you get a complete description.
You may wonder what this has to do with mobile. Mobile applications tend to use meta data more intensely than desktop applications, due to the increased importance of context and the smaller screen. User agent strings are a form of meta data, and quite important to many developers, but notoriously unreliable.
If we want these applications to be reliable and useful, we'll need to do the following:- build flexibility into any application that relies on meta data. This is a place where explicitly limiting mobile access to a subset can be a problem. Maybe the content is indeed a video, but it is a slideshow and can easily be shown on a mobile. That's unlikely to be caught in content-type meta data
- build content search into the listings, perhaps by providing an initial list that are simple meta data matches and then a link or list of content matches as well.
- build robustness into context detection. A user might not update status or might have skipped the meeting on the calendar
- incorporate meta data quality management into processes
- avoid requiring extremely accurate meta data in applications; give the user the opportunity to fix the problem; use alternate spellings
You folks are smart ... what strategies do you use to make use of meta data but not be killed by its negative aspects?