CHAPTER 2. Overview of Tools and Technologies in Ontology Development

Transcription

1 CHAPTER 2 Overview of Tools and Technologies in Ontology Development 2.1. Ontology Representation Languages 2.2. Ontology Development Methodologies 2.3. Ontology Development Tools 2.4. Ontology Query Languages 2.5. Summary Domain-specific Ontology for Student s Information in Academic Institution Page 35

2 CHAPTER-2 Overview of Tools and Technologies in Ontology Development The Semantic web is built on top of various technologies. To support these technologies, various tools and techniques have been developed. In this Chapter, the various Ontology Representation Languages that forms the base of the Semantic stack are discussed. A few methodologies which help in the Ontology development life cycle have been reviewed. A few tools which support the life cycle are also studied in this Chapter. Finally, the types of query languages are reviewed, including the details of the SPARQL query are also reviewed. This will help get an insight into the construction of Ontology as per the W3C recommendations. 2.1 Ontology Representation Languages Extensible Markup Language The XML is a general-purpose specification for creating custom markup languages. It is an extensible language as it allows the user to create the markup elements. XML allows sharing structured data via the Internet [24], to encode documents, and to serialize data. XML has a simple format that is flexible enough to accommodate highly diverse needs. It can be used by developers working on different types of applications to share XML formats and tools are available for parsing those formats into data structures that applications can use. XML is a W3C standard for simple, self-describing way of encoding data so that content processing can be automated and exchanged across varied hardware, operating systems, and applications [181]. Exchange of information over the Internet and between software applications has Domain-specific Ontology for Student s Information in Academic Institution Page 36

3 always been difficult due to different data formats and proprietary structures. XML is a data interchange format in that it allows you to exchange data between dissimilar systems or applications. XML separates the data from the presentation and defines the data and describes how the data is structured so that the same XML data can be presented in multiple ways by using different presentation files. XML uses the tags similar to HTML to delimit data, and leaves the interpretation completely to the application. There are many programming interfaces that software developers may use to access XML data, and several schema systems designed to aid in the definition of XML-based languages. Hundreds of XML based languages have been developed [218], including RSS, Atom, Simple Object Access Protocol (SOAP), and Extensible HyperText Markup Language (XHTML). XMLbased formats have become the default for most office-productivity tools, including Microsoft Office (Office Open XML), OpenOffice.org (OpenDocument), and Apple's iwork. Few advantages of XML: Simplicity, Self-describing data [90], Integration with all traditional databases and formats, Modifications to data presentation - no reprogramming required, One-server view of distributed data, Multilingual document support, Open and extensible, Less storage required, Future-oriented technology, Separates content from presentation, Facilitates the comparison and aggregation of data, Can embed multiple data types, Can embed existing data, Validation using schema languages such as XML Schema Definition (XSD), making software construction easier. XML is more suitable because of its openness, flat file structure, ease of use with any programming language like C, C++, PERL, PHP, etc and its interoperability. Domain-specific Ontology for Student s Information in Academic Institution Page 37

4 Disadvantages of XML: XML syntax is redundant and large relative to binary representations of similar data; The redundancy may affect application efficiency through higher storage, transmission and processing costs; XML syntax is too verbose relative to other alternative 'text-based' data transmission formats; No intrinsic data type support: XML provides no specific notion of "integer", "string", "boolean", "date", and so on available with other data formats; It uses hierarchical model for representation which is limited; XMLNS are problematic to use and namespace support are difficult to correctly implement in an XML parser; XML is commonly depicted as "self-documenting" but this depiction ignores critical ambiguities; XML does not support data types in any meaningful sense of the word; Disambiguity of meaning of the markups is not helpful in expressing semantics of the data [97] Document Type Definition and XML Schema Definition XML is a standard for document markup. Both Document Type Definition (DTD) and XML Schemas are mechanisms used to define the structure and restrictions of XML documents and define the permitted content. They define what elements can be contained within the XML document, how they are to be used, what default values their attributes can have, and so on. They provide a means of creating a set of rules that your computer can use to identify document rules governing the validity of the XML documents that you create. Given a DTD or XML schema and its corresponding XML document, a parser can validate whether the document conforms to the defined structure and constraints. This is useful for data exchange since both provide and enforce a common vocabulary for the data to be exchanged. XML schemas differ from DTDs in that the XML schema definition language is based on XML itself. As a result, unlike DTDs, the set of constructs available for defining an XML Domain-specific Ontology for Student s Information in Academic Institution Page 38

