Ontological Modeling (Part 14)

Terry   Halpin
Terry Halpin Professor of Computer Science, INTI International University (Malaysia) Read Author Bio || Read All Articles by Terry Halpin

This is the fourteenth in a series of articles on ontology-based approaches to modeling.  The main focus is on popular ontology languages proposed for the Semantic Web, such as the Resource Description Framework (RDF), RDF Schema (RDFS), and the Web Ontology Language (OWL).

The first article[3] introduced ontologies and the Semantic Web, and covered basic concepts in the Resource Description Framework (RDF), contrasting them with other data modeling approaches.  The second article[4] discussed the N3 notation for RDF, and covered the basics of RDF Schema.  The third article[5] provided further coverage of RDFS, and introduced different flavors of the Web Ontology language (OWL).  The fourth article[6] discussed basic features of OWL, mainly using Manchester syntax.  The fifth article[7] discussed OWL taxonomy, comparison operators for classes, data types, and predicates, and examined inverses, functional roles, and keys in more depth.  The sixth article[8] covered cardinality restrictions in OWL 2.  The seventh article[9] discussed the union, intersection, and complement operators in OWL 2.  The eighth article[10] explored support for ring constraints within OWL 2.  The ninth article[11] discussed enumerated types as well as value restrictions on properties in OWL 2.  The tenth article[12] examined OWL 2's support for property chains, and compared this with related concepts in data modeling approaches.  The eleventh article[13] reviewed the logical status of structural statements in OWL 2, contrasting this with other data modeling approaches that support both integrity constraints and derivation rules.

The twelfth article[14] discussed how to express negated facts in OWL 2 and avoid circularity when declaring subproperty chains. The thirteenth article[15] provided a detailed comparison of the ways in which OWL 2, ORM, Barker ER, UML 2.5, and relational databases support simple identifiers. The current article discusses modeling of unary facts, and extends the comparison of identification schemes in [16] by considering one complex case of reference schemes (compound identifiers).

Unary Facts

Figure 1(a) depicts a simple data model about hospital patients in the graphical notation of Object-Role Modeling (ORM).[2]  Each patient is identified by a patient number and has exactly one patient name (not necessarily identifying).  The fact type Patient smokes is used to record which patients smoke.  Sample data are provided in the fact tables.  The entry 102 in the fact table for Patient smokes indicates that Patient 102 smokes.  This model adopts closed world semantics, so the absence of an entry for patients 101 and 102 in this fact table indicates that patients 101 and 103 do not smoke.  The fact type Patient smokes is said to be a unary fact type because its logical predicate (smokes) is unary (i.e., has a single argument).  Figure 1(b) and Figure 1(c) show equivalent schemas without the sample data in the notation of Barker ER[1] and UML[17] respectively.  Both of these capture smoking facts by using a Boolean attribute (e.g., Patient.isSmoker).  Alternatively, all three notations could model smoking facts by introducing a Smoker subtype/subclass of Patient.

Figure 1.  A simple Patient model in the graphical notation of (a) ORM, (b) Barker ER, and (c) UML.

Previous articles in this series discussed how to model subtyping and binary relationships in OWL, but not unary facts expressed as unary relationships (e.g., Patient 102 smokes) or Boolean attribute assignments (e.g., 102:Patient.isSmoker = true).  Recall that all facts in OWL must be expressed subject-predicate-object triples, where the predicate is a binary relationship.  Hence, unary facts are expressed in OWL by using a binary predicate to relate the subject to an object that is either a Boolean value (true or false) or a status value with two possibilities (e.g., "Smoker", "NonSmoker").

Table 1 shows an OWL encoding of the model in Figure 1 using the data property isSmoker to map patients onto Boolean values (see the code highlighted in italics).  We assert that patient 102 smokes by mapping its isSmoker data property to the value true.  OWL adopts open world semantics, so the absence of a proposition (e.g., Patient 101 smokes) does not imply that the proposition is false.  To match the models shown in Figure 1, we need to apply closed world semantics for smoking facts.  We therefore make the isSmoker data property mandatory (minimum multiplicity of 1) for Patient, and explicitly assert that patients 101 and 103 do not smoke by mapping their isSmoker data property to the value false.

