Ontology development is engineered (as discussed in Ontological Engineering) and has a continuous lifecycle from requirements and analysis thru design to implementation and representation in a formal language to testing. All of this requires a number of skills and remains a mixture of practice and science. A number of methodologies have been constructed to help us develop an ontology. Some leverage good practice from earlier work on object-oriented analysis while others emphasize representing ontological content in formal languages. For the exposition here we follow Nicola Guarino's advice of first things first and "No ontology without ontological analysis!" Analysis provides the content which is to be represented. (2JJB)
A recent survey of ontological engineering by Simperl et al (Achieving Maturity: the State of Practice in Ontology Engineering in 2009) is available at: http://www.tmrfindia.org/ijcsa/v7i13.pdf As in the development of other IT artifacts and products (e.g. software applications) it is common practice to ask a set of questions that briefly summarize the problem areas that the product is intended to deal with. This may include different abstraction levels that need to be addressed in order to build an ontology. Examples of very high-level questions are: (2V4D)
1. What is the purpose and use of the ontology? Is it to be applied in a software or data system? If so what requirements and scope do they provide? (2V4E)
2. What conceptual parts and relationsform the content of the ontology? How should the ontology be architected from its parts? (2V4F)
3. How should the ontology be represented syntactically? What fornalism should be used for implementation? (2JJK)
One common practice is to construct motivating use scenarios which frame the work and clearly identify the ontology purpose and its intended use, that is, the competence or prgagmatics of the ontology. A scenario or use case helps to organize requirement ideas which will be specified in the ontology. Analysis can proceed from that. See http://ontolog.cim3.net/cgi-bin/wiki.pl?GeoUsecases for a discussion of some of the Use Cases proposed for the SOCoP INTEROP project (2K0M)
In Gruninger's TOVE methodology, for example, scenarios are used to construct "competency question and answering facts that can be expressed by the ontology. These help focus on a necessary ontological vocabulary. Axioms in the ontology should be able to characterize answers to the competency questions. The questions play the role of constraints and are used to evaluate the resulting ontology. (2JJC)
See M. Grüninger and M.S. Fox, Methodology for the Design and Evaluation of Ontologies, Technical Report, University of Toronto, April 1995. (2JDP)
An early one called Enterprise Ontology[EO]came out of the effort of Ushold and King. (2JDQ)
The core of the methodology of interest here is the procedure of informal ontology development outlined below. (2JDR)
1. Scope definition (2JJD)
(a) Concepts collection by discussion, leveraging previous work and brain storming. In this step a concept's content must be studied, understood, analyzed as such, independently of the way it may be represented in existing appliations, DBs or even other ontologies. (2JJL)
(b) Clustering of the concepts collected into groups that seem related (2JJM)
(c) Refinement of the concept set by investigating what concepts are basic vs. derived, what proportion is appropriate between numbers of generic and specific concepts, etc. (2JDS)
(2) Determination of word name. For each concept, select a domain word which has only one meaning. This may not be easy since many words have multiple meanings, but if the Sciences some terms have pretty tight definitions. If there is no appropriate word for representing a concept, then create a new one. (2JDT)
(3) Definition Meaning definition in an ontology is prescriptive in the sense that it should represent the meaning of a concept intended by domain users. (2JDU)
Formalizing Ontologies (2K0N)
After a conceptual form ontology is developed it is then translated into a formal language and is usually semantically tightened in the process. One way to do this is by adding axioms. This many geographic terms ( river and stream or lake and "pond") are vague concepts with no clear boundaries. Constraints are added to particular concepts as axioms to distinguish them. (2JJE)
For example BENNETT et al (An Ontology for Grounding Vague Geographic Terms) use a threshold value (V) to specify a point in the hydrographic geography domain to distinguish ponds from lakes: (2JJF)
V = [pond_vs_lake_area_threshold = 200m2] See http://www.comp.leeds.ac.uk/qsr/pub/Bennett08fois.pdf (2JJG)
John Sowa distinguishes formal ontologies from informal ones by the way in which an ontologies subtypes are distinguished from their supertypes. (2RRY)
Axioms play a key role here. In Sowa's view axiomatized ontology are ones where subtypes by axioms and definitions stated in a formal language, such as first-order logic or some computational notation that can be translated to logic. Ontologies without such axioms are often called "light ontologies". These may be created from still lighter, less formal data models and they can often serve as a useful scaffolding to hang axioms on. (2JJH)
One stategy is for a group to take a light ontology and make it logically consistency using top-down extension of its terms. In this process sub-type terms are logically specified starting with a core set of well defined top-level terms. In the case of geospatial ontology these might be terms pertain to geospatial concept, features and their sub-types. (2K0O)