5 document is extensible. Also stronger datatypes can be forced on the data as a range of primitive data types such as string, decimal, and integer are supported. This makes XML schemas highly suitable for defining data-centric documents [33]. An XML schema language is a formalization of the constraints, expressed as rules or a model of structure, that apply to a class of XML documents [207]. XML Schema is the W3C-recommended schema definition language, expressed in XML 1.0 syntax, intended to describe the structure and constrain the content of documents written in XML [217]. It is explicitly intended to improve on the schema functionality that was provided by the DTD, which was the original form of schema for XML documents that the W3C recommended in 1998 when XML was first released. DTDs impose several restrictions with respect to expressivity. This means that only very simple languages can be defined by DTDs. For instance, one cannot define cardinality restrictions of an element by only regular expressions; Data types are hardly supported; etc [64]. These limitations are overcome by XML Schema, a mechanism for defining XML grammars. XML schema, successors of DTDs, allows advanced features such as the following: Support for primitive data types (numbers, strings, and dates, etc.), which can be restricted further Defining one s own element or attribute types, can be reused through inheritance which allows restriction Namespace support XML Schema uses XML syntax thus allowing developers to profit from tool support, the inherent extensibility of XML, the combination of several XML Schema files, etc. Domain-specific Ontology for Student s Information in Academic Institution Page 39

6 XML Schemas define the legal building blocks of an XML document, just like a DTD [214]. An XML schema is a description of a type of XML document, expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. It defines elements and attributes that can appear in a document; defines which elements are child elements, its order and the number of child elements; defines whether an element is empty or can include text; defines data types for elements and attributes; defines default and fixed values for elements and attributes. XSD Schema adds the capability to combine schemas from more than one source [217]. This technique would enable schemas to be reused in a variety of combinations, thus improving efficiency. XML schemas are not ontologies, for three reasons [93]: They define representation syntax for a given domain but not the semantics of domain elements. They define the sequence and hierarchical ordering of elements in a valid document, but do not specify the semantics of this ordering. They do not aim at carving out re-usable, context-independent categories of things e.g. whether a data element student refers to the human being or the role of being a student Resource Description Framework The RDF [167] is a set of standardized technologies designed to represent information about web resources, publish structured information on the Web, and exchange information between web-based information systems. RDF is a major component in the vision of extending the current Web to what is called the Semantic Web [3][20][175]. The basic idea of the Semantic Web is to make structured data accessible on the Web by using common formats and by referring to terms from shared Domain-specific Ontology for Student s Information in Academic Institution Page 40

7 conceptualizations of an application domain. The meaning of these terms is captured in the form of ontologies [84]. Such a web of semantically accessible data will allow a person or machine to start browsing the content of one data source, and then move through a potentially huge set of data sources that provide related information [209]. It would also enable sophisticated queries, similar to Structured Query Language (SQL) queries, to be executed against the data sources over the web semantically. RDF is a simple general-purpose metadata language for representing information in the Web and provides a model for describing and creating relationships between resources. RDF originates from the Platform for Internet Content Selection (PICS) [120], a standard for associating metainformation with Internet content. The standardization effort led in 2004 to a set of six W3C recommendations which together specify RDF. At the top of XML, the W3C has developed the RDF [167] language to standardize the definition and use of metadata. Therefore, XML and RDF each have their merits as a foundation for the semantic Web, but RDF provides more suitable mechanisms for developing ORLs like Ontology Integration Language (OIL). RDF uses XML and it is at the base of the semantic Web, so that all the other languages corresponding to the upper layers are built on top of it. RDF builds standards for XML applications so that data can be integrated more easily. XML supports interoperability within applications whereas RDF supports cross applications interoperability [176]. The RDF data model represents information as node-and-arc labeled directed graph [118] where all objects of interest are called resources. Resources have properties which have a property type value. Property values can be atomic, e.g. strings or numbers, or references to other resources, which in turn may have their own properties. Information about resources is represented in the form of triples. Each triple Domain-specific Ontology for Student s Information in Academic Institution Page 41

8 represents a single property of a resource. Triples can be compared to simple sentences consisting of a subject, a predicate, and an object. The subject determines the resource which is described by the triple. The predicate determines a property type. The object contains the property value. Triples can be visualized as node and arc diagrams. In this notation, a triple is represented by a node for the subject, a node for the object, and an arc for the predicate, directed from the subject node to the object node. A set of triples forms a directed labeled graph by sharing subjects and objects. To facilitate the interchange of RDF data a normative syntax for serializing RDF graphs as XML documents is defined. The RDF/XML syntax is rather verbose and not very readable for humans. Various shorter, plain-text syntaxes for RDF have been developed. The most prominent are N-Triples, Notation3 (N3), and Turtle. Examples of real world systems that use RDF include applications developed under the Mozilla project, RSS, Annotea, and Dublin Core. Advantages of RDF: Following are a few advantages of RDF [154]: Combine the data with other datasets with different data model. Exchange data with other applications which can handle RDF data over the web, or any other exchange format. Apply logical reasoning to discover unstated relationships. Connect to other RDF resources over the web by adding URIs. Extend the RDF dataset by adding irregular data structures. RDF allows for reification of a given triple. Disadvantages of RDF: Problem with RDF is that there are repeating patterns of the graph when describing the same resource within multiple triples. It is difficult to tell Domain-specific Ontology for Student s Information in Academic Institution Page 42

