Introduction

The first installment in this series, "Create collaborative and dynamic method content using Web 2.0" (developerWorks, Apr 2008), showed you how to build a collaborative and dynamic software development method. To provide the user with relevant content particular to a place in the method, you filtered various social software through a Web feed (for example, bookmarks, assets, blogs, people, and so on) application using a predefined set of tags that represented that location in the method. This approach works well if the tag set remains consistent across different social software applications. But each of these applications manages and maintains its own set of tags (or folksonomy), which results in tag inconsistency across applications.

Social software applications that enable collaborative tagging, such as Flickr (photos) and YouTube (movies), have proliferated over the Web and have been adapted for a variety of purposes. The major benefit of these is that users of these applications can manage their own content. Moreover, most applications provide application programming interfaces (APIs) to manage content programmatically. For example, Flickr is a photo service that provides an API to perform create, read, update, and delete operations on photo elements. The SOA challenge now is to build business-driven composite services on top of these atomic-like APIs or informational services. Thus, to build these composite services you need a better way to manage and maintain a consistent set of tags across these applications.

This article presents a way to tackle this problem of tag consistency with the idea of standardizing on a set of tags for a community of practice and then providing a way to maintain the consistency of these tags across the various social software applications.

Back to top

Playing tag with a community of practice

Folksonomies can be inherently ambiguous or inconsistent due to conflicts between homographs or homonyms, single tags with multiple meanings, and synonyms, many tags for the same concept (see the Resources section for a link to an article about folksonomies.) All CoPs have their own lexicon, that is a domain-specific set of terms or keywords that they use as their common vocabulary. Consequently, when community members use social software, a CoP may want to provide a predefined set of domain-specific tags for its community to enable greater uniformity of tags across folksonomies.

Imagine that you're a member of the Star Trek CoP and have found a new important piece of information about the Romulans. Today you can only use existing folksonomies or create a tag on the fly, which may not be consistent with the Star Trek-specific taxonomy. While this user is aware of this artifact, other CoP members may not encounter this new information when performing tag or keyword searches if the user-defined tag is inconsistent with the CoP's standard vocabulary.

A domain knowledge group, such as a CoP, can use an administrative control approach by publishing the mandatory or recommended domain-specific tags for use with Web 2.0 or social software applications. An enterprise can determine if special accounts or spaces are available with different social software sites and see if they can provide a mechanism for adding their domain-specific tags to existing folksonomies.

Back to top

A user with many hats

Let's look at a more concrete example here of a patent (IP) attorney or agent (see the sidebar for more information about what a patent agent does).

Consider the following use case of a patent agent writing a patent application:

• This agent belongs to a number of communities of practice (for example, patent agents CoP, a lawyer CoP, the firm the agent works for CoP, and so on).
• The agent has also created a set of personal tags associated with social bookmarks, podcasts, media, and online libraries. These might have to do with things like prior art and tips on writing better patents.
• The agent wants to make meaningful queries across social software applications based on his role.

In Table 1, you can see the patent attorney has a number of roles.

The patent agent may want to do one of the following with the various roles that are attributed to him:

• The patent attorney might be in a personal role and want to manage his tags around all of the Web 2.0 applications that he's involved with.
• The patent agent might be in the CoP role and want to manage or use a domain-specific tag for his CoP.

Figure 1 shows a simple Unified Modeling Language (UML) class diagram that shows the has a and is a relationship between the user and his roles. A user can have multiple roles and that role can be a combination of either personal or CoP roles.

Back to top

Solution outline

Now that you understand the use case and the idea of managing tags around CoPs, let's outline a solution for doing coherent queries across social software applications. This solution outline is for when the attorney wants to make meaningful queries.

• The separate set of tags for each role, both personal and CoP roles, is kept synchronized with registered Web 2.0 applications.
• This set of tags should be maintained independent of any of the information silos or Web 2.0 applications, that is new tags can be added, tags can be deleted, and tags can be renamed.
• After the user, in his role, is happy with the consistency of the tags, the tags are then updated (one-way synchronization) in all of the Web 2.0 applications that the user was registered with.

This now provides the user, in his particular role, with a consistent set of tags across all Web 2.0 applications and lets the user make meaningful queries to search for content across these applications.

Back to top

Solution details

The solution includes a proxy that sits on the client side. It also includes a database of personal and domain-specific tags, and other metadata associated with the social software or Web 2.0 applications.

Talk to your proxy

