Ontology of Folksonomy: A Mash-up of Apples and Oranges

Thomas Gruber

TomGruber.org and RealTravel.com

Published in Int’l Journal on Semantic Web & Information Systems, 3(2), 2007. 
Originally published to the web in 2005.

SUMMARY

Ontologies are enabling technology for the Semantic Web.  They are a means for people to state what they mean by the terms used in data that they might generate, share, or consume.  Folksonomies are an emergent phenomenon of the Social Web. They arise from data about how people associate terms with content that they generate, share, or consume.  Recently the two ideas have been put into opposition, as if they were right and left poles of a political spectrum.  This is a false dichotomy; they are more like apples and oranges. In fact, as the Semantic Web matures and the Social Web grows, there is increasing value in applying Semantic Web technologies to the data of the Social Web. This article is an attempt to clarify the distinct roles for ontologies and folksonomies, and previews some new work that applies the two ideas together – an ontology of folksonomy.

ONTOLOGY AS ENABLING TECHNOLOGY FOR SHARING INFORMATION

A while ago, the Artificial Intelligence research community got together to find a way to “enable knowledge sharing” (Neches et al., 1991). They weren’t talking about writing papers or going to conferences; they wanted their computer programs to be able to interact with and build on the information from other computer programs.  They proposed an infrastructure stack that could enable this level of information exchange, and began work on the very difficult problems that arise.  Ten years later, Tim Berners-Lee articulated a wonderful vision of how this might all work on the Web – the Semantic Web (Berners-Lee, 2001).  Today the idea that web-resident programs can interoperate with and build on each other’s data is widely accepted.

In the context of the Semantic Web, “ontology” is an enabling technology — a layer of the enabling infrastructure — for information sharing and manipulation.  The approach is simple: parties who have software/data/services to offer identify some common conceptualization of the data; they specify that conceptualization as clearly they can; they build systems that interoperate on those specifications.  This is standard-issue information technology, with the twist that ontologies are specifications of the conceptualizations at a semantic level (Gruber, 1993). Other layers of the stack (other ways of enabling information sharing) include standard data formats, APIs, and sharing reference implementations of code that define the semantics of the APIs and data operationally.

FOLKSONOMY AS DATA THAT IS EMERGENT FROM SHARED INFORMATION

Not so long ago, keen observers of the Internet (Vander Wal, 2004),(Sterling, 2005), (Mieszkowski, 2005) and inventors of social software (Shachter, 2003), (Fake and Butterfield, 2003) began to notice that people who don’t write computer programs were happily “tagging” with keywords the content they created or encountered.  Of course, keyword tagging is nothing new; the interesting observation is that when these folks do their tagging in a public space, the collection of their keyword/value associations becomes a useful source of data in the aggregate.  Hence the term “folksonomy” – the emergent labeling of lots of things by people in a social context.  Thomas Vander Wal, who is credited with the term, emphasizes that the resulting folksonomy is not a taxonomy or even a collaborative categorization (Vander Wal, 2004).  At least that was the original observation and intent for the term.  Today, tagging is a widespread phenomenon popularized by applications such as social bookmarking (Del.icio.us) and social photo sharing (Flickr).  In these applications, the emergent data from the actions of millions of ordinary, untrained folk doing things for their own local interests is rather useful.  For bookmarking, tagging helps to counter the spam-induced noise in search engines, and for photo sharing, tagging gives those text-based search engines a fighting chance.

 

COMPARING APPLES AND ORANGES

Like all vague but evocative terms, both of the words ontology and folksonomy have taken on many senses.   Given the frustration with how hard it is to share data at a semantic level and the delightful observation about how much value can come “for free” from bottom up tagging, it was inevitable that the terms would be compared as alternatives.  In a widely-read blog post, Clay Shirky (2005) makes the argument that “ontology is overrated” and tags are “a radical break with previous categorization strategies…much more organic ways of organizing information than our current categorization schemes allow.”  Equating ontology with information organization, he illustrates how hierarchical, centrally controlled taxonomic categorization schemes are limited, and how free-form, massively distributed tagging is resilient against several of these limitations.  I think he’s right on both counts.  Yes, folksonomies are interesting in contrast to taxonomies. Taxonomies limit the dimensions along which one can make distinctions, and local choices at the leaves are constrained by global categorizations in the branches.  It is therefore inherently difficult to put things in their hierarchical places, and the categories are often forced.  Folksonomies are massively dimensional (one dimension per potential term, as in full-text indexing), and there is no global consistency imposed by current practice.  Things are easy to tag — there is no wrong answer — and the emergent patterns give insight into collective attention.

