Techdirt is on holiday this Thursday and Friday. We'll be back with our regular posts on the weekend!Hide

Insight Community

Closed: 20 Nov 2007, 11:59PM PT

Earn up to $300 for Insights on this case.


Do Tagging and Folksonomies Fit Into The Enterprise?

Dow Jones is looking for submissions that will be distributed in its upcoming social media round table and then incorporated into a whitepaper associated with that event.

Folksonomies and taxonomies in the Enterprise will be the main topic of discussion. With social software applications gaining in popularity across the web, collaborative tagging, or folksonomy, has emerged as a popular way to organize ideas. These tools have made information more accessible on consumer sites such as and Flickr.

Now, businesses are starting to take notice. What are some best practices for implementing social tagging and folksonomies in the Enterprise? For example, how do you manage and merge folksonomies and existing taxonomies? Do folksonomies and taxonomies even belong in the corporate environment?

14 Insights


Why not just open a corporate branch of  There are many open-source alternatives to that could be implemented on a single server by an experienced admin in a few hours.  Once setup, this tagging environment could be made available internally for use by employees.  The success of social networking and collaboration tools revolves around one thing : the tools' availability. If everyone has access, then the tool can develop into something useful.  


Corporations have an obligation to moderate the use of such tools to make sure that their primary focus is the business.  A single admin or elected moderators can contribute a tiny portion of their time, and since the majority of posts will be work-related anyhow from the implied ethics rules of most organizations, it should be far easier to moderate an internal community site than a true public site. 


Many of these tools take a long time for a critical mass of items to be entered, to where the tool becomes very useful.  This time is extended by virtue of the limited number of people with access. However, corporations may be able to license a copy of the true public open-source tags as a read-only, single copy down into their internal network.  This way, they gain a critical mass of content right away, and employees can switch off of the public tool and onto the internal tool.

Many of these internal tools must have rules setup about sharing confidential material.  Providing secure, tiered access so that confidential and secret material can be shared amongst the relevant parties is the future of corporate community tools. 

This strikes me as an overly broad question. "The enterprise" is a big place, and there are doubtless lots of places where various enterprises could make use of folksonomies. Folksonomies seem to me more like a (relatively minor) feature you'd add to an existing enterprise application than a major new "social software" initiative. Any time you have a database-driven application--internal documentation, a bug-tracking or trouble-ticket system, a CRM database, etc--it makes sense to add a capability for users to add free-form tags to each record, and then to search based on those tags to find information they're looking for.

Adding tagging abilities to an application is relatively easy and has very little downside, so any corporation with a suitable application might as well put it on their development staff (or vendor)'s to-do list. The more important question is when it's worth making a serious investment in training users how to use it. Because in most cases, simply adding the feature to applications isn't going to spur mass adoption by your employees. Most won't even notice the addition, and the few that do probably won't understand the point. For a large enterprise, deploying the technology is likely to be cheaper than the training effort needed to make it effective.

I think the basic (if somewhat obvious) answer is that companies should only spend resources promoting folksonomies if their existing software has deficiencies that widespread use of folksonomies would solve. The best candidates for productive use of folksonomies are applications in which a lot of people are looking at the same records, and in which users have trouble finding the records they're looking for. If only one or two users looks at a typical record, there's obviously little value in adding tags. Conversely, if your database is already so well-organized that users have no difficulty finding the records they need, there's no reason to invest resources in creating another, redundant searching mechanism.

The trick to making folksonomies work is to get your users in the habit of adding tags on a regular basis. If there aren't a critical number of tags in the system, searching will be useless and so users won't understand the point of using them. So the goal should be for every user to add at least a couple of tags to every record she creates. That will probably require a significant investment in training, sitting down with each user and walking her through the process of adding tags and searching on tags. It would be a good idea to pre-populate a few dozen records with helpful tags so that a user's first few searches will turn up something useful. That will build user enthusiasm for further tagging.

One way to jump-start the process is to provide users a pre-defined list of "basic" tags and require users to enter at least one of those basic tags for every record. And even more aggressive approach would be to remove one or more fields that used to be pop-up menus or text boxes, and require that users enter the information in those fields as tags instead. Obviously, it's important to choose those fields carefully so that it doesn't braek any current functionality users have come to rely on.

