0N.B. You might want to start a pot of tea and put on your bunny-slippers. This post is kinda long.

The Plugins

0There's something really exciting going on in Omeka development lately. There's been a flurry of work developing new and exciting importers for Omeka. First there were the usual suspects for imports for an app aimed partially at archivists, things like OAI and EAD, the good solid formats that archivists know and love.

0But then Jim Safly told the Omeka-dev mailing list that an alpha version of a Zotero import plugin is ready for testing. What's more, a Flickr Importer is in the list of desired plugins, and I've been hacking steadily away at another plugin from the desiderata, a FeedImporter. It's not quite ready for testing yet, but you'll get a sneak-peek below. These represent a distinct move into new territory.

0They move us into bringing social media into the collecting and archiving tools of Omeka. More precisely, they move us toward having the curation tools of Omeka ready to operate on the content from social media sites. Okay, that should be no suprise, surprise Tom Scheinfeld and Jeremy Boggs at CHNM, and Jeff McClurken among others are already organizing a conference on archiving social media, and especially given that the Library of Congress has announced that LOC has acquired the entire Twitter archive. I guess that it all really came together for me conceptually last week. And it suggests an important step in the evolution of Omeka.

WordPress vs. Omeka vs. Drupal

0Omeka has always consciously maintained a middle-ground between the ease of use of WordPress, and the content management power of Drupal. It's maintained a solid focus on having standard metadata available in the form of Dublin Core. And it's excellent for quickly building an exhibit of items. Since I regularly use all three in my work with faculty, here's the quick run-down of how I think about them.

WordPress

0

0Wordpress is about publishing. It is very strong for quickly getting content published on the web, and is wonderful for the number and variety of themes available for display. I only grudgingly call it a content management system. With only two item types ("Posts" and "Pages") and only tags/categories available for organizing the content, for anything more than fairly simple information architectures, it quickly requires a lot of hacking. That said, its lets you start publishing on the web in interesting ways in a matter of minutes, and that's important.

Drupal

0

0Now Drupal is a content management system. Many people will say that the administrative interface is far too complicated. I think that's in large part due to somewhat unfair comparisons with WordPress (unlike with WordPress, the typical Drupal user isn't supposed to see much of the administrative back-end, if any. And the complexity of the "Edit" form is honestly not greater than most web forms that people are expected to negotiate, at least when the admin has designed it well). The themes available have gotten much better over the last few years, but ultimately Drupal usually expects some amount of theme tweaking or developing. The big thing with Drupal is that it can accomodate any level of complexity in information architecture. With the ability to create multiple taxonomies, any content type you need with any field you need, and mixing and matching pieces of content any way you need with the Views module, you can do amazing things with Drupal. Yes, you see where my preferences lie. But I also acknowledge that there's a lot of work to do and a lot of complex thinking required to take advantage of Drupal. There's just a lot of conceptual and info architecture work to do up fron before getting off the ground. And that's a real constraint.

Omeka

0

0Omeka hits the sweet spot between the two by having a much tamer administrative interface, and allowing for creating new item types through a more streamlined mechanism than Drupal has, as well as lots of built-in item types. Because it starts with Dublin Core ready to go, it's great for people who care about metadata, but don't want to create it all from scratch as you would with Drupal. So for creating a carefully crafted set of collections or exhibits -- with usable metadata and everything! -- Omeka is the way to go. There is, though, a real need for themers to get start building up some variety to the out-of-the-box themes available. I'd really like to see more theme developers build some themes for Omeka. Let's go people--lots of untapped potential!

0That's been my usual starting point for talking about the three applications: WordPress for quick publishing; Drupal for complex relationships between different types of content, and Omeka for exhibits with good metadata.

0The social media importers, though, shift around the ecosystem a bit. Now, Omeka is establishing a unique position as the go-to application for curating content that exists elsewhere on the web. That is, if you see content in either WordPress or Drupal (or Flickr, or YouTube, or Zotero, or. . . ) Omeka is poised to be the meta-application to gather it up and make more sense out of it.