The only problem with the anti-ontology blog, is, as my friend put it: “He misses the point … so beautifully.”

The problem is that the blog, like much of the popular writing on ontology, confuses ontology-as-specified-conceptualization with a very narrow form of specification (the taxonomic classification) and a very specific methodology for agreeing on a conceptualization (centrally controlled categorization).   One of the examples of taxonomy cited is the Dewey Decimal System.  Of course, it is difficult to categorize everything in the world according to the Dewey Decimal System.  As Shirky points out, it was designed to manage book shelves in the eighteenth century.  (Notice the word design; the DDS is an organizational system, not a model of the world’s knowledge.)  You could try to build an ontology of all the world’s knowledge, and some people still do, but not for locating books. Today’s scholarly researchers use search engines (where every word is a tag) and index reference materials (with domain specific, controlled vocabularies, organized non-hierarchically) to find works on a subject.  And today’s curators of books and other cultural artifacts are designing ontologies-as-conceptual-specifications that enable multiple, independently developed databases of carefully categorized artifacts to interoperate, and for agents to reason about the differences among the vocabulary used in each of those independent databases (International Council of Museums, 2006).

The attack on “ontology” is really an attack on top down categorization as a way of finding and organizing information, and the praise for folksonomy is really the observation that we now have an entirely new source of data for finding and organizing information: user participation.  For the task of finding information, taxonomies are too rigid and purely text-based search is too weak.  Tags introduce distributed human intelligence into the system.  As others have pointed out, Google’s revolution in search quality began when it incorporated a measure of “popular” acclaim — the hyperlink — as evidence that a page ought to be associated with a query.  When the early webmasters were manually creating directories of interesting sites relevant to their interests, they were implicitly “voting with their links.”  Today, as the adopters of tagging systems enthusiastically label their bookmarks and photos, they are implicitly voting with their tags.  This is, indeed, “radical” in the political sense, and clearly a source of power to exploit.

LET’S SHARE TAGS

Yes, we agree, tags are cool.  I am a big fan of collective intelligence, and have personally experienced the power of collaborative tagging.  With my collaborators at RealTravel, we have built a “Web 2.0″ product that has user contributed content, social networking, and tagging.  I would like to join forces with my colleagues in the tagging community (TagCamp, 2005) to help build the infrastructure that will enable systems like RealTravel to interoperate in an ecosystem of data sources, services, agents, and tools that combine and add value to the tagging done by all these users.  How do we do this?  You guessed: create an ontology for folksonomy.  Let’s start by clarifying our purposes. After all, this is an engineering design effort — not an exercise in categorizing the world’s content.  Consider two use cases.

Use Case 1: Collaborative Tagging Across Multiple Applications

Today we can tag our photos on Flickr and use tags for bookmarking in Del.icio.us.   We can look up blogs on Technorati by tags.  I want to tag the content I find on any application, and I want the benefit of others’ tags across these applications.  This means that there must be some way of reasoning about the equivalence or relationship among tagging data across applications.

For example, let’s say I write a blog about my trip to Bali on my favorite travel site.  I tag it with the labels that categorize my trip for travel (“adventure” “culture” “diving” etc.) and the travel site can tag it automatically with things like the places I visited (“Bali” “Ubud” etc.) and my screen name. If I use Flickr photos in that travel blog, I want to display existing Flickr tags when those photos are shown in the context of the travel blog (“lotusflower” “beach” etc.).  I want to put the travel-related tags onto the Flickr photos, so the Flickr audience can automatically know that the lotus flower was in Ubud, and vice versa, so the travel site audience can find pictures of beaches in Bali.  When my blog is syndicated through the Net, I want it joining forces with other blogs in Technorati or Del.icio.us or other aggregators, where the whole world can get focused streams of fresh, authentic, user-contributed content about places they want to visit and things they want to do.  Tagging across various and varied applications, both existent and to be created, requires that we make it possible to exchange, compare, and reason about the tag data without any one application owning the “tag space” or folksonomy.