One final point: social media is ultimately user-driven, so management should be prepared for the possibility that users will find tagging unhelpful and resist using it. Don't push it too far. Users almost always know more about the usability of their applications than do IT staff or management. If, after a serious training effort, users continue to resist using a tool, that's a good sign that it's either not needed or not well designed. Tagging should be seen as an experiment. If users believe it doesn't help them get their job done, no amount of brow-beating is going to change their minds. If users don't like the feature, management should be prepared to quietly drop it.

Timothy Lee
Thu Nov 8 10:23am
One other comment on integrating with existing taxonomies: the best policy is probably just to use the two side-by-side for a while and observe how users take to tagging. One of two things will happen: either users will love tagging and the taxonomy will become redundant, or users will hate tagging and the traditional taxonomy will continue to be essential. It would be a big mistake to phase out the old taxonomy before the new folksonomy has proven to be a hit.

If users embrace folksonomies, converting the taxonomy should be fairly straightforward; most likely you can just convert each taxonomy category into a corresponding tag or set of tags.
Case Sponsor
Daniela Barbosa
Sun Dec 16 3:52pm
Thanks for your Insight.

I think you make some good point on adoption and change management that is certainly being observed in enterprises that are starting to implement social tagging in their companies at different levels.

You are also right that the Enterprise is a big place and we could have been more specific in our request- but some of the Insights like yours in which you comment on the applications that that it can be used with value and specifically 'philipp's' Insight was valuable and if we had left it very targeted we might not have exposed those thoughts which are important ones to keep in mind when evaluating whether tagging in one's company is appropriate.

The fundamental insight that anyone looking to take advantage of a folksonomy must understand is what is sometimes called the " lesson" in usability circles.  The premise is simple.  Before community wide value can be extracted from a folksonomy, it must provide value to the individual.  People will not effectively tag things if they are simply asked to do it for the benefit of the community.  Their motivation must be selfish.  The system should be saying, "you should tag this because it will help you to organize your own things."  The benefit to the community is a fortunate by-product of the selfish actions of many.  

On it's easy to see how this has been put in action.  Each person uses tags to organize their own large collection of bookmarks.  When many people do this, the tagging overlap leads to rather interesting correlations across the entire user-base.  The same thing happens on Flickr.  Each person uses tags to better organize their own large photo collection.  When many people do this, we find that a useful community wide folksonomy emerges.  

If this lesson is applied properly, there is no reason that a folksonomy couldn't be used to aid in the organization and discovery of information on corporate intranets.  As long as each individual or team is given the tools to tag their own documents or wiki-pages in order to make them easier to browse for themselves, then this practice will gain some traction throughout the organization.  Once many people begin to tag things for their own benefit, a community folksonomy will emerge that will no doubt be useful as well.  It will help to spread knowledge across units as commonalities in purpose will naturally emerge. 

More on the lesson: 




Sean McClowry, Andreas Rindler and I had a very fruitful session talking about Enterprise 2.0 yesterday. In large part the conversation revolved around recognizing business worthy ideas and turning into robust, corporate-ready assets embraced enterprise wide. I touched on this a couple of months ago when talking about maturing innovation.

Sean has done a great job creating a taxonomy for information management over at (disclaimer: I’m affiliated with openmethdology through my company) and we focused mainly on how to harness assets “organically conceived” in the Enterprise 2.0 cloud by mapping them to our taxonomy of mature intellectual property without losing the crowd’s perspective on said assets.

We came up with a scheme whereby ideas in the Enterprise 2.0 ecosystem can be socially bookmarked and tagged, much as one would do on delicious. But in this scheme the user is also presented with the enterprise taxonomy, along with “tooltips” (thanks Andreas for that term) to explain the taxonomy to the user. The user then selects the category from the taxonomy to classify the idea with other corporate assets.

What’s beautiful about this system is that we get two perspectives on ideas/information:

  1. A corporate view based on a pre-conceived taxonomy. This groups an “immature” Enterprise 2.0 asset with a “mature” corporate knowledge asset and prepares the former for corporate assimilation at the identified level in the taxonomy. Or, if an Editor so chooses, he may associate the asset with a different category.
  2. The user’s perspective of the asset (a.k.a his tags) is not lost. So for every Enterprise 2.0-generated idea that is matured into the taxonomy we maintain the “crowd’s perspective”. This means categories (corporate view) in the corporate taxonomy will also be related to tags (user’s view).

This is an area that is often neglected when we talk about Enterprise 2.0. The process of maturing ideas often means integrating social computing (E2.0), with more controlled content management systems requiring mediation before ideas are recognized as corporate strategy, policy etc. I think it’s here that the old world meets the new.


