Let’s cut to the chase, this is how it should NOT look like:

Fig 1: Internal Collaboration Enterprise Social Graph of the US Senate – 2009  (Source: Slate.com)

The graph you are seeing above is a visual representation of internal collaboration enterprise social graph of the US Senate [This force directed graph from Slate is based on votes in 2009 (I will be working on a 2011 graph). Each blue dot represents a Democratic senator, each red dot represents a Republican senator. A line connects two senators when they voted the same way on 65 percent of the votes]. The force directed graph clusters dots with the most connections to each other, pushing away dots with the least connections and as a result we can visually identify the people who collaborate with each the most and those who collaborate the least.

In my engagements with various companies, I have observed that many people draw an enterprise social graph as dots connected by lines, some even go as far as drawing pretty clusters of dots connected by lines as shown in the US Senate graph above. While such a graph is not incorrect, it is not what you want your internal collaboration enterprise social graph to look like if you are to have effective internal collaboration. An effective internal collaboration enterprise social graph looks like this:

Fig 2: Effective Internal Collaboration Enterprise Social Graph (Source: Tom Chikoore -http://tomchikoore.com)

It’s not pretty, it’s messy but it’s effective. Each dot represents an employee and each line represents two employees who follow each other on an internal social enterprise collaboration community. This means each line represents a “bi-directional” follow between two employees. A bidirectional follow represents an open communication channel for effective collaboration. The color of each dot represents department in the organization. The following is a legend for some of the organizational departments shown in the graph:

BLUE – Sales
RED – Engineering
SALMON – Product Marketing
FLUORESCNET GREEEN – Product Management
ORANGE – Marketing
BLACK – Professional Services
ACQUA – Support
QUALITY ASSURANCE – Saddle Brown
LIME GREEN – Vendor

From this graph, you can see that the departments that one would expect to collaborate with each other are collaborating with each other. This is a beautiful visualization: Notice how the Support team is positioned between Engineering and Professional Services; and Professional Service is positioned between Support and Sales. This is the type of relationship you would expect to see is the majority of product development organizations. QA is positioned right next to Engineering and Product Management is nestled between Engineering Product Marketing, and Sales. This is what you would expect in most organizations, this is what your internal collaboration enterprise social graph should look like.

You can think of graph depicted above as a depiction of the “internal collaboration DNA” of your organization. Using this graph and the right algorithms, an assessment of the health of your community is possible. The right tools can help you identify collaboration problems and suggest solutions to fix the problems to enable effective internal collaboration.

For more information on the social graph and community health assessment tools send me an email at tom AT tomchikoore.com

Given the fact that conversation venues, such as Twitter, democratize the notion of “reach”  by providing a venue where anyone can mention anything (including your brand) to an organic audience (original target audience+viral audience), it is imperative that  brand protecting companies,

1) Track mentions of the company’s brand (s)

2) Analyze the influence (“reach analysis”) of the people who mention a company’s brand(s)

As social media networks become entrenched conversation venues where participants discuss anything under the sun including company brands, “reach analysis” needs to be expanded beyond messages that originate from a company’s marketing department.  This is the first step in acknowledging that there are other messages that are emanating from places other than your marketing department.  Those messages you cannot control. However, you can manage the conversations that the messages produce. In order to manage messages that result in conversations about your brand, regardless of their origin, brand mentions need to be effectively monitored and the message reach effectively analyzed.

Consider the following example: Every brand protecting company’s nightmare is seeing the following brand mention (message) on Twitter (or any conversation venue e.g. Facebook, Blog comment, Online newspaper comment)

“(put your brand here) sucks!!”

The next time people Google your brand; you do not want this to be the first brand mention they see. It well can be, if you do not properly manage the conversation that emanates from this mention. Therefore, before you react to the mention, it is important that you perform a “reach analysis” of the mention (measure the “influence” of the “mentioner”) in order to understand the authority of the person who made the brand mention, the nature of the venue in which it was made and the number of people who potentially saw the mention.  Performing such a reach analysis gives you the ability to assess an appropriate entry into the conversation and gives you a basis for formulating an approach on how to manage the conversation going forward. Products like Filtrbox simplify the “reach analysis” determination through Twitter Influence scoring and FiltrRank scoring.

In closing, it is important that ALL companies pay attention to “influence” in social media conversation venues. Think of “influence” as good old “reach analysis”, except the message whose reach needs to be analyzed is not coming solely from your marketing department – its coming from anyone, its coming from everywhere and, in a real-time information environment, its coming fast.

