Experiences with Fuzzzy social bookmarking and ontology creation

Fuzzzy.com is a social bookmarking tool with a twist. It lets users add and share bookmarks but it also has a folktology (mix between folksonomy and ontology) where users can create tags that have meaningful relations between them. Some of the things you can do on fuzzzy.com is to create tags, create tags relations between tags. Vote on relations between tags and between bookmarks and tags. With this voting feature you over time evolve more relevant tag-bookmark and tag-tag relations.  

In this blog post I'll share some of my experiences with folktologies. Unfortunately I don't have an updated scientific study for the fuzzzy.com's folktology so you'll have to do with my personal observations. To learn more about fuzzzy.com and the folktology read my paper Metadata Creation in Socio-semantic Tagging Systems: Towards Holistic Knowledge Creation and Interchange.

Folksonomies, as we have come to know them on many social media sites, let users create any tag. This tag becomes available to everyone else. An Ontology on the other hand is a set of concepts within a domain, and the relationships between those concepts. Ontologies are the backbone of the Semantic Web so Fuzzzy was a project to see if the imprecise folksonomies could be replaced with more semantic folktologies. Some of the problems with folksonomies are synonyms, ambiguous tags, overly personalised and inexact, homonyms, plural and singular forms, conjugated words and compound words etc [1]. While folksonomies work just fine for a blog, it does not scale as well if semantics is important. As the folksonomy grows it grows into a large flat list of tags where a large percentage of tags just don't make any sense. To fix this problem they usually just show the tags that are used most frequently.

How the folktology of fuzzzy.com was used
A folktology seemed to be a smart use of Topic Maps. The folktology was seen as a way to make tagging more semantic but here's what happened:

• Few users created relations between tags.
• Few users assigned subject identifiers (needed to tell tags apart or if they represented the same thing) 
• Few users voted on relations between tags.
• Few users voted on relations between tags and bookmarks.

Users did however use tags as if they were folksonomies. Users created both tags and bookmarks and added tags to bookmarks. Tags did have better quality [3] as users could edit tags and make them more consistent.  Tags where more intuitive and made more sense when used on bookmarks. Common folksonomy problems such as synonyms, ambiguity, overly personalised, homonyms, plural and singular form tags etc were to a large degree weeded out.

I can only speculate on why the new way of using tags (Fuzzzy folktology) was not more adopted. Here's my personal hunches. I don't think there was a single reason but a mix:

• People did already have a fixed view on how tagging should work and did not care to learn about the other tag features. 
• People are in a hurry when tagging. They bookmark because thy don't have time to read the webpage. So its very important to be able to add bookmarks quickly and to assign tags just as quick.
• Bookmarking is personal even if you use a social service. Every user has their own reasons for saving those particular bookmarks so he or she has no incentives to create an pretty shared ontology/tag network.
• The rewards for creating tag to tag relations are perceived as low. Users don't see a direct value. With a built out folktology or semantic network, users can have more relevant bookmarks suggested to them. This is obviously a nice to have feature but it does not justify the work that goes into managing the folktology.   
• The advanced tagging features becomes overkill and a source for cognitive overload for regular web users.

These interpretations are based on typical use of the system. Analyzing this further we begin to see contours of some general underlying issues.

Problems with a folktology
The social and semantic bookmarking service fuzzzy.com has a shared semantic tag set. This introduces several issues in comparison to plain and simple folksonomies. I summarize these issues as context and authority.

• Who gets to update the individual tags? A tag is shared and reused by all. If a person decides to create a tag, say “vintage furniture” and another person want to use the same tag but would rather have a different description for the tag, or maybe he thinks the tag should have a different name all together. (Language and vocabularies naturally evolve over time). Then what? Who gets to decide? The meaning of a tag all depends on the context of the person. His situation and background will decide what is meaningful to him. No two persons has the exact same context.
• For tags to be semantically interoperable it needs to have an addressable identifier (a PSI in Topic Maps jargon) and a particular semiotic meaning attached to the tag. An authority or other entity must make sure the Id and the meaning of the tags are fairly stable. In an open web environment this is not trivial. 
• One persons definition of a term might be slightly different from the other person because they have different backgrounds. It would not be right to force them to use a definition that does not reflect how they see the world.
• What if a tag name is to be changed because language is changing. If it is changed other users might not find what they are looking for. In this case one might present old tag names marked as deprecated etc but it still enforces a new world view onto users. In some cases (maybe on a corporate Intranet) this might be a good thing.
• Who will garden and have the last say? What if a user want to delete a semantic tag he has created but this tag have been adopted and used by many other users?

Comparing folksonomies and folktologies are not straight forward. In general we can say that a folksonomy provide more serendipity and discovery and the folktology provides more semantics that can be used to provide more relevant or contextual aware content.