Table 1.  Coding the Figure 1 model in OWL.

Manchester Syntax

Turtle Syntax

DataProperty: hasPatientNr
     Domain: Patient
     Range: xsd:integer
     Characteristics: Functional

:hasPatientNr  a  owl:DatatypeProperty ,
          owl:FunctionalProperty ;
    rdfs:domain :Patient ;
    rdfs:range xsd:integer .

DataProperty: hasPatientName
     Domain: Patient
     Range: xsd:integer
     Characteristics: Functional

:hasPatientName  a  owl:DatatypeProperty ,
          owl:FunctionalProperty ;
    rdfs:domain :Patient ;
    rdfs:range xsd:string .

DataProperty: isSmoker
     Domain: Patient
     Range: xsd:Boolean
     Characteristics: Functional

:isSmoker  a  owl:DatatypeProperty ;
    rdfs:domain :Patient ;
    rdfs:range xsd:boolean .

Class: Patient
     HasKey: hasPatientNr
     SubClassOf: hasPatientNr min 1 xsd:integer
     SubClassOf: isSmoker min 1 xsd:boolean

:Patient  owl:hasKey ( :hasPatientNr  ) ;
    rdfs:subClassOf
    [ a  owl:Restriction ;
      owl:onProperty :hasPatientNr ;
      owl:minQualifiedCardinality
        "1"^^xsd:nonNegativeInteger ;
      owl:onDataRange xsd:integer ] ,
     [ a  owl:Restriction ;
      owl:onProperty :isSmoker ;
      owl:minQualifiedCardinality
        "1"^^xsd:nonNegativeInteger;
      owl:onDataRange xsd:boolean ] .

Individual: Patient101
     Types: Patient
     Facts: hasPatientNr 101
     Facts: hasPatientName "John Smith",
        isSmoker  false

:Patient101  a  :Patient ,
        owl:NamedIndividual ;   
    :hasPatientNr 101 ;
    :hasPatientName "John Smith" ;
    :isSmoker "false"^^xsd:boolean .

Individual: Patient102
     Types: Patient
     Facts: hasPatientNr 102
     Facts: hasPatientName "John Smith",
        isSmoker  true

:Patient102  a  :Patient ,
        owl:NamedIndividual ;
    :hasPatientNr 102 ;
    :hasPatientName "John Smith" ;
    :isSmoker "true"^^xsd:boolean .

Individual: Patient103
     Types: Patient
     Facts: hasPatientNr 103
     Facts: hasPatientName "Ann Jones",
        isSmoker  false

:Patient103  a  :Patient ,
        owl:NamedIndividual ;
    :hasPatientNr 103 ;
    :hasPatientName "Ann Jones" ;
    :isSmoker "false"^^xsd:boolean .

 

Figure 2.  Adopting open world semantics for smoking facts in (a) ORM, (b) Barker ER, and (c) UML.

Figure 2(a) shows an ORM model where open world semantics is adopted for the fact type Patient smokes, as shown by the dashed (and hence open) line for the smokes predicate.  In this case, the absence of entries for 101 and 103 in the smokes fact table indicates that it is unknown whether they smoke.  In this model, there is no way to explicitly assert that a given patient does not smoke.  Figure 2(b) partly captures this in the Barker ER version of the model by indicating that the "is a smoker" attribute is optional (as indicated by the preceding "o" instead of "*").  We also need to ensure that the only values allowed for this attribute are true and null, but the Barker ER notation does not display this on the diagram.  Figure 2(c) fully captures the semantics in UML by assigning a multiplicity of [0..1] to the isSmoker attribute and adding a note to prevent the attribute being assigned the value false.

The open world semantics model in Figure 2(a) may be coded in OWL by modifying the code shown in Table 2 as follows:  remove the minimum multiplicity of 1 restriction on the isSmoker data property; remove the "isSmoker false" fact assertions for patients 101 and 103.