As I have said in the past, the goal of the semantic web is still a long ways to be realized. However, rather than wait for every website owner to build semantic web conforming website (or retrofit their past content to be semantic web compliant), we should seek to derive web semantics at the application level using a whole new set of applications, web semantic analysis-based applications. Yahoo’s BOSS can be one of the missing components that pushes the ball forward towards this goal.

Surprisingly, one of the challenges of deriving web semantics is as simple as programmatically identifying and extracting the content from a web page (I have talked about this in a previous post: A case for standardizing blog templates).  Before semantic analysis can be performed on a web page, the proper content must be extracted fom the web page first. As humans, when we look at a web page, we can readily distinguish the “main content” of a web page from  navigation bar, header, links or ads.  This is not so easy for computer programs to accomplish.  At Filtrbox, we have developed algorithms to accomplish this with a very high success rate only because we have devoted time and resources into the algorithms because they are core to our business.  Other application developers wishing to leverage web content semantics may not have the time and resources to build such algorithms because that is not core to their business. This is where Yahoo BOSS comes into the picture. We know that Yahoo has built its massive Web index by indexing the “main content” extracted from web pages.  Yahoo has  invested time and resources to solve the content extraction problem. In addition, they have built a massive infrastructure to index and store web content.  Therefore, instead of re-inventing the wheel, developers of applications that leverage web semantics can take advantage of Yahoo’s content extraction through the Yahoo BOSS API. However, Yahoo needs to open up a little more for this to be possible.

Here is where Yahoo needs to open up: Although Yahoo currently performs content extraction and content indexing, unfortunately the Yahoo BOSS API is not geared towards applications that analyze web data semantics.  The Yahoo BOSS API in its current form is geared towards web searches.  It is keyword query-based and returns at least TITLE, URL and ABSTRACT/EXCERPT.  Unfortunately, to move towards web semantic analysis-based applications, the ABSTRACT/EXCERPT alone is not enough.  Instead, the Yahoo BOSS API should return the WHOLE “main content” (not links,ads and navigation etc) of a web page.  Returning the whole content enables applications to perform semantic analysis on the data from millions of web pages that is stored in Yahoo’s web index, thereby adding value to the data and moving the ball forward towards unlocking the hidden value in web data using web semantic analysis-based applications.

I think NLP fundamentals are essential for those who wish to undertake the challenge of building the next generation of web applications that process the unstructured data on the web.  Yes, there are efforts to build a structured web via initiatives such as the semantic web and the various APIs being proposed. I respect these efforts; however, I would not solely rely on these initiatives alone.  The proposed APIs provide access to structured data stored on various islands on the web.  For those users who do not have their data on those islands, their data is not accessible via the API.  The Semantic Web is the initiative that will bring us closest to structured data on the web.  However, as we are witnessing its painfully slow adoption, it looks like its going to be a while before we have some structure on the web. The challenge is what do we do now while we wait for these initiatives to mature. I think what we do today is, instead of waiting for content publishers to structure their content, we process content publishers’ content as is and we programmatically infer the structure of the content.  

The application of NLP concepts are one way we can make the content structure inferences.  By applying NLP, this will take us a step closer to programmatic input, processing and storage of unstructured data.  We have traditionally thought in terms of structured data, programmed for structured data and stored structured data.  The challenge posed by the web today is an opportunity to break new ground for software engineers and start thinking, programming and storing unstructured data.

To help answer this question, here is the Web 2.0 school of thought that I subscribe to:  Let’s start off with an enterprise database analogy. The basic assumption is that blogs are nothing but a data store.  While information in a blog makes for an interesting read, it is about as interesting as reading data in a text column in a relational database.  While the data in a single text column may have a lot of meaning, its meaning and usefulnes is enhanced when the data is combined with other columns in the same table in database, or with other tables in the same database, or even with data in other databases. The wealth of data is hidden in its interconnections with other data. In order to harvest the wealth of data in databases, applications are built on top of the databases that reference and make relational semantic inferences between the data in the database(s).  Today, blogs are the database(s). What is lacking are the applications that harvest the wealth of information stored in the blogs.  These are the applications that the next wave of Web 2.0 companies (including myself) are working on. 

The pace of these next generation applications is being hindered by the lack of a consistent structure (standard) in blog data. What Isikold is bringing attention to is that unlike relational databases, which adhere to relational database management system standard (characterized by a simple TABLE/COLUMN/ROW+SQL structure that has been consistent over the years), blogs have no such standard. The structure of blogs is currently left up to the blogging platforms such a WordPress, Typepad etc. Blogging standards today are akin to having Oracle, SQL Server, MySQL each using a different standard for storing and retrieving information. Not only a different a standard for each of the databases, but a different standard for each version of each database.  Exacerbating the problem further, each of the different databases being customizable by anyone and anyone can change the standard to a standard of their liking. If these databases were is such a state, it would be very difficult to write any applications that leverage data from these databases. ODBC and JDBC standards would be very unreliable, if not useless.  Such is the state of the blogosphere today when one looks at it from a data interface perspective.  

