Science Environment for Ecological Knowledge
Ecoinformatics site parent site of Partnership for Biodiversity Informatics site parent site of SEEK - Home
Science Environment for Ecological Knowledge









 

 

 



Eco Ontology Manual Draft

This is version 32. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]


1 Introduction

Comment: Introduction goes here. We need to introduce our basic vocabulary of concepts (i.e., classes), relationships (i.e., so called owl:ObjectProperty or property definitions between concepts), attributes (owl:DatatypeProperties; property definitions between a concept and a datatype like string), objects, and properties.

2 The Eco-Ontology Core

This section describes the fundamental building blocks of the eco-ontology -- called the eco-ontology core (or just "the core"). The core is represented as a single package, and all other ontologies defined within (or that extend) the eco-ontology are built from the core. The purpose of the core is to establish the set of basic semantic constructs that can be used to define more complex ecological concepts and relationships.

Things

Every concept in the eco-ontology extends the concept EcoOntThing. The name "thing" is often used informally in ontologies to denote the set of all things. Instead of "thing", we use the term object, but we retain the convention of using the term "thing" to name the most general concept. Every object in the eco-ontology is thus considered an ecological ontology "thing". Figure 1 below shows the definition of EcoOntThing. As shown, objects can be named using the hasName attribute. Object names are optional (denoted by the '0' in the cardinality restriction '0..*'), and an object may have more than one name (denoted by the '*' in the cardinality restriction '0..*').

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core1.png
Fig. 1: Definition of the most general eco-ontology concept.

Parts and Wholes

Objects are often described in terms of their structural relationships. One of the most basic structural relationships is the connection between parts and wholes. These part-whole relationships treat one object as the "composite", containing zero or more other objects serving as the "parts". Figure 2 shows the basic constructs used in the core for representing parts and wholes. The concepts Composite and Part are defined as sub-concepts of EcoOntThing. And composites and parts are related through the hasPart and partOf relationships, respectively.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core2.png
Fig. 2: Basic part-whole concepts and relationships.

As shown, the hasPart relationship relates a composite object to zero or more parts. Similarly, the partOf relationship relates a part object to its associated composite object. A part object can participate in zero or more composite objects (that is, a part can be shared between containers).

The part-whole relationship of Figure 2 is defined to be transitive. If a container c contains a part p1, and part p1 is also a container containing a part p2, then c is said to also contain p2 by virtue of transitivity. We can represent this more formally by saying that if hasPart(c, p1) and hasPart(p1, p2) is true, then hasPart(c, p2) is also true. The inverse also holds, that is, if partOf(p2, p1) and partOf(p1, c) is true, then partOf(p2, c) is also true.

There are five distinct ways that part-whole relationships can be specialized within the core, shown in Figures 3 - 7. The first specialization, shown in Figure 3, describes composites that contain at least one part. As shown, all NonEmptyComposite objects are connected to at least one part object.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core3.png
Fig. 3: Non-empty composites.

The second specialization, shown in Figure 4, describes the concept of inserperable parts. As shown, all InserperablePart objects are contained within at least one composite object, that is, the object will not exist separately from a collection.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core4.png
Fig. 4: Inseperable parts.

The third specialization, shown in Figure 5, describes the notion of an essential part. A composite object in general can contain heterogeneous parts, for example, a car is made up of wheels, a chassis, bumpers, and so on. An essential part denotes a specific type of part that all objects of a particular type of collection must posses. Wheels are generally considered an essential part of a car, whereas a sunroof is not an essential part.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core5.png
Fig. 5: Essential parts.

The fourth specialization, shown in Figure 6, describes unique parts. A collection object will have at most one unique part object, if a unique part is defined for the collection. A chassis is a unqiue part for a car, that is, any one car can have at most one chassis. Note that a chassis is also an essential part for a car. We permit part-whole specializations to be freely mixed.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core6.png
Fig. 6: Unique parts.

The last specialization, shown in Figure 7, defines unshareable parts. An unshareable part object can be a part of at most one collection at a time.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core6.png
Fig. 7: Unshareable parts.

Observations and Measurements

The following figure shows the basic definition of an observation, where itemMeasured is a restricted partOf relationship.

http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core7.png
Fig. 8: Observations and observation collections.



Go to top   More info...   Attach file...
This particular version was published on 02-Jul-2004 12:53:46 PDT by SDSC.bowers.