<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Ontological Engineering for Conceptual Modeling</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author role="corresp">
							<persName><forename type="first">Richard</forename><forename type="middle">)</forename><surname>Raban</surname></persName>
							<email>richard@socs.uts.edu.au</email>
							<affiliation key="aff0">
								<orgName type="department">Faculty of Information Technology</orgName>
								<orgName type="institution">University of Technology</orgName>
								<address>
									<settlement>Sydney</settlement>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Brian</forename><surname>Garner</surname></persName>
							<affiliation key="aff1">
								<orgName type="department">School of Computing and Mathematics Deakin</orgName>
								<orgName type="institution">University</orgName>
							</affiliation>
						</author>
						<title level="a" type="main">Ontological Engineering for Conceptual Modeling</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">40CD686BBDCC930B0F77AC77D2DCE92C</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-25T06:23+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>In acknowledging the importance of ontologies in conceptual modeling, database integration and business process modeling, this paper introduces a set of principles for building ontologies. Starting from Guarino's meta-properties of ontological terms, the paper describes the denotational semantics of the meta-properties and derives from them some engineering rules and checks for constructing domain specific conceptual models, based on the overarching requirement to assign meanings to concepts using tags and labels. Parallel research by the authors into the use of contextual references and roles to restrict such meanings will be published elsewhere.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Ontologies grew out of being a philosophical endeavor of finding the top level categories of existence (those appear in the works of Aristotle through Kant, Heidegger to the ontological categories introduced recently by Sowa <ref type="bibr" target="#b0">[1]</ref>) into an important tool in domain knowledge representation, and recently, in information systems modeling. Whenever a model is built, a certain ontological commitment is assumed. In most cases, however, this commitment is not explicitly stated. It makes information exchange, interoperability and integration very difficult. XML <ref type="bibr" target="#b1">[2]</ref>, XMI <ref type="bibr" target="#b2">[3]</ref> or UML <ref type="bibr" target="#b3">[4]</ref>, <ref type="bibr" target="#b4">[5]</ref>, <ref type="bibr" target="#b5">[6]</ref>, to mention just some of the prominent modeling and integration tools, will not be able to realize their full potential in the area of knowledge sharing and integration unless the tags and labels used have ontologybased semantics.</p><p>As ontologies become more and more part of knowledge engineering and modeling <ref type="bibr" target="#b6">[7]</ref>, <ref type="bibr" target="#b7">[8]</ref>, <ref type="bibr" target="#b8">[9]</ref>, it is imperative to have precise rules for engineering ontlologies themselves.</p><p>A similar problem also arises in managing changing contexts within reasoning processes which, as argued in <ref type="bibr" target="#b9">[10]</ref>, often requires dynamic ontology modifications. In order to be able to manipulate ontologies without loosing their internal consistency, strict ontology construction rules are required.</p><p>This paper aims to advance the basis of ontological engineering by specifying rules for creating a hierarchy of properties that individuals might have and by exploring some implications of the rules for conceptual modeling. We start by defining the denotational semantics of ontological meta-properties, also referred to in this paper as criteria, and then derive from them rules for properties subtyping. The metaproperties, which were partially introduced in <ref type="bibr" target="#b10">[11]</ref>, <ref type="bibr" target="#b11">[12]</ref>, <ref type="bibr" target="#b12">[13]</ref>, <ref type="bibr" target="#b13">[14]</ref>, <ref type="bibr" target="#b14">[15]</ref> and have been recently refined and formalized by Guarino and Welty in <ref type="bibr" target="#b15">[16]</ref>, were adopted as the starting point for this research.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Extensional semantics of meta-properties.</head><p>Let's assume that in a particular Universe of Discourse there are individuals x that can be dynamically created and destroyed.</p><p>Let ω t be the existence predicate defined on all x such that ω t (x) means that an individual x exits at a point in time t. We assume that each individual might have exactly one creation time t cx such that ∀ t &lt; tcx ¬ω t (x) ∧ ∃t ∆ ∀ tcx ≤ t &lt; tcx + t∆ ω t (x) and exactly one destruction time t dx such that ∀ t &gt; tdx ¬ω t (x) ∧ ∃t ∆ ∀ tdx -t∆ &lt; t ≤ tdx ω t (x).</p><p>Let τ x = [t cx , t dx ] be the period in which an individual x exists or the individual x's lifetime.</p><p>Let Ω t = {x | ω t (x)} be a set of all individuals existing at a point in time t.</p><p>First-order properties correspond to monadic predicates over Ω t . If P is a property, P t (x) means that an individual x has property P at a point in time t. This, of course, implies that the individual x must exist at the point in time t to have the property. For example, individuals of a Universe of Discourse might have properties like PERSON, EMPLOYEE, RED, SHORT, etc. Note that properties are not attributes like LENGTH, or COLOR which are functions defined on a domain of individuals and return attribute values. For example, LENGTH(x) = 175cm or COLOR(y) = 'red'.</p><p>A individual x acquires a property P at a point in time t cP(x) such that ∀ t &lt; tcP(x) ¬P t (x) ∧ ∃ t∆ ∀ tcP(x) ≤ t &lt; tcP(x) + t∆ P t (x) and discards it at a point in time t dP(x) such that ∀ t &gt; tdP(x) ¬P t (x) ∧ ∃ t∆ ∀ tdP(x) -t∆ &lt; t ≤ tdP(x) P t (x). A period of time during which an individual x holds a property P is called an attribution period of P to x and is defined as τ P(x) = [t cP(x) , t dP(x) ] such that ∀ t ∈ τP(x) P t (x). In this paper, the discussion is limited to such properties that apply for some period of time to at least one individual, that is ∀ P ∃ x t cP(x) , &lt; t dP(x) .</p><p>A property P can have many attribution periods for an instance x. For example, a person can hold property STUDENT many times in different periods of time.</p><p>We call a property P static if; ∀ x P t (x) → (τ P(x) = τ x ) Otherwise, a property is called dynamic. A static property is inherent to an individual; it is acquired at its creation time and holds for its entire lifetime. Properties like PERSON, LIVING-BEING are static. A dynamic property is acquired by an individual temporarily, and it can be acquired and discarded many times in an individual's lifetime. The previously mentioned property STUDENT is an example of a dynamic property.</p><p>The denotation of a property P is defined as δP t = {x | P t (x)} and represents a set of all individuals that have property P at a point in time t.</p><p>It is also valid to use the denotation for the existence predicate -δω t is a set of all individuals existing at a point in time t.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Subtyping</head><p>If a property Q is a subtype of a property, denoted by</p><formula xml:id="formula_0">Q ≤ P, then ∀ t (δQ t ⊆ δP t ). If additionally ∃ t (δQ t ⊂ δP t ),</formula><p>then Q is a proper subtype of P, which we denote by Q &lt; P. If a property Q is a (proper) subtype of a property P, it can be said that a property P is a (proper) supertype of a property Q.</p><p>There could be two different types of subtyping. Firstly, we can have time independent or static subtyping. In this case, a static property Q is a subtype of a static property P. For example, property PERSON is a static subtype of property LIVING-BEING and it means that a living-being can also be a person, and if it is so, it remains a person for its lifetime.</p><p>Secondly, we can have time dependent subtyping or dynamic subtyping. In this case, a dynamic property Q is a subtype of a property P, which could be either static or dynamic. It means that an individual x with the property P might have the property Q at some periods of time and might not have this property on some other occasions. For example, property STUDENT is a dynamic subtype of property PERSON as a person might be a student only for some periods of time. Similarly, properties PART-TIME-STUDENT and FULL-TIME-STUDENT are dynamic subtypes of property STUDENT and here too a student can change its status from being a part-time-student to being a full-time-student, and vice-versa, many times during the period of enrolment.</p><p>Using the above terminology let's define the semantics of the three meta-properties introduced by Guarino <ref type="bibr" target="#b15">[16]</ref>: identity, rigidity and dependence.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Identity</head><p>Following the original definition, we say that a property P has identity, and denote it by +I, if there is a relation R such that</p><formula xml:id="formula_1">∀ t ∀ xy (P t (x) ∧ P t (y)) → (R(x,y) ↔ (x = y)).</formula><p>The relation R is called an identity condition of P. For example, property PERSON has identity as its instances can be distinguished from each other by their DNA structure (relation HAS-SAME-DNA) or the makeup of their brains (relation HAS-SAME-BRAIN). On the other hand, individuals of property THING cannot be distinguished by any identity condition inherent to all things.</p><p>Further we say that a property P has its own identity, and denote it by +O, if there is a relation R such that ∀ t ∀ xy (P t (x) ∧ P t (y)) → (R(x,y) ↔ (x = y)) and</p><formula xml:id="formula_2">∀ Q (¬(Q &lt; P)) → (¬(∀ t ∀ xy (Q t (x) ∧ Q t (y)) → (R(x,y) ↔ (x = y))).</formula><p>In other words, a property P has its own identity, if it does not share its identity condition defined by the relation R with any property Q which is not a subsumption of the property P. For example, relation HAS-SAME-DNA allows us to distinguish between any two individuals having property LIVING-BEING, but it cannot be used to distinguish between individuals having a property being a supertype of LIVING-BEING. Thus, property LIVING-BEING has its own identity.</p><p>However, property PERSON shares its identity condition HAS-SAME-DNA with all individuals with property LIVING-BEING. And unless property PERSON introduces its own identity condition, we say that the property does not have its own identity, and denote it by -O.</p><p>Obviously, if a property has its own identity (+O) it also has identity (+I). Conversely, not having identity (-I) rules out its own identity, and therefore, implies lack of own identity (-O). This leaves only three possible identity criteria: -I-O, +I-O, and +I+O.</p><p>Let's explore under what conditions a subtype Q of a property P with given identity criteria can inherit or change the identity criteria of its supertype.</p><p>If a property P has identity, it means that there is an identity condition defined for its individuals. For any subtype property Q of P, individuals with property Q have also property P and, therefore, can be distinguished using the property P's identity condition. Thus, having identity is always inherited.</p><p>If a subtype property Q of P has its own identity, it becomes +I+O irrespective of what kind of identity criteria the supertype has. If, however, a subtype property Q of P does not have its own identity, it always becomes +I-O, unless its supertype does not have identity at all. These subtyping rules for identity are summarized in TABLE <ref type="table">I</ref>. The boxes with the phrase 'not allowed' signify the fact that identity cannot ever be lost in subtypes or acquired from a subtype, which does not have identity. The symbol I(T) means that subtyping is allowed under the identity criteria, and the symbol I(⊥) means that subtyping is not allowed under the identity criteria.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>TABLE I.</head><p>Subtyping Rules for Identity.</p><formula xml:id="formula_3">Q ≤ P -I-O +I-O +I+O -I-O allowed I(T) not allowed I(⊥) not allowed I(⊥) +I-O not allowed I(⊥) allowed I(T) allowed I(T) +I+O allowed I(T) allowed I(T) allowed I(T)</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.3">Rigidity</head><p>A property P is rigid, which is denoted by +R, if it is a static property. It means that all individuals with property P meet the rigidity condition</p><formula xml:id="formula_4">P t (x) → (τ P(x) = τ x ). A property is non-rigid, which is denoted by -R, if ∃ t' ∃ t" ∃ x (P t' (x) ∧ ω t" (x) ∧ ¬ P t" (x)).</formula><p>It means that there is at least one individual that violates the rigidity condition at some point in time.</p><p>A property is anti-rigid, which is denoted by ~R, if</p><formula xml:id="formula_5">∃ t' ∃ t" ∀ x (P t' (x) → (ω t" (x) ∧ ¬ P t" (x)).</formula><p>Anti-rigidity is a special case of non-rigidity, in which all individuals holding a property P violate the rigidity condition, and as such is subsumed by non-rigidity.</p><p>A rigid property P can have a rigid subtype property Q, if Q holds for its individuals for their entire lifetime. For example, property LIVING-BEING and its subtype PERSON. This amounts to static subtyping. But also, a subtype property Q of a rigid property P can be a result of dynamic subtyping, and then it can be either nonrigid or anti-rigid, depending whether some or all of its individuals violate the rigidity condition. Therefore, rigidity is not inherited.</p><p>It is possible to have a rigid proper subtype Q of a non-rigid property P, since the denotation δQ t ⊂ δP t could contain only those individuals out of δP t , which fulfill the rigidity condition. Equally, it is possible that a proper subtype Q of a non-rigid property P has the denotation δQ t ⊂ δP t that contains only those individuals out of δP t , which violate the rigidity condition, or contains some that do and some that do not. Hence, non-rigidity is not inherited.</p><p>Since all individuals that have an anti-rigid property P hold it for periods of time always shorter than their lifetimes, any subtype property Q of the property P cannot hold it longer than P's lifetime. Therefore, all individuals of any subtype property Q must violate the rigidity condition, which means that anti-rigidity is inherited.</p><p>The summary of subtyping rules of the rigidity conditions is presented in TABLE <ref type="table">II</ref>. The symbol R(T) means that subtyping is allowed under the rigidity criterion, and the symbol R(⊥) means that subtyping is not allowed under the rigidity criterion.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>TABLE II. Subtyping Rules for Rigidity</head><formula xml:id="formula_6">Q ≤ P +R -R ~R +R allowed R(T) allowed R(T) not allowed R(⊥) -R allowed R(T) allowed R(T) not allowed R(⊥) ~R allowed R(T) allowed R(T) allowed R(T)</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.4">Dependence</head><p>Following Guarino, we confine this discussion to one type of dependence that is "notional dependence, which holds for a property if its instances require instances of another property to exist" <ref type="bibr" target="#b15">[16]</ref>. We say that a property P is dependent, which is denoted by +D, if</p><formula xml:id="formula_7">∀ t ∀ x (P t (x) → ∃ Q≠P ∃ y≠x Q t (y)).</formula><p>In other words, for an individual x to have a property P ,it is required that there exists an individual having a property Q. In this definition, it is also assumed that Q is not a part of P. For example, individuals with property PARENT require individuals with property CHILD to exist.</p><p>A property P is independent, which is denoted by -D if it not dependent. If a property Q is a subtype of a dependent property P, all individuals with the property Q also have the property P, and are therefore subject to the same dependency condition, and as such, are dependent. Thus, dependence is inherited by subtypes. On the other hand, an independent property P can have dependent or independent subtypes.</p><p>The summary of subtyping rules of the dependence criterion is presented in TABLE III. The symbol D(T) means that subtyping is allowed under the dependency criterion, and the symbol D(⊥) means that subtyping is not allowed under the dependency criterion. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Ontological Engineering Rules</head><p>All desirable combinations of the three property criteria give rise to eight property types (a metalevel classification of properties), which were described in <ref type="bibr" target="#b15">[16]</ref>. Three of them are called Formal as they do not carry identity, and the remaining five are called sortals as they have either their own or an inherited identity. The property types are shown in TABLE IV. Note that we have split Category, Type and Merely Rigid Sortals according to their dependency criterion and Material Role according to its own identity criterion. This will enable us to have a closer look at subtyping allowed for those types of properties.    <ref type="table">II</ref>; and since it is a conjunction of the three conditions, it follows that the subsumption is not allowed. All allowed subsumptions are highlighted by shading of the cells.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Guarino's ontology engineering rules.</head><p>Let us examine subtyping rules given in <ref type="bibr" target="#b15">[16]</ref> and assess their coverage in the discussion so far: G1. "Antirigid class cannot subsume a rigid class." This rule has already been accounted for in the discussion of rigidity. G2. "ICs cannot be 'overriden' by a subclass, merely augmented" (in other words, sortals cannot subsume formal concepts). This has already been accounted for in the discussion of identity. G3. "A dependent class cannot subsume an independent one." This has already been accounted for in the discussion of dependence. G4. "A material role can be subsumed by rigid sortals, since they carry identity ... They are the roles that normally specialise formal roles… " In the discussion so far, a material role is the most flexible of all the property types in terms what it can subsume (see TABLE <ref type="table">V</ref>). Except for material roles without own identity, which cannot be subsumed by formal properties, all the other subsumptions are allowed. However, the cited rule makes good sense, since it would be desirable to have in the ontology some indication of what property the role applies to. Otherwise, the role specification would be somehow incomplete, like saying that there is a material role STUDENT without any indication that it applies to PERSON. But there is no reason to make the assumption that a rigid property must be subsumed by a rigid one; there could be some other material roles or even phased sortals between the material role and the subsuming rigid property in the subsumption hierarchy. G5. "Phased sortals must be subsumed by a type." This is required to be able to establish the identity of the changing entity. But since a merely rigid, independent sortal, type-attribution mixing, material role and phased sortal should all be subsumed by a type, all of them can directly subsume a phased sortal. G6. "Merely rigid sortals ... are always subsumed by at least one type." This is to provide an identity condition, as merely rigid sortals do not carry their own identity condition. G7. "Types can only be subsumed by categories and strictly non-rigid formal attributions." In other words, types sit between formal properties and the rest of the sortals in the subsumption hierarchy. In fact, it has already been said that the other sortals should be eventually subsumed by a type. Of course, types can form an hierarchy and subsume each other before being subsumed by a category or formal attribution. TABLE VI summarizes all the conditions discussed so far, and shows when subtyping of properties of different types is allowed, as indicated by the content of respective cells. If "not allowed" is written in a cell, it means that there is a restriction on the subsumption originating from TABLE V. In cases where "G(n) not allowed" is written, it indicates that one of the Guarino's rule n has been invoked to prohibit this subsumption. For example, a formal attribution (Attr row) cannot be subsumed by a formal role (FRole column) since the cell on the intersection of the two contains phrase "not allowed" derived from TABLE V.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>TABLE V.</head><p>Conditions for Subtyping Originating from the Three Property Criteria.</p><formula xml:id="formula_8">F O R M A L S O R T A L S ⊆ Cat+ O-I+D+R Cat- -O-I-D+R FRole O-I+D~R Attr O-I-D-R ATMix O+I-D-R</formula><p>Type+ O+I+D+R </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Type-O+I-D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>PSort</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>O+I-D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRole+ O+I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRole-O+I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRSort+</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>+I+D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRSort-O+I-D+R Cat+ -O-I+D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(⊥) I(⊥)D(T) R(⊥) I(⊥)D(T) R(⊥) I(⊥)D(T) R(T) I(⊥)D(T) R(T) Cat--O-I-D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(⊥) R(⊥) I(T)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(⊥) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(⊥) I(⊥)D(⊥) R(⊥) I(⊥)D(⊥) R(⊥) I(⊥)D(⊥) R(T) I(⊥)D(T) R(T) FRole -O-I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(⊥)D(T )R(T)</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(⊥) I(⊥)D(T) R(⊥) I(⊥)D(T) R(T) I(⊥)D(T) R(T)</head><formula xml:id="formula_9">F O R M A L Attr -O-I-D-R</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(⊥) R(⊥) I(T)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(⊥) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(⊥) I(⊥)D(⊥) R(⊥) I(⊥)D(⊥) R(⊥) I(⊥)D(⊥) R(T) I(⊥)D(T) R(T) ATMix -O+I-D-R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(⊥)D(⊥) R(T) I(⊥)D(T) R(T) I(⊥)D(⊥) R(⊥) I(⊥)D(T) R(T) I(T)D(T) R(T) I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(⊥) R(⊥) I(T)D(⊥) R(⊥) I(T)D(⊥) R(T) I(T)D(T) R(T) Type+ +O+I+D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(T) R(⊥)</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(T) R(⊥) I(T)D(T) R(T) I(T)D(T) R(T) Type-+O+I-D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(⊥) R(⊥) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(⊥) R(⊥) I(T)D(⊥) R(⊥) I(T)D(⊥) R(T) I(T)D(T) R(T) PSort</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>+O+I-D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(⊥) R(T)</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(⊥) R(T) I(T)D(⊥) R(T) I(T)D(⊥) R(T) I(T)D(T) R(T) MRole+ +O+I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) MRole--O+I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T)</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRSort+ -O+I+D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(⊥)D(T) R(T) I(⊥)D(T) R(T) I(⊥)D(T) R(⊥) I(⊥)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(T) R(⊥) I(T)D(T) R(⊥) I(T)D(T) R(T) I(T)D(T) R(T)</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>S</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>I(⊥)D(⊥) R(T) I(⊥)D(T) R(T) I(⊥)D(⊥) R(⊥) I(⊥)D(T) R(T) I(T)D(T) R(T) I(T)D(⊥) R(T) I(T)D(T) R(T) I(T)D(T) R(⊥) I(T)D(⊥) R(⊥) I(T)D(⊥) R(⊥) I(T)D(⊥) R(T) I(T)D(T) R(T)</head><p>TABLE VI. Summary of Subtyping Conditions. In knowledge bases <ref type="bibr" target="#b16">[17]</ref>, <ref type="bibr" target="#b17">[18]</ref> and databases <ref type="bibr" target="#b18">[19]</ref>, <ref type="bibr" target="#b19">[20]</ref>, there is a commonly accepted distinction between definitions of terms, their characteristics and the relations between them (often referred to as a schema or the TBox), and assertions about the world stated in instances of those terms (often referred to as a fact base or the Abox). This section will discuss implications of the taxonomy of properties for defining domain models, i.e. classes, their characteristics and the relations between them (the TBox).</p><formula xml:id="formula_10">F O R M A L S O R T A L S ⊆ Cat+ O-I+D+R Cat- O-I-D+R FRole O-I+D~R Attr O-I-D-R ATMix O+I-D-R Type+ O+I+D+R</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Type-O+I-D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>PSort</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>O+I-D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRole+ O+I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>MRole-O+I+D~R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>RSort+ O+I+D+R</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>RSort-O+I-D+R</head><p>In conceptual modeling of an application domain, not only properties are given, but also all the sufficient and necessary conditions for an individual to carry the specific property are defined. These property definitions are typically called classes. Individuals that hold the property defined by a class are called instances of the class. In order to maintain the distinction between properties and classes, the former will be denoted by all capital (hyphenated) names (e.g. LIVING-BEING), and the latter by non-hyphenated names with the first letter of each word capitalized (e.g. LivingBeing). Classes based on properties will have corresponding names consisting of the same wording.</p><p>A class defines domain specific conditions for the class membership. The conditions give characteristics that are pertinent to all the class members in the context of the domain and the purpose for which the modeling is performed. Properties of type Attribution seems to provide appropriate terminology for specifying class characteristics. However, property type Attribution, as explained in <ref type="bibr" target="#b15">[16]</ref>, is "refering … to an attribution as the property of having an attribute with certain value, i.e. having gender MALE or color RED." And therefore, while useful to describe characteristic of individuals, attributions are not suitable for declaring that class Person should have gender stated for its instances. This requires a relation, which maps instances of the class to a set of attributions relevant to the characteristic being defined. The sets of attributions will be called attribution types. This brings us to the first relation type of conceptual modeling, which has the following format:</p><p>Characteristic(Class, AttributionType). In order to answer this question, it is useful to call upon Charles Peirce's three basic categories Firstness, Secondness and Thirdness which were described in the quotation from the original provided in <ref type="bibr" target="#b0">[1]</ref>:</p><p>"First is the conception of being or existing independent of anything else. Second is the conception of being relative to, the conception of reaction with, something else. Third is the conception of mediation, whereby a first and a second are brought into relation. ( <ref type="formula">1891</ref>)" Obviously, independent properties are related to the Firstness. Dependent properties relate to the Secondness. The Thirdness, which mediates the relationship, provides an answer to the original question. The mediating element that brings STUDENT and UNIVERSITY-COURSE together is ENROLMENT, and the one that brings BANK-CUSTOMER and BANK-ACCOUNT together is BANK-ACCOUNT-CONTRACT. In general, dependent properties will result in a conceptual relation type defined as follows:</p><p>DependencyMediator(DependentClass, Class) which for the two examples is instantiated as: Enrolment(Student, UniversityCourse) BankAccountContract(BankCustomer, BankAccount). The only other issue here is what property type DependencyMediator is based on. Mediating properties seems to be rigid, dependent and carry their own identity, and therefore they are of type Type+.</p><p>Another type of relationships that can exist between properties is the structural relationship. In this case, the relations bring about certain arrangement of individuals. For example, PartOf(Engine, Car), Above(Roof, Basement). This type of relationship can be defined as StructuralDependency(Class, Class). Structural dependencies are properties that seem to be both dependent and nonrigid. It is the type of properties, which are not included in the taxonomy as they are "too weak … to capture the rigor … intended" <ref type="bibr" target="#b15">[16]</ref>. However, if a structural dependency is combined with one of the related properties, for example, PART-OF-CAR or ABOVE-BASEMENT, it becomes independent and non-rigid and therefore is of type Attribution.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Conclusion</head><p>This paper critically reviews the application of ontological engineering to conceptual modeling. The two activities, while related, differ in purpose. Ontological engineering deals with rules and principles of conceptualization of a problem domain. Conceptual modeling, on the other hand, is concerned with the problem domain structuring. While one may accept that no structure exists without underlying conceptualization, the requisite conceptualization is usually implicit and often derived on an intuitive, craft basis. Manifestation of an explicit basis for conceptualization will, in our opinion, not only result in IT solutions of greater integrity, but will also facilitate system and data integration vital to enterprise application integration, including semantic web applications.</p><p>In the first part, the paper presented denotational semantics of identity, rigidity and dependence used to define types of properties, and then introduced a set of property subtyping rules and checks. It established the foundations for creating clean, wellstructured taxonomies. In the second part, the links between ontology engineering principles and conceptual modeling were explored. In particular, three types of emergent relationships were discussed.</p><p>Further work will concentrate on the development of domain ontologies as the basis for data and system integration for oceanographic data interchange and electronic business processes. Parallel work on the rules for context management and role constraints will also benefit from the explication of property subtyping rules and constraints.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head>TABLE III .</head><label>III</label><figDesc>Subtyping Rules for Dependence</figDesc><table><row><cell>Q ≤ P</cell><cell>+D</cell><cell></cell><cell>-D</cell><cell></cell></row><row><cell>+D</cell><cell>Allowed</cell><cell>D(T)</cell><cell>allowed</cell><cell>D(T)</cell></row><row><cell>-D</cell><cell>not allowed</cell><cell>D(⊥)</cell><cell>allowed</cell><cell>D(T)</cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head>TABLE IV .</head><label>IV</label><figDesc>Property Types Resulting from Property Criteria.</figDesc><table><row><cell>Property Type</cell><cell>Property</cell><cell>Examples</cell></row><row><cell></cell><cell>Criteria</cell><cell></cell></row><row><cell>Category+</cell><cell>-O-I+D+R</cell><cell>SOCIAL-ENTITY</cell></row><row><cell>(Cat+)</cell><cell></cell><cell></cell></row><row><cell>Category-</cell><cell>-O-I-D+R</cell><cell>THING, LOCATION, ENTITY</cell></row><row><cell>(Cat-)</cell><cell></cell><cell></cell></row><row><cell>Formal Role</cell><cell>-O-I+D~R</cell><cell>PART, PATIENT, ACTOR</cell></row><row><cell>(FRole)</cell><cell></cell><cell></cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_2"><head></head><label></label><figDesc>TABLE V summarizes the allowed subsumptions between property types shown inTABLE IV. Cells contain three subsumption conditions originating from identity, dependence and rigidity criteria discussed earlier. These are shown in the table, as appropriate, for the respective property types. For example, at the intersection of Formal Attribution (Attr row) and Formal Role (FRole column) there are: • I(T) indicating that the identity criterion allows the subsumption, as per TABLE I. • D(⊥) which indicates that the dependency criterion does not allow the subsumption, as per TABLE III. • R(⊥) which indicates that the rigidity criterion does not allow the subsumption, as per TABLE</figDesc><table /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_4"><head></head><label></label><figDesc>into existence in relation to some other properties holding over different individuals. For example, STUDENT is a property of a person being enrolled for a university course, or BANK-CUSTOMER is a property of a person having a bank account. The statements have the following elements in them:• they tell us that STUDENT and BANK-CUSTOMER are subtypes of property PERSON, and• they also point out what properties STUDENT and BANK-CUSTOMER are dependent on; in this case the properties depend on the existence of respectively, a UNIVERSITY-COURSE and of a BANK-ACCOUNT.It is easy to show that there are relationships between classes based on these properties by creating pairs (Student, UniversityCourse) and (BankCustomer, BankAccount). What remains to be answered is what type of relationships do they represent.</figDesc><table><row><cell>For class Person, this relation type can be instantiated as</cell></row><row><cell>Gender(Person, {"Male", "Female"}) -enumerated attribution type</cell></row><row><cell>Height(Person, {x: x is distance measurement in meters}) -measured</cell></row><row><cell>attribution type</cell></row><row><cell>Address(Person, {x: x is a character string}) -description attribution</cell></row><row><cell>type</cell></row><row><cell>Dependent properties come</cell></row></table></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<title level="m" type="main">Knowledge Representation</title>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">F</forename><surname>Sowa</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2000">2000</date>
			<publisher>Brooks/Cole</publisher>
			<biblScope unit="page">593</biblScope>
			<pubPlace>Pacific Grove, CA USA</pubPlace>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<title level="m" type="main">Extensible Markup Language (XML)</title>
		<author>
			<persName><forename type="first">D</forename><surname>Connolly</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1997">1997</date>
			<publisher>W3C</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<title level="m">Object Management Group, XMI Metadata Interchange (XMI)</title>
				<imprint>
			<publisher>OMG</publisher>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">The Unified Software Development Process</title>
		<author>
			<persName><forename type="first">I</forename><surname>Jacobson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Booch</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Rumbaugh</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Object Technology Series</title>
				<meeting><address><addrLine>Reading, MA</addrLine></address></meeting>
		<imprint>
			<publisher>Addison-Wesley</publisher>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<monogr>
		<title level="m" type="main">The Unified Modelling Language Reference Manual. Object Technology Series</title>
		<author>
			<persName><forename type="first">J</forename><surname>Rumbaugh</surname></persName>
		</author>
		<author>
			<persName><forename type="first">I</forename><surname>Jacobson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Booch</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1999">1999</date>
			<publisher>Addison-Wesley</publisher>
			<pubPlace>Reading, MA</pubPlace>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">The Unified Modelling Language User Manual</title>
		<author>
			<persName><forename type="first">G</forename><surname>Booch</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Rumbaugh</surname></persName>
		</author>
		<author>
			<persName><forename type="first">I</forename><surname>Jacobson</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Object Technology Series</title>
				<meeting><address><addrLine>Reading, MA</addrLine></address></meeting>
		<imprint>
			<publisher>Addison-Wesley</publisher>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">Ontology-Based Web Site Mapping for Information Exploration</title>
		<author>
			<persName><forename type="first">X</forename><surname>Zhu</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the Eighth International Conference on Information Knowledge Management</title>
				<meeting>the Eighth International Conference on Information Knowledge Management<address><addrLine>Kansas City, MO USA</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1999">1999</date>
			<biblScope unit="page" from="188" to="194" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Ontology-based Extraction and Structuring of information from Data-Rich Unstructured Documents</title>
		<author>
			<persName><forename type="first">D</forename><forename type="middle">W</forename><surname>Embley</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the 1998 ACM 7th International Conference on Information and Knowledge Management</title>
				<meeting>the 1998 ACM 7th International Conference on Information and Knowledge Management<address><addrLine>Washington, USA</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1998">1998</date>
			<biblScope unit="page" from="52" to="58" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">Building and (Re)Using an Ontology of Air Campaign Planning</title>
		<author>
			<persName><forename type="first">A</forename><surname>Valente</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">IEEE Inteligent Systems</title>
		<imprint>
			<biblScope unit="volume">14</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="27" to="36" />
			<date type="published" when="1999-01">1999. Jan/Feb 1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">Ontologically Yours</title>
		<author>
			<persName><forename type="first">D</forename><surname>Keyser</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Lectures in Artificial Intelligence</title>
				<editor>
			<persName><forename type="first">M.-L</forename><surname>Mugnier</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">M</forename><surname>Chein</surname></persName>
		</editor>
		<imprint>
			<publisher>Springer-Verlag</publisher>
			<date type="published" when="1998">1998</date>
			<biblScope unit="page" from="35" to="47" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<analytic>
		<title level="a" type="main">Using a Lexicon of Canonical Graphs in a Semantic Interpreter</title>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">F</forename><surname>Sowa</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Relational Models of the Lexicon</title>
				<editor>
			<persName><forename type="first">M</forename><forename type="middle">W</forename><surname>Evens</surname></persName>
		</editor>
		<meeting><address><addrLine>Cambridge</addrLine></address></meeting>
		<imprint>
			<publisher>Cambridge University Press</publisher>
			<date type="published" when="1988">1988</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<monogr>
		<title level="m" type="main">Individuals. An Essay on Descriptive Metaphysics</title>
		<author>
			<persName><forename type="first">P</forename><forename type="middle">F</forename><surname>Strawson</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1959">1959</date>
			<publisher>Routledge</publisher>
			<pubPlace>London</pubPlace>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b12">
	<monogr>
		<title level="m" type="main">Relative Identity</title>
		<author>
			<persName><forename type="first">N</forename><surname>Griffin</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1977">1977</date>
			<publisher>Oxford University Press</publisher>
			<pubPlace>Oxford</pubPlace>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<analytic>
		<title level="a" type="main">An Ontology of Meta-Level Categories, in Principles of Knowledge Representation and reasoning</title>
		<author>
			<persName><forename type="first">N</forename><surname>Guarino</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Carrara</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Giaretta</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the Fourth International Conference (KR&apos;94)</title>
				<editor>
			<persName><forename type="first">J</forename><surname>Doyle</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">E</forename><surname>Sandewall</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">P</forename><surname>Torasso</surname></persName>
		</editor>
		<meeting>the Fourth International Conference (KR&apos;94)<address><addrLine>San Francisco, CA</addrLine></address></meeting>
		<imprint>
			<publisher>Morgan Kaufman Publishers</publisher>
			<date type="published" when="1994">1994</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b14">
	<analytic>
		<title level="a" type="main">Formal Ontology, Conceptual Analysis and Knowledge Representation</title>
		<author>
			<persName><forename type="first">N</forename><surname>Guarino</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">International Journal of Human-Computer Studies</title>
		<imprint>
			<biblScope unit="volume">43</biblScope>
			<biblScope unit="issue">5/6</biblScope>
			<biblScope unit="page" from="625" to="640" />
			<date type="published" when="1995">1995</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b15">
	<analytic>
		<title level="a" type="main">A Formal Ontology of Properties</title>
		<author>
			<persName><forename type="first">N</forename><surname>Guarino</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Welty</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of EKAW-2000: The 12th International Conference on Knowledge Engineering and Knowledge Management</title>
				<editor>
			<persName><forename type="first">R</forename><surname>Dieng</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">O</forename><surname>Corby</surname></persName>
		</editor>
		<meeting>EKAW-2000: The 12th International Conference on Knowledge Engineering and Knowledge Management</meeting>
		<imprint>
			<publisher>Springer-Verlag</publisher>
			<date type="published" when="2000">2000</date>
			<biblScope unit="page" from="97" to="112" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b16">
	<analytic>
		<title level="a" type="main">An Overview of the KL-ONE Knowledge Representation System</title>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">J</forename><surname>Brachman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Cognitive Science</title>
		<imprint>
			<biblScope unit="volume">9</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page" from="171" to="216" />
			<date type="published" when="1985">1985</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b17">
	<analytic>
		<title level="a" type="main">Knowledge Level Interfaces to Information Systems</title>
		<author>
			<persName><forename type="first">H</forename><forename type="middle">J</forename><surname>Levesque</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">J</forename><surname>Brachman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">On Knowledge Base Management Systems: Integrating Artificial Intelligence and Database Technologies</title>
				<editor>
			<persName><forename type="first">M</forename><forename type="middle">L</forename><surname>Brodie</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">J</forename><surname>Mylopoulos</surname></persName>
		</editor>
		<meeting><address><addrLine>New York</addrLine></address></meeting>
		<imprint>
			<publisher>Springer-Verlag</publisher>
			<date type="published" when="1986">1986</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b18">
	<analytic>
		<title level="a" type="main">Data Semantics</title>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">R</forename><surname>Abrial</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Data Base Management</title>
				<editor>
			<persName><forename type="first">J</forename><forename type="middle">W</forename><surname>Klimbie</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">K</forename><forename type="middle">L</forename><surname>Koffeman</surname></persName>
		</editor>
		<meeting><address><addrLine>Amsterdam</addrLine></address></meeting>
		<imprint>
			<publisher>Noth-Holland Publishing</publisher>
			<date type="published" when="1974">1974</date>
			<biblScope unit="page" from="1" to="59" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b19">
	<analytic>
		<title level="a" type="main">A Language Facility for Designing Database-Intensive Applications</title>
		<author>
			<persName><forename type="first">H</forename><forename type="middle">J</forename><surname>Mylopoulos</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><forename type="middle">A</forename><surname>Bernstein</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Journal on Database Systems</title>
		<imprint>
			<biblScope unit="volume">5</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page" from="185" to="207" />
			<date type="published" when="1980">1980</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