0It's timely, too, since a lot of people have noticed the word "curation" being bandied about in different ways, and there's rightly been some call to explain what we all mean by it in this kind of context (i.e., outside the museums, repositories, and archives that have traditionally been the loci of curation). It hits at the dynamics of all the information moving around the internet in various forms and formats, and some basic issues of how to make sense of it all.

Curation

First Rule of Info-Dynamics

Information is messy.

Second Rule of Info-Dynamics

Curation is the process of taking existing information and situating it within a new context of utility while augenting existing metadata about that information.

Corollary to the Second Rule of Info-Dynamics

That context must be shareable through existing interpretive and/or technical standards. Except when existing standards are not up to the task of capturing the utility. Then, new interpretive and/or technical standards must be created. (Feel free to think of Thomas Kuhn here.)

0I'm especially concerned to differentiate between republishing and curation. Lots of great work has been done with republishing content, especially blog posts, into a single blog/site. While that new context of the single site does have the utility of aggregation, I don't see a really significant addition of information in that process. We might be able to glean additional information about the aggregation by reading the about page for the blog, and that's important and useful, but it's not something that I see as a curatorial step. It is, rather, information that we now have about the new publication. The important thing I'm thinking about is the moment of transfer, not the final destination at the end of the transfer. It's one thing, for example, to know the history of monasteries and libraries that have owned a particular manuscript and to learn from that information. But it's a different matter to study how the different libraries and monasteries reinterpreted that artifact by, for example, shelving it with or copying it into other manuscripts deemed to be similar, or how it was recatalogued, or what other manuscripts it travelled with and why.

0It's those latter notions that intrigue me, but as a conscious practice of how we move content around to different sites on the web. And the important thing is to make use of the tools that let us carefully add information in those moments of transfer and interpretive transformation. It's sort of like the opposite of entropy, but for information. As information moves through the web, I'd like to see each snapshot of it in any particular site connected to augmented more information and organization.

Curation By Tags

0First, before anyone says, "What about categories in addition to tags?", shush. The distinction is completely idiosyncratic to each site -- one site's tag is another site's category and vice versa. Moreover, the distinction is not necessarily maintained in the feed, even if it exists in the site. In other words, when it comes to curation, the distinction is more noise than signal. So here I'll be referring to "tags" to cover both. That's part of the info-entropy that I'm trying to reverse.

0Tags are especially interesting. They can and often do carry a LOT of information. The trick is that that information is usually context-dependant. Take, for exammple, the tag "Paris", my favorite, though admittedly extreme, example. When you see that tag, the context of the site -- the domain name, images, post titles, other tags, etc. -- will help you discern whether it really means "Paris France", "Paris Texas", "Paris Hilton", or "Paris the Trojan hero."

0In other words, the human mind does what it excels at: filling in missing or ambiguous information based on the context. Now, a conscientious writer might very likely curate at the moment of publication, carefully applying tags that eschew ambiguity. The ad-hoc nature of tagging, though, makes that unlikely. Categories do facilitate the process of curation at publication-time, but again that information is only meaningful within the context of the individual site. In any case, the distinction is lost when the post is republished.

cc licensed flickr photo shared by stevenvanwel

cc licensed flickr photo shared by Katherine H

cc licensed flickr photo shared by thisisbossi

0That's where curation comes in. If, in republishing that content, I take some care of the import by knowing both the originating site and the target site, in the transfer I can make explicit some of the missing information that was supplied contextually in the originating site. Even better, if I have options like Collections and Item Types to choose from in order to provide additional structure, I have lots of tools for counter-acting -- and/or, if I'm lucky, reversing-- the information-entropy that is inherent in republishing.

0So, if I have a reasonable idea about the tagging patterns in a flock of sites I'm importing, I could, for example, send items with the tag "Paris" from one site to a "Celebrity" collection, and items with the tag "Paris" from another feed to a "Travel" collection. At the same time, I'd augment the tags from one into "Hilton, Paris" and the tags from the other to "Paris, France".

Some Live-Fire Examples

0Much of my thinking here reflects the heavy use we make of republishing content based on tags in UMWBlogs and what that has meant for how I think about the FeedImporter plugin. A recent grab of the feed from UMWBlogs lists these tags (among others):

• Featured Blog
• featured
• UMW Blogs News
• Annex B
• apocalypsnow
• geography
• Snowpocalypse
• art
• banned art
• fsem