First of all, you have to consider what the purpose of tagging your data is. Social tagging helps data to be better found and used. However, the data has to be widely available for this to work. If data is widely available it loses its value, and becomes harder to control.

When used as a way to organise ideas, a large amount of input is needed to gain a lexical profile of how data might appear across a population. If a small or closed workgroup is used to delineate a piece of data, it will only remain useful to the original group, or to another group who are aware of the make-up of the first, or the data. Thus creating more data, or metadata to be analysed along with the original data; or meaning that the data has to be visible and highly available in the first instance. This can add complexity to a system designed to create usefulness and simplicity, or introduce security issues where it is not necessary to do so.

If the data is sensitive in any way, access will only be permitted to a defined (closed) group. If tagging is to be used it is better to allow the system of tagging to be closed/limited as well, so that data can be classified rather than just tagged. This can include security tags for keeping the data safe and not leaked outside the original sample workgroup. However, this is not folksonomy, this is data classification and an altogether different issue. Classification and folksonomy are close but do not overlap. Classification is a regimented closed system which can be used to define data and is dependent on an overarching administrator or system. Folksonomy defines data on the fly, relying on nothing but the imagination of the user identifying their opinion of the data at that moment. Folksonomy has an almost unlimited scope of defining data, but is therefore only useful when the sample is large.

Imagine that ten people have seen an image, for example of a dog, and all ten decide that it is a dog, so tag it as such. When someone wants to search for a dog, the result is relatively easy. However, imagine the picture is tagged by 3 users as 'dog' 2 as 'animal' 1 as 'quadruped' and 2 as 'canine' and 2 as 'scottie'. Imagine that 1 can't spell very well and calls it a 'scotie'. Imagine one is in a hurry and designates it a 'god'. We now have 7 different tags for 1 picture, some of which may never be used. Only 20% of which would show up in a search for 'dog', even though the image is obviously of a dog.

Increase the sample to 1000, and the number and inaccuracy of tags increases, unless the system of definition is closed. If only a certain number of tags are available, the data will be defined less accurately, but more usefully to a system. If an unlimited number of tags are available, the data can be defined more accurately, and the statistically insignificant tags can be ignored when searching for it. To achieve this however, the number of users needs to be unlimited, the data needs to be insensitive, and widely available.

So, for a folksonomy to work in a corporate environment, you need not to be concerned about the sensitivity of the data you are tagging, or to close the system and let only a certain number of tags be used, which means that the system containing the data can have more control over it, but the data will not be so well described - which may limit the sharing of ideas. 

Rob Newby
Mon Nov 12 5:27pm
And integrating with existing taxonomies should be possible to just mix together as long as the systems are not closed. The base you are picking from is always the same, infinite.
Case Sponsor
Daniela Barbosa
Sun Dec 16 4:16pm
Thanks for you Insight.

Critical Mass was certainly a topic that came up quite a bit in our recent round table on this subject. Question came up on when does Critical Mass become an issue- for example if a specific group is very proactive in tagging while others aren't would it 'drown' out the other voices?

What if there was large engagement with tagging at a specific time and then it ebbs? For example a change in the company retirement plan made everyone tag a specific intranet article on the changes 1 yr ago when tagging was 'hot' so everyone tagged that article- now a new retirement plan is posted but not many people tag or only do tag when they see value in their specific domain and not corporate type news- so the new relevant information will never be the first result or be presented in a tag cloud etc. Hence the need for "Editors" and business rules.

One of the areas least exploited in social media research is the automated focus group.  We can measure people very well now and if we can recombine them into interactive online focus groups, we can achieve folksonomies that are much more accurate to group will and interest.  

There are lots of interesting ways to do this, but the real killer app of focus groups online has yet to emerge.  It is a wonderful start-up opportunity.

Folksonomies work when a critical number of participants are willing to invest time into improving the framework of their work environment, without any direct payoff. Folksonomies can be generated as the an unintended consequence of individual action or as the intended acts of socially minded participants.

Ronald Coase would have tried to take a shot at the question on the level of abstraction it was posed on: Markets tag products and services with prices as an unintended byproduct of supply meeting demand (folksonomy), while firms classify inputs strategically (taxonomy). So, he would argue no folksonomies inside the firm. However, with the introduction of cost centers, internal markets, flattened hierarchies, and the networked enterprise, the question becomes more complicated. It is has two aspects, namely:

a. How do we work? - do we play our role in a given hierarchy or do we work as problem-solvers.

b. Why do we work? - do we work because of incentives or do we identify with the problem-solving.

Depending on the combination of "how" and "why" the work environment will be conducive for folksonomies. So we have the following combinations:

(1) We play a role and are incentivized to work, example: any McJob [folksonomies will not play a big rolel].

(2) We play a role and identify with the problem-solving, example: medical personnel, police, etc. [folksonomies could work].

(3) We are problem-solvers and work for incentives, example: finance, techdirt-community [folksonomies might work if a mid-term monetary incentive is given].

(4) We are problem-solvers and identify with problem-solving, example: open source developers, some creative jobs [folksonomies will fly].

 So the question cannot be answered on the level of abstraction it was posed, however, it can help us to distinguish between the contexts in which it makes sense to introduce folksonomies as a tool. 





Case Sponsor
Daniela Barbosa
Sun Dec 16 4:19pm
Thanks for your Insight- these are some great questions that all companies should ask themselves as they start to investigate the corporate use of tagging.

Taxonomies reflect the ideas of a certain group of people, e.g. organizing library books by genre. Folksonomy is organization by the people, which often doesn't reflect the ideas of the "learned class". I can see using taxonomy as a way to "block organize" things into broad categories then allow the users to assign their own tags. This will reflect the apparent and actual use of an item better than an arbitrary classification.

For example, my organization deals with intelligence information, both documents and images. Much of the data is broadly classified by country, vehicle type, area of concern, etc. It's very difficult to reuse this data because it simply can't be easily found in the current search engines; there is too much noise in the system. This leads to individuals keeping copies on their computers and having to send emails back and forth when other people want to use it. If there was a central repository that is easily searched, many of these problems could be reduced.

The information is already organized via a taxonomy system. If a tagging system was introduced, allowing users to add their own descriptions of the files, it could make the information much more useful. People often describe things the same way, especially like-minded people doing the same job. Therefore, allowing them to describe something in their own words makes it more likely that a positive search will come up.

The metadata could be stored with the file to make it more useful later on, such as an XML document, database field, or other method. This would not only allow the search engine to use the tags but other programs a company may implement could potentially use the metadata also.

The use of collaborative tagging empowers the workers but also leverages the power of the group mind. Just like this Insight Community, many people have similar ideas while others have different ones; together they can create a useful pattern of information.

There's a clear distinction that should be understood between folksonomies and existing taxonomies within organizations which is primarily one of consistency and the benefits derived from using each.

Taxonomies attempt to classify information in ways that address specific business issues. Whether the enterprise is using automated classification tools to categorize the information consistently or is having people do this manually, the taxonomy has inherent value in its structure and desire to facilitate responding to very specific and important questions that the organization is trying to address.  In other words, taxonomies address issues of context.

Folksonomies on the other hand, are meant to be unobstructed and unencumbered by structure. They are meant to reflect the agendas of those tagging the information (the "taggers"), though those tags may also at times apply to other users' needs. Because tags are dependent on the agenda of the tagger, it means that they may not necessarily reflect or help provide answers to issues the organization as a whole may care about. This, however, should not diminish their value since the tagger clearly benefits from this tagging and as a contributor to the organization, is having their life made more productive, which in turn is good for the organization.  The results of the tagging activity may also provide the organization with insights previously obscured by its singularity of context.  In other words, it may provide other ways to look at information that provide useful out-of-the-box perspectives.

Folksonomies are also excellent tools to help identify non-textual information such as images or audio content, where automated classification technologies do not generally tackle this problem well. Hence, this is an area that could greatly benefit from tagging, whether in a structured taxonomical format or in a purely free-form basis.

The reason folksonomies thrived in services such as Flickr and, has more to do with the fact that the need of the individuals was purely selfish and not an organizational one. Hence, it is good to look on these examples to understand that the sum of the selfish acts can provide great benefit to the whole, but that benefit is not necessarily the same as what is gained from taxonomical approaches. For every great example of the usefulness of folksonomy, one can show the irrelevance of a tag due to a context foreign to the need of the searcher. Taxonomies bring with them context, whereas folksonomies do not inherently provide context, at least not in a manner that is always clear and consistent for the searcher.

Case Sponsor
Daniela Barbosa
Sun Dec 16 4:00pm
Thanks for your Insight.

Some of the other Insights recommend that either the systems are pre-populated with suggested tags or automation of tags and then letting the user select from a predefined list and potentially add their own- would you considered that a Folksonomy?
Pierre Wolff
Sun Dec 16 7:59pm
I'd say that the pre-populated part enables the organization to solve its predefined requirements (the stuff it's trying to solve through this categorization exercise). The part where users can add their own is consistent with the folksonomy side of things, letting users take advantage of the platform to also solve their own probs in addition to the organization's. For the org, the additional benefit is one of externalities, where it may gain some additional insights fm the folksonomy exercise that could yield unspecified benefits.

The idea of folksonomies came about partially as a response to the constraints of taxonomies. They help people organize data in a way that makes sense for themselves using freeform tagging of pieces of data. When the tags are aggregated the network that uses the data can retrieve data more easily. This is due to the emergent nature of tagging. Tagging has existed in the enterprise for some time In Lotus Notes[1]. But the use of aggregated folksonomies are a slightly different and new take on the idea.

The use of folksonomies in social software (in something such as, for example) in an enterprise setting can be a direct challenge to the command-and-control style of some organizations. Taxonomies, on the other hand, fit more with authoritarian style of management. Folksonomies are emergent, and emergence cannot be controlled. What weary executives need to keep in mind is that folksonomies are used to help individuals make more sense of their work, and this increases productivity, which helps the bottom line. Taxonomies force workers to adapt to a style that may be counterproductive to his or her way of thinking. If an enterprise is interested in increasing productivity, they should be interested in folksonomies. There is no need to merge folksonomies and taxonomies since they are the antithesis of each other. They can and should exist separately.

There are two places were taxonomies and folksonomies may present themselves as useful in the enterprise. Knowledge management systems[2], and what you might call “contact relationship management” or organizing e-mail archives based on people, topics, or actions required. In his book Getting Things Done, David Allen suggests creating folders with an @ at the beginning of the folder name as way to separate from your reference folders. But the idea could be taken beyond keeping e-mails in folders for references.

Companies can also make it possible for consumer to tag items on their website in order to find items more easily. Amazon has experimented with this recently by allowing customers to tag items. Some consumers have used the tagging system to negatively criticize products. Instead of simply moderating negative tags, both Amazon and their vendors could use the opportunity to address concerns and improve products and services. Let go of control to gain insights.

In some enterprises, tagging and folksonomies may need to come in slightly under the radar in order for them to take off, similarly to intranet blogs that are started without permission. It might take that same creative and daring IT person to get them implemented. And, like enterprise wiki adoption, not everyone will use tagging at first, and incentives should not be given from the top down use them[3]. People will need to discover the value of tagging by experiencing it in the enterprise first hand, as well as blogging and wikis for that matter. All of these tools are new (new is scary), and have the intention of democratizing information. Adoption of these tools takes place slowly, first by early adopters who evangelizes them, and then spread slowly through the organization. Eventually, everyone is using the tools and cannot imagine how they survived without them. Anyone who has a problem with the democratization of information within a enterprise by that time will appear as a luddite, and thus they are not longer a fit for that enterprise.

Check out blog posts about folksonomies by the man who coined the term, Thomas Vander Wal.

One company selling a service that allows for tagging for intranets is Connect Beam.



[1] A Stale State of Tagging? By Thomas Vander Wal

[2] Knolwedg Mangment on Wikipedia

[3] An Adoption Strategy for Social Software in the Enterprise by Ross Mayfield

The word folksonomy implies an open and decentralized system where tags are supplied by anyone accessing the system. Enterprises worry that this can lead to inconsistency — but it doesn't have to.

Users should be educated about the enterprise's tagging policy. Otherwise, even the most obvious tags can create problems. Here's some examples.

  • Abbreviations. Is it "General Motors" or "GM"?
  • Alternate spellings. Will the CEO's name include his middle initial?
  • Capitalization. What happens if a user types "nbc" instead of "NBC"?
But even then, there's simple ways to work around these small differences. One option is including all possible spellings of each tag on every relevant document. Another option involves building that intelligence into your tag-searching system. (If a user types in "GM," the system would also return documents tagged with "General Motors.")

Sometimes it's also possible to offer users a pre-defined list of tags — for example, requiring that they specify the region and department that's producing the document. But inevitably there will be situations which don't fit into a narrow set of choices, so it's always a good idea to include an "other" option where users can create new tags.

