This document is also available in non-normative PDF version.
Copyright © 2006 by DIP. All Rights Reserved. DIP liability, trademark, document use, and software licensing rules apply.
This document provides a tutorial and user guide for the DIP Ontology Management Suite (OMS), a repository-based tool suite for editing & browsing for WSML ontologies with integrated versioning and an editor for ontology mappings.
As a comprehensive user guide for the integrated OMS tool suite, this document accompanies the following deliverables of DIP work package 2 (Ontology Management):
This document provides the user guide for the DIP Ontology Management Suite OMS, an integrated repository-based tool suite for editing and browsing of WSML [Lausen et al., 2005] ontologies along with integrated versioning support, an editor for ontology mappings, and a reporting tool for external browsing and community-enabled ontology development. While the technical information for each tool is provided in the respective fact sheets, this document focuses on the provided end-user facilities and explains their usage in form of a tutorial.
The document is structured as follows: The remainder of the introduction recalls the need for ontology management and explains the approach and facilities provided by the OMS. The next sections explain and illustrate the usage of the OMS in detail: Section 2 explains the editing and browsing facilities for ontologies, Section 3 illustrates the versioning technology for ontology evolution support and explains the OMS facilities, Section 4 explains and illustrates the usage of the Ontology Mapping Editor of OMS, and Section 5 illustrates the ontology reporting facility for external browsing and community feedback for ontology repositories managed with the OMS.
Ontologies provide a shared and common understanding of a domain that can be communicated between people and application systems [Fensel & Brodie, 2003]. As a modern knowledge representation technique, an ontology consists of concepts that denote entities of a domain that are characterized by attributes, relations that describe correlations and associations between concepts with subsumption and membership relations defining the taxonomic structure of an ontology, axioms that define constraints and complex aspects of the domain in terms of logical expressions, and instances as concrete individual in a domain that are associated to concepts, relations, and axioms as the ontology schema definition. Ontologies are considered as the base technology for the Semantic Web [Berners-Lee et al., 2001], and provide the data model for Semantic Web Services: every semantic resource description is based on ontologies, and each data element interchanged between a Web service provider and its clients is defined in terms of an ontology [Fensel & Bussler, 2002].
For realizing the vision of semantically enabled web content processing on basis of ontologies as well as their usage as the underlying data model for Semantic Web services, ontology management technology is indispensable. Ontology-enhanced commercial applications require ontology management that is scalable, available, fast, and reliable [Das et al., 2001]. This comprises techniques for editing, storing, browsing, and maintaining ontologies - similar to data base management technologies for conventional IT technology. In order to provide sophisticated ontology management facilities for the Semantic Web and Semantic Web services, the required techniques should be integrated in a coherent tool suite that supports ontology engineers and users throughout all management task occurring during ontology development, evolution, maintenance, and usage.
An ontology management system provides a mechanism for dealing with ontological information at an appropriate level of abstraction [Lee et al., 2004]. This is the purpose and aim of the DIP Ontology Management Suite (short: OMS), which provides newly developed tools for the central ontology management tasks and integrates them into a coherent tool suite for ontology engineers and users. With respect to the distinct requirements that occur for ontology usage in the Semantic Web and Semantic Web services, the OMS realizes a novel approach that (1) considers ontology versioning for evolution support and ontology mapping for handling heterogeneities between ontologies as first class citizens, and (2) provides repository -based ontology management in order to ensure scalability and persistent storage of ontology data. Figure 1 shows the OMS approach with 3 horizontal layers: repository-based storage, representation by the ontology language and data model, and user interfaces for the 3 vertical end-user tools: editing & browsing facilities, versioning and evolution support, and editing and maintenance facilities for ontology mappings. While we recall the technical architecture of the OMS below, the remainder of this document focuses on the usability of the vertical end-user tools.
| Figure 1. DIP Ontology Management Approach |
 |