Figure 3(a) shows an ORM model where open world with negation semantics is adopted for the fact type Patient smokes, as shown by the tilde "~"(a logical symbol for negation) inside the dashed line box for the smokes predicate.  In this case, the entry "~101" in the smokes fact table indicates that patient 101 does not smoke, the 102 entry indicates that patient 102 does smoke, and the absence of an entry for 103 in the smokes fact table indicates that it is unknown whether patient 103 smokes.  Figure 3(b) and Figure 3(c) show the equivalent schemas in Barker ER and UML respectively:  the isSmoker attribute is optional but may be assigned true or false where known.

Figure 3.  Adopting open world with negation semantics for smoking facts in (a) ORM, (b) Barker ER, and (c) UML.

The open world with negation semantics model in Figure 3(a) may be coded in OWL by modifying the code shown in Table 2 as follows:  remove the minimum multiplicity of 1 restriction on the isSmoker data property; remove the "isSmoker false" fact assertion for patient 103.

As you can see, how unary facts are coded in OWL depends on how complete your knowledge is.  If you have complete knowledge of the relevant property, choose the code for closed world semantics.  If you know some instances where the property is true, and some where the property is false, but there are also some instances where you don't know the truth value of the property, then choose the code for open world with negation semantics.  If you know some instances where the property is true but have no knowledge of where the property is false, then choose the code for simple, open world semantics.  In practice, closed world semantics and open world with negation semantics are the most common cases.

Compound Identifiers

A compound reference scheme identifies entities of a given type by means of a combination of two or more attributes or relationships.  For example, in the ORM schema of Figure 4(a), rooms are identified by combining their building number with their local room number (e.g., the room in building 1 with room number 205 is distinct from the room in building 2 with room number 205).  The circled double bar denotes an external uniqueness constraint underlying this compound, preferred reference scheme for Room.  This corresponds to fact verbalizations that identify rooms by compound definite descriptions (e.g., "the Room that is in the Building with BuildingNr 1 and has RoomNr 205").

The circled single bar depicts an external uniqueness constraint for a compound, alternate reference scheme for buildings based on a combination of their x and y coordinates.  Buildings also have a simple, preferred reference scheme (based on building number).  The unary fact type Room is windowed is used to record which rooms have a window.

Figure 4.  A compound reference scheme for rooms in the notation of (a) ORM, (b) Barker ER, and (c) UML.

Figure 4(b) shows a Barker ER schema for the same example.  The composite reference scheme for Room is indicated by the # on the room nr attribute and the vertical stroke "|" through Room's role in its containment relationship with Building.  The simple reference scheme for Building is captured by the # on the building nr attribute.  However, Barker ER has no way to indicate that the building coordinate pair provides an alternate reference scheme for Building.

Figure 4(c) shows a UML class diagram for the same example.  The composite reference scheme for Room is captured by marking the attribute Room.nr and the association end Room.building with the {id} modifier.  The simple reference scheme for Building is indicated by the {id} modifier on Building.nr.  However, UML cannot graphically depict that the coordinate combination is also unique for buildings.

Table 2 lists the OWL code for the model in Figure 4, along with a sample population.  The isWindowed predicate is declared as a data property with domain Room and range xsd:Boolean, with individual facts using true or false as appropriate.  For the external uniqueness constraints in Figure 4(a), composite HasKey properties are declared as shown in italics.

However, as explained in the previous article [15], these HasKey declarations have no effect on specific room or building instances unless an IRI is also explicitly declared for those instances.  In this case, I've used meaningful IRIs (e.g., Room1-205 for room 205 in building 1).  However, in cases where this is impractical (e.g., consider IRIs for street addresses), we could use surrogate identifiers (e.g., address_1, address_2, etc.) or instead simply abandon any attempt to capture the uniqueness semantics in the OWL ontology.

Table 2.  Coding the model in Figure 4 in OWL.

Manchester Syntax

Turtle Syntax

ObjectProperty: isInBuilding
  Domain: Room
  Range: Building
  Characteristics: Functional