Conclusion
An ontology is a generic, commonly agreed upon specification of a conceptualization of a domain [2]. This definition is not compatible with open online social web 2.0 environments where people do not have a shared understanding. This and the above mentioned issues suggest that a folktology such as on fuzzzy.com is best suited for personal use or for coherent teams that have large amount of bookmarks.

To fix these folktology issues a solution could be to have personal topic maps which overlap with other users topics maps. For this to work with some degree of semanticity you could have subject identifiers for each node or deduce node similarity from looking at naming and nodes close by.

References

• [1] Folksonomies Tidying up Tags?
• [2] A Formal Ontology on User Interfaces – Yet Another User Interface Description Language?
  
• [3] Metadata Creation in Socio-semantic Tagging Systems: Towards Holistic Knowledge Creation and Interchange

Checklist for deciding implementing Topic Maps

When should I go for Topic Maps? Why should I use Topic Maps and where do we use use Topic Maps? As a system developer or architect you may have asked these questions. The use of Topic Maps does undoubtedly increase complexity of an IT development project but at the same time does provide other very valuable benefits in comparison to plain relational databases.

This checklist can be used as a tool to decide if to use Topic Maps technology. Note that this only discuss using the Topic Maps paradigm, it does not discuss to what extent is should be used or on what parts of the system etc.

[ ] We need a flexible data model (3)
Do you need to model and represent knowledge that is evolving (evolving ontology), where concepts, their metatypes and relations change over time? Do you have information consisting of diverse concepts and need to make distinctions between their type, their relations and the roles the associations play among each other and you are not sure if this conceptualization will change in the future?

[ ] We need a high degree of (semantic) interoperability (2)
With Topic Maps PSI’s you get a strong and accurate identification of subjects between loosely coupled systems. Do you need to represent knowledge such as “Oslo is in Norway, Oslo is a City and Norway is a country”? With Topic Maps this can be expressed in interoperable formats that make sense to both humans and computers. Topic Maps enable import and export of both complete knowledge structures and of fragments only.

[ ] We need to merge semantic information or arbitrary knowledge from diverse sources (2)
Merging is a built in feature of the Topic Maps standard. Queries on the data will work after a merge.

[ ] We are developing a knowledge centric application (1)
Are you going to integrate or build a Knowledge Management system where knowledge generation, codification, and transfer is essential? Is there a need for a paradigm that can collate everything known about any given set of subjects? Do you need a Ontology (a conceptualization of a domain)? Do you have users that will want to interact with the system to create new knowledge? When using Topic Maps people often see new potential relations and thus increasing knowledge leading to new insight, innovation etc.

[ ] We need a technology to access information using different criteria or navigation paths (1)
Do you need a technology that is tailored for displaying multiple navigational aids or multiple views/paths in a networked information structure? Built into the standard is the concept of scopes that let the modeler contextualize information. With Topic Maps you get two-way or navigation. If you need to provide faceted navigation or search where users navigate by related concepts, then Topic Maps may fit your needs because of its support for bidirectional associations and scopes.

[ ] We need a strong separation between metadata and resources (1)
Do you have persons that work with metadata and others that add or edit resources? For instance your organization might have a vocabulary that is maintained by a set of dedicated specialists and you might have authors that create content which is categorized with the taxonomy. Is there a need to manage some form of complex networked information structure or other information structure such as a controlled vocabulary, concept map or taxonomy?

[ ] We have a strategic goal to be among the first to adopt new technologies (1)
Topic Maps is similar or complementary to the Semantic Web initiative, which are seen by many as the precursor for Web3.0 and eventually the raise of Artificial Intelligence and collective wisdom for the web. For many organizations it is a marketing strategy to identify itself with such technologies.

Conclusion
Add the points for each of the sections you answered yes to. The points are indicated from 1 to 3 at the right-hand side of each section. If you got a sum of 3 or more points you might have a good reason for embarking on a Topic Map development project.

Topic Maps pros and cons in comparison to Relational databases

Pros
Provides a semantic interoperable knowledge structure for use by both humans and machines. It will give you tremendous power in modelling a domain. Topic Maps have built in constructs to make changes to a model less painstaking after the system have been deployed and is in production. Last but not least, Topic Maps is an enabling technology that opens up new possibilities for use of the embedded knowledge within the Topic Map.

Cons
Topic Maps projects require more development time. It often leads to highly increased complexity, which again results in systems that are harder to maintain and require special competence. It also requires large amount of cognitive efforts under specification, design and development. Topic Maps also increase the risk in the project due to higher complexity and higher demands on competence. It will often require higher demands on computer hardware because of more complex database processing.

Last updated 5. April 2008.

Why was fuzzzy developed

Fuzzzy was part of Roy Lachica's masters' thesis. The purpose of the project was to:

1. Test a new type of metadata categorization, namely the "folktology" (folk + ontology) a semantic tagging system which resembles folksonomies but are built on Topic Maps.
2. To investigate polyscopic, democratic, collaborative and holistic aspects of knowledge creation.
3. For personal benefits. To learn Topic Maps and to become more nerd.