2010 has been designated the year of cataloging research by the Association for Library Collections and Technical Services.  So it’s a good time for me to continue my series on concept-oriented catalogs.  Before I talk about specific ways to implement them, I’d like to give some attention to what they look like, and the ways they interact with users.

If you’ve explored the links from my post giving examples of such catalogs, you may have noticed that there’s no single look and feel across the catalogs.  Most of them diverge substantially from the familiar “search box followed by uniform list of hits” paradigm we see with Google and other generic search engines.  But what should such catalogs provide, beyond the simple hit list?  And what do different well-designed concept-oriented catalogs have in common, from a user’s point of view?

Generally speaking, concept-oriented catalog displays are more complex than traditional catalogs.  Since they use a variety of concepts to help users find knowledge resources, the displays will generally show both a set of resources, and some information about other concepts in the catalog.

In theory, a catalog could start by just showing concepts, and requiring users to choose a particular concept before displaying the resources associated with it.  That’s in fact how many traditional library catalogs work, when users try to browse by author or by subject: you just see lists of headings, and you have to click through each heading individually before you can see what resources are associated with it.  But forcing this kind of interaction gets in people’s way unnecessarily.   I think that’s why I don’t see a lot of this sort of browsing  in library catalogs, and why the most frequently used Internet search engines take pains to show useful resource results as quickly as possible.

So good concept-oriented catalogs will feature resource “hits” quickly and prominently, just as other good catalogs will.  Concept-oriented catalogs will generally also show other concepts that provide context for these knowledge resources.   They can do this in a variety of ways.  They may mix in “concept” hits with “resource” hits (as with these search results for “Hava Nagila” in the Freedman archive, which combine hits for tracks, albums, and compositions).  They may display concept-related information alongside resource hit information.  (In some displays, like in WorldCat Identities’ display of Charles Dickens, resource hits are displayed after information about the concept. In other displays, like the Online Books Page subject map for “Prisoners of war”, they’re literally side by side.)  Or they may have complementary displays that overlay concepts and resources.  Consider, for instance, this Philadelphia neighborhood history display, where resources are represented as push-pins that overlay a background of geographic representations, a display also used in many Google Maps applications.

In designing a concept-oriented catalog, one needs to avoid confusing users with over-complex, under-explained displays.  Rather, the catalog should work with the user by providing an easily understood context for their search. Users should be given a clear idea of what concepts they’re looking at (e.g. by clearly naming and describing them), and what resources are associated with those concepts (e.g. by showing the resources along with the concepts, in some sensible organization).

In well-designed concept-oriented catalogs, the concepts and the resources complement each other.  The concepts, and the information displayed about them, helps users understand and choose appropriate resources.  And the resources, in turn, can help users understand what a concept is about, and what is known about the concept.  Looking over the available resources, the conceptual information, and mentions of related concepts, users can decide whether they want to delve more deeply into a particular set of concepts, or move to different concepts for further investigation.  (Facet-oriented displays let you do all this, for instance, and are useful even when they provide no information about concepts other than their names.)

In the Internet age, we also shouldn’t assume that users just stick to our own catalogs to do their research.  There’s a whole Web’s worth of context out there.  Concept-oriented catalogs should link out to (or include outright) external resources that can help users with concepts and resources, as appropriate.  Going the other way, they should also make it easy for external resources to stably link to a particular concept (or concept set) in the catalog.  (It’d be great if someone looking up an article on Wikipedia or another database could see a prominent link to “Stuff your library has on this topic”.)

I’ve mentioned or implied a number of design rules in what I’ve said above.  I’d like to point out 4 of them in particular, for a moment:

• Use clear names for your concepts.
• Make your concepts linkable via the Web.
• Provide useful information about concepts when people come across them.
• Include links to knowledge resources, other concepts, and external resources, so people can find more things.

Now I’d like you to look at the 4 rules for linked data by Tim Berners-Lee, inventor of the Web.

Notice a resemblance?  I didn’t start out trying to make my design requirements match Sir Tim’s principles, and I don’t necessarily think that Linked Data and its associated technologies are the be-all and end-all of information management.   But there are enough points in common to suggest some interesting synergies between the design of concept-oriented catalogs and the work of the Linked Data community.

And with that to think on, I’ll take my leave till next time, when I’ll talk more about the data that powers concept-oriented catalogs.