9 that all the references have the same structure in a large graph. Hence there is a lot of redundancy. RDF trades regularity for flexibility. It uses URIs whose meaning is not clear. Since anyone can make statements about anything, there are large possibilities of conflicting statements. Drawing conclusions from missing facts is inconsistent in different agents. It cannot be used to make general statements but only for specific resources. There is no facility to create statements which negate. Full First-order logic requires these capabilities, hence complex logical reasoning capability is not possible for use with automated agents [154] Resource Description Framework Schema RDF is a framework for metadata. RDFS [25] is an extensible KR language, providing basic elements for the description of ontology, otherwise called RDF vocabularies, intended to structure RDF resources [121]. RDF describes resources with classes, properties, and values. RDF also needs a way to define application-specific classes and properties using extensions to RDF like RDFS. RDFS provides a framework to describe application-specific classes and properties. Classes in RDFS are like those in object oriented programming languages that allow resources to be defined as instances of classes, and subclasses of classes. RDFS is a lightweight ontology language for defining vocabularies for RDF. Unlike XML Schema, which prescribes the order and structure of tags in an XML document, RDFS only provides information about the interpretation of the statements given in an RDF vocabulary [64]. RDFS does not specify the syntactical appearance of the RDF description. RDFS can be seen as an extension of RDF with a vocabulary for defining classes, class hierarchies, properties, property hierarchies, and property restrictions. RDFS classes and properties can be instantiated in RDF [117]. The basic building blocks offered by RDFS are: Classes and their instances Domain-specific Ontology for Student s Information in Academic Institution Page 43

10 Binary properties between classes Organisation of classes and properties in hierarchies Domain and range restrictions A few limitations of the Expressive Power of RDFS: RDF and RDFS allow the representation of some ontological knowledge, but a number of other features are missing. Here is a list of a few [3][30]: Local Scope of Properties: rdfs:range defines the range of a property for all classes. So RDFS cannot declare range restrictions that apply to some classes only. For example, the fathers of elephants are elephants, while the fathers of humans are humans. Disjointness of Classes: Sometimes we wish to say that classes are disjoint. But in RDFS we can only state subclass relationships but not disjointedness. For example, female is a subclass of person. The gender of a person can be male or female. While it is possible in RDFS to express that x is male and y female, there is no way of saying that x is not a female and y is not a male. Boolean Combinations of Classes: RDFS does not allow building new classes by combining other classes using union, intersection and complement. For example, we may wish to define the class person to be the disjoint union of the classes male and female. This means the creation of new classes that are composed of other classes is not possible. For example, the class person might be the union of the classes male and female and may also be described as the intersection of the classes student and employee. Cardinality Restrictions: Restrictions on how many distinct values a property can take is impossible to express in RDFS. For example, a student has exactly one gender. RDFS does not have the capability of expressing the uniqueness and cardinality of Domain-specific Ontology for Student s Information in Academic Institution Page 44

11 properties. For example, a property has only one value in an instance of a class. Special Characteristics of Properties: Sometimes it is useful to say that a property is unique (like has gender ), or the inverse of another property (like haspassport and ispassportof ). No Negation: Since there is no negation in RDFS, domain and range restrictions never lead to any kind of inconsistency. Instead, they can always be fulfilled by adding instances to classes. Equivalence between properties: RDFS cannot express equivalence between properties, which is important for expressing the equivalence of concepts in different ontologies. Closed set for property: RDFS can express the values of a particular property but not that it is a closed set. For example, enumeration gender property has only two values: male, female Web Ontology Language The OWL [46] is an expressive ontology language which extends RDF and RDFS and adds more vocabulary for describing properties and classes to describe semantics of RDF statements. It is a language for defining and instantiating web ontologies. OWL uses the RDF concept of classes and properties and adds language primitives to support richer expressiveness required. Such an extension of RDFS is also consistent with the layered architecture of the Semantic Web. OWL uses RDF and RDFS to a large extent: All varieties of OWL use RDF for their syntax. Instances are declared as in RDF, using RDF descriptions and datatyping information OWL constructors are specialisations of their RDF counterparts. Domain-specific Ontology for Student s Information in Academic Institution Page 45

