The Semantic Web aims to add a layer of meaning to the World Wide Web [134]. It is characterised as an open and distributed environment, where few assumptions can be made about the parties involved (for more on environments see Section 6.2.3). The result of this is to turn the Web from a web of documents into a web of knowledge, whereby the knowledge becomes machine understandable. For example, a query such as“Give me a list of Jaguars built before 1980”. This query on the ‘syntactic’ (current) Web is useless because the search engine has no notion of what the query is about; for that we need semantics. If all the pages containing information about jaguars were marked up in such a way as to describe the information they contained in a machine understandable way11 then, it may be possible, for a computer to disambiguate the terms used in the query. For example, it would be able to tell the difference between Jaguar the car manufacturer and jaguar the animal. On the Semantic Web it is assumed that every resource is given a uniform resource identifier (URI) so that “anyone can link to it, refer to it or retrieve a representation of it” [116].
“The challenge of the Semantic Web, therefore, is to provide a language that ex- presses both data and rules for reasoning about the data” [134]. Thus, ontologies provide the mechanism by which we can assign semantics to the Web, but having an ontology is not enough. The adoption of a standard ontology language to encode on- tologies is required to prevent the Web from becoming a set of “isolated monoliths” [57]. By agreeing upon a standard ontology language, for the Semantic Web this is OWL (see Section 2.3), we are agreeing upon both a shared syntax and a shared semantics to interpret this syntax. For example, if one ontology contains the following statement in OWL:
<owl:Class rdf:ID="PhDStudent">
<rdfs:subClassOf rdf:resource="#Student"/> </owl:Class>
This states that PhDStudent is a subclass of Student. However, for this to be machine understandable this syntax needs to be given a standard semantics so that the notion of ‘subclass’ remains the same across machines. In the case of OWL, the standard semantics are Description Logic semantics, see Section 2.3, which in this case means that every instance of PhDStudent is also an instance of Student and it is possible, though not necessary, that PhDStudentand Student are equivalent. Thus, a standard syntax and semantics, or ontology language, provides a way to unambiguously interpret a set of symbols.
11
This kind of markup is possible through the use of RDFa (http://www.w3.org/TR/
In Semantic Web ontologies facilitate interoperability by allowing the different par- ticipants to agree on the meaning of the terms they use to communicate. An important step towards this is to achieve a form of consensus. Section 6.4 demonstrates a mecha- nism by which agents are able to reach consensus over a set of mappings between their ontologies. However, consensus can be achieved in another way and that is through the use of a shared ontology, with the shared ontology representing a shared concep- tualization. For example, the Friend of a Friend (FOAF)12 ontology is an ontology for describing people and the links between them. Thus, if two separate ontologies reuse FOAF to describe the people in their ontology then they will be interoperable with respect to the terms described by FOAF; each ontology will be able to interpret the description of a person provided by the other ontology.
12
Chapter 3
Ontology Modularization
‘Peace comes from within. Do not seek it without.’ - Buddha
Summary This chapter details the research relating to ontology modularization, the process of identifying subsets of an ontology. Both ontology partitioning and on- tology module extraction are approaches to ontology modularization. The different ontology modularization techniques are discussed, including both logical and traver- sal based ontology module extraction techniques. A classification of ontology module extraction techniques based on their properties is also provided. Work covering the is- sue of producing a common framework for ontology module extraction is also discussed.
3.1
Motivation
Ontologies are increasingly being used in knowledge management systems, e-Science, and bio-informatics [124]. As such, ontologies are used to perform a diverse range of tasks, such as reasoning, query answering, reuse, etc.; with each of these tasks placing different constraints upon the ontology. However, the design, maintenance, reuse, and integration of ontologies are complex tasks [24]. In order to provide efficiency gains for these tasks one can use ontology modularization.
Ontology modularization overcomes the problem of identifying a fragment of an existing ontology to be reused and is listed as one of the principles for building good ontologies in Ontology Engineering good practices [6]. It enables ontology developers to include only those concepts and relations that are relevant for the application they are modelling an ontology for. In essence, why use the whole ontology when an ontology module would suffice?
Consider the example ontology presented in Section 2.5 that presents an ontology about theses, and in the application under consideration there is only a need to talk about PhDStudent. There are several choices available:
to be included in the ontology for the application, such as those concerningAca- demic. This creates an unnecessary overhead, which is even bigger if the ontology being reused is large. The overhead being in terms of reasoning and maintenance.
• Build a new ontology. If the overhead in reusing the whole of the existing ontology is large then one solution would be to create the definitions needed in the ontology for the application. This requires much work on the part of the developer and, as mentioned above, ontology design is a complex task. Furthermore, if the ontology being reused has definitions that are popular or a standard, such as the Systematised Nomenclature of Medicine Clinical Terms (SNOMED CT)1, then it makes little sense to reinvent what is already there.
• Reuse part of the existing ontology. This allows for the reuse of part, a module, of the existing ontology. It can be seen as a compromise between the above two. The application ontology only gets added to it what is needed and existing resources can be taken advantage of.
With this in mind Rector et al.[108] present the following goals for ontology mod- ularization:
1. Scalability. This is concerned with the scalability of Description Logic (DL) rea- soning (see Section 2.3.2). It is widely understood that, in general, the perfor- mance of DL reasoners degrade as the size of the ontology grows.2 Thus, there
is a motivation to reduce the size of the ontology that needs to be reasoned over to that which is necessary, i.e. an ontology module. The scalability issue also concerns the evolution of the ontology, the aim being to localise the change within an ontology module.
2. Complexity Management. With human designed ontologies it becomes increas- ingly difficult to control the accurateness of the ontology. Ontology modulariza- tion allows the designer to just focus on the relevant portion of the ontology. 3. Understandability. Intuitively smaller modules are easier to understand than
larger ones. This is the case for both humans and agents (for more on agents see Section 6.2).
4. Reuse. This is common practice in Software Engineering and Ontology Engineer- ing would benefit from such an approach; Chapter 5 addresses this goal. This goal emphasises the need for mechanisms to produce modules in such a way that increases their chances of being reused; i.e., they only contain what is relevant and useful.
1
http://www.ihtsdo.org/snomed-ct/
2It is also possible that small ontologies can degrade performance, for example by including numerous
This Chapter details the principles underlying the many techniques for ontology modularization. Indeed, the existence of numerous techniques for ontology modular- ization has motivated research into creating a common framework for ontology modu- larization; this work is detailed in Section 3.6.