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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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
ece 627, winter ‘13

9. 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

10. 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

11. 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

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

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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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
ece 627, winter ‘13

21. 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

22. 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

23. 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

24. 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

25. 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 - - -
ece 627, winter ‘13

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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:
ece 627, winter ‘13

35. 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

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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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

51. 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