As many of you know, I am currently devoted to work on the layer of applications that leverages the data in blogs and beyond in order make such data more useful to users.  The lack of standardization (as described above) makes it difficult to identify the content in blogs.  Content identification is important because an application needs to be able to identify the difference between actual blog post text and some other text on the blog so that analyses and inferences can be established appropriately.  I have been monitoring the different types of templates in an attempt to predict template patterns for the different blogging platforms (mainly WordPress, TypePad, Blogger, MovableType).  I came to the conclusion that pattern prediction is only successful to a certain point due to the following

1) the original templates from the blogging platform vendor consists of multiple major and minor versions that do not have a predictable consistency in the template content tagging and

2) there are modified/hand coded templates floating out there which are totally unreliable.

As a result of these observations, I have resorted to writing my own content identification algorithms that include a combination of template pattern predictor algorithms and NLP based semantic blog post text identification algorithms.  While this has served me well up to now, a blog template standard will be very beneficial not only to myself but many people who have not figured out how get past the problem.  

Isikold is suggesting that a standard be adopted with the goal of giving blog templates a consistent structure.  This means the adoption of a template standard that identifies the different types of data on the different parts of bogs post. Isikold is suggesting that on a blog post, the template should make it easy to identify the blog post text, the side bar, the name of the author, the data that blog post was published, the tags for the blog post content and the blog posts comments.  I believe an adoption of this simple template will go a long way in helping to bring the next wave of Web 2.0 applications to market faster.  I support a blog template standard.

Today, the words “enterprise” and “social”,  convey two contradictory notions. The enterprise today is characterized by its emphasis on the productivity of the individual employee. For the 8+ hours that an employee is at work, they are supposed to be 100% productive (even though we all know that this rarely happens).  “Social” is  a word that does not really exist in the vernacular of the productivity oriented enterprise especially as it relates to software.  Everything in the enterprise is geared towards productivity, thus every enterprise software vendor attempts  to tag their software with the phrase “productivity tool”. With all this obsession with productivity, the enterprise is very “anti social”. Thus, the perception of social computing in the enterprise is not really the same as that of the people outside the enterprise.   While those outside the enterprise harness the variety of benefits of social software for variety of business needs on a daily basis, to some in the enterprise, social software still carries the stigma of being a non productive, time wasting web based consumer applications that you use at home (not at work).  Unlike those who believe that the terms “enterprise” and “social” are contradictory, I believe otherwise.  I think that there is a lot of social software that can be very beneficial to the enterprise but the enterprise will not fully embrace it until three things happen: 

1. Social software companies need to leverage concepts that being applied by web-based consumer applications rather than try to implement these application the enterprise as they are.  Trying to implement a Facebook in an enterprise is not necessarily the right approach, however, applying the concept of a “social graph” for a Sales Department or “implicit web” concepts for lead qualification and cross selling will have a better shot of being successful in the enterprise.

2. Elimination of the word “social”. While this may sound silly, I think I may be onto to something here. Words like “productivity” and “collaboration” mean something in the enterprise.  Take for example, del.icio.us concepts can be very useful in an enterprise intranet; however, calling that concept  “social classification” will not carry as much weight in the enterprise as “collaborative classification” So, instead of “social networking” maybe start using “productive networking” or “collaborative networking”. No more “social graph”, it’s now a “collaborative graph” J A good example is IM/Chat which was renamed to “Real Time Communications Suite” by some enterprise vendors (well, you guessed it, the word ”Chat” is too social); it is quickly becoming a staple within the enterprise.

3. The enterprise needs to make a mind shift from its current notion of “productivity tools”.  The enterprise is beginning to absorb a generation of employees who are proficient with “social” tools. Why not leverage the social tools to make them even more “productive”?

The perception of the gap between “enterprise” and “social” exists only at a semantic level. The convergence of the enterprise space and the social space is inevitable; however for some of the more popular applications, it’s not a matter of simply transplanting the application as-is but rather, transplanting the concept. 

I believe Enterprise Social Software/Enterprise 2.0 is here to stay. Recall several years ago many companies resisted employee access to the web in the enterprise because it would affect “productivity”.  Looks like a similar battle brewing here.