Skip to main content
SpringerLink
Log in

Compositionality: An Implementation Guide

  • Chapter
  • First Online:
Book cover Terminology and Terminological Systems

Part of the book series: Health Informatics ((HI))

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.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Log in via an institution
Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 54.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    By implicit we mean relations that were present in the ICD9 textual descriptions

References

  1. 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.

    Article  PubMed  CAS  Google Scholar 

  2. 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.

    PubMed  CAS  Google Scholar 

  3. 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

    Google Scholar 

  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.

    Google Scholar 

  5. Rector AL, Nowlan WA. The Galen project. Comput Methods Programs Biomed. 1994;45(1–2):75–8.

    Article  PubMed  CAS  Google Scholar 

  6. 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.

    PubMed  CAS  Google Scholar 

  7. Wagner JC, Rogers JE, Baud RH, Scherrer JR. Natural language generation of surgical procedures. Int J Med Inform. 1999;53(2–3):175–92.

    Article  PubMed  CAS  Google Scholar 

  8. Wagner JC, Rogers JE, Baud RH, Scherrer JR. Natural language generation of surgical procedures. Medinfo. 1998;9(Pt 1):591–5.

    Google Scholar 

  9. 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.

    PubMed  CAS  Google Scholar 

  10. 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.

    Google Scholar 

  11. Rector AL. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4–5):239–52.

    PubMed  CAS  Google Scholar 

  12. Rector AL. The interface between information, terminology, and inference models. Medinfo. 2001;10(Pt 1):246–50.

    Google Scholar 

  13. 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.

    Google Scholar 

  14. 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.

    Google Scholar 

  15. Baud R, Rassinoux A, Scherrer J. Natural language processing and semantically representation of medical texts. Meth of Inf Med. 1992;31(2):117–25.

    CAS  Google Scholar 

  16. 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.

    Google Scholar 

  17. http://www.w3.org/TR/owl-semantics/#1

  18. 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

    Google Scholar 

  19. 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.

    Google Scholar 

Download references

Author information

Authors and Affiliations

  1. 212 East 95th Street, Suite 3B, New York, NY, 10128, USA

    Peter L. Elkin M.D., MACP, FACMI (Physician, Researcher and Author)

  2. Department of Veterans Affairs and Vanderbilt, Department of Biomedical Informatics, Nashville, TN, USA

    Steven H. Brown M.D., MS, FACMI

Authors
  1. Peter L. Elkin M.D., MACP, FACMI
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Steven H. Brown M.D., MS, FACMI
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Peter L. Elkin M.D., MACP, FACMI .

Editor information

Editors and Affiliations

  1. Mount Sinai School of Medicine, USA, 17 East 102nd Street, New York, 10029, USA

    Peter L. Elkin

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. 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. 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. 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

Reprints 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)

Publish with us

Policies and ethics

Search

Navigation