In most cases, there's even simpler solutions. Depending on the number of documents, it might be possible to have in-house experts review all the incoming documents' tags for consistency. Some companies even dedicate a "data cleaning" panel for periodically updating the tags on all documents. But remember that the whole idea of "collective" tagging assumes that the labor can be distributed among many users, each performing a small amount of the work. There's a common principle which applies to collaborative projects — with enough eyeballs, most errors are easy to spot. Even with a centralized "tag review" team, users should still be involved in the editing process, or at the very least allowed to interact easily with the team.

Some enterprises even "hard wire" some document tagging. If the enterprise uses a web page for uploading documents, it's possible to "enforce" a tagging requirement by refusing to let a user save a document unless they've also entered tags. It's sometimes even possible to automatically scan an incoming document and suggest tags based on the use of words associated with popular existing tags.

Remember that a folksonomy is a "living system" — constantly being updated based on the activities of the entire user base. So one of the most helpful practices is monitoring which searches are being performed on the company's tags. This identifies the tags which are most important — and which tagging errors are creating the most problems.

And it also ultimately serves as a reminder of how valuable a good folksonomy can be.

Case Sponsor
Daniela Barbosa
Sun Dec 16 4:05pm
Thanks for your Insight.

I have seen some great examples of companies that are using a combination of some of the items you present here from automatically scanning documents and suggesting tags to having in-house experts 'approve' the applied tags. These thoughts however seem to be focused on internally produced content only- do you see this same solution being applicable to external content that is either found by the user on various web sites or provided by content aggregators- is there value in providing the added assistance for content that is consumed but not produced in the Enterprise itself?
David Cassel
Mon Dec 17 12:06am
It's hard to talk in generalities, but let me answer the question by sharing some examples from my own experience.

When biotechnology started heating up in the 90s, I worked for a
startup in Northern California which used the industry's one definitive (and proprietary) database for medical reference articles. Its owner would license installations, along with searching software, and I assumed it'd be difficult to integrate that into any internal "universe" of documents.

More recently, I worked for Kaiser Permante. There the biggest concern was the confidentiality of patient information. (There's new federal legislation which identifies specific, stringent safeguards which apply to any network containing sensitive personal information.) For this reason, integrating internal and external systems was strictly forbidden.

This seems to imply that it would be hard to set up a dedicated internal interface for external documents -- but not necessarily. In most cases, any external folksonomy is designed with searches in mind, so there's already a search engine and, more importantly, a search engine API. Any motivated geek in your company can rig up a quick interface optimized for your specific needs.

We've seen Google create search tools for your own personal hard drive (which I believe offers the option of including search results from
the web.) So it's not too hard to imagine a search tool for your corporate network which combines internal and external documents, while applying your own homegrown folksonomies.

Within a business, these new social tagging and folksonomy tools present the opportunity for members across teams and across offices to collaborate without physical limitations or wasting the time needed to hold brainstorming type meetings.

 The best practice for implementing these types of tools is to start fresh and use them for what they can do rather than trying to apply them to your existing structural system: tagging is meant to be structured creativity, allowing users to advance without having to start at the very beginning: the same should be true if it's too be used at the enterprise level.

I don't believe folksonomy should be merge into the exsisting hierarchtical structure.  It works well online because the Internet is a space that is completley horizontal, without vertical superiority and that's the best way for free though to flow in social media.  Hence the term 'viral,' if the social web had any sort of taxonomy (outside of google trying to take over things) it wouldn't be the viral web, it'd be 'orders.'  The second a suggestion comes from existing taxonomies it's no longer free-thought, it's an order.  

So, folksonomies bring the opportunity to take a hierarchical organization, especially one spread across geographies, and bring it back to the startup level, to the level playing field, where everyone's thoughts and idea are equally waited, and the community takes the best one and uses it as a stepping stone to move forward.

 For many entrenched businesses with traditional models and little room for innovation, implementing social tools will be too much of a headache.   There are easier ways to give lower employees a voice.

 However, for companies swept along the technology ride looking to grow, innovate, and adapt to the new markets, using folksonomy tools within their intranet to build on leads, product tests, and sales channels has great potential.  

 1st, it must be annonymous.  Free thought is stopped if one feels their comments could affect their next paycheck.

2nd, there must be movement.  A stagnant space allowing employees to comment is not a folksonomy, it's a forum.  It must go somewhere, and most likely someone must help steer it, allowing the group effort to move toward something actionable.

3rd, it must be open, without a strong taxonomy, putting the ceo on the level of the receptionists; plus that gives even the mailroom guys a space to present the next great company innovation.