0Here's a look what I'm working on having the FeedImporter plugin for Omeka do to curate items based on tags.

0

cc licensed flickr photo shared by logista

0First off is the inconsistency in capitalization that I'd like to clean up, so every tag get's to have a "Preferred Name" within the Omeka site. That's what will be used when the original tag name is mapped over to Omeka's element sets. Usually, that means Dublin Core Subject. There's a simpler configuration screen that gives a simple checkbox if that's all you need. But, if you have additional element sets available, the options at the far right let you map to anything in Omeka.

0Next is the "Featured Blog"/"featured" possible overlap that I'd like to clean up. Here, I'm setting things up to have a special collection of Featured Posts. This will override the default collection (set elsewhere) of "UMWBlogs Posts". The upshot is that, based on specific tags, in the feed I can push the item in the feed around to add some additional curatorial information. Notice I can also push the more verbose tag "Featured Blog", into a Dublin Core Description field if I want to. Clearly, this will work best when the tags coming from the feed are somewhat regular. Even so, if there are patterns you the curator see in the tags coming from a feed, it allows multiple options for how to augment the information the pattern signifies.

0

0One stumbling block that I've sometimes encountered in using Omeka is the workflow of creating collections and items. Sometimes it would be nice to be able to quickly create a collection while in the middle of another workflow so you can use it right away, then go back to it later to fill in the details. That was doubly-true in a situation like this, where I'm concentrating on how to manage the tags and sending them to a new collection on that basis. So I've been working on an AjaxCreate plugin that'll allow creating a record quickly so you can use it right away, then go back and fill in its details later. There's still some work to do on it, but I hope it'll help to keep the focus here on how to get the most out of the tag information with interruption that thinking process to go create new collections. Same principle with Item Types and Omeka Tags.

0

0Tags from the feed like "art", "banned art", and "fsem" (all from the same blog post) start to bring up some nice, rich possibilities for curating by tags. "fsem" is short for "Freshman Seminar", and there are a lot of very different courses that fall under that heading at UMW. One way to curate this might be to make a collection in Omeka for all the Freshman Seminars and map other tags to other elements, either Dublin Core Subject or something else. Curating UMWBlogs -- because ultimately, that's what I'm talking about doing here -- would benefit greatly by being able to separate courses into collections. Elsewhere, I'll also be creating a field for "Default Omeka Tag". In this case, I might create "Spring 2010 Courses" as the default tag for the feed, and change it from semester to semester. Alternatively, or in addition, I might create a new Item Type for Course Blog Posts, and create an Item Type Element to make further distinctions.

0Yes, this calls for a curator to do a lot of work, not just to maintain settings like these, but also to understand the patterns in the feed and the metadata options with Omeka and how to design them. Moreover, some of the possibilities here would require some theming work to make the slicing and dicing possible. The first step, though, is to get the data available to work with by having a skilled metadata geek do reverse info-entropy on the tags. Fortunately, the audience of Omeka includes exactly that group of people.

"Life Curation"

0That starts to offer lots of options for what I'll call "Life Curation". That's really just the same thing as "assembling your CV/resume/portfolio". Okay, so I might really mean "Professional Life Curation". (I'll leave it as an exercise for the reader to sort out the implications for various flavors of "Social Life Curation").

0I started experimenting a bit ago with Omeka-fying my CV. It's a bit neglected at this point. And I've discovered lots of hidden difficulties in the process of puttting my CV into Omeka. That was started before the "Cura Importalis" implications whacked me on the nose. With these curatorial tools, though, there should be lots of wonderful way to curate your onlice presences. There should be lots of great options on the horizon. (Especially if we can get some more variety in the Omeka themes out there and available).

0One last thing. I've ignored, so far, the most powerful feature in Omeka, the Exhibit Builder. That brings us to curation of a different mode: curration by narration. Once a flock-load of items have been brought into Omeka from all these existing social sites (blogs, Flickr, Zotero, etc.), then interested parties can get busy arranging the stories around the items into exhibits. I've found that to be really hard to do with my CV. It's a skill that I think needs some attention. That storytelling, too, is a kind of curation. Maybe the most important kind.