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

Tom Gruber
tomgruber.org andRealTravel.com
Summary
Ontologies are enabling technology for the Semantic Web.  They are a means for people to state what they mean by formal terms used in data that they might generate or consume.  Folksonomies are an emergent phenomenon of the social web.  They are created as people associate terms with content that they generate or consume.  Recently the two ideas have been put into opposition, as if they were right and left poles of a political spectrum.  This piece is an attempt to shed some cool light on the subject, and to preview some new work that applies the two ideas together to enable an Internet ecology for folksonomies.
1.    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"[1].    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[2].  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[3]. 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.
2.    Folksonomy as data that is emergent from shared information
Not so long ago, keen observers of the Internet[4],[5],[6] and inventors of social software[7],[8] 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[4].  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.
3.    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 now-famous blog[9], Clay Shirky 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, 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 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 (every word is a tag) and index reference materials (domain specific 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[10].
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 feedback.  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.
4.    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.  I have built a "Web 2.0" product that has user contributed content, social networking, and tagging.  I want to join forces with my colleagues in the tagging community[11] to help build the infrastructure that will enable my system 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.
5.    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.  (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 as about 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[12], 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 internal coherence 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 [3].  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 some 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, etc.).
6.    Conclusion - work in progress
The tag ontology introduced in this piece is a work in progress, and very early in the process.  In this writing, I have tried to lay out some of the design issues and challenges.  The process for developing the ontology is open, with a working group orchestrating how issues are laid out for work by different teams.   The evolving specification will be published under the URL tagontology.org and the working group is operating under the name tagcommons.org.  If you are interested in contributing, please visit tagcommons.org and sign up.
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 call TagCamp.  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 is 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.  Special thanks to Esther Dyson, Sergei Lopatin, Mika Illouz, and Erik Haugo for suggestions on the draft.
References
[1] Robert Neches, Richard Fikes, Tim Finin, Thomas Gruber, Ramesh Patil, Ted Senator, and William R. Swartout (1991). Enabling technology for knowledge sharing. AI Magazine, 12(3):16-36, 1991.  Available athttp://www.aaai.org/Library/Magazine/Vol12/12-03/Papers/AIMag12-03-004.pdf
[2] Tim Berners-Lee, James Hendler, and Ora Lassila: “The Semantic Web”, Scientific American, May 2001. http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21
[3] Thomas R. Gruber (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 1993, pp. 199-220. http://tomgruber.org/writing/ontolingua-kaj-1993.htm andhttp://www-ksl.stanford.edu/kst/what-is-an-ontology.html
[4] Thomas Vander Wal, Off the Top: Folksonomy.http://www.vanderwal.net/random/category.php?cat=153
[5] Bruce Sterling, Order Out of Chaos, Wired 13.04, April 2005.http://www.wired.com/wired/archive/13.04/view.html?pg=4
[6] Katharine Mieszkowski, Steal this bookmark!, Salon, Feb. 8, 2005
http://www.salon.com/tech/feature/2005/02/08/tagging/
[7] Joshua Shachter, inventor of del.cious.us,http://del.icio.us/joshua
See alsoarticle on del.icio.us in PC week
[8] Caterina Fake and Stewart Butterfield, inventors of Flickr,http://blog.flickr.com
[9] Clay Shirky, Ontology is Overrated: Categories, Links, and Tags.  http://shirky.com/writings/ontology_overrated.html
[10] For example, the CIDOC Conceptual Reference Model ,http://cidoc.ics.forth.gr/index.html
[11] TagCamp,http://tagcamp.org/ andhttp://tagcamp.org/index.cgi?TagInfrastructure in particular
[12] Thomas Gruber. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal Human-Computer Studies 43, p.907-928.http://tomgruber.org/writing/onto-design.htm