Folksonomies fit in an organization if the taxonomy, at least in that intranet state, is dropped, and if the company is willing to give some power back to it's employees. 

Of course folksonomies (FK) belong in the corporate environment. The do because they are a very "human" way of organizing data based on importance, and relevance.

In some senses, folksonomies have always existed in the enterprise: water cooler chatter, and conversations at the campus cafeteria have always self selected the topics that humans find most interesting. Say it's 1980. Corporations have lots of info stored in file cabinets. If everyone in a corporation comes across slightly different information, chances are one of them will come across some little-know but useful fact. Could be product info, or some HR policy that is particularly interesting. The person that finds it and thinks it relevant would talk about it with colleagues. The other colleagues at the water cooler would also offer their tidbits of info. If the colleagues agreed that the HR policy topic was interesting, they would repeat it with other colleagues, resulting in a sort of vote/validation driven "rumor mill" type of relevance screen. Eventually, one could see that everyone would get the important information about the HR policy.

But despite the rosy communication picture presented above, there are limitations to how well this can work. The "champion" of the HR policy story could be a lousy story teller, and the topic could die at step 1. The information could get mangled and re-related poorly as it got passed from person to person, to where the "rumor mill" had pretty much ground the original idea up and spit out garbage. (ex: Last week someone told me that UNICEF was against foreign adoptions. I checked it out today, and that wasn't correct. That information had been mangled through the oral tradition. If it weren't' for the Internet, I probably would still be mis-informed.) So despite the fact that we've always had folksonomies, they have been erratic in their performance, and the quality of the shared information has been impaired.

But what if a 2005 corporation formalized all of its information into an electronic library, and made it all available. Sounds great, for sure. Put all the white papers, all the HR forms, all the databases, all the client info, all the competitive data, all the market research, all the pricing info, all the product design docs, all the specs, yada, yada, into a big ol' intranet. Then we could assure that no information got mangled because we'd all have access to the original source. But unfortunately, like the Internet, employees get buried by a mountain of information, which ends up almost as useless as before the information age. Grated, a search can reveal exactly the sought information, but what if someone doesn't know what is worth searching for?

So now, combine the two advancements: the information age's ability to catalog all the information, with the folksonomy's ability to democratically find and assign an interest level on particular pieces of data. All of a sudden, the important, relevant information starts to pop out. People searching for "pricing" of the company's products don't get results from 1997, but they will first get current pricing, because that's what other users have identified as a "hot topic". That obscure HR policy would get "dugg" by the same person who found it in 1980, but instead of just chatting about it at the water cooler, they would tag it as important. Others would see the tag and agree, others would do a search after hearing about it at the cooler and agree, and pretty quickly this topic would trickle up to the top. Soon, everyone at the firm would know about this policy -- with the correct information. Then the relevance would fade a little as the topic got less "hot". To me, that's a beautiful management of "corporate intelligence".

In a sense, that's what Techdirt has done for corporate news for some time with their subscription service. Intelligently find, tag, and show news that is relevant to a company. Instead of having to read all the news every day, corporate customers of Techdirt can rely on intelligent (but centralized) filtering of the news. A folksonomy could easily compete with this service. For example staff could tag any news story they found relevant, and as such each employee would not have to comb the newsworld every day, since the enterprise would develop its own "intelligence" about which stories were relevant to it. Pretty cool. (Oh, but you wouldn't necessarily get the analytical advantage, although you could get some interesting discussion.)