The proxy is configured to be aware of Web 2.0 applications and provide the necessary login information for each Web 2.0 application connection, such as del.ici.ous, Flickr, and so on. The user logs in to the agent or proxy and is also automatically logged into all of the agent-aware applications. The user specifies her role at login time (that is whether she is logging in as herself or as part of a CoP).

The client proxy has access to the user's personal tags (or the domain-specific tags of a particular CoP if that's how the user is logged in). This allows the management of the personal tags (or the tags of the particular CoP if that's the user role the attorney logged in with), such as adding, deleting, or renaming tags.

The proxy is then responsible for comparing (doing a diff) and updating the user's personal tags with the tag sets in each of the Web 2.0 applications that the attorney was aware of. This would ensure consistency of the user's tag set (or CoP tag set across the registered Web 2.0 applications). To achieve this:

• The attorney needs to load the domain-specific tags from each of the registered applications.
• The attorney, in the tag client, then needs to compare the domain-specific tag set with the tag sets from each of the registered applications and perform a one-way synchronization of the tags from the tag client to each of the registered applications. The tag client always has the master tag set.

Typically, within a CoP, the domain experts are responsible for creating the initial taxonomy of tags to be used as part of that COP.

Here are the steps that a patent attorney might take when interacting with the proxy:

1. The patent agent logs into the proxy.
2. The proxy identifies the user and which CoPs the patent attorney belongs to.
3. In her profile, the patent attorney would have identified which social software applications she used.
4. The patent attorney picks which role she's now playing (for example, a lawyer role).
5. The proxy then displays:
   • All of the tags relevant to this CoP.
   • The relevant CoP tags for a particular URL at tag time.

Tag your tags

Role-based session management on the client is accomplished using tag suffixes or prefixes. This allows the user to log in and assume one or potentially multiple roles during a session. Consider the following example.

A user logs in as the CoP administrator. In this role the user has access to domain-specific tags that are particular to that CoP. The user needs to make sure that the available tags in this role don't conflict with any other tags in her other roles. To achieve this, without requiring multiple logins for the different user role in each of Web 2.0 applications, the tags can be suffixed or prefixed with a unique user identifier. This identifier needs to be unique with no chance of incidental clashing with other tags. It might look like this: tag + Role Based Unique ID.

Moreover, additional information, such as which Web 2.0 applications this particular tag pertains to, can be encoded in the tag. This involves appending the above composite tag with a unique identifier for each of the back-end systems. If the tag is being stored in multiple Web 2.0 applications, then a unique tag for each of those applications needs to be added, as shown here:

(tag) + Role Based UniqueID + UniqueID for ApplicationA + UniqueID for ApplicationAB ....

Hence, community leaders can monitor the use of the tags across the various applications with a dashboard capable of performing various queries (for example, who's the most prolific tagger, tag and application usage, and so on). That information can then be used to create dynamic information for the community dashboard, perhaps using mashup technologies.

This additional encoding of the original tag is transparent to the user because he or she only wants to see and manage his or her particular role-based tags. Because of this, the tag-management client subtracts this extraneous information and only presents the tag information to the user

Back to top

Summary

This article showed how using the notion of roles and CoPs combined with a client-slide tag management capability can lead to a consistent set of tags that you can use to make more coherent queries across Web 2.0 applications. Future articles will build on this idea to provide content on demand to the user, such as a patent agent, to improve job performance.

Resources

Learn

• Read our first article on a related topic, "Create collaborative and dynamic method content using Web 2.0" (developerWorks, Apr 2008).
  
  
• Read the article "What is Web 2.0?" by Tim O'Reilly.
  
  
• Visit the IBM Web 2.0 home page.
  
  
• See the Wikipedia entry on patent agent.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Read "Folksonomies - Cooperative Classification and Communication Through Shared Metadata."
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out Eoin Lane's blog Building SOA applications with reusable assets..
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the authors

John Boyer is an SOA program manager for IBM Software Group. He has extensive experience designing and developing Java, J2EE, and C++ systems. He's currently focused on integrating social software into software development and learning activities.

Dr. Eoin Lane, senior solution engineer, is the lead for harvesting and developing an application pattern from key IBM SOA engagements and driving those patterns through IBM pattern governance process to accelerate adoption. Eoin also specializes in Model-Driven Development (MDD), asset-based development, and Reusable Asset Specification (RAS) to facilitate SOA development.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Playing tag with a community of practice
• A user with many hats
• Solution outline
• Solution details
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers