It is has been a while since I blogged. So I will break down what I have been up to over a few blog entries. This particular blog will focus on the overall picture of my work.
My work is underpinned by a need to have an architecture that is flexible and standard based for supporting development of IVR (Interactive Voice Response) applications. As it stands, despite providing unsatisfying user experience in the past, IVR technologies are still seen as pivotal in realising a new generation of self-service voice systems. There are a number of reasons for this including the fact that telephones and mobile phones are ubiquitous (just go to http://www.ametw.com/ and download the Africa Mobile Factbook for statistics on the mobile phones penetration in Africa). This means that there is, for example, a strong “market” for IVR applications – not just in the commercial sense but also for use in supporting social innovation 😉 .
With the above providing part of the motivation, the goal is to use IVR technologies (specifically VoiceXML) to propose an architecture for building IVR systems with high configurable dialogs to improve user experience. The premise is that the effort to customise (configure) each dialog to suit each users’ goals will bring intelligence to IVR systems – a component that is possibly a source of much user frustration.
In a nutshell, the proposed architecture builds IVR systems by generating dialogs using VoiceXML and a rich backend. The backend comprises of a specially built interface that allows a reasoner to interact with any ontology-based knowledge base in order to generate dialogs. In the context of AI, the interface can be regarded as some sort of an inference engine.
Architectural Design Considerations
An overarching consideration is to ensure that the architecture is flexible. Another important consideration is to ensure that the generated dialogs do not violate any principles of user interface design. This translates into ensuring that:
- Menu options do not exceed five options. Otherwise this is will result in an overload on the short-term memory of the user. Consequently, the user will have problems remembering the presented options.
- Break content into small chucks to enhance memorability by introducing rhetorical questions or using quiz type questions. However, the number of dialogs generated should be kept at a minimum.
Case Study: Service Directory for Locating HIV Test Providers
As part of the methodology, a case study is included to act as a proof of concept for validating the proposed architecture. This proof of concept case study is a service directory for locating HIV test providers.
The case study is built from a service provider ontology, which together with individual facts about specific service providers forms a knowledge base. This is strictly in the context of defining a knowledge base as an entity made up of a terminological box (TBox) and an assertional box (ABox). In simple terms, TBox refers to the definitions of various concepts and how they relate to each other within an ontology while ABox refers to the individual facts associated with the definitions in the TBox.
Below is a quote from good old Wiki to provide another angle to the definitions of TBox and ABox:
Tbox statements are sometimes associated with object-oriented classes and Abox statements associated with instances of those classes.
As I continue with my journey on use of ontologies, I decided to explore some of the tools that can be used in the development of ontologies. I have long decided to use Protege but I thought there is no harm in exploring what is available. I began my venture but like the good woman that I am, I decided to exercise the right to change my mind.
What served as a trigger for the change of mind was a random mention of Cyc in one of the articles I was reading. It wasn’t the first time I came across it but this time I thought to self: ‘about time you explored this!’ So with obvious determination, I proceeded with my exploration! This yielded fruitful results in less than 30 minutes (with the help of Google of course).
In 30 minutes, I was lead to believe that OpenCyc might be useful in helping me to model my HIV/AIDS ontology. As aptly put, OpenCyc can be used for “rapid development of an ontology in a vertical area“. What this means is that OpenCyc is ideal for developing ontologies in a specific domain. (Go here for more on vertical and horizontal ontologies)
This is literally good news since one is always adviced to avoid building an ontology from scratch – if possible! And I was almost under the impression that this is the route I may have to follow. ( I boldly told my supervisors not so long ago that ontologies related to HIV/AIDS for disseminating information to laymen are not available. ) Well I am yet to download OpenCyc and may be I might need to retract my statement. I shall cross that bridge when I need to, right now I am just happy I have an excuse to celebrate my Friday. (Of course, I don’t really need an excuse because every Friday is a good Friday 🙂 !)
Ontology use in the context of this research is beneficial in that it allows knowledge sharing and re-use. Although reuse may not be a challenge in this research as we will be modeling our ontology from scratch, it is important to ensure consistency. Without consistency, extendability of our ontology may be compromised; in a sense that it may be difficult to reuse.
Some important questions related to reuse include:
- How the changes will be handled.
- How versions of the ontologies will be related.
- How to store ontologies.
- How to identify and retrieve ontologies.
Central to these questions is the problem of harmonising the concept descriptions. For example, consider building a taxonomy that will be used to capture the statement” ‘HIV/Aids is an infectious disease that is not curable‘. With this in mind, which of these two is more preferable?
Right now I cannot say which between the two is better, but if at all one is better then it means there are good and bad ontologies. This is something to explore (but certtainly not today)! The point for today is simply to suggest that the two demonstrate that the challenge lies largely with the conceptualisation of the intial model; since to maintain consistency one depends mostly on initial modelling decisions. Further, idea of re-use of an ontology cannot be taken for granted even though it is one of the most cited reason for using ontologies.
Ontology is not a new concept. It is a century old concept, with roots from philosophy. However, the Semantic Web has popularised this concept (so many are forgiven to assume that this is new). But more to the point of this post, what is ontology?
In computer science, the classic definition is provided by Gruber. He defines ontology as a “specification of a conceptualization”. This definition although widely accepted some critics say it is too simplistic and incomplete. At the heart of this criticism is that Gruber’s definition reduces ontology to a model in people’s minds instead of a model that is representative of the universe that constitutes the domain.
I will try to explain what I think the critics say: in a nutshell, the argument being made is that ontology is much more than the concepts as understood by people in their own heads. Ontology needs to reflect completely the world of the domain being represented. To perhaps clarify this point of view, I imagined trying to see life through the eyes of an extremist (political or otherwise). To me, an extremist cannot possibly represent true reality of ‘what is’. Therefore, an attempt to reason about the world from that point of view would be doing the world injustice; since the vision of an extremist at best of times is not “true-to-the-world”.
My explanation may of course be a bit philosophical but as said before, ontology gets its roots from philosophy. Now, going back to Gruber. He does explicitly suggest that ontology pertains to modelling of knowledge of some domain be it is real or imagined. Further, he does insist that the modelling is as formal as specifying a program.
In conclusion, while the critics suggest that Gruber’s definition reduces an ontology to be seen as a mere “ad-hoc model built for some specific purpose”. I think I believe in Gruber’s definition for it is short and sweet (like me ) but also very open to interpretation. One possible intepretation is:
Ontology is a formal specification of conceptualization.