As an answer to "how do you manage and merge folksonomies and existing taxonomies?" I think the answer is a simple one: as an overlay to however you manage your information now. Delicious (I'm not doing the caps thing on that) and Digg are overlays to the net -- seems to work well, no?

Case Sponsor
Daniela Barbosa
Sun Dec 16 3:24pm
Thanks for the Insight Derek.

Offering filtered editorial services like Techdirt and what many corporate communications groups do or outsource to others vendors is quite different then tagging documents, articles etc. no? Those are usually around a topic like for example a specific Insight on Techdirt or a daily summary of the company as represented in the 'news', their competitors, industry news etc.

Tagging however can be valuable in the process as well- for example as experts on specific domains are asked to participate in the editorial process of creating what many call daily/weekly news summaries that typically a few editors produce either manually or with a tool- they can be assigned a 'specific' tag that will then deliver it to the main editors for further review and distribution.

First, I'd suggest that most enterprise environments are organized to the extent that quality information taxonomies may already be in place.   This does not necessarily make tagging undesirable, but it raises questions about the return on the development and time investment to create the routines and tag the content in new ways.    

Clearly, the overall web is in desperate need of more human intervention, and categorizing by tagging has emerged as a simple and powerful tool to use in organization of content and in the creation of communities around content.   It is not clear that a limited enterprise environment will benefit much from the "democratic free for all" that tagging might create in an information taxonomy that had evolved over many years to be effectively organized.    Algorithmic routines could be developed to "merge" existing content categories with newly tagged material but my understanding is that this is a  nascent field.  The expense to implement a complex merge of a legacy taxonomy with a tagging system would seem unlikely to match the benefits of other tagging implementations - such as the clearly advisable job of expanding, tagging, categorizing, and optimizing any public online content for search engine retrieval.

That said, IBM's "dogear" appears to be one of the most successful implementations of enterprise tagging.    Bill Ives (link below) notes from a demo of dogear that IBM developers feel the tool has been favorably received.   They describe it as "" inside the firewall and note that it allows the users to tag and retrieve information using terms they choose.   This "personalization" aspect of tagging would have clear benefits in many large information environments.   Dogear also looks for relationships among the tags which can help develop better information retrieval, and improve existing information taxonomies.    I saw a demo of the IBM Wiki environment last year and enterprise tagging was used as a tool for collaborative information retrieval and information organization, which the presenter described as a big success for the project. 

I think it's very important to separate issues of *human initiated tagging* from automatic tagging which is almost always desirable because of the very high return on effectively a near-zero time investment.   For example Flickr pictures are auto-tagged with the camera that took them.  A given company would not necessarily use this, but Flickr can show camera use across the network using this data which is then enormously helpful to shoppers or product reviewers.   More information is almost always better than less, and auto tagging makes more information easy.   Intel and others have fairly mature geotargeted auto tagging routines but they have not been widely deployed.  One Intel product can be used to capture nearby WIFI hotspot data, convert this to geolocation, and then tag photos or other output with that tag.   This type of tagging could have great benefits inside certain enterprise applications.   For example a Wal-Mart could use this (does?) to maintain much more elaborate product flow information.  Lastly, programs like those offered by Nstein (online publishing), offer automatic semantic indexing routines.   Analyzing enterprise content using this automated approach may prove more cost effective that developing human indexing systems, as well as bring consistency and massive data organization capabilities without much human overhead.

Human tagging can be cumbersome and even though it takes only moments, it's a task that does not naturally flow from the work even when users are prompted with tags that they or others have used before.   Enterprise tagging should recognize that success may be largely a function of making the tagging process consistent and simple for users, and as automated as possible.  Also note that IBM's dogear suggests workers will be very willing to tag content if it helps them with their information retrieval needs. 

Tagging abuses:
A challenge with the "democracy" of a folksonomy within the enterprise is that undesirable tags or generalizations could develop largely "under the radar".     This does not appear to be a major concern of dogear at IBM, but clearly it would be a company embarrassment or even a liability if, say, obscene tags were used in connection with certain employees.   Monitoring of the folksonomy would be desirably, especially during the early phases.  Ideally tagging environments will self-police to some extent, though this appears to be breaking down online.  Outside the enterprise there are serious tagging issues already as search marketing efforts can lead to inappropriate or excessive tagging.   The best solution here is likely algorithmic - e.g.  diminishing the value of a tag with respect to a search as the number of them increases. 


*Tagging and folksonomies are becoming a critical feature of the overall web.  

*Enterprise applications that are already well-organized may not benefit enough from tagging to justify the time, training, and expense.  

*IBM's dogear is an excellent model of a successful enterprise tagging deployment.


Sources and Follow up:

Enterprise tagging:
h ttp://


Eweek enterprise tagging slide show

Dogear - IBM's Enterprise Tagging routine: sp; Semantic indexing and retrieval

Follow Techdirt
Insider Shop - Show Your Support!

What is the Insight Community?

From time to time, we post cases like this from the Insight Community right here on Techdirt.

In these cases, companies are looking to directly engage YOU, the insightful readers of Techdirt, in meaningful conversations.

So, please take some time and look through this case and contribute your insights.

To sign up to contribute, go here.

Essential Reading
Techdirt Insider Chat
Techdirt Reading List
Recent Stories


Email This

This feature is only available to registered users. Register or sign in to use it.