ece 627 intelligent web: ontology and beyond lecture 9: ontology – how to …

ontology development three ways to use something that is already available (Web) to leverage information assets that already exist to model from scratch ece 627, winter ‘13

ontology development from scratch begin by determining what questions the model will need to answer then construct an ontology so that these questions can be answered, and to the extent possible, model no further than necessary to answer them (some limitations for the Semantic Web – you model for a variety of anticipated settings) ece 627, winter ‘13

ontology development from scratch insightful names vs. wishful names keeping in mind that your ontology will be “read” by others is always a good practice use annotations (label, comment, seeAlso) naming convention … ece 627, winter ‘13

ontology development from scratch classes and individuals when something should be modeled as a class and when it should be modeled as an individual it is possible for one application to consider something as a class, while the other considers this something as an individual ece 627, winter ‘13

ontology development from scratch classes and individuals classes can be seen as a set of individuals (it is a good idea to name the class in such a way that the nature of those individuals is clear) properties that describe the thing to be modeled – do you know specific values for those properties ece 627, winter ‘13

ontology development methods ? many different approaches: Uschold and King (1995) Toronto Virtual Enterprise Method (1995) Methontology (1997) ontology development 101 (2001) Horrocks (2003) Antoniou and van Harmelen (2008) yours … ece 627, winter ‘13

ontology development Uschold and King (UK) should be guided by motivating scenarios “… to create detailed scenarios that arise in the application. These correspond to the story problems and the scenarios should include possible solutions to the problem.” Ushold, M., and King, M., Towards a Methodology for Building Ontologies, in Skuce, D. (ed.) IJCAI’95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, 1995, pp 6.1-6.10 ece 627, winter ‘13

ontology development Uschold and King (UK) 1. identify purpose and scope of ontology why is being built? for what it is going to be used? (may be designed for knowledge sharing, reuse, or part of existing knowledge base) ece 627, winter ‘13

ontology development Uschold and King (UK) 2. build the ontology capture (define concepts and relationship textually) code (formalize the concept and relationships) integrate (question the possibility of reusing existing ontologies – done in parallel with others) ece 627, winter ‘13

ontology development Uschold and King (UK) 3. evaluate the ontology use technical criteria to verify the specification, using competency questions and real-world validations ece 627, winter ‘13

ontology development Uschold and King (UK) 4. document the ontology describe the ontology construction process (determine your own conventions) ece 627, winter ‘13

ontology development Uschold and King (UK) critique: little support in identifying ontology classes and relationships ece 627, winter ‘13

ontology development Toronto Virtual Enterprise Method (TVEM) creation of motivating scenarios once they are ready – the developer should elaborate competency questions (questions the ontology should answer) Gruninger, M., and Fox, M., Methodology for the design and evaluation of ontologies, in Skuce, D. (ed.) IJCAI’95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, 1995 ece 627, winter ‘13

ontology development Toronto Virtual Enterprise Method (TVEM) 1. description of motivating scenarios these scenarios are descriptions of problems or examples that are not adequately addressed by existing ontologies, they develop possible solutions that carry the informal semantics of the concepts and relations to be included in the ontology ece 627, winter ‘13

ontology development Toronto Virtual Enterprise Method (TVEM) 2. formulation of informal competency questions based on motivating scenarios, those questions are created – the ontology to be built must provide valid answers ece 627, winter ‘13

ontology development Toronto Virtual Enterprise Method (TVEM) 3. specification of ontology terms using a formal representation (define a set of concepts from the competency questions) 4. Formulation of formal competency questions (using a formal language) ece 627, winter ‘13

ontology development Toronto Virtual Enterprise Method (TVEM) 5. axiom specification (formally describe rules that capture the semantics associated with the ontology concepts and relations) 6. verification of ontology completeness (establish conditions to characterize the ontology is complete, based on the competency questions) ece 627, winter ‘13

ontology development Toronto Virtual Enterprise Method (TVEM) critique: concepts of ontology derived from motivating scenarios alone ece 627, winter ‘13

ontology development methontology – Gomez-Perez (M) based on IEEE standard for software development it suggests which activities should be accomplished when building ontology, but does not provide guidance as to how they should be carried out Fernandez-Lopez, M., Gomez-Perez, A., and Juristo, N., METHONTOLOGY: from ontological arts towards ontological engineering, in Proceedings of the AAAI97 Spring Symposium Series on Ontological Engineering, Stanford, USA, pp. 33-40. ece 627, winter ‘13

ontology development methontology – Gomez-Perez (M) plan specification (scope and goal) conceptualization (elicit the relevant concepts) formalization (using formal language - DL) integration (with existing ontologies) implementation (using formal ontology language) evaluation documentation maintenance ece 627, winter ‘13

ontology development 101 – Noy and McGuiness it is a set of heuristics defining classes arranging them in a taxonomy defining properties filling in the values for properties for individuals Noy, N., and McGuines, D., Ontology Development 101 – A guide to creating your first ontology, KSL Technical Report, Stanford, March 2006 ece 627, winter ‘13

