Sharpe Engineering Inc.
Streams Processing | InfoSphere Streams |
Challenges | Process Stack | 3-Layer Model | Elements | Soft Technologies | SOA | Orchestration | Ontologies
Challenges | Types of Uncertainty | Representations | Holy Grail | Framework
subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link
subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link
small logo

Using Ontologies for Consistent Semantic Meaning

Just as important as the ability to efficiently transfer data and events between various reasoning components is the need to ensure that the information that the data represents remains intact. Maintaining knowledge fidelity throughout the system can be compromised in two primary ways. First, individual components or sub-collections of components can over process their input data to the point of producing erroneous, or at least, misleading results. Second, the information transferred between components can be misinterpreted. I. e. the receiver of the information uses it in a way that might not be entirely consistent with the meaning under which it was produced. There are numerous ontology related techniques that have been shown to be effective to address some of the issues related to knowledge fidelity and should be leveraged as applicable for the framework design.

Even hard coded custom solutions can suffer from over processing the data, but they do have an advantage over a dynamic component architecture by having the meaning of the information directly implemented in a static fashion. I.e. if one module outputs a value of "hot" the receiving module has been implemented to understand exactly what a value of "hot" is intended to represent. This is not necessarily the case in a hybrid framework where new components can be added dynamically. One component's interpretation of what "hot" means or how it should be used, could be subtly different than that of another component. This is not necessarily a bad thing. In fact if handled appropriately, such as with a hierarchy of shared ontologies, it is actually a strength of the proposed architecture because multiple subsystems can be applied to the same input data and through the use of different processing techniques, configurations, or contexts, they could interpret the same data from different standpoints. It would then be up to higher layers of processing to "make sense" of the differences. While this can be an advantage, care must be taken both in the internal implementation of the components as well as that of the overall architecture so that the different interpretations do not become misinterpretations.

Specifications such as DAML+OIL/OWL and KIF/KQML or their derivatives, as well as numerous other ontology management concepts should either be directly leveraged or at a minimum, bring valuable insight into how best to address the issue moving forward. As with other parts of this effort, it will be desirable to utilize existing standards where they are sufficient and effective.

As part of our investigation, we looked at the relative merits between distributing the data and knowledge needed by the framework versus utilizing a knowledgebase that is equally available to all processing nodes. Most agent architectures tend to favor distributing the information and having each agent responsible for obtaining and carrying its own knowledge independently from other agents. While this approach does have merit for certain classes of applications, the types of problems in which we are most interested require that many nodes have access to the same information. The information repository requirements of the framework are more closely aligned with blackboard systems of the late 80's and early 90's. These systems allowed multiple processes to communicate by reading and writing tuples from a common data store. Each process watched for items of interest, performed computations based on the blackboard state, and then posted the results back to the blackboard for other processes to consider.

The concept proposed here goes beyond most blackboard systems by allowing and encouraging greater awareness and interaction between the processing elements. This characteristic extends to the point where some of the processing elements are entirely focused on the behavior of the system while others target primarily the main analysis elements of the problem space. Although perhaps it might not seem obvious, the meta -nodes that deal mainly with system behavior are just as much a part of the solution as the direct analysis nodes. They simply serve to make the overall response of the framework-based application more capable than would otherwise in their absence.

Finally, the web enabled nature of OWL enables the potential distribution of the common knowledgebase. Even though the content would be contained under a single semantic umbrella, the underlying implementation could be manifested as a number of separate repositories.

Here are a few resources we have found especially useful in the application ontologies. OWL Overview , Ontological Engineering Book , Protégé Ontology Editor , Jena 2 - A Semantic Web Framework

Contact Us | Search | ©2010 Sharpe Engineering Inc