5. METODOLOGÍA
6.2.4. Marco legal de la Educación Ambiental
6.2.5.2. Enfoque didáctico del centro docente mixto nuevo
Over the past decade there has been significant progress in the design and use of ontologies, and at the same time the size and complexity of the ontologies have increased (Janik, Scherp, & Staab, 2011). Solutions to address these issues include: the development and acceptance by the research and business community of the web ontology language OWL, the development of third generation ontology development methodologies, and the development of ontology authoring tools. In Chapter 4 of this thesis the decision is taken to use Protégé and OWL to construct the e-government ontology, and in this section only ontology development methodologies that use these two technologies are discussed.
Ontology Language (OWL) is used to describe the ontology based knowledge
structures (Horridge & Patel-Schneider, 2009)
Protégé is a free, open source application for ontology development and editing82
2.12.3.1Kanga / ROO Ontology Development Method
Kanga is a tool that facilitates ontology construction that is specifically designed to meet the needs of the domain expert with the intention of speeding up the construction process and lead to higher quality ontologies (Kovacs, Dolbear, Hart, Goodwin, & Mizen, 2006).
Kanga is a methodology for authoring ontologies that takes into consideration two viewpoints. The first viewpoint is obtained from the domain expert who provides a human-readable description of what is required of the system. This is referred to as the conceptual aspect. The second viewpoint is referred to as logical aspect, which takes the conceptual ontology provided by the domain expert and converts it into a Semantic Web language such as OWL (Denaux, Dolbear, Hart, Dimitrova, & Cohn, 2010).
The ontology engineering process is iterative and includes four key steps as shown in Figure 2-19.
Figure 2-19: The phases of the Kanga Methodology (Denaux, et al., 2010, p.7)
The five steps have the following purposes:
1. The requirements of the ontology are identified including the scope and purpose.
2. Information is gathered from documents and other sources, including the possibility of reusing ontologies.
3. Information relevant to the proposed ontology content is entered into a knowledge glossary.
4. Key concepts and relationships are formally defined using structured English sentences, which are then converted into the web ontology language OWL.
83
5. The constructs within the ontology are verified and validated.
The domain expert is responsible for carrying out the first three steps without the involvement of knowledge engineers.
In the fourth step, the knowledge engineer converts the structured English sentences into OWL. In step 5, validation of the ontology is performed.
The knowledge glossary in step 3 consists of lists of key and supporting concepts, together with relationships. To support the documentary process and assist maintenance of each concept, relationship and instance are given a natural language description.
ROO (Rabbit to OWL Ontology authoring tool)
The names ROO, OWL, Rabbit and Kanga originate from animal characters in the A.A.Milne classic Winnie-the-Pooh (Milne, 1926).
ROO is a Protégé plug-in that guides and supports domain experts who have little or no knowledge of semantic engineering principles, to build conceptual ontologies (Denaux, et al., 2010). The key features of ROO are as follows:
It is grounded on the Kanga ontology development methodology.
A controlled language is used to submit knowledge constructs; this language
reflects the needs of domain experts and is compliant with OWL 1.1.
ROO guides and supports the user through the ontology construction process.
The main architectural elements of the ROO tool and their interactions are shown in Figure 2-20.
Figure 2-20: UML component diagram depicting architectural elements of ROO (Dimitrova, et al., 2008, p.4)
84 ROO guides the domain experts throughout the first three steps of the development process by offering task suggestion rather like a wizard, which monitors the user’s activities and suggests appropriate actions that the user might then take.
Instead of directly editing OWL or the Manchester Syntax, the domain experts edit the ontology using the control language ‘Rabbit’. Errors in syntax are highlighted by the Rabbit editor, which provides appropriate feedback. Finally, the error free sentences are parsed through the Rabbit Language Processor.
2.12.3.2Noy and McGuiness Ontology Development Method
Noy and McGuinness (2001) suggested an iterative process to help designers to develop ontologies. The process model is inspired from the object-oriented system design and is based on their ontology-development experience using Protégé. Noy and McGuinness (2001) point out that major differences exist between the object-oriented system development and ontology development. For example, the object-oriented systems have primary focus on the behaviour and process of a class, whereas ontology systems have more focus on the structural properties of a class.
The seven steps of the Noy and McGuinness’s (2001) iterative process are listed below:
Step 1: Determine the domain and scope of the ontology
Noy and McGuinness (2001) suggest beginning with the ontology development by asking series of questions, such as:
What is the scope of the ontology?
What is the domain of the ontology?
For what we are going to use the ontology?
What are the expected outcomes to be delivered from the ontology?
Who are the target users of the ontology?
The answers to these questions help the developer limit the scope of the ontology. Answers to these questions may change during the development process, as this development process is an iterative process, and developers can always go back to these questions at any given time.
In this research, scope has been set within New Zealand e-government. This is based on the assumption that the structure of governmental agencies in New Zealand is representative of other governments internationally.
85
Noy and McGuinness’s (2001) suggestion about asking the questions has been adopted. Instead of simply listing the questions, users are asked what they would like the product to provide, and this information is then recorded in a series of use cases. More details about defining the scope and domain are addressed in Chapter 6.
Step 2: Consider reusing existing ontologies
Noy and McGuinness (2001) suggest the developers to try to find similar ontologies. If the developer is able to refine and extend the located ontology then it is incorporated into the current ontology. The purpose of reusing the existing ontologies is to save the developers time and money. According to Noy and McGuinness (2001), lot of ontologies have been developed in electronic form and can be imported into an ontology development environment such as Protégé. However, in this research, no obvious New Zealand based e-government ontologies are available. However, ontologies such as Dublin Core and FOAF could be imported to ease the problem of naming basic attributes, and increase the opportunity to link with other ontologies with similar naming conventions.
Step 3: Enumerate important terms in the ontology
It is useful to write down all the terms related to the domains that may appear in the ontology. This process is similar to brainstorming which is often suggested as something that should be done at the beginning of a traditional system design. This process can assist the developer identify concepts within the model. In this research, some of the important concepts that could be included are MPs, Political Parties, Ministries, Parliamentary roles, water and geographic areas.
Noy and McGuinness (2001) consider the two most important steps in ontology design are developing the class hierarchy and defining properties of classes. Usually the developer will make some classes in the hierarchical order and then continue with describing properties of these classes. As it is an iterative process, developers will repeat these two steps a number of times.
Step 4: Define the classes and the class hierarchy
Noy and McGuinness (2001) suggest there are three different approaches that can be used to develop a class hierarchy:
Top-down development process: This process begins with the identification of the
most general terms in the domain, followed by the identification of the more specialized terms. For example, in this research, Geographical entity and Governance Structure could be viewed as the more general terms (classes), and
86 more specialised terms would be New Zealand Geographical Regions and Parliamentary Electorate Regions.
Bottom-up development process is the opposite of top-down development; it
starts with the most specialized terms and then moves to identify the general terms.
Combination development process is a combination of the top-down and bottom-
up approaches. The developer may start with some noticeable terms within the domain, and then generalize or specialize in an appropriate way.
According to Noy and McGuinness (2001) and Breitman et al. (2007a) there is no best way of developing an ontology. The approach adopted by developers to some degree depends on the developer’s view of the structure of the domain and the ontology. However, Noy and McGuinness (2001) also point out that the combination approach is usually the easiest way for many ontology developers as starting with the terms in the middle tends to provide more descriptive concepts in the knowledge domain.
Step 5: Define the properties of classes
The terms created in Step 1 cannot all be treated as classes. Some of the terms such as title and personal profile are properties of the Person class, and these properties become slots attached to classes. There are two major types of properties: object properties and datatype properties. Object properties are relationships between two individuals, whereas datatype properties describe the relationship between an individual and data values. The data values are usually represented in XML Schema
Datatype value or an rdf literal. Figure 2-21 describes the two types of
properties:
Figure 2-21: Illustration of the property isElecteTo and hasTitle
The object property, isElectedTo, links the individual John Key to the individual
electorate of Helensville.
The datatype property, hasTitle, links the individual John Key to the data literal RtHon, which is of type xsd:string.
Representative of Helensville Electorate John Key RtHon isElectedTo hasTitle
87
All subclasses of its upper classes inherit the property of that class. For example, all
the properties of the class PoliticalParty will be inherited by all subclasses of
PoliticalParty.
Step 6: Define the facets of the properties
Noy and McGuinness (2001) point out that aspects related to the properties include the value type of the properties, the cardinality, and other values the property can take, such as domain and range of the property. In OWL, the object property is used to describe relationships between two individuals; a class of individuals is defined by the relationships that these individuals belong to. Restrictions are then applied to define these classes in OWL, such as cardinality restrictions.
Property cardinality
Cardinality (cardinality restrictions in OWL) defines how many values a property can take. Property cardinality can be specified numerically in Protégé OWL, where maximum cardinality of N means a property must have at most N values, for example, a person can be only elected to at most one position as a member of Parliament, or a person may not be elected as a member of the Parliament.
Property type
As described before, a datatype property links the individual with an XML datatype value, where a value-type facet describes what type of values a property can take. Noy and McGuinness (2001) list the most common value types as follows:
String: The value of it is a simple string; it is used for properties such as name, title.
Number: Describes properties with numeric values.
Boolean: Simply yes-no flags.
Enumerated: Specifies a list of specific allowed values for a property. Domain and range of a property
Properties link individuals from the domain to individuals in the range, for example, the
property hasPoliticalParty would link individuals belonging to the class Person
to individuals belonging to the class PoliticalParty. In this case, the domain of the
hasPoliticalParty is Person and the range is PoliticalParty. Noy and
McGuinness (2001) suggest several different ways of defining the domain and the range. One approach would be to define a domain and a range for a property; another approach might take the most general classes to be the domain or range. However,
88 Noy and McGuinness (2001) suggest there should be a balance between general and overly general, for example, some individuals in the Person class may be assigned to
some AssignedGovernancePosition. In this case, Person class becomes the
domain for property isAssignedTo and AssignedGovernancePosition becomes
the range. In Figure 2-22 there are five main subclasses under
AssignedGovernancePosition. Instead of applying the property isAssignedTo
to each of the possible subclasses of AssignedGovernancePosition class it is
only necessary to apply the relations to AssignedGovernancePosition, as all the
subclasses of AssignedGovernancePosition will inherit all the properties from its
upper class. On the other hand, the range cannot be too general. The Thing class is regarded as the most general class in the ontology.
Figure 2-22: The hierarchical class structure of 'AssignedGovernancePosition'
Step 7: Create instances
Creating individual instances of class is the final step in the ontology development processes. Noy and McGuinness (2001) propose three ways to create individuals: choosing a class, creating an individual instance of the chosen class, and filling in the
89
value or related individual for its responded properties. Figure 2-23 shows the definitions for individual Anderton_Jim in Person class.
Figure 2-23: Defining the instance Anderton_Jim in the Person class
2.12.3.3Use cases
Many practical suggestions embedded in ontology development methodologies include the use of use cases (Benbasat, Goldstein, & Mead, 1987; Bjorn-Anderson, 1985; Boland, 1985). It is a practical way to identify the target audience, the actors involved and the sources of information and, of course, the deliverables. More information on this topic can be found in Chapter 5.
2.12.3.4Choosing an ontology development method
The semantic framework under considertion is expected to be fairly large, complex and to require the researcher to perform all the roles of semantic engineer and a significant number of the domain experts roles. From that perpspective alone the researcher would benefit greatly if the methodology was able to be dovetailed into an ontology authoring tool such as Protégé-OWL or TopBraid Composer.
In terms of the ontology development methods discussed in this review, both Noy and McGuinness (2001) and Kanga (Denaux, et al., 2010) are both very promising. That is not to say that the Methontology could not be used but there was little evidence in the
90 literature that it had been used with Protégé by many researchers. Although Kanga could be used with Protégé or TopBraid Composer all the literature links it to ROO methodology.
Of the two possibilites, the Noy and McGuinness’ (2001) approach provides a more detailed set of guidelines than Kanga. In fact, they have many steps in common. The major difference is the role of the domain expert; this is significant in Kanga’s case and as access to such domain experts in the current research is unlikely, the Noy and MacGuinness (2001) approach is found to be the most suitable.
Also taking into consideration Breitman et al.’s (2007a) comment that there is no one methodology that meets all the requirements of specific situation, the most promising
approach would be to adapt Noy and McGuinness’ (2001) approach by adding a step
to include use cases as a way of generating competency questions and establishing system requirements.