:isInBuilding  a  owl:FunctionalProperty ,
        owl:ObjectProperty ;
    rdfs:range :Building ;
    rdfs:domain :Room .

ObjectProperty: containsRoom
  InverseOf: isInBuilding

:containsRoom  a  owl:ObjectProperty ;
    owl:inverseOf :isInBuilding .

DataProperty: hasBuildingNr
  Domain: Building
  Range: xsd:integer
  Characteristics: Functional

:hasBuildingNr  a  owl:DatatypeProperty ,
        owl:FunctionalProperty ;
    rdfs:domain :Building ;
    rdfs:range xsd:integer .

DataProperty: hasXcoordinate
  Domain: Building
  Range: xsd:integer
  Characteristics: Functional

:hasXcoordinate  a  owl:DatatypeProperty ,
        owl:FunctionalProperty ;
    rdfs:domain :Building ;
    rdfs:range xsd:integer .

DataProperty: hasYcoordinate
  Domain: Building
  Range: xsd:integer
  Characteristics: Functional

:hasYcoordinate  a  owl:DatatypeProperty ,
      owl:FunctionalProperty ;
    rdfs:domain :Building ;
    rdfs:range xsd:integer .

DataProperty: hasRoomNr
  Domain: Room
  Range: xsd:integer
  Characteristics: Functional

:hasRoomNr  a  owl:DatatypeProperty ,
        owl:FunctionalProperty ;
    rdfs:domain :Room ;
    rdfs:range xsd:integer .

DataProperty: isWindowed
  Domain: Room
  Range: xsd:boolean
  Characteristics: Functional

:isWindowed  a  owl:DatatypeProperty ,
        owl:FunctionalProperty ;
    rdfs:domain :Room ;
    rdfs:range xsd:boolean .

Class: Building
  HasKey: hasBuildingNr
  HasKey: hasXcoordinate, hasYcoordinate
  SubClassOf: hasBuildingNr min 1 xsd:integer
  SubClassOf: hasXcoordinate min 1 xsd:integer
  SubClassOf: hasYcoordinate min 1 xsd:integer

:Building  a  owl:Class ;
    rdfs:subClassOf [ rdf:type owl:Restriction ;
        owl:onProperty :hasYcoordinate ;
        owl:minQualifiedCardinality
          "1"^^xsd:nonNegativeInteger ;
        owl:onDataRange xsd:integer ] ,
    [ rdf:type owl:Restriction ;
      owl:onProperty :hasXcoordinate ;
      owl:minQualifiedCardinality
        "1"^^xsd:nonNegativeInteger ;
      owl:onDataRange xsd:integer  ] ,
    [ rdf:type owl:Restriction ;
      owl:onProperty :hasBuildingNr ;
      owl:minQualifiedCardinality
        "1"^^xsd:nonNegativeInteger ;
      owl:onDataRange xsd:integer  ] ;
    owl:hasKey ( :hasXcoordinate 
        :hasYcoordinate ) ,
      ( :hasBuildingNr  ) .

Class: Room
  HasKey: isInBuilding, hasRoomNr
  HasKey: hasXcoordinate, hasYcoordinate

  SubClassOf: isInBuilding min 1 Building
  SubClassOf: hasRoomNr min 1 xsd:integer
  SubClassOf: isWindowed min 1 xsd:boolean

:Room  a  owl:Class ;
    rdfs:subClassOf [ rdf:type owl:Restriction ;
       owl:onProperty :isWindowed ;
       owl:minQualifiedCardinality
         "1"^^xsd:nonNegativeInteger ;
       owl:onDataRange xsd:Boolean  ] ,
    [ rdf:type owl:Restriction ;
       owl:onProperty :hasRoomNr ;
       owl:minQualifiedCardinality
         "1"^^xsd:nonNegativeInteger ;
       owl:onDataRange xsd:integer  ] ,
    [ rdf:type owl:Restriction ;
       owl:onProperty :isInBuilding ;
       owl:onClass :Building ;
       owl:minQualifiedCardinality
         "1"^^xsd:nonNegativeInteger  ] ;
     owl:hasKey ( :hasXcoordinate 
         :hasYcoordinate  ) ,
       ( :isInBuilding  :hasRoomNr  ) .