12 OWL extends RDFS with additional modeling primitives like to describe more detailed characteristics of properties (owl:inverseof, owl:equivalentproperty) and to formulate cardinality constraints (owl:maxcardinality, owl:mincardinality) as well as value constraints (owl:allvaluesfrom, owl:somevaluesfrom) on properties. It is based on DL and so brings reasoning power to the semantic web. OWL itself consists of three species [64] of increasing expressiveness: OWL Lite: It is the least expressive. Compared with RDF it adds local range restrictions, existential restrictions, simple cardinality restrictions, equality, and various types of properties (inverse, transitive, and symmetric). One of the significant limitations of RDFS is the inability to make equality or inequality claims between individuals. Such equality and inequality is possible in OWL Lite, not only between instances but also between classes and between properties. Although equalities can be expressed indirectly in RDFS through Subclassof or SubPropertyOf statements, this can be done directly in OWL Lite. Since OWL does not make the unique name assumption, two instances x and y are not automatically regarded as different unless explicitly stated. OWL Lite also has constructs specifically aimed at properties like transitive, symmetric, etc. Another significant limitation of RDFS is the inability to state whether a property value is optional or required, and whether it is singlevalued or multi-valued. Technically, these restrictions constitute 0/1-cardinality constraints on the property. If a property is allowed to have at most one value for a given instance (i.e., a maxcardinality of 1), it is called Functional Property. If a property uniquely identifies the instance of which it is a value (i.e. the inverse property has a max-cardinality of 1), it is called Domain-specific Ontology for Student s Information in Academic Institution Page 46

13 InverseFunctional Property. These two constructions allow for some interesting derivations under the OWL semantics. Another important feature of OWL Lite is that it allows domain and range restrictions, depending on the class to which a property is applied. This allows us to use the same property name with different range restrictions on different classes which is not possible with RDFS. Similarly, although in RDFS we can define the range of a property, we cannot enforce that properties actually does have a value from the given range with minimum cardinality of 1. The somevaluesfrom corresponds to a min-cardinality constraint with value 1, and the functional property constraint corresponds to a max-cardinality constraint with value 1. If a property has a mincardinality and maxcardinality with same values, it can be shown by a single Cardinality constraint [30]. OWL Lite excludes enumerated classes, disjointness statements and arbitrary cardinality, which are present in OWL DL and so limits the language constructors to simple concepts. Advantage: It is easier to grasp and implement. Disadvantage: Its restricted expressivity [3] compared to other OWL species. OWL DL: Compared with OWL Lite, OWL DL adds full support for (classical) negation, disjunction, cardinality restrictions, enumerations, and value restrictions. The element DL comes from the resemblance to an expressive Description Logic language [9], namely SHOIN(D) and ALC. OWL DL has a number of additional language constructs. We can express that two classes are disjoint than merely saying not equal. OWL DL allows arbitrary Boolean algebraic expressions on either side of an equality of subsumption relation. Besides union and intersection, it provides a construct for negation. If it is not Domain-specific Ontology for Student s Information in Academic Institution Page 47

14 possible to define a class in terms of algebraic expressions, you can enumerate sets of individuals to define a class. The extension from OWL Lite to OWL DL also lifts the restriction on cardinality constraints to have only 0/1 values [30]. Advantage: It permits efficient first-order logic and reasoning support. Disadvantage: Full compatibility with RDF is lost [3], an RDF document is extended in some ways and restricted in others for it to be a legal OWL DL document. Every legal OWL DL document is a legal RDF document. OWL Full: OWL Lite and OWL DL impose restrictions on the use of vocabulary and of RDF statements, OWL Full does not have such restrictions. OWL Full allows both the specification of classes-asinstances and the use of language constructs in the language itself, which thereby modifies the language. In OWL Lite and OWL DL no term can be both an instance and a class, or a class and a property, and so forth, which is supported in OWL Full which is needed in many cases of practical ontology integration. When integrating two ontologies, opposite commitments have often been made in the two ontologies on whether something is modeled as a class or an instance. It is possible to have equality statements between a class and an instance. Just like RDFS, OWL Full allows us to apply the constructions of the language to itself [30]. Hence it is perfectly legal to apply a max-cardinality of 2 on the subclass relationship. It uses all the OWL languages primitives and allows the combination of these primitives in arbitrary ways with RDF and RDFS. This includes the possibility of changing the meaning of the predefined primitives in RDF or OWL by applying the language primitives to each other. Domain-specific Ontology for Student s Information in Academic Institution Page 48

15 Advantage: It is fully compatible with RDF, both syntactically and semantically [3], and any legal RDF document is also a legal OWL Full document. Disadvantage: Language is so powerful that complete or efficient reasoning support is less predictable and impossible. In OWL Lite, although there are many syntactic restrictions, the actual expressiveness of the language is very close to that of OWL DL [99]. OWL Full is a very expressive language and, because of the syntactic freedom of the language, key inference problems are undecidable. Statements in RDFS are triples whereas statements in OWL DL are either axioms or assertions. An axiom is a class definition, a class axiom, or a property axiom. Class definitions are used to define subclass relationships, as well as property restrictions for that class. With class and property axioms, one can express more complex relationships between classes and between properties such as Boolean combinations of class descriptions and transitive, inverse, and symmetric properties. Individual assertions can be used to express class membership, property values, and (in)equality of individuals. OWL DL is defined in terms of an abstract syntax [155]. However, the normative syntax for OWL is RDF/XML. The RDF representation of OWL DL ontology can be obtained through a mapping from the abstract syntax. 2.2 Ontology Development Methodologies Introduction The Ontology Development process and the Ontology Lifecycle were identified by Fernández-López and colleagues (1997) in the framework of Methontology [66]. These proposals were based on the IEEE standard for software development [103]. The Ontology Development process refers to the activities that have to be performed when building ontologies. The Domain-specific Ontology for Student s Information in Academic Institution Page 49

