Abstract
Vocabulary construction and organization is an essential part of a functional Electronic Health Record [1]. Concept level understanding of our day-to-day clinical practice will enable more accurate and more available outcomes research, evidence-based medicine, and effective cost management of medicine without a decline in service. This promise is hampered by the lack of a robust clinically relevant large-scale vocabulary, with a structure, which supports synonymy, multiple ontologies, semantic relationships, and compositionality [2, 3]. In recent years, many accomplishments have been made in the areas of synonymy, ontology, and semantic relationships. Compositionality is an area in which the underlying theory and practical implementation are relatively less well developed despite generally acknowledged payoffs for accurate data representations. In this chapter, we will review the promise and many challenges of compositionality. Toward that end, we will define compositionality and what constitutes a compositional system. We will define a set of rules for generating safe compositional expression (Desiderata for Composition). We will define methods for using multiple terminologies in a composite compositional expression, and we will present formalisms for defining the logical underpinnings that makes the use of compositional systems safe and scalable.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
By implicit we mean relations that were present in the ICD9 textual descriptions
References
Humphreys BL, McCray AT, Cheh ML. Evaluating the coverage of controlled health data terminologies: report on the results of the NLM/AHCPR large-scale Âvocabulary test. J Am Med Inform Assoc. 1997; 4(6):484–500.
Cimino JJ, Clayton PD, Hripcsak G, Johnson SB. Knowledge-based approaches to the maintenance of a Large Controlled Medical Terminology. JAMIA. 1994;1(1):35–50.
Elkin PL, Chute CG, et al. Standardized problem list generation, utilizing the Mayo canonical vocabulary embedded within the unified medical language system. JAMIA, Symp. Suppl., 1997:500–4
Rassinoux AM, Miller RA, Baud R, Scherrer JR. Modeling just the important and relevant concepts in medicine for medical language understanding: a survey of the issues. In Chute C, editor. ProceedÂings of the IMIA WG-6, Jacksonville; 1997. p 53–68.
Rector AL, Nowlan WA. The Galen project. Comput Methods Programs Biomed. 1994;45(1–2):75–8.
Evans DA, Cimino JJ, Hersh WR, Huff SM, Bell DS, for the Canon Group. Toward a medical-concept Ârepresentation language. JAMIA. 1994;1:207–17.
Wagner JC, Rogers JE, Baud RH, Scherrer JR. Natural language generation of surgical procedures. Int J Med Inform. 1999;53(2–3):175–92.
Wagner JC, Rogers JE, Baud RH, Scherrer JR. Natural language generation of surgical procedures. Medinfo. 1998;9(Pt 1):591–5.
Trombert-Paviot B, Rodrigues JM, Rogers JE, Baud R, van der Haring E, Rassinoux RAM, Abrial V, Clavel L, Idir H. Galen: a third generation terminology tool to support a multipurpose national coding system for surgical procedures. Stud Health Technol Inform. 1999;68:901–5.
Wroe CJ, Cimino JJ, Rector AL. Integrating existing drug formulation terminologies into an HL7 standard classification using OpenGALEN. Proceedings/AMIA Annu Symp:766–70; 2001.
Rector AL. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4–5):239–52.
Rector AL. The interface between information, terminology, and inference models. Medinfo. 2001;10(Pt 1):246–50.
Elkin PL, Cimino JJ, Lowe HJ, Aronow DB, Payne TH, Pincetl PS, Barnett GO. Mapping to MeSH. Presented to, and Published in the IEEE proceedings of the 12th annual symposium on computers and medical care. 01954210/88/0000/0185$01.00 © 1988 SCAMC, Inc.
Cimino JJ, Mallon LJ, Barnett GO. Automated extraction of medical knowledge from medline citations. Presented to, and Published in the IEEE proceedings of the 12th annual symposium on computers and medical care, Washington, DC, 1988.
Baud R, Rassinoux A, Scherrer J. Natural language processing and semantically representation of medical texts. Meth of Inf Med. 1992;31(2):117–25.
Baud R, Lovis C, Rassinoux AM, Scherrer JR. Alternate ways of knowledge collection, indexing and robust language retrieval. In Chute C, editor. Proceedings of the IMIA WG-6, 1997. p 81–93.
Elkin PL, Ruggieri AP, Brown SH, Buntrock J, Bauer BA, Wahner-Roedler D, Litin S, Beinborn J, Bailey KR, Bergstrom L. A randomized controlled trial of the accuracy of clinical record retrieval using SNOMED-RT as compared with ICD9-CM. JAMIA Suppl. 2001: 159–63
Elkin PL, Tuttle M, Keck K, Campbell K, Atkin G, Chute CG. The role of compositionality in standardized problem list generation. In Cesnik B, editor. Proceedings of MedInfo, Amsterdam; 1998.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Appendix
Appendix
Addendum Details of OWL
OWL Class Axioms
The full abstract syntax has more-general versions of the OWL Lite class axioms where superclasses, more-general restrictions, and Boolean combinations of these are allowed. Together, these constructs are called descriptions.
-
<axiom> ::= Class( <classID><modality>{<annotation>} {<description>} )
-
<modality> ::= complete | partial
In the full abstract syntax, it is also possible to make a class exactly consist of a certain set of individuals, as follows.
-
<axiom> ::= EnumeratedClass( <classID>{<annotation>} {<individualID>} )
Finally, in the full abstract syntax, it is possible to require that a collection of descriptions be pairwise disjoint, or have the same members, or that one description is a subclass of another. Note that the last two of these axioms generalize the first kind of class axiom just above.
-
<axiom> ::= DisjointClasses( <description>{<description>} )
-
<axiom> ::= EquivalentClasses( <description>{<description>} )
-
<axiom> ::= SubClassOf( <description><description> )
OWL Descriptions
-
<axiom> ::= Class( <classID><modality>{<annotation>} {<super>} )
-
<modality> ::= complete | partial
-
<super> ::=<classID> | <restriction>
In OWL Lite, it is possible to state that two classes are the same.
-
<axiom> ::= EquivalentClasses( <classID>{<classID>} )
Descriptions in the full abstract syntax include class IDs and the restriction constructor. Descriptions can also be Boolean combinations of other descriptions, and sets of individuals.
-
<description> ::= <classID>
-
| <restriction>
-
| unionOf( {<description>} )
-
| intersectionOf( {<description>} )
-
| complementOf( <description> )
-
| oneOf({<individualID>} )
OWL Restrictions
-
<restriction> ::= restriction( <datavaluedPropertyID> {allValuesFrom(<datatypeID>)}
-
{someValuesFrom(<datatypeID>)} [<cardinality>] )
-
<restriction> ::= restriction( <individualvaluedPropertyID> {allValuesFrom(<classID>)}
-
{someValuesFrom(<classID>)} [<cardinality>] )
-
<cardinality> ::= minCardinality(0) | minCardinality(1) |
-
| maxCardinality(0) | maxCardinality(1) |
-
| cardinality(0) | cardinality(1)
Restrictions in the full abstract syntax generalize OWL Lite restrictions by allowing descriptions where classes are allowed in OWL Lite and allowing sets of data values as well as datatypes. The combination of datatypes and sets of data values is called a data range. In the full abstract syntax, values can also be given for properties in classes. As well, cardinalities are not restricted to only 0 and 1.
-
<restriction> ::= restriction( <datavaluedPropertyID>{allValuesFrom(<dataRange>)}
-
{someValuesFrom(<dataRange>)} {value(<dataLiteral>)}
-
{<cardinality>} )
-
<restriction> ::= restriction( <individualvaluedPropertyID>{allValuesFrom(<description>)}
-
{someValuesFrom(<description>)} {value(<individualID>)}
-
{<cardinality>} )
-
<cardinality> ::= minCardinality(<non-negative-integer> )
-
| maxCardinality(<non-negative-integer>)
-
| cardinality(<non-negative-integer>)
A dataRange, used as the range of a data-valued property and in other places in the full abstract syntax, is either a datatype or a set of data values.
-
<dataRange> ::= <datatypeID>
-
<dataRange> ::= oneOf({<typedDataLiteral>} )
As in OWL Lite, there is a side condition that properties that are transitive, or that have transitive subproperties, may not have Âcardinality conditions expressed on them in restrictions.
OWL Property Axioms
-
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID>{<annotation>} {super(<datavaluedPropertyID>)}
-
{domain(<classID>)} {range(<datatypeID>)}
-
[Functional] )
-
<axiom> ::= ObjectProperty ( <individualvaluedPropertyID>{<annotation>} {super(<individualvaluedPropertyID>)}
-
{domain(<classID>)} {range(<classID>)}
-
[inverseOf(<individualvaluedPropertyID>)] [Symmetric]
-
[Functional | InverseFunctional | Functional InverseFunctional | Transitive] )
The following axioms make several properties be the same, or make one property be a subproperty of another.
-
<axiom> ::= EquivalentProperties( <datavaluedPropertyID>{<datavaluedPropertyID>} )
-
<axiom> ::= SubPropertyOf( <datavaluedPropertyID><datavaluedPropertyID> )
-
<axiom> ::= EquivalentProperties( <individualvaluedPropertyID>{<individualvaluedPropertyID>} )
-
<axiom> ::= SubPropertyOf( <individualvaluedPropertyID><individualvaluedPropertyID> )
Property axioms in the full abstract syntax generalize OWL Lite property axioms by allowing descriptions in place of classes and data ranges in place of datatypes in domains and ranges.
-
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID>{<annotation>} {super(<datavaluedPropertyID>)}
-
{domain(<description>)} {range(<dataRange>)}
-
[Functional] )
-
<axiom> ::= ObjectProperty
-
( <individualvaluedPropertyID> {<annotation>} {super(<individualvaluedPropertyID>)}
-
{super(<individualvaluedPropertyID>)}
-
{domain(<description>)} {range(<description>)}
-
[inverseOf(<individualvaluedPropertyID>)] [Symmetric]
-
[Functional | InverseFunctional | Functional InverseFunctional | Transitive] )
OWL Language and Its Formal Logic
The semantics here start with the notion of a vocabulary, which can be thought of as the URI references that are of interest in a knowledge base. It is, however, not necessary that a vocabulary consist only of the URI references in a knowledge base.
An OWL vocabulary V is a set of URI references, including owl:Thing, owl:Nothing, and rdfs:Literal. Each OWL vocabulary also includes URI references for each of the XML schema non-list built-in simple datatypes. In the semantics, LV is the (nondisjoint) union of the value spaces of these datatypes.
An Abstract OWL interpretation with vocabulary V is a four-tuple of the form: I  =  <R, S, EC, ER>
where
-
R is a nonempty set of resources, disjoint from LV
-
S : V  →  R
-
EC : V  →  2^R ∪ 2^LV
-
ER : V  →  2^(R  ×  R) ∪ 2^(R  ×  LV)
S provides meaning for URI references that are used to denote OWL individuals, while EC and ER provide meaning for URI references that are used as OWL classes and OWL properties, respectively.
Abstract OWL interpretations have the following conditions having to do with datatypes:
-
1.
If d is the URI reference for an XML schema non-list built-in simple datatype, then EC(d) is the value space of this datatype.
-
2.
If c is not the URI reference for any XML schema non-list built-in simple datatype, then EC(c) is a subset of R.
-
3.
If d,l is a datatype,literal pair, then D(d,l) is the data value for l in XML schema datatype d.
EC is extended to the syntactic constructs of <description>s, <dataRange>s, <individual>s, and <propertyValue>s as follows:
Syntax - S | EC(S) |
owl:Thing | R |
owl:Nothing | { } |
rdfs:Literal | LV |
complementOf(c) | R - EC(c) |
unionOf(c1 … cn) | EC(c1) ∪ … ∪EC(cn) |
intersectionOf(c1 … cn) | EC(c1) ∩ … ∩ EC(cn) |
oneOf(i1 … in) | {S(i1), …, S(in)} |
oneOf(d1,l1 … dn,ln) | {D(d1,l1), …, D(dn,ln)} |
restriction(p x1 … xn) | EC(restriction(p x1))∩…∩EC(restriction(p xn)) |
restriction(p allValuesFrom(r)) | {x ∈R | <x,y> ∈ER(p)  →  y ∈EC(r)} |
restriction(p someValuesFrom(e)) | {x ∈R | ∈ <x,y> ∈ER(p)  →  y ∈EC(e)} |
restriction(p value(i)) | {x ∈R | <x,S(i)> ∈ER(p)} |
restriction(p value(d,l)) | {x ∈R | <x,D(d,l)> ∈ER(p)} |
restriction(p minCardinality(n)) | {x ∈R | card({y : <x,y> ∈ER(p)})  ≤  n} |
restriction(p maxCardinality(n)) | {x ∈R | card({y : <x,y> ∈ER(p)})  ≥  n} |
restriction(p cardinality(n)) | {x ∈R | card({y : <x,y> ∈ER(p)})  =  n} |
Individual(annotation(…) … annotation(…) type(c1) … type(cm) pv1 … pvn) | EC(c1) ∩ … ∩ EC(cm) ∩ EC(pv(pv1)) ∩…∩ EC(pv(pvn)) |
Individual(i annotation(…) … annotation(…) type(c1) … type(cm) pv1 … pvn) | {S(i)} ∩ EC(c) ∩ … ∩ EC(cm) ∩ EC(pv(pv1)) ∩…∩ EC(pv(pvn)) |
pv(p Individual(…)) | {x ∈R | ∃y∈EC(Individual(…)) : <x,y> ∈ER(p)} |
pv(p id), for id an individualID | {x ∈R | <x,S(id)> ∈ER(p) } |
pv(p d,l) | {x ∈R | <x,D(d,l)> ∈ER(p) } |
An Abstract OWL interpretation, I, is an interpretation of OWL axioms and facts as given in the table below. In the table, optional parts of axioms and facts are given in square brackets ([…]) and have corresponding optional conditions, also given in square brackets.
Directive | Conditions on interpretations |
Class(c complete annotation(…) … annotation(…) descr1 … descrn) | EC(c)  =  EC(descr1) ∩…∩ EC(descrn) |
Class(c partial annotation(…) … annotation(…) descr1 … descrn) | EC(c)  ⊆  EC(descr1) ∩…∩ EC(descrn) |
EnumeratedClass(c annotation(…) … annotation(…) i1 … in) | EC(c)  =  { S(i1), …, S(in) } |
DisjointClasses(d1 … dn) | EC(di) ∩ EC(dj)  =  { } for 1  ≤  i  <  j  ≤  n |
EquivalentClasses(d1 … dn) | EC(di)  =  EC(dj) for 1  ≤  i  <  j  ≤  n |
SubClassOf(d1 d2) | EC(d1)  ⊆  EC(d2) |
DataProperty(p annotation(…) … annotation(…) super(s1) … super(sn) domain(d1) … domain(dn) range(r1) … range(rn) [Functional]) | ER(p)  ⊆  ER(s1) ∩…∩ ER(sn) ∩ EC(d1)  ×  LV ∩…∩ EC(dn)  ×  LV ∩ R  ×  EC(r1) ∩…∩ R  ×  EC(rn) [ER(p) is functional] |
IndividualProperty(p annotation(…) … annotation(…) super(s1) … super(sn) domain(d1) … domain(dn) range(r1) … range(rn) [inverse(i)] [Symmetric] [Functional] [InverseFunctional] [Transitive]) | ER(p)  ⊆  ER(s1) ∩…∩ ER(sn) ∩ EC(d1)  ×  R ∩…∩ EC(dn)  ×  R ∩ R  ×  EC(r1) ∩…∩ R  ×  EC(rn) [ER(p) is the inverse of ER(i)] [ER(p) is symmetric] [ER(p) is functional] [ER(p) is inverse functional] [ER(p) is transitive] |
EquivalentProperties(p1 … pn) | ER(pi)  =  ER(pj) for 1  ≤  i  <  j  ≤  n |
SubPropertyOf(p1 p2) | ER(p1)  ⊆  ER(p2) |
SameIndividual(i1 … in) | S(ij)  =  S(ik) for 1  ≤  j  <  k  ≤  n |
DifferentIndividuals(i1 … in) | S(ij)  ≠ S(ik) for 1  ≤  j  <  k  ≤  n |
Individual([i] annotation(…) … annotation(…) type(c1) … type(cm) pv1 … pvn) | EC(Individual([i] type(c1) … type(cm) pv1 … pvn)) is nonempty |
The effect of an imports construct is to import the contents of another OWL ontology into the current ontology. The imported ontology is the one that can be found by accessing the document at the URI that is the argument of the imports construct. The imports closure of an OWL ontology is then the result of adding the contents of imported ontologies into the current ontology. If these contents contain further imports constructs, the process is repeated as necessary. A particular ontology is never imported more than once in this process, so loops can be handled.
Annotations have no effect on the semantics of OWL ontologies in the abstract syntax.
An Abstract OWL interpretation, I, is an interpretation of an OWL ontology, O, iff I is an interpretation of each axiom and fact in the imports closure of O.
An Abstract OWL ontology entails an OWL axiom or fact if each interpretation of the ontology is also an interpretation of the axiom or fact. An Abstract OWL ontology entails another Abstract OWL ontology if each interpretation of the first ontology is also an interpretation of the second ontology. Note that there is no need to create the imports closure of an ontology—any method that correctly determines the entailment relation is allowed.
From the RDF model theory [RDF MT], for V a set of URI references containing the RDF and RDFS vocabulary, an RDFS interpretation over V is a triple I  =  <RI, EXTI, SI>. Here RI is the domain of discourse or universe, i.e., a set that contains the denotations of URI references. EXTI is used to give meaning to properties and is a mapping from RI to sets of pairs over RI  ×  (RI∪LV). Finally, SI is a mapping from V to RI that takes a URI reference to its denotation. CEXTI is then defined as CEXTI(c)  =  { x∈RI | <x,c> ∈EXTI(SI(rdf:type)) }. RDFS interpretations must meet several conditions, as detailed in the RDFS model theory. For example, SI(rdfs:subClassOf) must be a transitive relation.
An OWL interpretation, I  =  <RI, EXTI, SI>, over a vocabulary V, where V includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing, is an RDFS interpretation over V that satisfies the following conditions:
Relationships between OWL classes
If E is | then CEXT I (S I (E))= | with |
owl:Thing | IOT | IOT  ⊆  RI |
owl:Nothing | {} | Â |
rdfs:Literal | LV | Â |
owl:Class | IOC | IOC  ⊆  CEXTI(SI(rdfs:Class)) |
owl:Restriction | IOR | IOR  ⊆  IOC |
owl:Datatype | IDC | IDC  ⊆  CEXTI(SI(rdfs:Class)) |
owl:Property | IOP | IOP  ⊆  CEXTI(SI(rdf:Property)) |
owl:ObjectProperty | IOOP | IOOP  ⊆  IOP |
owl:DataTypeProperty | IODP | IODP  ⊆  IOP |
rdf:List | IL | IL  ⊆  RI |
Membership in OWL classes
If E is | then S I (E)∈ |
owl:Thing | IOC |
owl:Nothing | IOC |
rdfs:Literal | IDC |
a datatype of D | IDC |
rdf:nil | IL |
Characteristics of members of OWL classes
If E is | then if e∈CEXT I (S I (E)) then |
owl:Class | CEXTI(e)  ⊆  IOT |
owl:Datatype | CEXTI(e)  ⊆  LV |
owl:ObjectProperty | EXTI(e)  ⊆  IOT  ×  IOT |
owl:DatatypeProperty | EXTI(e)  ⊆  IOT  ×  LV |
The next constraints are IFF, which may be harder to deal with in OWL/DL, as they extend the various categories of properties to all of owl:Property. However, in OWL/DL ontologies, you can neither state that an owl:DatatypeProperty is inverse functional nor ask whether it is, so there should be not adverse consequences.
If E is | then c∈CEXT I (S I (E)) iff c∈IOP and |
owl:SymmetricProperty | <x,y> ∈EXTI(c)  →  <y, x>∈EXTI(c) |
owl:FunctionalProperty | <x,y1> and <x,y2> ∈EXTI(c)  →  y1  =  y2 |
owl:InverseFunctionalProperty | <x1,y> ∈EXTI(c) ∩ <x2,y>∈EXTI(c)  →  x1  =  x2 |
owl:TransitiveProperty | <x,y> ∈EXTI(c) ∩ <y,z>∈EXTI(c)  →  <x,z> ∈EXTI(c) |
RDFS domains and ranges are strengthened to if-and-only-if over the OWL universe
If E is | then for | <x,y>∈CEXT I (S I (E)) iff |
rdfs:domain | x∈IOP,y∈IOC | <z,w>∈EXTI(x)  →  z∈CEXTI(y) |
rdfs:range | x∈IOP,y∈IOCÎIDC | <w,z>∈EXTI(x)  →  z∈CEXTI(y) |
Some OWL properties have iff characterizations
If E is | then <x,y>∈EXT I (S I (E)) iff |
owl:sameClassAs | x,y∈IOC ^CEXTI(x)  =  CEXTI(y) |
owl:disjointWith | x,y∈IOC ^CEXTI(x)∩CEXTI(y)  =  {} |
owl:samePropertyAs | x,y∈IOP ^EXTI(x)  =  EXTI(y) |
owl:inverseOf | x,y∈IOOP ^<u,v>∈EXTI(x) iff <v,u>∈EXTI(y) |
owl:sameIndividualAs | x = y |
owl:sameAs | x = y |
owl:differentFrom | x ≠y |
Some OWL properties have only-if characterizations
We will say that l1 is a sequence of y1,…,yn over C iff n=0 and l1=SI(rdf:nil) or n>0 and l1εIL and ∃l2, …, ln ∈IL such that <l1,y1>∈EXTI(SI(rdf:first)), y1∈CEXTI(C), <l1,l2>∈EXTI(SI(rdf:rest)), …, <ln,yn>∈EXTI(SI(rdf:first)), yn∈CEXTI(C), and <ln,SI(rdf:nil)>∈EXTI(SI(rdf:rest)).
If E is | then if <x,y>∈EXT I (S I (E)) then |
owl:complementOf | x,y∈IOC and CEXTI(x)=IOT-CEXTI(y) |
If E is | then if <x,l>∈EXT I (S I (E)) then |
owl:unionOf | x∈IOC and l is a sequence of y1,…yn over IOC and CEXTI(x) = CEXTI(y1)∪…∪CEXTI(yn) |
owl:intersectionOf | x∈IOC and l is a sequence of y1,…yn over IOC and CEXTI(x) = CEXTI(y1)∩…∩CEXTI(yn) |
owl:oneOf | x∈CEXTI(rdfs:Class) and l is a sequence of y1,…yn over RI∪LV and CEXTI(x) = {y1,…, yn} |
If E is | and | then if <x,l>∈EXT I (S I (E)) then |
owl:oneOf | l is a sequence of y1,…yn over LV | x∈IDC and CEXTI(x) = {y1,…, yn} |
owl:oneOf | l is a sequence of y1,…yn over IOT | x∈IOC and CEXTI(x) = {y1,…, yn} |
If | then x∈IOR, y∈IOC, p∈IOP, and CEXT I (x) = |
<x,y>∈EXTI(SI(owl:allValuesFrom))) ^ <x,p>∈EXTI(SI(owl:onProperty))) | {u∈IOT | <u,v>∈EXTI(p) → v∈CEXTI(y) } |
<x,y>∈EXTI(SI(owl:someValuesFrom))) ^ <x,p>∈EXTI(SI(owl:onProperty))) | {u∈IOT | ∃ <u,v>∈EXTI(p) ^v∈CEXTI(y) } |
<x,y>∈EXTI(SI(owl:hasValue))) ^ <x,p>∈EXTI(SI(owl:onProperty))) | {u∈IOT | <u, y>∈EXTI(p) } |
If | then x∈IOR, y∈LV, y is a nonnegative integer, p∈IOP, and CEXT I (x) = |
<x,y>∈EXTI(SI(owl:minCardinality))) ^ <x,p>∈EXTI(SI(owl:onProperty))) | {u∈IOT | card({v : <u,v>∈EXTI(p)}) ≥ y } |
<x,y>∈EXTI(SI(owl:maxCardinality))) ∧ <x,p>∈EXTI(SI(owl:onProperty))) | {u∈IOT | card({v : <u,v>∈EXTI(p)}) ≤ y } |
<x,y>∈EXTI(SI(owl:cardinality))) ∧ <x,p>∈EXTI(SI(owl:onProperty))) | {u∈IOT | card({v : <u,v>∈EXTI(p)}) = y } |
RI contains elements corresponding to all possible OWL descriptions and data ranges
The first three conditions require the existence of the finite sequences that are used in some OWL constructs. The remaining conditions require the existence of the OWL descriptions and data ranges.
If there exists | then there exists l 1 ,…,l n ∈ IL with |
x1, …, xn ∈IOC | <l1,x1> ∈EXTI(SI(rdf:first)), <l1,l2> ∈EXTI(SI(rdf:rest)), … <ln,xn> ∈EXTI(SI(rdf:first)), <ln,SI(rdf:nil)> ∈EXTI(SI(rdf:rest)) |
x1, …, xn ∈IOT∪LV | <l1,x1> ∈EXTI(SI(rdf:first)), <l1,l2> ∈EXTI(SI(rdf:rest)), … <ln,xn> ∈EXTI(SI(rdf:first)), <ln,SI(rdf:nil)> ∈EXTI(SI(rdf:rest)) |
If there exists | then there exists y with |
l, a sequence of x1,…,xn over IOC | y∈IOC, <y,l> ∈EXTI(SI(owl:unionOf)) |
l, a sequence of x1,…,xn over IOC | y∈IOC, <y,l> ∈EXTI(SI(owl:intersectionOf)) |
l, a sequence of x1,…,xn over IOT∪LV | y∈CEXTI(SI(rdfs:Class)), <y,l> ∈EXTI(SI(owl:oneOf)) |
If there exists | then there exists y ∈ IOC with |
x ∈IOC | <y,x> ∈EXTI(SI(owl:complementOf)) |
If there exists | then there exists y ∈IOR with |
x ∈IOP ^w ∈IOC ∪IDC | <y,x> ∈EXTI(SI(owl:onProperty)) ^ <y,w> ∈EXTI(SI(owl:allValuesFrom)) |
x ∈IOP ^w ∈IOC ∪IDC | <y,x> ∈EXTI(SI(owl:onProperty)) ^ <y,w> ∈EXTI(SI(owl:someValuesFrom)) |
x ∈IOP ^w ∈IOT ∪LV | <y,x> ∈EXTI(SI(owl:onProperty)) ^ <y,w> ∈EXTI(SI(owl:hasValue)) |
x ∈IOP ^w ∈LV ^w is a nonnegative integer | <y,x> ∈EXTI(SI(owl:onProperty)) ^ <y,w> ∈EXTI(SI(owl:minCardinality)) |
x ∈IOP ^w ∈LV ^w is a nonnegative integer | <y,x> ∈EXTI(SI(owl:onProperty)) ^ <y,w> ∈EXTI(SI(owl:maxCardinality)) |
x ∈IOP ^w ∈LV ^w is a nonnegative integer | <y,x> ∈EXTI(SI(owl:onProperty)) ^ <y,w> ∈EXTI(SI(owl:cardinality)) |
Rights and permissions
Copyright information
© 2012 Springer-Verlag London
About this chapter
Cite this chapter
Elkin, P.L., Brown, S.H. (2012). Compositionality: An Implementation Guide. In: Elkin, P. (eds) Terminology and Terminological Systems. Health Informatics. Springer, London. https://doi.org/10.1007/978-1-4471-2816-8_5
Download citation
DOI: https://doi.org/10.1007/978-1-4471-2816-8_5
Published:
Publisher Name: Springer, London
Print ISBN: 978-1-4471-2815-1
Online ISBN: 978-1-4471-2816-8
eBook Packages: MedicineMedicine (R0)