Individual: Building1
  Types: Building
  Facts: hasBuildingNr 1,
        hasXcoordinate 100, hasYcoordinate 50

:Building1  a  :Building ,
        owl:NamedIndividual ;
    :hasBuildingNr 1 ;
    :hasXcoordinate 100 ;
    :hasYcoordinate 50 .

Individual: Building2
  Types: Building
  Facts: hasBuildingNr 2,
        hasXcoordinate 123, hasYcoordinate 55

:Building2  a  :Building ,
        owl:NamedIndividual ;
    :hasXcoordinate 123 ;
    :hasBuildingNr 2 ;
    :hasYcoordinate 55 .

Individual: Room1-205
  Types: Room
  Facts: isInBuilding Building1, hasRoomNr 205,
        isWindowed  true

:Room1-205  a  :Room ,
        owl:NamedIndividual ;
    :isInBuilding :Building1 ;
    :hasRoomNr 205 ;
    :isWindowed "true"^^xsd:boolean  .

Individual: Room2-205
  Types: Room
  Facts: isInBuilding Building2, hasRoomNr 205,
        isWindowed  false

:Room2-205  a  :Room ,
        owl:NamedIndividual ;
    :isInBuilding :Building2 ;
    :hasRoomNr 205 ;
    :isWindowed "true"^^xsd:boolean  .

 

Conclusion

The current article discussed how to model unary facts in ORM, Barker ER, and UML, and how to encode them in OWL by using data properties with a Boolean range.  It also compared the different ways in which ORM, Barker ER, UML, and OWL support compound identification schemes.  The next article discusses how these various modeling notations support more complex kinds of identification schemes (viz. disjunctive reference and context-dependent reference).

References

[1]  R. Barker.  CASE*Method:  Tasks and Deliverables.  Addison-Wesley:  Wokingham, England (1990).  return to article

[2]  T.A. Halpin & T. Morgan.  Information Modeling and Relational Databases, 2nd edition.  Morgan Kaufmann:  San Francisco (2008).  return to article

[3]  T.A. Halpin, "Ontological Modeling (Part 1)," Business Rules Journal, Vol. 10, No. 9 (Sep. 2009), URL:  http://www.BRCommunity.com/a2009/b496.html   return to article

[4]  T.A. Halpin, "Ontological Modeling (Part 2)," Business Rules Journal, Vol. 10, No. 12 (Dec. 2009), URL:  http://www.BRCommunity.com/a2009/b513.html  [Erratum:  In the original version of the second article in this series, the discussion of transitivity of subclassing incorrectly used "a" instead of "rdfs:subClassOf" in the inference example for MaleSinger, Singer, and Person.]   return to article

[5]  T.A. Halpin, "Ontological Modeling (Part 3)," Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b527.html  return to article

[6]  T.A. Halpin, "Ontological Modeling (Part 4)," Business Rules Journal, Vol. 11, No. 6 (Jun. 2010), URL:  http://www.BRCommunity.com/a2010/b539.html  return to article

[7]  T.A. Halpin, "Ontological Modeling (Part 5)," Business Rules Journal, Vol. 11, No. 12 (Dec. 2010), URL:  http://www.BRCommunity.com/a2010/b570.html   return to article

[8]  T.A. Halpin, "Ontological Modeling (Part 6)," Business Rules Journal, Vol. 12, No. 2 (Feb. 2011), URL:  http://www.BRCommunity.com/a2011/b579.html   return to article

[9]  T.A. Halpin, "Ontological Modeling (Part 7)," Business Rules Journal, Vol. 12, No. 6 (Jun. 2011), URL:  http://www.BRCommunity.com/a2011/b602.html   return to article

[10]  T.A. Halpin, "Ontological Modeling (Part 8)," Business Rules Journal, Vol. 12, No. 9 (Sep. 2011), URL:  http://www.BRCommunity.com/a2011/b614.html   return to article