16 Knowledge acquisition Evaluation Documentation original Ontology Lifecycle of Methontology has been modified recently to take into account the fact that more ontologies are available in ontology libraries or spread over the Internet, so that their reuse by other ontologies and applications has increased. These ontologies can be reused to build others of more granularity and coverage, or can be merged with others to create new ones. Several methods and methodologies have been proposed: Methods and Methodologies used for the Whole ontology development lifecycle, for the main phases of the ontology development lifecycle. The selection of one or another will mainly depend on the characteristics of the ontology to be developed, including the context where they are being developed Ontology Engineering Process The top-level partitioning of a generic ontology engineering process [93] can be realized by taking into account available process-driven methodologies in this field [78][191]. According to them ontology building consists of core steps as given in Figure 6. Requirement Analysis Requirement Analysis Motivating scenarios, Use cases, Existing solutions, Cost estimation, Competency questions, Application requirements Conceptualization Conceptualization of the model, Integration and Extension of the existing solutions Implementation Implementation of the formal model in a representation language Figure 6: Ontology Engineering Process i. Requirements Analysis. The engineering team consisting of domain experts and ontology engineers performs analysis of the project setting with respect to a set of predefined requirements. This step Domain-specific Ontology for Student s Information in Academic Institution Page 50

17 might also include knowledge acquisition activities in terms of the reusage of existing ontological sources or by extracting domain information from text corpora, databases etc. If such techniques are being used to aid the engineering process, the resulting ontologies are to be subsequently customized to the application setting in the conceptualization /implementation phases [93]. The result of this step is an Ontology Requirements Specification document [191] which contains a set of competency questions describing the domain to be modeled by the prospected ontology, as well as information about its use cases, the expected size, the information sources used, the process participants and the engineering methodology. ii. Conceptualization. The application domain is modeled in terms of ontological primitives, e. g. concepts, relations, axioms. iii. Implementation. The conceptual model is implemented using a formal representation language, whose expressivity is appropriate for the richness of the conceptualization. If required reuse ontologies and other information sources may be integrated in the final data model. iv. Evaluation. The ontology is evaluated against the set of competency questions. The evaluation may be performed automatically, if the competency questions are represented formally, or semiautomatically, using specific heuristics or human judgment. The result of the evaluation is reflected in a set of modifications/refinements at the requirements, conceptualization or implementation level Existing Methodologies Depending on the ontology lifecycle underlying the process-driven methodology, the aforementioned four steps may be performed as sequential workflow or as parallel activities. There are various Domain-specific Ontology for Student s Information in Academic Institution Page 51

18 methodologies developed, based on the generic methodology, some of which are as follows: Methontology [78], which applies prototypical engineering principles, considers knowledge acquisition, evaluation and documentation as being complementary support activities performed in parallel to the main development process. Other methodologies, usually following a classical waterfall model and consider these support activities as sequential process. Methontology [67] is a methodology that can be used to create domain ontologies that are independent of the application where they will be used. The generic Ontology Development process is derived from this methodology. This methodology proposes specific techniques to carry out each of the activities identified there. The main phase in the ontology development process is the conceptualisation phase. The OTK Methodology or On-To-Knowledge methodology [190] additionally has an initial feasibility study in order to assess the risks associated with ontology building. Other optional steps are ontology population/instantiation, evolution and maintenance. The former deals with the alignment of concrete application data to the implemented ontology. The latter relates to modifications of the ontology according to new user requirements, updates of the reused sources or changes in the modeled domain. Also reusing existing knowledge sources in particular ontologies is the key to ontology development. In terms of the process modeling, ontology reuse is considered a knowledge acquisition task. This methodology [184] is based on an analysis of usage scenarios. The steps proposed by the methodology are: kick-off, where ontology requirements are captured and specified, competency questions are identified, potentially reusable ontologies are studied and a Domain-specific Ontology for Student s Information in Academic Institution Page 52