ontology development 101 – Noy and McGuiness it is not a linear process it should leave room for a number of interactions and refinements in the process of finding an adequate model at the end of each interaction – a validation process with domain experts and analysts ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 1. determine the domain and scope of the ontology what is the domain? for what the ontology will be used? what types of questions will be used? who will use and maintain the ontology? ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 2. consider reusing existing ontology a good practice to check if others developed some terms in another ontology of if it is possible to extend an existing ontology to our needs - http://www.ksl.standford.edu/software/ontolingua - http://www.daml.org/ontologies - http://hcs.science.uva.nl/projects/NewKACTUS/home.html ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 3. enumerate important terms in the ontology it is paramount to make a list of terms that require definitions or explanations (different elicitation techniques – some from software requirements) ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 4. define classes and the class hierarchy steps 4 and 5 should be executed in parallel there are three approaches to define the class hierarchy ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 4a. top-down approach (functional decomposition – divide et impera/divide and conquer) the most general classes first, and then their successive decomposition into more specialized classes ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 4b. bottom-up approach the most specific classes are defined first, and then successively grouped, according to some generalization criteria – and for each group a more generic class is chosen as a superclass favors listing the entire set of classes results in more balanced ontologies ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 4c. mixed approach more important classes are identified and then the generalization/decomposition process is recursively applied interesting justification: concepts more frequently used in the real world tend to occupy an intermediate position in the ontology (being neither the more general nor the more specific) ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 5. define class properties classes alone do not provide the necessary semantics to define the domain – properties are needed ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 6. define the “aspects” of the properties property values may be constrained in different ways – cardinality, values …. ece 627, winter ‘13

ontology development 101 – Noy and McGuiness 7. create individuals (instances) choosing a class creating an individual (instance) of that class filling in the property values ece 627, winter ‘13

ontology development Horrocks (H) a simple, but very useful method for developing and editing simple OWL ontologies Horrocks, I., An example OWL ontology, available at: www.cs.man.ac.uk/~horrocks/ISWC2003/Tutorial/examples.pdf ece 627, winter ‘13

ontology development Horrocks (H) determine how the world (domain) should work: determine the classes and properties determine domains and ranges for properties determine characteristics of classes add individuals and relationships as necessary iterate until the current ontology is good enough package all this into an ontology ece 627, winter ‘13

ontology development Horrocks (H) build the OWL ontology: ask whether the ontology is consistent ask whether the classes are coherent ece 627, winter ‘13

ontology development Antoniou and van Harmelen (AvH) determine scope consider reuse enumerate terms define taxonomy define properties define facets define individuals (instances of classes) check for anomalies Antoniou, G., and van Harmelen, F., A Semantic Web Primer, Chapter 7, MIT Press, 2008. ece 627, winter ‘13

ontology development (AvH) 1. determine scope there is no correct ontology of a specific domain an ontology is an abstraction of a particular domain - and there are always viable alternatives ece 627, winter ‘13

ontology development (AvH) 1. determine scope (2) what is included in this abstraction should be determined by the use to which the ontology will be put by future extensions that are already anticipated ece 627, winter ‘13

ontology development (AvH) 1. determine scope (3) questions to be answered at this stage are: what is the domain that the ontology will cover? for what we are going to use the ontology? for what types of questions should the ontology provide answers? who will use and maintain the ontology? ece 627, winter ‘13

ontology development (AvH) 2. consider reuse with the spreading deployment of the Semantic Web, ontologies will become more widely available you do not have to start from scratch when defining an ontology there is almost always an ontology available from a third party that provides at least a useful starting point for our own ontology ece 627, winter ‘13

ontology development (AvH) 3. enumerate terms write down in a list (no specific order) of all relevant terms that you expect to include in the ontology nouns form the basis for class names verbs (or verb phrases) form the basis for property names ece 627, winter ‘13

ontology development (AvH) 3. enumerate terms (2) traditional knowledge engineering tools (e.g. laddering and grid analysis) can be used to obtain the set of terms an initial structure for these terms ece 627, winter ‘13

ontology development (AvH) 4. define taxonomy relevant terms must be organized in a taxonomic hierarchy no clear indication if it is more efficient/reliable to do this in a top-down or a bottom-up fashion ece 627, winter ‘13

ontology development (AvH) 4. define taxonomy (2) ensure that your hierarchy is indeed a taxonomy i.e., if A is a subclass of B, then every instance of A must also be an instance of B (compatible with semantics of rdfs:subClassOf ece 627, winter ‘13

ontology development (AvH) 5. define properties often interleaved with the previous step subClassOf means that whenever A is a subclass of B, every property statement that holds for instances of B must also apply to instances of A it makes sense to attach properties to the highest class in the hierarchy to which they apply ece 627, winter ‘13

ontology development (AvH) 5. define properties (2) while attaching properties to classes, it makes sense to immediately provide statements about the domain and range of these properties - to define them as narrowly as possible, so potential inconsistencies and misconceptions can be spotted ece 627, winter ‘13

ontology development (AvH) 6. define Facets cardinality restrictions required values owl:hasValue owl:allValuesFrom owl:someValuesFrom relational characteristics symmetry, transitivity, inverse properties, functional values ece 627, winter ‘13

ontology development (AvH) 7. define individuals (instances) filling the ontologies with individuals is a separate step number of individuals >> number of classes populating an ontology with individuals is quite often not done manually retrieved from legacy data sources (DBs) extracted automatically from a text corpus ece 627, winter ‘13

ontology development (AvH) 8. check for anomalies an important advantage of the use of OWL over RDF Schema is the possibility to detect inconsistencies in ontology or ontology+individuals ece 627, winter ‘13

ontology development (AvH) 8. check for anomalies (2) examples of common inconsistencies incompatible domain and range definitions for transitive, symmetric, or inverse properties cardinality properties requirements on property values can conflict with domain and range restrictions ece 627, winter ‘13