From IKS Project
Jump to: navigation, search


The main feature of the Stanbol CMS Adapter (a.k.a OntoGen) component is to provide defining semantic relationships between content items of a CMS and transforms those relationships to ontology elements. In this manner, already available semantics in CMSs can be extracted and stored in a knowledge base.

CMS Adapter provides ontology generation mechanism on JCR and CMIS interfaces. Furthermore, RESTful services are supplied for CMSs that do not support JCR or CMIS. This semi-automatic ontology generation mechanism can be thought as a semantic bridge between a content repository and a knowledge-base storing the extracted semantics.

Repository Content Model


Considering hierarchical repository model of JCR and CMIS and for the sake of having a generic model that can be used by any content repository, we keep the common model as generic and abstract as possible as depicted in figure. This model covers structure of JCR and CMIS repositories i.e Object element in the figure corresponds to node in JCR repository and object in CMIS repository. Thanks to child relation objects can have child objects and a hierarchical structure can be represented like in JCR or CMIS repositories. In addition to other common properties of those repositories e.g property of elements or object type/node type model, we have added two other conceptual elements which are Content Object and Classification Object. Content objects are used to represent repository items that contain actual data. On the other hand, Classification Objects are conceived to represent hierarchical structure of content repositories.


Semantic relationships between content items are defined with the help of the following bridge constructs.

  • Concept Bridge: This bridge allows the content administrator to annotate the graphically selected objects in the content repository as classification objects. As a result of this bridge execution, an ontology class or an ontology class hierarchy is created corresponding the selected objects.
  • Subsumption Bridge: This bridge allows users to specify the properties in a content repository that correspond to subsumption relationships in the ontology. A Subsumption Bridge has two elements: objectQuery element is used to specify the objects as “SuperClasses”, and the predicateName specifies the property name that will be used to select the “SubClasses” of these objects selected as “SuperClasses”.
  • Property Bridge: In order to selectively “lift” some of the content repository properties to the ontological representation being created, Property Bridge construct is used. Property Bridge helps to selectively lift the semantics of properties. Similar to Subsumption Bridge, the Property Bridge has two elements: the objectQuery element is used to specify the set of objects to which this PropertyBridge is applied to. The selected objects are set as the “domain” of the ontology property that is to be generated. The predicateName element gives the name of the property in the content repository to be used to select the range of the ontology property.
  • Instance Bridge: This bridge is used to select the objects in the repository that are actually used for storing content items, i.e. to select content objects. Each selected object is created as an individual of the class created to represent its object type.


  • Graphical User Interface

In order to explicate the semantics of a content repository supporting standard interfaces semi-automatically we have developed a GUI. The user is provided with four graphical semantic bridge constructs. As the user drags and drops, indicating the correspondences between the selected repository item or item collections and the semantic bridge constructs; the native content repository queries are automatically generated by the system along with the bridge definitions in XML. After retrieving the object types and processing them the semantic lifting mechanism processes these bridge definitions, and the ontological representation of the repository content model is enriched with the new axioms.


Initially users meet with CMS connection screen and after requested data is provided and connecting successfully, CMS Adapter retrieves hierarchical structure of the repository like in the figure in the bottom. Thanks to “New Bridge” on top of the figure, it is possible to define bridges which are explained above. Once bridge definitions are completed “Save” button is clicked. The dialog shows the intermediate XML format i.e bridge definitions that will be processed. After clicking “Start Engine” button, it creates corresponding elements according to bridge definitions in the target ontology having URI specified in the Ontology URI field.

  • RESTful Interface:

CMS Adapter provides RESTful interfaces to interact with CMSs that do not support JCR or CMIS. See the provided RESTful services through the following link. CMS Adapter RESTful Services