19 first draft version of the ontology is built; refinement, where a mature and application oriented ontology is produced; evaluation, where the requirements and competency questions are checked, and the ontology is tested in the application environment; and ontology maintenance. The CYC method [122], is mainly oriented to support the knowledge acquisition activity, and is structured in three phases. In all of them, the objective is to derive common sense knowledge that is implicit in different sources. The difference between them is the degree of automation of the knowledge acquisition process (from manual to automatic). Once knowledge has been acquired, it is divided into contexts, which are bundles of assertions in the same domain. The Uschold and King s method [206] covers more aspects of the ontology development lifecycle. It proposes four phases: (1) to identify the purpose of ontology, (2) to build it, integrating other ontologies if necessary, (3) to evaluate it, and (4) to document it. Depending on the charactristics of the ontology three strategies are proposed for identifying the main concepts in the ontology: a topdown approach in which the most abstract concepts are identified first, and then, specialised into more specific concepts; a bottom-up approach in which the most specific concepts are identified first and then generalized into more abstract concepts; a middle-out approach, in which the most important concepts are identified first and then generalised and specialized into other concepts. Grüninger and Fox [85] proposed a methodology that is based on the development of knowledge-based systems using FOL. They propose first to identify intuitively the possible applications where the ontology will be used, and determine the scope of the ontology using a set of natural language questions, called competency Domain-specific Ontology for Student s Information in Academic Institution Page 53

20 questions. These questions and their answers are used both to extract the main ontology components (expressed in FOL). This methodology is very formal and can be used as a guide to transform informal scenarios into computable models. In the method proposed in the KACTUS project [15] the ontology is built on the basis of an application KB, by means of a process of abstraction using a bottom-up strategy. The more applications are built, the more reusable and sharable the ontology becomes. The method based on Sensus [195] aims at promoting the sharability of knowledge, as it proposes to use the same base ontology to develop ontologies in particular domains. It is a topdown approach where we need to identify a set of seed terms relevant to a particular domain. These terms are linked manually to broad-coverage ontology, the Sensus ontology, which contains more than 50,000 concepts. Then, all the concepts in the path from the seed terms to the ontology root are included. For those nodes that have a large number of paths through them, the entire subtree under the node is sometimes added, based on the idea that if many of the nodes in a subtree have been found to be relevant, then, the other nodes in the subtree are likely to be relevant as well. Though this method may introduce additional processing burden on the application. 2.3 Ontology Development Tools These tools have been created to integrate ontology technology in actual information systems. They are built as robust integrated environments or suites that provide technological support to most of the Ontology Lifecycle activities. They have extensible, component-based architectures, where new modules and add-on packages can easily be added to provide more functionality to the environment. Also the knowledge models Domain-specific Ontology for Student s Information in Academic Institution Page 54

21 underlying these environments are language independent. These tools have their own ontology development methodologies. Following section describes a few of the most popular tools [30] available PROTÉGÉ Protégé [162] is one of the most widely used ontology development tool. Since Protégé is free and open source, it is supported by a large community of active users. It has been used by experts in domains such as medicine and manufacturing for domain modeling and for building knowledge-based systems. Protégé provides an intuitive editor for ontologies and has extensions for ontology visualization, project management, software engineering and other modeling tasks [147]. In early versions, Protégé only enabled users to build and populate frame-based ontologies in accordance with the Open Knowledge Base Connectivity Protocol (OKBC). In this model, an ontology consisted of a set of classes organized in a subsumption hierarchy, a set of slots associated to classes to describe their properties and relationships, and a set of instances of those classes. Protégé editor included support for classes and class hierarchies with multiple inheritance; templates and slots; predefined and arbitrary facets for slots, which included permitted values, cardinality restrictions, default values, and inverse slots; metaclasses and metaclass hierarchy. In 2003, the frame-based architecture was extended to support OWL, which attracted many users captivated by the Semantic Web vision. The OWL plug-in extends the Protégé platform into an ontology editor for the OWL enabling users to build ontologies for the Semantic Web. This plugin allows users to load, save, edit and visualize ontologies in OWL and RDF. It also provides interfaces for DL reasoners such as Racer and Pellet. Ontologies can be exported into a variety of formats including RDFS, OWL, and XML schema. Domain-specific Ontology for Student s Information in Academic Institution Page 55

22 The current Protégé version can be used to edit classes and their characteristics, to access reasoning engines, to edit and execute queries and rules, to compare ontology versions, to visualize relationships between concepts, to acquire instances using an editable graphic user interface (GUI) and also allows collaborative ontology editing by a group of users. Protégé can be extended by way of a plug-in architecture and a Javabased API for building knowledge-base tools and applications. Protégé is based on Java and provides an open-source API to develop Semantic Web and KB stand-alone applications. External Semantic Web applications can use the API to directly access Protégé KBs without running the Protégé application. An OWL API is also available for access to OWL ontologies. Its extensible architecture makes it useful as a base platform for ontology-based research and development projects. Protégé also includes a Programming Development Kit (PDK) for programmers and describes how to work directly with Protégé APIs and how to program plug-in extensions for Protégé. Several plug-in are available some of which are listed below: JSave [109] generates Java class definition stubs for Protégé classes and Protégé Web Browser is a Java-based Web application that allows users to share Protégé ontologies over the Internet. WordNet plug-in [161] provides interface to WordNet KB. Users can easily annotate a Protégé KB using information from WordNet database. The users can annotate ontologies with terms, concept IDs, synonyms, and relations. XML schema [219] plug-in transforms a Protégé KB into XML. It generates an XML schema file describing the Protégé knowledge model and an XML file where the classes and instances are stored. Domain-specific Ontology for Student s Information in Academic Institution Page 56

