| At line 0 added 1 line. |
| + |
| Line 3 was replaced by lines 4-7 |
| - ;:''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.'' |
| + |
| + |
| + ;:''Comment: Introduction goes here. Introduce our basic vocabulary of concepts including: 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, properties, and what we mean by package.'' |
| + |
| At line 4 added 1 line. |
| + |
| Line 7 was replaced by lines 12-15 |
| - 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. |
| + |
| + |
| + 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. |
| + |
| At line 8 added 1 line. |
| + |
| Line 11 was replaced by lines 20-23 |
| - 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..*'). |
| + |
| + |
| + Every concept in the eco-ontology extends the generic concept ''EcoOntThing''. The name "thing" is often informally used in ontologies to denote the set of all things. We use the term ''object'' instead of "thing", but we retain the convention of using "thing" to name generic concepts. Figure 1 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..*'. |
| + |
| Line 14 was replaced by line 26 |
| - \\__Fig. 1:__ Definition of the most general eco-ontology concept. |
| + \\__Fig. 1:__ Definition of EcoOntThing; the most general eco-ontology concept. |
| Line 22 was replaced by line 34 |
| - 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 parts and wholes are defined in the core. The concepts __Composite__ and __Part__ are sub-concepts of EcoOntThing, which are related through the __hasPart__ and __partOf__ relationships. |
| + 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'', containing zero or more other objects serving as ''parts''. Figure 2 shows how parts and wholes are defined in the core. The concepts ''Composite'' and ''Part'' are sub-concepts of EcoOntThing, and are related through the ''hasPart'' and ''partOf''' relationships. |
| At line 23 added 1 line. |
| + |
| Line 28 was replaced by lines 41-44 |
| - 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 by composites). The hasPart and partOf relationships are inverses: if a composite c has a part p, denoted {{hasPart(c, p)}}, then p must also be a part of c, denoted {{partOf(p, c)}}. |
| + The hasPart relationship relates a composite object to zero or more parts. We denote a hasPart relationship between a composite c and a part p as {{hasPart(c, p)}}. The partOf relationship relates a part object to its associated composite object, that is, {{partOf(p, c)}}. A part object can participate in zero or more composite objects -- thus, parts can be shared by composites. |
| + |
| + |
| + The hasPart and partOf relationships are inverse and transitive. The inverse relationship states that for every composite object c and part p, {{hasPart(c, p)}} if and only if {{partOf(p, c)}}. The transitive relationship states that for every composite object c and parts p1 and p2, if {{hasPart(c, p1)}} and {{hasPart(p1, p2)}} then {{hasPart(c, p2)}}. The inverse relationship also implies that if {{partOf(p1, c)}} and {{partOf(p2, p1)}} then {{partOf(p2, c)}}. |
| Removed line 30 |
| - The hasPart and partOf relationships are also transitive. 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. |