Use Case 2: Collaborative Filtering Based on Tagging

Google is great, but it takes work sorting through all the noise. Why should I have to repeat the effort if others have already gone through it?  When I enter the term “folksonomy” into a search engine I want to be able to see results that lots of others have tagged with folksonomy.   I want to find Shirk’s and Vander Wal’s writing right away because other people have implicitly marked them as required reading.  If some spammer has attempted to hijack the popular tag, I want the masses to reject him with their tagging.  I want to be told, without knowing to ask, that the term “folksonomy” correlates with the term “tagging”, because people have tagged the same things with both tags.  I want to go to Rojo and see which blogs tagged with this word are most read, across all major blogging systems.  Ideally, I want to see what my colleagues around the world have tagged as such, using whatever tagging system they choose.  More generally, when I do knowledge work on the web, I want to take advantage of all the other work other people have done.  I want to discover other people doing the same work, perhaps to share or connect up.  This is the vision that launched the Web, and it drives the goal of accelerating human knowledge and understanding.  What does it take?   Again, this use case requires that there be a common conceptualization of what tagging means and at least some way for a service to correlate or connect tag data from one application to another.

How to proceed?  I doubt there will ever be a single, standardized way to collect, interpret, or use tag data.  But we can build the substrate for an ecosystem of tagging that will lets us innovate and work toward the vision of an open tagosphere.   I argue that ontology is core to this effect.   We identify a common conceptualization, and work out a specification at the semantic level. We identify and build systems that commit to the specifications at various levels of commitment, and hook up the ecosystem.  In particular, we come up with a conceptualization of tagging that enables the power we want while allowing innovation in implementation, optimization, and extension.  We hash out those concepts that are clear, and try to make unambiguous definitions for terms.  We identify those concepts that are vague, and set out to clarify them.  And we lay out a conceptual framework for identifying those areas where systems will differ.  Ontologies are as much about reasoning about incompatibilities as about finding commonalities.

A TAG ONTOLOGY – SOME DESIGN CONSIDERATIONS

With this vision and these sorts of use cases in mind, a group of people from the tagging community are beginning to work on a common ontology for tagging – the TagOntology (Gruber, 2005).  (Note: this is not about developing a common folksonomy – a common set of words to use when tagging.  For example, the ontology will not include terms for labeling documents under topics of science or business; it will not be for modeling particular domains such as geography or photography.)  The TagOntology is about identifying and formalizing a conceptualization of the activity of tagging, and building technology that commits to the ontology at the semantic level.  The community is also working on enabling infrastructure at the levels of formats, data models, and APIs.  The larger approach is to create a coherent stack from conception to implementation that fosters innovation at all levels.

Let us focus on the ontology layer here.  If developing ontologies is like engineering design (Gruber, 1995), what are some of the design problems facing us?  I will offer a flavor for the issues here, and offer some preliminary analysis.  The actual work to hammer out solutions is collaborative and ongoing.

The Core Concept: Tagging

To enable the use cases described above, the core idea of tagging must account for the full environment of social tagging.  From the user’s point of view, tagging is an activity in which you label some content you create or experience with one or more labels, or tags.  So one might be tempted to formalize it as the two-place relation

Tagging(object, tag)

This is fine if you live in a closed world.  But to enable collaborative filtering, you need some notion of tagger – the person or agent doing the tagging.  So we need to represent the tagger in our relation, as so:

Tagging(object, tag, tagger)

Now we have to think about how these data might be shared.  You can’t leave this implicit at the inter-application level.  For example, if two applications modeled their tag data using the three-place relation, when they pooled or exchanged their data, it might look like this:

Tagging(Object1, tag1, tagger1)  // by system 1

Tagging(Object1, tag2, tagger1)  // by system 1

Tagging(Object1, tag1, tagger2)  // by system 1

Tagging(Object1, tag3, tagger3)  // by system 2

Tagging(Object2, tag1, tagger4)  // by system 2

where the first three facts are from the first system and the rest are from the other system. If we are to compare data from different systems, we can’t assume that they all have exactly the same sets of objects, tags, and taggers.  Thus, we need to make explicit some notion of source, which you can think of as the scope of namespaces or universe of quantification for these objects.  (I am tempted to think of source in terms of community, but that is an application -specific interpretation.)  So now we have a four-place relation, with source as a formal term:

Tagging(Object1, tag1, tagger1, source1)

Tagging(Object1, tag2, tagger1, source1)

Tagging(Object1, tag1, tagger2, source1)

Tagging(Object1, tag3, tagger3, source2)

Tagging(Object2, tag1, tagger4, source2)

This allows us to say something about a collection of tag data, independent of the specific applications they come from.

Constraints on “tagging”

To make any valid conclusions from the merged or exchanged data, we need an ontological commitment to the semantics of tagging and its three parties. First, consider the criterion of internal coherence (Gruber, 1995) for the relation itself.  First is the notion that a single tagger “votes” with its tag, and you can only vote once.  That is, if tag1 = tag2, then there is no difference between the first and second assertions above; they are logically redundant and you could go on asserting them forever without adding any information.  (You can state this various ways with inference rules or axioms, but they all amount to the single vote idea.)  This is an excellent example of why systems need to make ontological commitments at the semantic level, aside from any agreements on formats (Gruber, 1993).  If one system gave different meaning to repeated assertions of the tagging relation, then it would be logically inconsistent to combine their data.

A second notion intrinsic to tagging is that things-that-are-tagged play a role in the meaning of tagging that is different from the tag or the tagger.  One of the proposals on the table of the TagOntology discussion is whether one can tag a tag.  Of course, one can make a system to store these tuples, but the meaning is not clear on the tagging relation as it stands. In particular, the Tagging relation is not symmetric: you can’t swap tagger and tagged roles and preserve the meaning of a tagging assertion.  So to clarify the meaning of tagging, we would design a different sort of relation or family for “metatagging” or whatever it might be called.  One system might use a tag-on-tag notion to mean “this tag is a synonym of that tag” and another system might have a notion of “this tag represents a cluster of other tags”.  There is no requirement that all systems share the same notions; a successful knowledge sharing agreement only requires that they clearly identify the differences when they share data.

Negative Tagging

Now consider how to handle the collaborative filtering of “bad” tags from spammers.  How does a crowd “out vote” a spammer?  It turns out this requires negative tagging – asserting that a tag should not apply to an object.  What is a minimal commitment for negative tagging?   One could model the negative tagging assertion as literally a negation: “it is not true that tagger1 tagged object2 with tag3″.  However, representing important facts as logical sentences rather than relations leads to all sorts of computational deep water.  It becomes rather difficult to prove, in general, whether a tagging has occurred.  It is also tempting to try to assign some kind of evidential weight to the statement, but this has similar problems in trying to reason about tagging.  If we can refrain from the temptation to do too much, it is perfectly reasonable to simply add another argument to the relation – a polarity argument.  This would bring us to a five-place relation:

Tagging(object, tag, tagger, source, + or -)

To give this meaning, we can write the constraint that you only get one “vote”, either positive or negative.  Again, there are fancy ways to say this in logic but I think English does a pretty good job.  You can distinguish between what it would mean for someone to “untag” something as opposed to changing their polarity.  Similarly, you can write “default logic” inference rules.  For now, we are content with statements such as “if you don’t give a polarity, it defaults to positive).  Although informally specified, this is still an ontological commitment at the semantic level: you can reason about pools of facts of the form Tagging(object, tag, tagger, source) and Tagging(object, tag, tagger, source, polarity). If one system uses the four place version and another uses the five place relation, the five-place system can infer that the four places are equivalent to five place variants with “+” for value of polarity.  Because of a shared ontology, systems with negative tagging can share data with those that do not support the notion, and third party agents that can understand and reconcile the differences.