23 UML plug-in [163] provides import/export mechanism between the Protégé knowledge model and the object-oriented modeling language, Unified Modelling Language (UML). To enables the exchange of ontologies and UML class diagrams, this plug-in uses the standard format for UML diagram exchange, XML Metadata Interchange (XMI), which is supported by major CASE tools. The use of the XMI enables users to work with Protégé in combination with Software Engineering tools and IDEs. DataGenie [159] is an import/export plug-in that allows reading and creating a knowledge model from a subset of a relational database using Java DataBase Connectivity (JDBC) and convert tables into Protégé classes and attributes into slots. Docgen [160] is an import/export plug-in that allow users to create reports describing Protégé KBs or ontologies. Classes, instances and documentation can be exported to various output formats such as HTML, Dynamic HTML (DHTML), PDF, and XML. OWL-S Editor plug-in [151] allows loading, creating, managing, and visualizing OWL-S services. OWL-S (formerly DARPA Agent Markup Language for Services (DAML-S)) is a Web Service Description Language (WSDL) that semantically describes Web Services using OWL ontologies. This plug-in provides an overview of the relations between different OWL-S ontologies in an intuitive way in the graphic user interface (GUI) and also as a graph. Plug-ins is also available to carry out rule-based programming using the information stored in a Protégé frame-based KB. Three worth mentioning examples are: JessTab [107]. JessTab is a plug-in that provides a Jess console where you can interact with Jess while running Protégé. It extends Jess with additional features that map Protégé KBs to Jess facts. Domain-specific Ontology for Student s Information in Academic Institution Page 57

24 Algernon [2]. Algernon is implemented in Java and performs forward and backward inference of frame-based KBs. Algernon operates directly on Protégé KBs instead of using a mapping operation to and from a separate memory space. PROMPT plug-in [141] allows to manage multiple ontologies within Protégé, mainly compare versions of the same ontology, merge ontologies into one, and extract parts of an ontology. Protégé has been developed by the Stanford Medical Informatics (SMI) at Stanford University. It is an open source, standalone application with an extensible architecture. The core of this environment is the ontology editor which holds a library of plugins that add more functionality to it. Currently, plugins are available for ontology language import/export (F- Logic, Jess, XML, Prolog), ontology language design [119], OKBC access, constraints creation and execution, ontology merging [144]), and so on ONTOEDIT OntoEdit [189] was developed by the Knowledge Management Group of the AIFB Institute at the University of Karlsruhe. It is an ontology engineering environment which allows creating, browsing, maintaining and managing ontologies. It supports collaborative development of ontologies [188] through its client/server architecture where ontologies are managed in a central server and clients can access and modify these ontologies. The successor of OntoEdit is OntoStudio which is a commercial product based on IBM s development environment Eclipse. It can be downloaded for 3-months free evaluation period. OntoEdit was developed with two major goals: Firstly, the editor was designed to be as independent and neutral of a concrete representation language as possible. Secondly, it was to provide a powerful GUI to represent concept hierarchies, relations, domains, ranges, instances and axioms. OntoEdit supports Fuzzy Logic (F-Logic), RDFS and OIL. The tool Domain-specific Ontology for Student s Information in Academic Institution Page 58

25 is multilingual. Each concept or relation name can be specified in several languages which is useful for the collaborative development of ontologies by teams of researchers spread across several countries and speaking different languages. OntoEdit is built on top of an internal data representation model, Office XML (OXML) 2.0, which is frame based. OXML is defined in XML using XML-schema. Besides concepts, relations and instances, the model can represent predicates, predicate instances, and axioms. Several types of relationships can be established between concepts, such as symmetric, reflexive, transitive, antisymmetric, asymmetric, irreflexive, or intransitive. The internal representation data model can be exported to DAML+OIL, F-Logic, RDFS, and OXML as well as to relational databases via JDBC. OntoEdit can import external data representation in DAML+OIL, Excel, F-Logic, RDFS, and OXML. OntoEdit provides an API for accessing ontologies in an object-oriented fashion. The inference engine that OntoEdit uses is OntoBroker [48]. OntoEdit uses F-Logic to represent expressive rules. OntoBroker is now a commercial product. OntoEdit is based on a plug-in architecture, open to third party plug-ins, which extends specific functionalities. The architecture consists of three layers: GUI, OntoEdit core and Parser. Several plugins are available. For example, the Sesame plug-in [28] is a generic application for storing and querying RDF and RDFS. Sesame allows persistent storage of RDF data and schema information. It has a useful query engine which supports Resource Query Language (RQL), an Object Query Language (OQL) style query language. OntoEdit [188] is commercialized by Ontoprise. It is an extensible and flexible environment, based on a plugin architecture, which provides functionality to browse and edit ontologies. It includes plugins that are in charge of inferring using Ontobroker, of exporting and importing Domain-specific Ontology for Student s Information in Academic Institution Page 59

