Title: Ontology Manager The Stanbol Ontology Manager provides a __controlled environment__ for managing ontologies, __ontology networks__ and user sessions for semantic data modeled after them. It provides full access to ontologies stored into the Stanbol persistence layer. Managing an ontology network means that you can activate or deactivate parts of a complex model from time to time, so that your data can be viewed and classified under different "logical lenses". This is especially useful in [Reasoning](reasoners.html) operations. ## Usage Scenarios ### User networks In your CMS, you might be interested in figuring out the trust and acquaintance network of its users. This can be a combination of the _asserted_ network (i.e. what other users are included in the contact or friend list of a given user) with the _inferred_ network (e.g. exclude those who are in the contact list of a blacklisted user). The latter can be derived from the user activities over the user-generated content of your CMS (e.g. blogs posts, forum posts, reviews, tweets, ratings). Both types of networks can be modelled as ontologies. Models can be build on the _class_ level, or _TBox_ (e.g. everyone who is an Administrator is also a User, and collaborates with every other Administrator of the same system) and on the _instance_ level, or _ABox_ (e.g. John is a friend of Mary, who created blog post bp345263 on 3/10/2012 at 15:10). These models can all be stored using the Store facility of the Ontology Manager. Using a [reasoner](reasoners.html) you can classify all the knowledge loaded on Stanbol, but this can be a time-consuming process due to classifying knowledge we are not interested in for this task. [OntoNet](ontologymanager/ontonet.html) allows you to select only the "interesting" parts of your knowledge base. For example, if the knowledge contains classifications of animal species, you may want to deactivate that model when reasoning on user networks. Likewise, you may want to consider the user profiles _today_, rather than who was a user's friend five years ago. Therefore, on the instance level you will exclude the profile history and only consider today's snapshot. ### Knowledge within content Hierarchical, tree-like structures are a tried-and-true mechanism for organizing documents, applications and in fact any content items. What users are required to do is select _one_ set of criteria and organize the directory structure accordingly. For instance, if journalists were to classify the reserch papers on their file system, they could do as follows: * `articles/mine` (articles authored by the users) * `articles/ours` (articles authored by colleagues from the same publication) * `articles/others` (articles of any other kind) This simple structure works well because it creates a perfect partition, i.e. you will always know in which _one_ of these directories any article should go. But what if the user also wanted to create directories by year of publication, or by section (politics, sports etc.)? In a file system it is possible to create these directories and add symbolic links as needed, but what if the user does not want to _know_ a priori the categories to create directories for? Why not have a system that creates them aoutomatically according to the semantics of content that create "good" directories (e.g. not too many directories with just one content item)? Organizing a network of ontologies that describe content items can allow such an application to be built. Having a dataset that represent the metadata of content stored in a CMS, it is possible to attach different ontology scopes, e.g. those with domain knowledge, or with the user's organizational hierarchy. This "virtual directory" structure can also update automatically as the knowledge does. For instance, if the user removes another user from a "friends" list, that user's contributions will also be moved out of a `articles/friends` directory but stay in a `articles/friends_of_friends` directory. ## Features A Web __Ontology__ in computer and information science is a shareable conceptual model of a part of the world [1]. This model describes concepts terms of their characteristics and their relations with other concepts. By means of OntoNet, it is possible to improve ontology managers like this: * Setup multiple __Ontology networks__ simultaneously, by interconnecting the knowledge contained in ontologies that normally would not be aware of one another. * Dynamic __(de-)activation__ of parts of any ontology network, as needed by specific reasoning, rule execution, or other knowledge processing tasks. * Organize ontologies into __ontology libraries__, which can be populated by setting up simple RDF graphs called __registries__. * Use Stanbol as a central __ontology repository__ that mirrors the ontologies scattered aound the Web, so that there will be no need to query more than a single server for all the formal knowledge managed by the CMS. ### Sub-Components - [OntoNet](ontonet/) - allows to construct subsets of the knowledge base managed by Stanbol into OWL/OWL2 [2]ontology networks - [Registry](registry/) - manages ontology libraries for bootstrapping the network using both external and internal ontologies - Store - create, read, update and delete operations on single ontologies stored in Stanbol. These operations can be performed on entities, axioms, and whole ontologies. ## References: * [1] Ontologies (PDF) * [2] The OWL 2 ontology language ____ _[Back to components](../components.html)_