Tag Identity

Finally, the ontology needs formal definitions of identity for each of its core concepts: object, tag, tagger, and source.  In other words, when interpreting a set of tagging data, how do we know when two objects, tags, taggers, or sources are the same?  The Semantic Web (and RDF) offers a convenient pattern for registering namespaces using URIs.  For example, it is not hard to imagine allowing anything with a URI to be the object of a tagging assertion.  However, what about tags?  Is case sensitive in names?  White space?   Are these semantic level issues or just implementation details?

It is clear that different tagging systems today handle the input, output, and matching of tag phrases differently. However, we believe it is possible to formalize a conceptualization that factors out these differences clearly, so that third party agents can reason about the differences. One technique is to represent a function from names to tags. For example

f("san francisco") = tag1

f("San Francisco") = tag2

f("sanfrancisco") = tag3

Then one can write clear axioms that define how a particular system handles the name matching.  One might say that tag1 = tag2, another that tag2 = tag3, and so forth.   It is also possible to model the function the other way, that a given tag has a canonical name cname(tag)=”string”.  Then differences among surface forms of tags are bounded within the application (i.e., don’t care how tags are entered and displayed within the application , but insist that any export of the tag data to other systems only uses the canonical name).

Similar issues arise for the scope of identifiers for taggers – should they be relative to the source or be required to be universally scoped by something like a URI?  If they are scoped by URI, do they also have surface string names (“screen names”) that can be matched by third party systems, and by what rules of identity?   Does source represent a set of taggers or something else?  Is there any portability of identity across applications, and if so, by what mechanism (central registry, coincidental string match, FOAF (Miller & Brickley, 2005), etc.).

CONCLUSION

In this article I have tried to lay out some of the issues and challenges for designing a specification of tag concepts that might enable services for analyzing and reasoning over tag data across applications.  This article was originally written in November of 2005, and the tag ontology introduced here remains work in progress. The process for developing the ontology is open, with a working group operating under the name tagcommons.org. If you are interested in contributing, please visit tagcommons.org and sign up. That site contains links to ongoing work, proposals, and working group discussions.

What is more important than a specific ontology, however, is the more general notion that techniques of the Semantic Web, such as formal specification of structured data and reasoning across disparate data sources, can apply to the Social Web. Tagging data offers an interesting window into the intersection of formal reasoning (logical inference, database query processing, linguistic parsing) and semistructured data with context-dependent semantics (labels and groupings of content, people’s online identities). Tag assertions mean different things in different applications, yet they do not have to have a unified semantics to be comparable across sources. The process of developing a tag data ontology forces us to identify the kinds of ontological assumptions made by various source of tag data, and to specify a vocabulary for stating those assumptions. With a tag data ontology, or similar ontologies for other social data, we might enable technologies for searching, aggregating, and connecting the people and content they contribute throughout the Web. At the same time, the rich data from millions of active, participating human beings might offer fuel for the development of systems that tap the power of collective intelligence (Engelbart, 1963).

Acknowledgements

The impetus for this work comes from people who are building new applications in the spirit of “Web 2.0″ and from the attendees at a self-organized event called TagCamp (TagCamp, 2005).  There are many people contributing to this effort, and I’d like to thank those who helped most with the ideas in this paper.  Michael Tanne catalyzed TagCamp and pioneered the vision of collaborative tagging. Mika Illouz created a preliminary implementation of a system for multi-application tagging and negative tagging which offered a working laboratory for the ontology.  Bill and Holly Ward, who are working on a similar system, are also contributing significantly to the process. Kevin Marks and Ryan King of Technorati are leading a process for defining Microformats, which drives the problems of tag identity and tag spaces. Nitin Borwankar has been working on the data model level of the stack.  Thomas Vander Wal is developing applications that reason across tag spaces. Special thanks to Esther Dyson, Sergei Lopatin, Mika Illouz, and Erik Haugo for suggestions on the draft.

REFERENCES