Extending the Ontology with a domain-specific model, defining classes and relationships
As a semantic annotation platform, KIM uses ontologies and knowledge bases. It can also generate and store new knowledge. This section explains the roles of the different data sources related to KIM. It also clarifies which are mandatory and which are subject to configuration, extension or customization.
KIM is based on the PROTON ontology, developed in the scope of the Semantically Enabled Knowledge Technologies (SEKT) project. KIM depends solely on the System module of PROTON that is further extended by KIMSO (KIM System ontology). The other related ontologies - KIMLO (KIM Lexical ontology) and the Top and Upper modules of PROTON, are part of the distribution. KIM makes use of them, but they can also be replaced, changed, or extended.
PROTON is a light-weight upper-level ontology that defines about 300 classes and 100 properties, covering most of the upper-level concepts, necessary for semantic annotation, indexing, and retrieval. It is separated into three modules:
|System module||contains a few meta-level primitives (5 classes and 5 properties). It introduces the notion of 'entity' that may have aliases. The primitives on this level are usually a few elements that have to be hard-coded in the ontology-based applications. This module can be considered as an application ontology.|
|Top module||the highest, most general, conceptual level, consisting of about 20 classes. They ensure a good balance of utility, domain independence, and ease of understanding and usage. The top layer is usually the best level for establishing alignment to other ontologies and schemata.|
|Upper module||over 200 general classes of entities, that often appear in multiple domains (E.g. various sorts of organizations, a comprehensive range of locations, etc.)|
The diagram below demonstrates the dependencies between the different modules of PROTON and the KIM specific modules. The strongest dependency is placed at the bottom of the diagram.
The diagram also illustrates potential extension/customization paths. You can easily extend or substitute (partially or completely) the proprietary PROTON Top and Upper modules with any other Top and Upper ontologies. (Here, this is represented by the Custom Top Ontology and Custom Upper Ontology). However, we expect the PROTON Top and Upper modules to be efficient, consistent, and generic enough to satisfy the needs in the majority of use cases.
Application Ontology and Domain Ontology are designators of the respective specific application and/or domain ontologies that will be mapped to PROTON as its extensions, depending on the requirements of each particular use case.
To summarize, in order to be recognized by KIM, any extensions to the ontology must be integrated with PROTON and KIMSO.
In order to integrate an ontology extension, you have to accomplish two steps:
- the new classes should subclass protons:Entity
- set the new classes' visibility level
Make sure that the new classes inherit at least http://proton.semanticweb.org/2006/05/protons#Entity, directly or indirectly.
|We recommend that, if applicable, your classes inherit one of these PROTON Top classes:|
By default, the ontology extension modules (* .owl) are located in the <KIM_HOME>/context/default/kb/owl folder. You can place them somewhere else if you prefer, as long as you include them in the OWLIM configuration file correctly.
All classes should have the "label" attribute set. You should pay special attention when using a third-party schema designer to create the ontology extension.
Here is an example extension module that defines "Robot" as a class and also defines the relation "createdBy":
If you have an existing ontology in OWL, you can alternatively create a separate mapping file with only rdfs:subClass statements . Then add both your ontology and the mapping file to the KIM Server installation. See this step-by-step mapping from DBPedia ontology integration case-study as an example:
All new classes that should be visible in the class hierarchy in the web interface and in the Structure/Patterns screens must be declared "visible" in the <KIM_HOME>/context/default/kb/visibility.nt file like this:
Example: visibility.nt (addition)