26 ontologies in different formats. Two versions of OntoEdit are available: OntoEdit Free and OntoEdit Professional ALTOVA SEMANTICWORKS 2006 Altova SemanticWorks 2006 is a commercial visual Semantic Web editor which provides powerful, easy-to-use functionality for a visual creation and editing of N-triples, XML, RDF, RDFS, OWL (Lite, DL, Full) documents. This editor has an intuitive GUI and drag-and-drop functionality. It allows users to visually design instance documents, vocabularies, and ontologies. There is no evident orientation or methodology associated to this tool. This tool provides powerful features for working with RDF in RDFS vocabularies and OWL ontologies. Users are capable of printing the graphical RDF and OWL representations to create documentation for Semantic Web implementations. The user can switch from the graphical RDF/OWL view to the text view to see how documents are being built in RDF/XML, OWL or N-triples format, which is automatically generated from the user s design. Therefore, users can learn and try out with the concepts of the Semantic Web without having to write complicated code. The graphical display is highly configurable interms of orientation, adjusting the nodes, and changing the font styles and colors used. An intelligent right menu and context sensitive entry helpers help to change or add details to the RDF resource according to the user choices based on the RDF specification, so that users can be certain to create valid documents. The errors are written as links in the error window, so that the user can find and repair them easily. A full version of this editor can be installed using a self-contained installer. A 30-day free evaluation version is available to test the editor. Domain-specific Ontology for Student s Information in Academic Institution Page 60

27 2.3.4 SWOOP SWOOP [197] is a Web-based OWL ontology editor and browser. It contains OWL validation and offers various OWL presentation syntax views. SWOOP is developed as a separate Java application that attempts to provide the look and feel of a browser-based application. Its architecture was designed to optimize OWL browsing and to be extensible via a plug-in architecture. It has reasoning support and provides a multiple ontology environment. Ontologies can be compared, edited and merged. Different ontologies can be compared against their DL-based definitions, associated properties and instances. Its interface has hyperlinked capabilities so that navigation can be simple and easy. It does not follow a specific methodology for ontology construction. Users can reuse external ontological data [111] by purely linking to the external entity, or importing the entire external ontology. It is not possible to do partial imports of OWL. It is possible to search concepts across multiple ontologies. SWOOP makes use of an ontology search algorithm, that combines keywords with DL-based in order to find related concepts. This search is made along all the ontologies stored in the SWOOP KB. SWOOP allows collaborative annotation using the Annotea plug-in, which is used to write and share annotations on any ontological entity. Users can maintain different version of the same ontology since mechanisms exist to maintain versioning information using a public server. SWOOP takes the standard Web browser as the User Interface paradigm. This Web ontology browser has a layout that is known to most of the users. The navigation side bar on the left contains list of ontologies and class/property hierarchy of the ontology and center pane works like an editor. This editor provides support for automatic OWL ontology partitioning into distinct modules each describing a separate domain. Domain-specific Ontology for Student s Information in Academic Institution Page 61

28 SWOOP supports ontology debugging/repair by identifying the precise axioms that causes errors in ontology and also provides natural language explanation of the error. A Crop-Circles visualization format is used to better understand the class hierarchy. SWOOP is based on the conventional Model-View Controller (MVC) paradigm [111]. Therefore, it is possible to guarantee modularity of the code, and encourage external developers to contribute to the SWOOP project easily. SWOOP uses the Wonder Web OWL API that provides programmatic access to data representing OWL ontologies. This API is used as the underlying OWL representation model. It has Ontology Renderers that display statistical information about the ontology, the annotations, the DL expressivity and the OWL species level. There are default plug-ins for different presentation syntax for rendering ontologies like RDF/XML, OWL and N Comparison of Tools Protégé is one of the most widely used free and open source ontology development tool. It is an intuitive editor for ontologies and there are plug-ins available to carry out some of the tasks for building an ontology. OntoEdit is an ontology editor that integrates numerous aspects of ontology engineering. OntoEdit environment supports collaborative development of ontologies. Altova Semantic Works is a commercial visual Semantic Web editor that offers easy-to-use functionality for visual creation and editing. It can be downloaded for 30 days free evaluation period. SWOOP is a Web-based OWL ontology editor and browser and has default plug-ins for different presentation syntax for rendering ontologies. Protégé is used for domain modeling and for building KB systems. It provides an intuitive editor for ontologies and has extensions for ontology visualization, project management, software engineering and other Domain-specific Ontology for Student s Information in Academic Institution Page 62