The DIP Ontology Management Suite OMS provides an integrated, extensible tool suite for editing, maintaining, and managing WSML ontologies. In accordance to the ontology management approach outlined above, Figure 2 shows the architecture of the OMS implementation. At the storage layer, two ontology repositories are provided in order to allow scalable ontology management with persistent data storage: the FOR repository (see: http://sw.deri.org/2005/03/diprdf/UnicornRepositoryFactSheet.html) is a the default repository of the OMS, while ontology data interchange with the triple store YARS (see: http://sw.deri.org/2005/03/diprdf/FactSheet) is facilitated through ORDI, a repository middleware that extends WSMO4J (see http://www.ontotext.com/ordi/v0.3/FactSheet.html). At the representation layer, the Web Service Modeling Language WSML - the specification language for WSMO and DIP [de Bruijn et al., 2005] - provides the conceptual and logical specification language for ontologies along with WSMO4J as the data model; with WSMO4J being the common interface for WSMO and DIP applications, this layer enables interoperability with other WSMO and DIP tools and systems. The application layer consists of four end-user tools: the editing and browsing facilities for ontologies (see Section 2), the versioning tool for ontology evolution management (see Section 3), the mapping editor (see Section 4), and the ontology reporting tool (see Section 5). Apart from the reporting tool that is provided as a web application in order to allow external browsing of the OMS repository, the user interfaces of all tools are realized as plug-ins for the Eclipse framework [Object Technology International, 2003] - an open source development environment that has been chosen as the common technical platform for all DIP user interfaces; the OMS versioning technique (see: http://www.omwg.org/tools/versioning/v1.0/FactSheet.html) as well as the OMS Mapping Editor (see: http://www.omwg.org/tools/dip/factsheets/MappingEditorFactSheet.html) provide open source APIs.
| Figure 2. OMS Architecture |
 |
While the subsequent sections explain and illustrate the usage of the OMS end-user tools, we denote the following beneficial features of the OMS architecture:
This section explains and illustrates the OMS facilities for editing and browsing ontologies. We first explain why editing and browsing is desired and then illustrate the ontology editing facilities and their usage in detail.
Ontology library systems should feature adequate editing and browsing functions [Davies et al., 2003]. Hereby, editing includes the creation, the modification and the deletion task. Browsing includes tasks like exploring the hierarchy of concepts, blending in their attributes and getting handed on to the respective instances which in turn reveal their attribute values.
On the UI level, ontologies to be edited and browsed have to be visually represented. The user has to be enabled to interact with the displayed objects.
On the representation layer, editing & browsing regards the in-memory treatment of ontology objects. I.e., a data model exists that can on demand be visualized to the UI or saved to the storage.
The storage layer is responsible for long-term persistence of ontology elements. Especially for large scale ontologies this is crucial, as they cannot completely be loaded into read-only memory.
In the following, we explain the central tasks for ontology creation, editing, import, and export in detail.
The OMS is an ontology management for the Web Service Modeling Language WSML; for syntax and semantics specification we refer to [de Bruijn et al., 2005] along with an introductory guide for ontology specifications in WSML as provided in [Feier, 2005]. It is to note that support for other ontology languages is an orthogonal aspect to the OMS ontology editing: import / export / transformation to other languages like OWL or RDF are allocated in WSML .... respective translation services are to be added in future versions.
In order to create a new ontology, right click “Ontologies” in the left column of the Repository View (see Figure 3), select “New…” from the context menu and filling out the up-popping form dialog. Import an ontology by right clicking on “Ontologies”, selecting “Import…” from the context menu and selecting a WSML file in the up-popping dialog. Open an ontology from the repository by either double clicking on it or right clicking it and selecting “Edit” from the context menu
Figure 3. The repository view
In order to edit ontology components displayed in the outline view (see Figure 4) one has to double-click on them.
Figure 4. The outline view
Use the Properties view (see Figure 5) to inspect properties of ontology components selected in the outline view or in an editing form.
Figure 5. The properties view
NOTE: The forms, described in the following, can be opened in parallel, i.e. arbitrarily many at a time. If this is done, it can be switched between the forms by using the tabs provided at the bottom of the forms.
In order to edit a concept or a relation double click it inside the composition tree. The opening form page (see Figure 6) contains sections for the NFPs, the identifier and the properties of the edited concept / relation. Within the concept / relation section
Figure 6. The concept editing form
In order to edit an instance or relation instance, double-click it inside a form page where it is referenced to (e.g. inside the ontology form page). The opening form page (see Figure 7) contains sections for the NFPs, the identifier and for the properties of the instance / relation instance. Within the instance / relation instance section the user can
Figure 7. The instance editing form
To edit an axiom double click it inside the composition tree. The opening form page contains sections for the NFPs, the identifier and the definitions of this axiom. Right clicking a definition allows to select the edit command from the context menu. Inside the opening logical expression editor (see Figure 8) the definition can be modified. Hereby, the user is supported through syntax highlighting and code completion (invoked through the space key).
Figure 8. The logical expression editor
WSML ontologies can be validated against one of its variants
The validation can be explicitly invoked by right-clicking on an ontology in the repository view and selecting "Validate WSML..." from the context menu. In case of an error a respective message will pop-up (see Figure 9).
Figure 9. A validation error message
This section explains and illustrates the OMS facilities for the versioning and evolution of ontologies. We first explain why versioning and evolution is desired and then illustrate the ontology versioning facilities and their usage in detail.
In the Semantic Web setting, evolution is a persistent problem through the whole ontology life-cycle, i.e. ontology elicitation and ontology application. The elicitation of these ontologies is conducted massively in a distributed fashion, and is governed by a combination of ontology engineering processes such as: (i) lexical disambiguation of terms into concepts [De Leenheer and de Moor, 2005], (ii) “conceptualization” of existing definitions for particular purposes by refinement, restriction, projection, etc. Different parties might disagree on the actual meaning and relevance of concepts and processes. This leads to a diverging range of (subjective) views (versions). Finally, (iii) ontology integration is indispensable when converging or combining subontologies [Euzenat et al., 2001; Kalfoglou and Schorlemmer, 2005].
All these processes characterizing ontology engineering on the level of the Semantic Web show that ontology reuse is not a trivial copy-paste, and hence should be supported by a respective set of tools and an ontology management framework.
This imposed strong requirements on our ontology (versions) management infrastructure (and consequently our tool suite), which is not be limited to the persistent identification, storage, and versioning of multiple concurrent versions, such as required for a classical library system [Ding and Fensel, 2001]. On the contrary, we provide an additional canonical set of operators to alter or access the ontologies. Different resolution strategies are presented to the knowledge engineer when during evolution the ontology is brought into a presumed inconsistent state. Furthermore, there is a way to describe ontologies with meta-information, and express dependencies (in terms of e.g., change logs or mappings) between ontologies that result from particular OE processes such that alternative definitions can possibly be disambiguated properly [De Leenheer et al., 2006 ; de Moor and De Leenheer, 2006]. Such an infrastructure increases the power of the ontology engineering processes on top of it. E.g., three-way merging of two ontologies is much straightforward: if there is a common origin and this origin is known, or can be read in terms of the correlations. Furthermore, a management framework is indispensable during the application of ontologies, where (autonomous) agents representing multiple stakeholders, have multiple views on multiple ontologies. The availability of this contextualized knowledge is critical, as these agents are expected to collect the right bits and pieces of meaning for correctly interpreting web services.
From versioning point of view, any ontology is in two states - a committed (stable) version or a version in progress. The difference between these two is that a committed version is guaranteed to remain unchanged - any updates, tweaks or bug fixes will be part of a later version. A committed (frozen) ontology version gives its users the stability necessary for developing and testing their products, and if a problem with a committed version is discovered, the users may migrate (usually with little pain) to a new version when they need it.
From the point of view of a human editing an ontology, this means that they should only "commit" a version when they want to publish it to their users.
When a new ontology is created (or a previously unversioned ontology is imported), it adopts the state "in progress", also called "uncommitted" or "changed". Any changes may be made to such an ontology, and it can be saved to a file or to a repository as usual. When the ontology reaches suitable maturity level, the user may choose to "commit" it (see Figure 10). This action will also give the ontology a new non-functional property to indicate that the ontology is now committed (frozen). Notice that the user may specify a commit comment (something like a textual change log entry) and a version identifier for the committed version, but we will mention changing the version identifiers later.
Figure 10. The commit dialog
If there was a previous committed version, the ontology management tool keeps track of a limited log of changes so that it can also automatically generate a mapping document (see Figure 11) that captures a part of the relationship between the two versions (the change log is visible in non-functional properties of the ontology, and in a field in the commit dialog). Since the tool cannot guess the intent of most ontology changes, the generated mapping relates elements that have not changed substantially, and it will usually be necessary for the user to fill in any missing pieces if a full mapping is desired.
Figure 11. How to invoke the generation of a mapping document
Once the ontology is "committed", the user may decide to start working on a new version - whether it is to fix a bug, to add new parts or just to tweak the ontology. A new version is started automatically when a user does any change to a committed ontology. The new version gets an increased version identifier, but that identifier can be changed easily when this version is ready to be committed again - the commit dialog gives the user the power to set any arbitrary version identifier. Because a "committed" ontology is meant for public use, various factors may influence the form of the version identifier - to illustrate, we can take the sequence of some major version identifiers for the Microsoft Windows operating system - 3.11, 95, 98, 2000, XP, and possibly Vista.
The list of available ontologies shows for every ontology a listing of previous versions (if any), which allows the user to browse through the older versions. Indeed, the user can take any of the previous versions and "branch out" a new version from it; however, care must be taken not to use a version identifier under which this ontology was previously committed.
Throughout several edits made by the user there may be certain cases where more than one obvious behavior is optional and the editor supports several of those cases. As the user edits (evolves) an ontology, there may be cases where an action may have impact on other parts of the ontology and where multiple different ways of resolving that impact are apparent. For instance, when deleting a concept that has instances that are members only of this concept, the options are:
To illustrate, let us assume we just got a new legislation forbidding discrimination based on race of employees, and we may want to remove the concepts Black, Caucasian etc. and move the instances into the superconcept Human; but when we discontinue a line of products (we may sell our laptop computer subdivision), we remove the concept LaptopComputer and we want to drop all the instances with it. For an ontology editing tool, it would be very hard to distinguish between these two cases, therefore the tool contains a wizard (see Figure 12) that guides the user through the choices.
Figure 12. The evolution strategy wizard
The OMS Mapping Editor supports editing ontology mapping documents. Ontology mappings is an important part of ontology management as it allows interoperability between the ontologies modeling a same domain with a different perspective. While we refer to [Scharffe 2006] for details and the mapping language specification, the following explains and illustrates the usage and handling of the OMS mapping editor.
In order to create a new mapping document, select the ‘Ontologies’ blue box, right click on your source ontology and select ‘New Mapping Document’ menu item. This will open the mapping editor (see Figure 13). Dragging the target ontology to the right panel will create the initial mapping document. To add a mapping rule drag an element from the source ontology to an element of the target ontology:
Figure 13. The mapping editor
Tip: right click on the ‘Repository View’ tab and select ‘Fast View’ to enlarge the mapping canvas.
To edit the mapping rule properties, click on the mapping rule. A form will appear on the bottom, letting the user edit the mapping rule label, directionality, logical expression and annotations.
Navigating the mapping rule is done by clicking on the mapping rules tree on the ‘Outline View’ on the upper LHS.
To create a complex expression (see Figure 14), drag another ontology element (of the same type) to the current expression on either side:
Figure 14. A complex expression
To edit the operator of the complex expression, click on the expression and edit the form view (see Figure 15) on the bottom.
Figure 15. The form view
To add more sub-expressions to the complex expression drag ontology elements to the complex expression icon or the operator label on the top of the complex expression figure.
An advanced mapping feature is the ability to create nested complex expressions. This is done by dragging an ontology element on a sub-expression:
Right click on the blue ‘Mapping Documents’ node. The user can import an existing mapping document from a “*.map” file. Selecting a file and pressing OK will import the mapping document into the repository.
Note: the import will work only if the referenced ontologies and ontology element described in the mapping document exist in the repository!
Known bug: currently there is a bug in the mapping parser that can not parse mapping documents with instance mappings.
Right clicking on a concrete mapping document in the repository will display the available actions on a mapping document:
‘Export’ will export the mapping document from the repository to a file. A ‘Save’ dialog enables the user set the file name. A mapping document may be exported in 3 formats indicated by the exported file extension:
Click on edit for editing a mapping document. You can either browse or edit the mapping rule as described above.
‘Delete’ will delete the mapping document from the repository.
This section explains and illustrates the OMS facilities for the reporting about ontologies. We first explain why reporting is desired and then illustrate the ontology reporting facilities and their usage in detail.
The fourth and final OMS end-user tool is the reporting tool (RT). An important aspect of ontology management is the ability to better understand your ontologies. This deliverable is a graphical user interface (GUI) for reporting functionality that is intended to provide this understanding as it provides repository browsing and various graphical reports. In contrast to the other tools that are provided as Eclipse plug-ins to be used by ontology engineers, the reporting tool is provided as a web application. A web based thin client is an important interface to an ontological reporting tool. Insofar as the goal of the system is to expose and communicate a shared ontology and the benefits thereof, the value of the system increases as the number of users able to interact with the system increases. Most end-users in an organization, and particularly those who are most concerned with reporting and analyzing the information as opposed to creating it, are not likely to install a complex software package to handle these discreet jobs. Therefore a thin, web based reporting tool is critical for reaching these business focused end users. This approach is a step towards a semantic web where distributed communities of interest are exposed to existing ontologies and in addition are able to provide feedback and change requests to the ontologies owners.
Referring to the fact sheet for installation instructions and technical details (see: http://www.omwg.org/tools/dip/factsheets/ReportingToolFactSheet.html ).
The reporting tool features advanced graphical views of ontologies and mappings such as "UML style" ontology hierarchy diagram and mapping data lineage diagrams. In addition it has a generic relations (neighborhood) diagram, search capabilities and statistical reports. Following is a detailed description of the reporting tool facilities.
In order to use the reporting tool, a web server must be running on the same machine as the ontology database server.
The welcome page serves as an entry point to repository browsing. On the right hand side displays the number of ontologies, mapping documents and change requests stored in the repository (see Figure 16).
Figure 16. The repository overview
By clicking on a category (i.e. ontologies or mapping documents), the following screen (see Figure 17) is displayed. For example, by clicking on Ontologies category, a list of the ontologies stored in the repository is displayed:
Figure 17. An ontology list
Clicking further on ontology shows the entities of the ontology:
For example, by clicking on Ontologies category, a list of the ontologies stored in the repository is displayed.
Clicking further on an entity navigates on nicely. For example, let’s click on concept “Parent”:
The RT can display a neighborhood graph (see Figure 18) for every entity stored in the repository. Neighborhood graph show all the entities that are referenced by the selected entity. For example, the neighborhood graph for the tc.wsml ontology looks as follows:
Figure 18. A neighborhood graph
In addition to the functionality described above which is a generic functionality for every entity of any type stored in the repository, there are additional graphs specific for ontologies and mapping documents.
Returning to the ontologies list page, clicking on “UML Graph View” icon will show a ‘UML style’ diagram (see Figure 19) that shows the concepts of the ontology and their hierarchy.
Figure 19. A UML graph
Clicking further on a concept will display its super classes and sub-classes.
From the mapping documents list page (reached from the homepage), clicking on “Data Lineage” icon will show display expanding diagrams that show source and target ontologies and the mapping rules of the mapping document. Clicking on a specific mapping rule and expanding it will show the data lineage mapping rule level (see Figure 20).
Figure 20. A lineage diagram
In addition access to the graph is also available while browsing any element from the ‘Actions’ menu on the upper top left of the screen.
Statistics information is available on ontologies and mapping documents from the entities list page. Clicking on statistics icon shows the following information (see Figure 21).
Figure 21. A statistics example
Since the idea of the web based reporting tool is to easily share ontologies and mappings across a large community, it is important to have some kind of a feedback mechanism from the RT users which do not have rights to modify the data to the editors of the content in the repository. Therefore it is possible to create a ‘Change Request’ (see Figure 22) via the RT.
To create a ‘Change Request’: From the home page. Click on ‘Change Requests ’, on the next page, click on ‘Actions’ and select ‘New Change Request’.
Fill in the form and press ‘OK’.
A new change request is created. The OMS user can see the request and handle it.
In addition it is possible to edit and remove change request by browsing the elements from the ‘Actions’ menu on the upper top left of the screen.
Figure 22. A change request
An additional powerful feature of the RT is the ‘Audit Trail’ report (see Figure 23) which can be run on any entity. This report shows changes done to the entity across time.
For example, the following ‘Audit Trail’ of the 'trip' concept shows its creation and that it has been edited:
Figure 23. An audit trail report
A search input field is available on top left of every screen.
It is also possible search within results and there is also an ‘Advanced Search’, where it is possible to limit the search scope a specific type.
Wild characters can be also applied by using ‘%’, although by default a wild character is applied at the end of the search string.
Note: refining you search criteria will improve the response time. The results are returned within a concise table (see Figure 24).
Figure 24. A search result
The RT caches information to increase performance, so if the repository have been modified by other tools, such as the OMS, the cache needs to be refreshed by clicking ‘Refresh Repository Cache’ on the home page (see Figure 25).
Figure 25. The "Refresh Repository Cache" link
[Berners-Lee et al., 2001] Berners-Lee, T., Hendler, J., Lassila, O. (2001). The Semantic Web. Scientific American.
[Das et al., 2001] Das, A., Wu, W., McGuinness, D.L. (2001) Industrial Strength Ontology Management. Paper presented at the First Semantic Semantic Web Working Symposium, Stanford, USA.
[Davies et al., 2003] Davies, J. , Fensel, D., van Harmelen, F. (2003) Towards the Semantic Web: Ontology-Driven Knowledge Management, John Wiley and Sons.
[De Bruijn et al., 2005] de Bruijn, J., Krummenacher, R., Lausen. H., Polleres, A., Predoiu, L. : Ontology Representation Language, DIP Deliverable D2.7, June 2005.
[De Leenheer and de Moor, 2005] De Leenheer, P., and de Moor, A. (2005) Context-driven Disambiguation in Ontology Elicitation. In Shvaiko P. & Euzenat J.,(eds.), Context and Ontologies: Theory, Practice and Applications, AAAI Technical Report WS-05-01 (Pittsburgh, Pennsylvania), AAAI Press, pp. 17--24.
[De Leenheer et al., 2006] De Leenheer, P.,de Moor, A., and Meersman, R. (2006) Context Dependency Management in Ontology Engineering. STARLab TR STAR-2006-01, Brussel.
[De Moor and De Leenheer, 2006] de Moor, A., De Leenheer, P., and Meersman, R. (2006) DOGMA-MESS: A Meaning Evolution Support System for Interorganizational Ontology Engineering . In Proc. of the 14th Int'l Conference on Conceptual Structures (ICCS 2006) (Aalborg, Denmark), LNAI 4068, Springer-Verlag, pp. 189-203, in press.
[Ding and Fensel, 2001] Y. Ding, and D. Fensel (2001) Ontology Library Systems: The key for successful Ontology Reuse. In Proceedings of the 1st Semantic web working symposium, Stanford, CA, USA.
[Euzenat et al., 2001] Euzenat, J., Le Bach, T., Barrasa, J. and et al. (2001) State of the Art on Ontology Management. Knowledge Web Deliverable KWEB/2004/d2.2.3/v1.2.
[Feier, 2005] C. Feier (Ed.): WSMO Primer, WSMO Deliverable D3.1, WSMO Working Draft 30 April 2005, latest version available at http://www.wsmo.org/2004/d3/d3.1/.
[Fensel, D., Brodie, M., 2003] Fensel, D., Brodie, M. (2003) Ontologies: a silver bullet for knowledge management and electronic commerce. Springer.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Kalfoglou and Schorlemmer, 2005] Kalfoglou, Y. and Schorlemmer, M. (2005) Ontology Mapping: the State of the Art. In Proc. Of the Dagstuhl Seminar on Semantic Interoperability and Integration (Dagstuhl, Germany).
[Lausen et al., 2005] Lausen, H., deBruijn, J., Polleres, A., Fensel, D. (2005) WSML - a Language Framework for Semantic Web Services presented at the W3C Workshop on Rule Languages for Interoperability, Washington DC, USA
[Lee et al., 2004] Lee, J. et al. (2004) Towards Enterprise-Scale Ontology Management from http://alphaworks.ibm.com/g/g.nsf/img/semanticsdocs/$file/ent_ontmgmt.pdf
[Object Technology International, 2003] Object Technology International (2003) Eclipse Platform Technical Overview from http://www.eclipse.org/whitepapers/eclipse-overview.pdf
[Scharffe and de Bruijn 2005]Scharffe F., de Bruijn J. (2005): A Language to Specify Correspondences between Ontologies, In Proc. IEEE SITIS`05, Yaounde, Cameroun
[Scharffe 2006]Scharffe F. (2006): Mapping Tool Background, DIP Deliverable 2.6.