OSF Ontologies Modularization and Architecture

From TechWiki

Ontologies are the central logic and controlling structures in the open semantic framework (OSF).^[1]

At an introductory level, there are two sets of summary documents regarding ontologies on this wiki. One set of documents provides an executive summary to ontologies and their basic role in knowledge systems. A second set of documents pertains to how ontologies are used in an OSF installation. One document in that set -- the present document herein -- describes the overall ontology modularization and architecture within an OSF installation. A complementary document in that set describes the roles and use of ontologies in an OSF instance. Both of these documents are in turn reinforced by an ontology best practices document.

Contents 1 Introduction 2 OSF Constituent Ontologies 3 The OSF Ontologies Architecture 4 Summary of OSF Roles 5 Interactions Are More Complex than Arrows 6 References

Introduction

Ontology-driven applications (or ODapps) are modular, generic software applications designed to operate in accordance with the specifications contained in one or more ontologies. The relationships and structure of the information driving these applications are based on the standard functions and roles of ontologies (namely as domain ontologies), as supplemented by UI and instruction sets and validations and rules. When these supplements are added to standard ontology functions, we collectively term them adaptive ontologies.

This document is a broad overview of the modularization and architecture of the constituent ontologies that make up an OSF installation.

OSF Constituent Ontologies

As presently configured, an OSF installation may typically utilize most or all of the following internal ontologies:

• The SCO Ontology (Semantic Component Ontology)
• The WSF Ontology (Web Service Framework Ontology)
• The AGGR Ontology (Aggregation Ontology)
• The irON Ontology (Instance Record and Object Notation Ontology)
• One or more domain ontologies, to capture the concepts and relationships for the purposes of a given OSF installation, and
• Possibly UMBEL (optional) or other upper-level concept ontologies, used for linkages to external systems.

(Note: the internal wiki links to each of these ontologies also provides links to the actual ontology specifications on Github.)

Depending on the specific OSF installation, of course, multiple external ontologies may also be employed. Some of the common external ones used in an OSF installation are described by the external ontologies document. These external ontologies are important -- indeed essential in order to ensure linkage to the external world -- but have little to do with internal OSF control structures. That is why the rest of this discussion is focused on internal ontologies only.

The OSF Ontologies Architecture

The actual relationships between these ontologies are shown in the following diagram. Note that the ontologies tend to cluster into two main areas:

1. Content (or domain) ontologies, which tend to embody more of the traditional ontology functions such as information interoperability. inferencing, reasoning and conceptual and knowledge capture of the applicable domain; and
2. Administrative ontologies, which govern internal application use and user interface interactions.

This ontology architecture supports the broader open semantic framework:

The WSF ontology plays a special role in that it sets the overall permission and access rights to the other components and ontologies. The UMBEL ontology (or other upper-level ontologies that might be chosen) is also optional. Such vocabularies are included when interoperability with external applications or knowledge bases is desired.

Summary of OSF Roles

We can further disaggregate these ontology splits with respect to their specific dozen or so OSF ontology roles. These dozen roles are shown by the rows with interactions marked for the various ontologies:

One of the unique aspects of adaptive ontologies is their added role in informing user interfaces and supporting specific semantic tools. Note, for example, the role of the content ontologies in informing interface displays, as well as their use in tagging concepts (via information extraction). These additional roles are the reason that these ontologies are shown as straddling both content and administrative functions in the first figure.

Interactions Are More Complex than Arrows

Naturally, a simple drawn arrow between ontologies (first figure) or a checkmark on a matrix (table above) can hide important details of how these interactions between ontologies and components actually work. In the Introduction to Semantic Components we can see how the whole workflow takes place between users and user interface selections affecting the types of data returned by those selections, and then the semantic components (widgets) used to display them. This example interaction is shown by the following animation:

The blue nodes show the ontology interactions. These, in turn, instruct how the various components (yellow) and code (green) need to operate. These interactions are the essence of an ontology-driven app. The software is expressively designed to respond to specifications in the ontology(ies) used, and the ontologies themselves embrace some additional properties specific to driving those apps.

References

1. ↑ The first version of this document appeared as M.K. Bergman, 2011. An Ontologies Architecture for Ontology-driven Apps, December 5, 2011.