| Lines 1-60 were replaced by line 1 |
| - !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 generic concepts. Figure 1 below defines 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. A basic structural relationship is the connection between parts and wholes in which one object serves as a "composite" that contains zero or more other objects serving as "parts". Figure 2 shows how the definition of parts and wholes in the core. The concepts __Composite__ and __Part__ are sub-concepts of EcoOntThing, which are related through the __hasPart__ and __partOf__ relationships. |
| - |
| - [http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core2.png] |
| - \\__Fig. 2:__ Basic part-whole concepts and relationships. |
| - |
| - |
| - 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 hasPart and partOf relationships are considered inverses. That is, if a composite c has a part p, denoted {{hasPart(p, c}}, then p must also be a part of c, denoted {{partOf(p, c)}}. |
| - |
| - The hasPart and partOf relationships are also transitive. That is, if a composite c contains a part p1, and part p1 is also a composite containing a part p2, then c also contains p2. More formally, 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 four distinct ways that part-whole relationships can be specialized within the core, shown in Figures 3 - 6. The first specialization, defined in Figure 3, allows parts to be inseparable. That is, all __InseparablePart__ objects are contained within at least one composite object -- the object will not exist separately from a collection. |
| - |
| - [http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core3.png] |
| - \\__Fig. 3:__ Inseparable parts. |
| - |
| - The second specialization, shown in Figure 4, 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/core4.png] |
| - \\__Fig. 4:__ Essential parts. |
| - |
| - The third specialization, shown in Figure 5, 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/core5.png] |
| - \\__Fig. 5:__ Unique parts. |
| - |
| - The last specialization, shown in Figure 6, 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. 6:__ Unshareable parts. |
| - |
| - |
| - !''Observations and Measurements'' |
| - |
| - Like parts and wholes, measurements (as well as the more general notion of observations) are fundamental building blocks in the eco-ontology. As shown in Figure 8, we define __MeasurementConcept__ to highlight the special status of measurements in the core. In particular, MeasurementConcept is defined as an abstract concept (denoted by the italics type in the figure) that all other measurement definitions fall under. |
| - |
| - [http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/seek/projects/kr-sms/docs/OntoManual/core8a.png] |
| - \\__Fig. 7:__ Observations and observation collections. |
| - |
| - Observations (and therefore, measurements, which we describe further below) can be grouped into collections through the concept __ObservationCollection__. Observation collections can also be grouped into other collections. We use the abstract concept __ObservationCollectionPart__ to denote the objects that can act as parts in an observation collection object. As shown in Figure 8, we use the part-whole constructs to describe these relationships between observations and observation collections. Note that the cardinality restrictions are not shown because they are implied by the part-whole constructs used. |
| - |
| - An observation is a generalization of a measurement. Informally, we define an observation as an assertion of the existence of an entity or of the existence of some property of an entity. A measurement goes further by asserting a value for a property. To illustrate, consider the statement "I saw a tree frog". This statement refers to an observation, in which the existence of a tree frog was observed. The statement "I noticed the tree frog had spots" is also an observation in which the existence of the property "spots" was observed for a tree frog. We say that for this case, the observation asserts there is some value for the property "spots" that was observed, but the value was not provided. Finally, the statement "I noticed the tree frog had ten spots" is a measurement, in which the existence of the value ten is being asserted for the "spots" property of a tree frog. |
| + Coming Soon ... |
