The world beyond Web 2.0

8 March, 2008

I was privileged enough to sit in on a seminar recently by Annie Rowland-Campbell, a researcher from FujiXerox. She’s been doing research into semantic technologies and preparing the way for organisations to move beyond Web 2.0.

Annie’s research suggests that the web will become more and more immersive in the coming years — something we’re starting to see with applications like Second Life and games like World of Warcraft. To provide users with a more immersive and information rich experience, systems will ultimately need to better understand an individual’s context.

Context will help provide systems with the ability to intuit what people want (and what they also might need) and serve it up to them without users having to search and browse and differentiate what information is of value to them (and what is not of value). This understanding of context will be based largely on an understanding of who a user is, and what their personal needs are. And this technology to deliver this experience is actually not far away. In fact, the capability exists today through ontologies and semantic technologies.

without-the-semantic-web.jpg

Without semantic technologies driving the web, we can only produce context through direct points of integration with information. We can tag, categorise, and add other pieces of metadata directly into documents and link databases together where we identify that information has connections. Unfortunately, this traditional information technology approach requires meanings and relationships to be predefined and “hard wired” into data formats and the application program code at design time. This means that when something changes (which it always does in the human-centric world) the systems involved need to be changed in order to interoperate in a new way — a lengthy, messy, and manually intensive process.

Semantic technologies, though, are “meaning-centred”. They encode relationships, meaning, and context separately from data and content files, and separately from the application. This separation of layers allows systems to provide context that can change and adapt as the world around which information exists changes — exactly what is needed for the truly immersive, context-driven experiences required by Web 3.0 and Web 4.0. It could potentially even allow systems to ‘learn’ based on their own experiences of the changes in context. But how can we start to deliver context?

Topic Maps can provide the ontological layer required to describe context in addition to the metadata and data layers.

data-metadata-and-ontology.jpg
Utilising a Topic Map as the point of integration between systems will decrease the number of integration points required to deliver context. In this example, introducing an ontological layer decreases the number of points of integration from 24 to just 6.
with-the-semantic-web.jpg

It’s an interesting paradigm shift for Service Oriented Architecture models and database designs because it allows context to be added and data adapted to an evolving- rather than a static-world because its generally only the relationships between pieces of information that change, not the information itself (assuming that change in information is largely a factor of time, so new pieces of information only result in new versions).

ontology-layers.jpg

A Topic Map used in this space enables machines, as well as people to understand, share and reason with information when its called upon. With this approach, adding, changing and implementing new relationships or interconnecting programs in a different way can be just as simple as changing the external model that these systems share.

Given a question, query, or report request, the ontology layer can access topics, concepts, associations that span a vast number of sources. It’s an approach:

  • that has already gained traction in Finland (which is no surprise to me given that Northern Europe is where Topic Maps (ISO/IEC 13250:2000) were born). Here the ontology layers are being used to provide context and points of interchange where standards and language differ between EU countries.
  • that is employed by Reuters in their Calais system to provide reporting capability based on context. Theirs is the reporting equivalent of “do you want fries with that?” and “…you may also be interested in…”
  • that is being developed by the German government in partnership with SAP and Siemens in a project worth around €440m

As the web moves more toward immersive environments and intelligent agents, this approach is exactly what businesses need to begin to adopt in order to meet future system design needs, the needs and expectations of their users, and survive the evolution of Web 2.0 into Web 3.0 and beyond.

M


Identity management: are you Clark Kent or Superman?!

22 January, 2008

I was recently asked to help with a systems implementation. This system was no small beast by any means. The organisation wanted a complete system, with one business module, but also wanted the scope of the underlying system to cover up to some 23 business program, each with their own separate business logic.

I’m sure that some developers would faint at this suggestion — that you could have a modular approach to data and business logic management without directly handling the ontological relationships between data entities!

Strangely enough, I had read some information on Lars Marius Garshol’s blog a few months ago that gave me the idea for using topic maps for identity management and had an idea — what if you use a topic map to handle ALL the relationships between databases and entities …. yes … all of them??!

Conceptually, I found the idea very interesting. Ultimately, it would mean that you could add and remove system modules without adversely affecting other modules because all you would need to do is handle the associated ontological and semantic relationships stored in one area — the topic map layer: an approach called Semantic Technology

service-oriented-architecture.jpg

This was also my first go at looking at enterprise systems architectural concepts (with a little help from my colleague and friend “Billy”) for a service oriented architecture. I have a feeling that these two disciplines could learn a lot from each other

M


I say tom-r-toe. You say tom-aye-toe

18 January, 2008

What is it about terminology that makes some people roar and others cringe? While the literature has a lot to say about the problems of knowledge sharing between groups when language is different [1], there are some obvious obstacles to sharing knowledge in the same language when the terms, or even the style of language to describe information, differs between groups.

In the medical field, the National E-Health Transition Authority in Australia (NEHTA) is currently developing a taxonomy of terms, and an ontology to support it, to fully articulate the relationships between the chemical composition of a drug and its medicinal use all the way down to how it is represented as a product on the shelf. This set of terms is supposed to help systems “efficiently exchange data and improve how important clinical and administrative information is communicated between healthcare professionals”.

This initiative would be a great step forward if only this dictionary of terms actually represented the way that doctors prescribe medicines, the way that pharmacists in Australia dispense medicines, and the way in which companies label and market their products. Of course there are also other taxonomies around the world that also try to do the same thing, and some of them are more successful than others. The hard thing is to apply their use outside of community that uses them.

When I was recently doing some IA work in the area of health I think I found about half a dozen or so of these so called “standards”. I also found that a number of business-teams working in the same organisation each with unique terms of their own used to describe these same things. If it were just an issue of Eskimos having a zillion words for ice it probably would have been OK, but rarely did each term carry any additional meaning. You can imagine the pain caused when it came to developing a shared business system, not to mention the problems associated with creating documentation, with each team demanding specification documents with their own terms reflected and refusing to sign-off on them until this was achieved.

How can you manage terms and definitions when there’s no agreement of a one-size-fits-all approach, especially when your goal is to achieve a one-size-fits-all approach?

Topic maps are a good way to manage this chaos. For these teams I created a wiki powered by a topic map engine, allowing the members of each team to collaborate to describe the terms they used. I then coopted bribed persuaded asked subject matter experts to create the relationships between terms and across those teams. Where one team used, for example, the term “tom-r-toe” and another “tom-aye-toe”, the topic map allowed for the existence of both terms, and their definitions as agreed by those teams, and included a relationship between them that indicated they were actually the “same term”. Other relationships, like “equal term”, “equivalent term”, “parent term”, “child term”, even collections of terms, were also captured. A module in the topic maps engine even allowed for the capture of which terms were used in what documents and included an glossary of terms as an output just to make each team happy. There was even some talk of the topic map being used provide team-preferred terms within the business systems interface.

Having “one taxonomy to rule them all” isn’t always necessary when communicating knowledge across teams. Language might be a barrier, but if you can articulate and capture the relationships between terms, then you’ve got a translation matrix that will assist with and ease the burden of knowledge transfer, and can help with challenge of creating awareness of differences and similarities in intra-office communication.

M

- - - -
[1]. Preece, J. (2004) Etiquette and trust drive online communities of
practice. Journal of Universal Computer Science, 10(3), 294-302.