[11]  T.A. Halpin, "Ontological Modeling (Part 9)," Business Rules Journal, Vol. 12, No. 12 (Dec. 2011), URL:  http://www.BRCommunity.com/a2011/b629.html   return to article

[12]  T.A. Halpin, "Ontological Modeling (Part 10)," Business Rules Journal, Vol. 13, No. 3 (Mar. 2012), URL:  http://www.BRCommunity.com/a2012/b644.html   return to article

[13]  T.A. Halpin, "Ontological Modeling (Part 11)," Business Rules Journal, Vol. 13, No. 6 (Jun. 2012), URL:  http://www.BRCommunity.com/a2012/b657.html   return to article

[14]  T.A. Halpin, "Ontological Modeling (Part 12)," Business Rules Journal, Vol. 13, No. 11 (Nov. 2012), URL:  http://www.BRCommunity.com/a2012/b678.html   return to article

[15]  T.A. Halpin, "Ontological Modeling (Part 13)," Business Rules Journal, Vol. 14, No. 3 (Mar. 2013), URL:  http://www.BRCommunity.com/a2013/b693.html  return to article

[16]  T.A. Halpin, "Modeling of Reference Schemes," BPMDS 2013 and EMMSAD 2013, eds. I. Bider et al.  LNBIP 147, Springer-Verlag, Berlin Heidelberg (2013), pp. 308–323.  return to article

[17]  Object Management Group.  OMG Unified Modeling Language Specification (OMG UML), version 2.5 FTF Beta 1.  Object Management Group (2012).  Available online at:  http://www.omg.org/spec/UML/2.5/  return to article

[18]  NORMA tool (www.ORMSolutions.com) available online at www.ORMFoundation.org

[19]  W3C.  OWL 2 Web Ontology Language:  Primer (Second Edition).  W3C (2012).  URL:  http://www.w3.org/TR/owl2-primer/

[20]  W3C.  OWL 2 Web Ontology Language:  Direct Semantics (Second Edition).  W3C (2012).  URL:  http://www.w3.org/TR/owl2-direct-semantics/  

[21]  W3C.  OWL Web Ontology Language Manchester Syntax (Second Edition).  W3C (2012).  URL:  http://www.w3.org/TR/owl2-manchester-syntax/  

[22]  W3C.  OWL Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition).  W3C (2012).  URL:  http://www.w3.org/TR/owl2-syntax/  

# # #

Standard citation for this article:


citations icon
Terry Halpin, "Ontological Modeling (Part 14)" Business Rules Journal, Vol. 14, No. 9, (Sep. 2013)
URL: http://www.brcommunity.com/a2013/b720.html

About our Contributor:


Terry   Halpin
Terry Halpin Professor of Computer Science, INTI International University (Malaysia)

Dr. Terry Halpin, BSc, DipEd, BA, MLitStud, PhD, is a Professor of Computer Science at INTI International University, Malaysia, and a data modeling consultant. His prior industrial background includes many years of research and development of data modeling technology at Asymetrix Corporation, InfoModelers Inc., Visio Corporation, Microsoft Corporation, and LogicBlox. His previous academic background includes many years teaching computer science at the University of Queensland (Australia) and Neumont University (USA). His current research focuses on conceptual modeling and conceptual query technology. His doctoral thesis formalized Object-Role Modeling (ORM/NIAM), and his publications include over 200 technical papers and seven books, including Information Modeling and Relational Databases, 2nd Edition (2008: Morgan Kaufmann). Dr. Halpin may be reached directly at t.halpin@live.com.

Read All Articles by Terry Halpin
Subscribe to the eBRJ Newsletter
CONTRIBUTOR ARCHIVES
Logical Data Modeling (Part 14)
Logical Data Modeling (Part 13)
Logical Data Modeling (Part 12)
Logical Data Modeling (Part 11)
Logical Data Modeling (Part 10)
In The Spotlight
 Jim  Sinur
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.