CMS Adaptor

From IKS Project

Jump to: navigation, search


PAGE_TITLE: Q01TIEFkYXB0b3I=


Short Description

CMS Adapter (a.k.a OntoGen) provides services for 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 also aims to keep generated ontology synchronized with content repository by providing notification services to submit updates on the content repository.

Software Licensing: Apache License, Version 2.0

What can this software do?

Main Features 

CMS Adapter provides ontology generation mechanism on JCR and CMIS interfaces. 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.

  • Ontology Generation:
  1. CMS Adapter can lift an ontology from any JCR/CMIS enabled content repository when provided the URL and credentials of the repository.
  2. Lifting can be done on any content repository when the content is converted to Content Repository Model.
  3. Updates on a content item or deletion of a content item can be reflected on a previously created ontology through RESTful services.





Demos



Developer Stuff

Development Resources

Web page: http://wiki.iks-project.eu/index.php/CMS_Adaptor

Source code: incubator/stanbol/trunk/cmsadapter

Issue Tracker: Uses STANBOL issue tracker

Mailing list: stanbol-dev AT incubator.apache.org

Modules

Main modules of CMS Adapter:

  • API: Generic Content Repository Model, common interfaces used by CMS Adaptor modules.
  • Core: Processors for generic Content Repository model.
  • Web: RESTful services.
  • JCR Adapter: Implementation of JCR specific processors.



Releases

This component is not released yet.

Roadmap

Following items are planned to be implemented before the first release:

  • Enhanced RESTful Services: Implementation of CRUD operations on all Content Repository Model objects through RESTful services.
  • CMIS Module: Current implementation is restricted to apply bridge definitions on JCR enabled content repository. The release should include an adaptor for CMIS enabled repositories.

Documentation

  • 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.

  • Bridges:

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

  1. 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.
  2. 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”.
  3. 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.
  4. 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. It is not supposed to be defined standalone instead it is used in a ConceptBridge or InstanceBridge.
  • 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