Techniques for extracting operational ontologies and data models from a well formed concept ontology (explanatory ontology). This deck includes an overview and taxonomy of different styles of ontology. Takes an example of a real world mortgage risk semantics issue and shows how a concept ontology would set out the appropriate distinctions in meanings of similar data. Then goes on to describe 2 techniques for managing this process: 1. Squashing (telescoping): data ontology has all locally defined properties for what were inherited properties in the concept ontology; 2. Squeezing (concertinaing): data ontology has fewer, simpler properties representing a longer path across blank nodes in concept ontology. Also shows how these may be rendered in conventional data model versus OWL application ontology as a data model.

1. Squashing and Squeezing:
Extracting Operational ontologies (and data
models) from Concept Ontology
A Semantic Shed Explanatory Deck
April 2024

2. Overview Framework:
Concept v Data Ontologies

3. Ontology Referents: Real World
The Language
Interface
Business
Technology
OWL Serialization of DL Model
OWL is a serialization of Description Logic
• Referent is things in the real world
Concept Level
Physical level (data)
DL Model
represents
Things in the World
Strictly: What we believe exists
Logical (design) level
represents
Serialize
RDF Instance data
(Knowledge Graph)
represents

4. Ontology Referents: RDF Data
The Language
Interface
Business
Technology
OWL Serialization of DL Model
Concept Level
Physical level (data)
DL Model
represents
Things in the World
Strictly: What we believe exists
represents
Logical (design) level
represents
Serialize
OWL accompanies instance data
Referent switches:
• from real world referent
• to data representing those things
RDF Instance data
(Knowledge Graph)

5. Introduce a Data Ontology
The Language
Interface
Business
Technology
OWL Serialization of DL Model
How useful is this ontology as a KB schema?
• Needs datatypes
• Some real things may not be reflected in
the data world at all
• D
• Data
Concept Ontology
Data
DL Model
represents
Data Ontology
represents
Serialize
Things in the World
Strictly: What we believe exists
Conceptual Data Ontology
RDF Instance data
(Knowledge Graph)

6. Introduce a Data Ontology
The Language
Interface
Business
Technology
OWL Serialization of DL Model
How useful is this ontology as a KB schema?
• Needs datatypes
• Some real things may not be reflected in
the data world at all
• D
• Data
Concept Ontology
Data
DL Model
represents
Data Ontology
represents
Serialize
Things in the World
Strictly: What we believe exists
Conceptual Data Ontology
RDF Instance data
(Knowledge Graph)
Can also think of this as a
“Semantic Data Model”

7. Add Datatypes for RDF Data
The Language
Interface
Business
Technology
OWL Serialization of DL Model
Conceptual Data Ontology:
• Add RDF/XML datatypes
• D
• Data
Concept Ontology
Data
DL Model
represents
Data Ontology
represents
Serialize
Things in the World
Strictly: What we believe exists
Conceptual Data Ontology
Datatypes
Triple store data
RDF Instance data
(Knowledge Graph)

8. Conceptual Data Ontology
Add Data Surrogates for non-Data Items
The Language
Interface
Business
Technology
OWL Serialization of DL Model
Some real things may not be reflected in
the data world at all
• Add Data surrogates
• D
• Data
Concept Ontology
Data
DL Model
Datatypes
Data
Surrogates
represents
Data Ontology
Includes data surrogates
Triple store data
represents
Serialize
Things in the World
Strictly: What we believe exists
RDF Instance data
(Knowledge Graph)

9. Ontology Types and Styles

10. Concept v Data Ontologies
Ontology
Concept
Ontology
Data
Ontology

11. Reference v Application Ontologies
Reference
requirement
Use Case
To be the kind of thing
that has a use case is to
be an application!
Reference
Ontology
Application
Ontology
Ontology
Concept
Ontology
Data
Ontology
Use Concept Ontology
as a point of reference
for business meanings
AKA
Explanatory
Ontology

12. Conceptual Data Ontology
Ontology
Concept
Ontology
Data
Ontology
Conceptual
Data
Ontology
Inferencing
Application
Ontology
Mapping
requirement
Knowledge
Graph
requirement

13. Reasoning / Inference Processing Ontology
Ontology
Concept
Ontology
Data
Ontology
Conceptual
Data
Ontology
Inferencing
Application
Ontology

14. Mapped Data
Taxonomy of Ontologies
Ontology
Concept
Ontology
Data
Ontology
Conceptual
Data
Ontology
Inferencing
Application
Ontology
Knowledge Graph RDF App Data
Mapped Data
Mapped Data

15. Operational Ontology Extraction

16. Extraction and Design Techniques
• We will look at two techniques:
• Squashing (Telescoping)
• Applicable to any Concept v Data ontology transformation
• Squeezing (Concertinaing)
• more applicable to application ontology than to data-facing KG Schema / Conceptual
Data Ontology
• Application considerations:
• Need to extract and simplify from the conceptual representation of things, to
what’s appropriate for data processing
• No need for Top Level Ontology (TLO) in application ontology
• Use Ontology Design Patterns (ODP) in place of direct inheritance from TLO

17. A Tale of Two Post Codes
• There’s a story that’s told…
• About a bank with a book of mortgage loans.
• They wanted to see if there was any concentration risk in the
mortgage portfolio
• So they looked at the addresses:

18. Risk Concentration: Apparent

19. But that wasn’t the full story
• Most of these mortgages were for second homes
• The addresses they were looking at were for the borrowers.
• Here’s where the houses were…

20. Risk Concentration: Actual

21. Story2

22. Oops!
• There was a semantic distinction to be made between two things:
• The risk represented by the borrower’s address
• The risk represented by the homes used as mortgage collateral
• These are two different meanings
• So we put these in an ontology (for real world meanings)

23. The Problem
• There are multiple uses of the concept of “conventional street
address”
• Each use has a different meaning
• The address of a mortgage borrower (e.g., living in New York)
• The address of the collateral (e.g., in Florida)
• Each use is defined by a unique path from Mortgage

24. Telescoping
Inherited properties
property a
property b
property c
property d
Class A
property e
property f
Class B
property g
property h
property j
Class C
property k
Class D Distinguishing feature(s)
• Concept Model / Ontology
has mandatory properties at
each level where they apply

25. Telescoping
• Concept Model / Ontology
has mandatory properties at
each level where they apply
property a
property b
property c
property d
Class A
property e
property f
Class B
property g
property h
property j
Class C
Class D
property k

26. Telescoping
• Concept Model / Ontology has mandatory properties at each level where they apply
• For data model we want one class with all the (inherited) properties and other
expressions (restrictions etc.)
• So we want to ‘squash’ (telescope) the hierarchy, retaining cardinalities as appropriate
property a
property b
property c
property d
Class D
property e
property f
property g
property h
property j
property k

27. Squashing

28. Squashing

29. Squeezing: Concertina Effect
• Concept Model has lots of high-level distinctions:
• Things in themselves versus things in roles (e.g. collateral, party)
• Geographical versus geophysical
• Things versus records / data about things
• Etc.
• We need to squeeze these together as needed for a given data model
Class Class Class Class
property property property

30. Squeezing: Concertina Effect
• Concept Model has lots of high-level distinctions:
• Things in themselves versus things in roles (e.g. collateral, party)
• Geographical versus geophysical
• Things versus records / data about things
• Etc.
• We need to squeeze these together as needed for a given data model
Class Class
property

31. Squeezing: The Multi-Path Problem
Loan Borrower Address
Collateral Address

32. Path to Mortgage Loan Borrower Address
Loan Borrower Address

33. Mortgage Loan Borrower Address Definition
Credit: Jim Logan

34. Mortgage Loan Borrower Address Refinement
• In description logic:
• ‘Mortgage Loan Borrower Address’ ≡ ‘conventional street address’ ⊓ ∃‘has
residence’-.(‘legally competent natural person’ ⊓ ∃’has identity’-.(‘borrower’
⊓ ∃’has borrower’-.’Mortgage Loan Contract’))
• In description logic, after naming inverse properties:
• ‘Mortgage Loan Borrower Address’ ≡ ‘conventional street address’ ⊓
∃‘residence of’.(‘legally competent natural person’ ⊓ ∃’identity
of’.(‘borrower’ ⊓ ∃’borrower in’.’Mortgage Loan Contract’))
• In plain English:
• exactly a conventional street address that is the residence of exactly some
legally competent natural person that is the identity of exactly some borrower
that is the borrower in a mortgage loan contract
• In a CCM diagram (next slide)
Credit: Jim Logan

35. Mortgage Loan Borrower Address: Option One
• Same namespace
Credit: Jim Logan

36. Mortgage Loan Borrower Address: Option Two
Mortgage Loan Contract Conventional
Street Address
Thing has borrower primary residence address
on property
must be some
• Option Two: Operational Ontology in separate namespace

37. Borrower Risk
Information
(Data) Model

38. Path to Collateral Address
Collateral Address

39. Collateral Address Definition
Credit: Jim Logan

40. Collateral Address Refinement
• In description logic:
• 'Collateral Address' ≡ 'conventional street address' ⊓ ∃'has address'-.('real
estate' ⊓ ∃'has identity'-.(Real Estate Collateral ⊓ ∃'is collateralized by'-
.('Mortgage Loan Contract’)))
• In description logic, after naming inverse properties:
• 'Collateral Address' ≡ 'conventional street address' ⊓ ∃'address of'.('real
estate' ⊓ ∃'identity of'.(Real Estate Collateral ⊓ ∃'collateralizes'.('Mortgage
Loan Contract’)))
• In plain English:
• exactly a conventional street address that is the address of exactly some real
estate that is the identity of exactly some real estate collateral that
collateralizes a mortgage loan contract
• In a CCM diagram (next slide)
Credit: Jim Logan

41. Collateral Address: Option One
• Same namespace
Credit: Jim Logan

42. Collateral Address: Option Two
Mortgage Loan Contract Physical Address
Thing has collateral address
on property
may only be
Conventional Street
Address
• Option Two: Operational Ontology in separate namespace

43. Collateral Risk Information (Data) Model

44. Summary: Squashing and Squeezing
Credit: Jim Logan

45. Thank you!
The Semantic Shed
www.semanticshed.org
© The Semantic Shed, 2024
© The Carmarthen Group Ltd, 2024