Understanding the semantics landscape

Understanding the
Semantics Landscape:
Kinds of Ontology and their
Applications
Mike Bennett
Hypercube Ltd.
At Open Financial Data Group
19 October 2018
Hypercube Ltd.
© Hypercube Ltd. 2018

Outline
• Rationale for ontology (FIBO)
• Introducing The Semantic Web
• Observations on kinds of ontology
• A unified view of ontologies
• Conceptual to Operational Ontology
• Ontology Applications
• Summary / Recommendations

Ontology Motivations (FIBO)
3

4
?
?
?
?
?

5
Common ontology
Shared business meanings

6
Common ontology
Validated by business

7
Common ontology
Validated by business
Expressed
logically

8
Model Positioning
Conceptual Model
Logical Model (PIM)
Physical Model (PSM)
Realise
Implement

9
Model Positioning
Conceptual Model
Logical Model (PIM)
Physical Model (PSM)
Realise
Implement
The Language Interface
Business
Technology

What is an Ontology?
• An ontology is a representation of real things using
formal logic
10

Defining a Kind of Thing
Some kind
of thing
• We start with some kind of thing
11

Defining a Kind of Thing
Some kind
of thing
• We ask just two questions about this kind of thing:
• What kind of thing is it?
• What distinguishes it from other things?
12

What kind of thing is it?
Animal
Vertebrate Invertebrate
Bird Mammal Fish
Waterfowl
Some kind
of thing
13

What distinguishes it from other
things?
Animal
Bird Mammal Fish
Waterfowl
Some kind
of thing
Walks like a duck
Swims like a duck
Quacks like a duck
14

It’s a Duck!
Animal
Bird Mammal Fish
Waterfowl
Walks like a duck
Swims like a duck
Quacks like a duck
15

For Every Kind of Thing
• Taxonomy
• Taxonomies form the backbone of ontologies
• A taxonomy is simply a classification scheme
• For this we need to explore classification theory
• Ontology
• Ontologies add properties to formally distinguish
concepts in a taxonomy
• The use of Restrictions in Semantic Web ontologies
refine this further by defining necessary membership
conditions for a class of Thing

17
This is not a more abstract
model of the solution…
Conceptual Ontology
Logical Data Model (PIM)
Physical Data Model (PSM)
Realise
Implement
Business
Technology

18
This is not a more abstract
model of the solution…
Conceptual Ontology
Logical Data Model (PIM)
Physical Data Model (PSM)
Realise
Implement
Business
Technology
It’s a concrete model
of the problem!

The Semantic Web

Introducing the Semantic Web
• Web Ontology Language (OWL):
• Triples (Subject – predicate – Object)
• Model Formalism: First Order Logic
• UMLCMP (SMIF), OntoUML, OWL, ODM
• Model Theory (semiotics):
• What the items in the model represent: Concepts
– Conceptualization of real world things
– Legal, accounting etc.
20

Subject-predicate-Object
Subject Object
predicate

Subject-predicate-Object
Subject Object
predicate
This is a class of “Thing”
Defined in set theoretic terms
This is formal assertion
(like a verb)
This may be another class of “Thing”
or it may be a basic type e.g. number

Classification
Thing Thing
predicate
Thing
Classes of thing are classified
according to what type of thing they areIs a

Triples
Thing Thing
predicate
Thing
All of these assertions are called “Triples”
and are stored in some kind of “Triple store”

Features of the Semantic Web
• Data storage
• Triple store
• Resource Definition Framework (RDF)
• URIs for each node and edge
• Editing tools
• Protégé
• TopBraid Composer
• UML-based tools with RDF/OWL serialization (CCM, VOM)
• OntoUML tooling
• Reasoning / Inference processing
• Pellet, Hermit, TrOWL, RacerPro
• stand-alone or as Protégé plugins
• Semantic querying: SPARQL

Inference Processing: Asserted Relations
26

Inference Processing: Inferred Relations
27

Observations on kinds of ontology

Conceptual Ontology Example

Application Ontology
• We don’t want all that stuff in the ontology
• It slows down the reasoner
• We don’t need all those abstractions
• There is no data for all those abstract things
• We don’t need to return reasoning results about those
abstract things
• By ‘abstract’ here you really mean concrete
• Data is abstract
• So what goes in an application ontology for
reasoners?

Application Ontology Example
Suitable for
‘Operational
ontology’

Example:
Trajectory
Ontology
(Mike Dean)
32

Deep and Shallow Ontologies
Deep classification hierarchy of types of thing
in the world, with relationships and sufficient
logic to disambiguate
33

Self-contained classes, properties
and logical statements corresponding
to some set of things in the world
34

Deep classification hierarchy of types of thing
in the world, with relationships and sufficient
logic to disambiguate
35
Self-contained classes, properties
and logical statements corresponding
to some set of things in the world

Shallow: Correspondence
• Graph has logical relations between elements
• These correspond to the relations between things in reality
• Automated reasoning checks the “deductive closure” of the
graph for consistency and completeness

Correspondence Theory Semantics
• The more detailed logic there is in the application ontology, the
more confident we can be that it reflects only one set of things
and their relation in reality
• Like a crossword solution
• This allows for stand-alone ontologies to do very powerful
processing of knowledge in an application
• This is not incompatible with the techniques described for
conceptual ontology modelling – IFF it is done right!
• However, some techniques which are appropriate for stand-alone
operational ontologies would not be compatible with a
conceptual enterprise ontology
• Decide whether to have application and conceptual ontologies in
separate namespaces, or satisfy both sets of requirements in one
namespace
38

Two Approaches to Ontology
Development
• Approach 1: For a given concept, identify a suitable
word, then look up the definition in a well-
established English Language dictionary, and take this
definition as representing the concept
• Add assertions (properties) as required
• Approach 2: In order to support a given set of
industry-specific concepts, imaginatively arrive at a
high level abstract concept of which that and other
concepts are specializations.
• Hunt for a suitable word or words which reasonably
reflect the meaning of that abstraction.

Two Approaches to Ontology
Development
• Approach 1: For a given concept, identify a suitable
word, then look up the definition in a well-
established English Language dictionary, and take this
definition as representing the concept
• Add assertions (properties) as required
• Approach 2: In order to support a given set of
industry-specific concepts, imaginatively arrive at a
high level abstract concept of which that and other
concepts are specializations.
• Hunt for a suitable word or words which reasonably
reflect the meaning of that abstraction.
Please don’t do this

OWL Datatype Properties
Business Conceptual
Ontology (CIM)
Operational Ontology
(PSM)
Extract and Optimise
Business
Technology

OWL Datatype Properties
Business Conceptual
Ontology (CIM)
Operational Ontology
(PSM)
Extract and Optimise
Business
Technology
Data
types
Data
types
Platform specific matter
• An OWL ontology plus data seems to be a physical design artifact
• Uses datatype properties for dates, numbers etc.
• This is appropriate for data
• RDF is data!
• However, concept modeling should NOT use datatype properties
• Except where the real thing is and only is some computational data
• Identify ‘kinds’ of information e.g. names, dates, numbers as things
• Can still use OWL but without datatype properties

Data for Application Ontologies
• OWL ontologies use a restricted sub-set of the XML
datatypes set
• These are chosen in line with operational constraints on reasoner
applications
• These constraints have no place in a conceptual ontology
• We need to translate real world kinds of information into
OWL XML datatypes for any onward processing in
operational ontology applications
• Also a conceptual ontology must be presented to the
business for validation in their own terms
• Business folks do not know about technical datatypes
• They officially don’t care!
• Conceptual (Reference) ontology should reflect the kinds of
information qua information, in the world

Information Kinds
• Names
• Textual material
• Dates and Times
• Yes or No (or maybe)
• Numbers
• Whole numbers, Numbers with decimal places, Fractions, Percentages…
• URL
• Pictures
• Sounds
• Words
• Letters
• And many more…

Datatypes
• Text
• Restricted text
• Unrestricted text
• Dates and Times
• Boolean
• Numeric datatypes
• Integer
• Float
• Positive integer, positive float
• URL/URI
• Other information kinds are rendered in files, for example
vector graphics, rich text, video and sound formats

Reference v Application Ontology
Reference Ontology
• Used as an authoritative
source for concepts
• Used across applications
• Represents the real things
• Grounded in
foundationally primitive
concepts
Application Ontology
• Built to support a particular
application (use case)
• Reuse general properties
wherever possible
• Each model construct
corresponds to some data
• Create concepts directly or
through inference
• Minimal foundational ‘glue’

Upper ontologies
• Overview
• Partitions v Dimensionality
• Relative Things (qua entities)
• Time sensitive things
• General UO choices
• Other partitions
• Information construct
• Dispositions, other philosophical stuff we probably don’t
need

Partitioning
• In general there seem to be 2 things to consider
with top level ontologies:
• How the world (the domain of discourse) is divided up:
Partitions
• How these concepts are framed: Dimensionality
• 4D v3D / 3D+
• Endurantism v perdurantism
• Mereology (parts and wholes)
• Dimensions, values, quantities
• etc.

Ontological Stance
• Consider the ontological stance of the upper ontology
• Possible stances (not exhaustive)
• Realist: the ontology only represents things that have some
extension in some real or possible world
• Idealist: Ontology must be able to represent concepts whether or
not these have physical or temporal extent
• For risk, business planning, commitments etc. concepts are
essential
• Risk event is avoided in any world in which it is a risk event
• Plans, commitments, Prescriptive processes etc.
• Realism includes social constructs (they are real)

A unified view of ontologies

Semantic Technology may be the Next Steps in
the Evolution of Information Management
51
XML Schema (2001)
weak semantics
strong semantics
XML (1997)
Semantic Web Languages
RDF/RDFS/OWL (2004)
* Ontology Spectrum courtesy of Dr. Leo Obrst, The Mitre Corporation
The power of an information
management paradigm
depends upon the intelligence
and expressive power of its
underlying conceptual model
or schema
Evolving Semantic
Technologies e.g. FLORA-2
(2013+)
Relational Model (1970)
Relational Schema (1976)

Dimensions of a Model
52
Formalism
Application
Model Theoretic Relation
(grounding)
MODEL
e.g. First Order Logic
e.g. Business domain
(business process etc.)
e.g. Messaging Level

The Semiotic Triangle (Peirce)
Concepts
Signs Real World
Objects
53

Concepts
Diagram: Jim Odell
54

Extension as a Happening
55
Concept
ExtensionIntension
Extends
Intends

A Semiotic Rhombus
Extensions
Signs Real World
Objects
Intensions
Concepts
56

Things Information
Type A set specification for a kind of
Independent Thing that
generalizes all towers (e.g., “a
tall narrow structure”)
A set specification for a kind of
Dependent Continuant that is a
record structure containing tower
observations (e.g., a “TOWER”
table or a “#Tower” class)
Member A member of zero or more sets
of all towers (E.g., the actual one
we call the “Eiffel Tower”)
A member of one or more sets of
record structures containing tower
observations (E.g., one that
represents the actual Eiffel Tower)
“#tower123”Represents
Introducing Data
Jim Logan, NoMagic

Data: The T Box
58
Things the
data is about
Data-focused
ExtensionsData-centric
Intensions
about
represents

Data Delta
59
Things the
data is about
Data-focused
Extensions
about
represents
ẟD

Data Delta: ẟ => 0
60
Things the
data is about
about
represents
ẟD => 0

Truth Makers versus Data
• Meaning of Bank: framed in terms of legal capabilities and rights
• The capacity to take on funds
• The capacity to disburse funds
• Data surrogates for this
• Incorrect data surrogate: FDIC insurance
• Data surrogate: banking license
• Legal Person
• Has capacity: liability capacity
• No data surrogate for that
• Real meaning – by definition mostly does not rely on data!
• Physical things (I was not born in a string)
• Social Constructs (see Searle)
• There are some other things that are only data
• This is if the thing originates on a computer
61

Conceptual to Operational ontology
• What to retain in Operational ontology
• Data Surrogates
• What to exclude in operational ontology
• What to add in operational ontology
• Implicit model content
• Other techniques and transformations

Operational Ontologies: What to
Exclude
• Items generally excluded from operational ontology (based
on FIBO transformations)
• Upper ontology partitioning
• Occurrents
• Process
• Information artifact
• Names as a kind of thing
• Social Constructs (Searle)
• But should these really be excluded?
• The next few slides will explore these and other questions
• In many cases, specific examples of these kinds of thing are
included but not the over-arching framework within which
they are classified conceptually
• E.g. PartyInRole, LegalCapacity, IdentificationScheme

Retaining Concepts
• When to retain something in operational (data
focused) ontology
• Is there a data surrogate for this conceptual notion?
• Is there a use case for reasoning to return this data?
• Including sub classes / properties

Data Surrogates Principles
• Identify data surrogate for real thing (truth maker)
• Look for signatures in data that imply the presence of
real world, identifying matter
• Frame the necessary conditions for membership of a
class (in a logical ontology) in terms of what would be
found (true) in data when the class of thing is there
• Inference as distinct from meaning in the original sense
• From the data you can infer that a thing exists in reality

Operational ontologies: Additions
• Restriction ‘cascades’
• Use of anonymous unions
• Unions are anonymous in OWL anyway
• Concept models in OWL use equivalent class for these
• Concepts that are the ‘equivalent class’ to some unions
may not be needed in OO
• Reuse of very general properties
• Property characteristics
• These should also be included in conceptual ontology
where possible

Property Reuse
• Conceptual Ontology:
• Define properties with domain and range
• Many of these domains and ranges require very abstract classes to
capture the necessary domain and range of the property
• Introduce sub properties where these have known business
meaning (name and definition)
• Operational Ontology
• Define properties with minimal or no domain and range
• Use restrictions even where the restriction has some business
meaning
• Hazard: sometimes properties are re-used with more than
one meaning (called ‘polysemy’),
• The same word is used for more than one concept and is reused
without regard to semantics

Reasoning and Classification
• Operational ontology
• Does not need to include model content that can be inferred
by the reasoner
• Do not include class hierarchy relations that may be inferred
• Do not include inverse properties – these are implicit except
where property type excludes them (symmetric)
• Conceptual ontology
• Intended to reflect business understanding of subject matter
• Include any defined concept whether not it is implicit in the
rest of the model
• Explicit inverse properties where given
• Explicit sub class relations

Other Operational Ontology Choices
• Relative Things
• Conflate thing-in-role with thing-in-itself
• Transform the corresponding property chain to single property
• Classification Facets
• Choose one monohierarchical facet as appropriate for the use case
• Datatypes
• Replace values / information kinds with datatypes
• Names and other Information Artifacts
• Replace names with strings
• Dates
• Use of ‘Date’ as a thing versus date datatype
• Can some of this be automated to return use case
perspective specific operational ontology graphs?

Other Treatments
• Model Theoretic Treatment
• See Nehmer and Bennett 2018
• Defines formal model parameters for Conceptual
and Operational ontologies
• Defines transformation between these
• Basis for individual techniques such as those
described above

Deployment Choices
• Ontology has many applications
• Different considerations for different uses
• Conceptual Model
• Represent the things in the world
• Truth makers include social constructs etc.
• Operational ontology
• Use case driven
• Represents data about the things
• Correspondence semantics rather than foundational
• Conceptual data ontology
• Reflects all the nuances of things in the world to
accommodate full range of data model semantics
• Represents data (use data surrogates)

Virtual Ontology
Reporting
R2RML based Ontology to Legacy Database Adapters
Semantic Queries
Risk, Compliance etc.
Reference ontology
Legacy Data Sources and Systems

Virtual Ontology
Reporting
R2RML based Ontology to Legacy Database Adapters
Semantic Queries
Risk, Compliance etc.
Reference ontology
Legacy Data Sources and Systems
Data focused Ontology
Foundational semantics

Semantic Web Applications
Swap1001
Leg 1 Leg
2
10000000
notional notional
LIBOR 3.5%
Fixed Float IR Swap
LEI5001 LEI7777
Trader LLCAcme Inc
identifies
identifies
USD
currency
Interest Rate Swap
74
10000000
USD
currency
Swap
FloatingRateLeg
Inferred
Leg1 is inferred to be a
FloatingRateLeg because
any leg tied to an index is
semantically defined as
floating
Inferred
FixedRateLeg
Inferred
FixedRateLeg because any
leg tied to an interest rate
is semantically defined as
fixed
LEI LEI
Business EntityBusiness Entity
Swap is inferred to be a
Fixed-Float IR Swap
because one leg was
inferred to be fixed and one
leg was inferred to be
floating fulfilling the
definitions in the ontology
Inferred
Data for an undefined Swap
Contract before semantic
reasoning performs
classification and
identification
type type
type
type
An interest rate swap in which
fixed interest payments on the
notional are exchanged for
floating interest payments.
Human Facing Definition
Swap_Contract and
hasLeg FixedRateLeg and
hasLeg FloatingRateLeg
Machine Facing Definition
Fixed Float IR Swap (Ontology)
Semantic reasoning
Semantic reasoning
Semantic reasoning1 2
3
isTradingWith
isTradingWith is a new
property relationship that is
inferred based on a
semantic rule and can be
queried
Semantic reasoning4
fixedRateindex
• Semantic Operational Processing Reasons over Data to Infer
Classifications and Relationships
David Newman, Wells Fargo

Semantic Web Applications
Swap1001
Leg 1 Leg
2
10000000
notional notional
LIBOR 3.5%
Fixed Float IR Swap
LEI5001 LEI7777
Trader LLCAcme Inc
identifies
identifies
USD
currency
Interest Rate Swap
75
10000000
USD
currency
Swap
FloatingRateLeg
Inferred
FloatingRateLeg because
any leg tied to an index is
semantically defined as
floating
Inferred
FixedRateLeg
Inferred
FixedRateLeg because any
leg tied to an interest rate
is semantically defined as
fixed
LEI LEI
Business EntityBusiness Entity
Swap is inferred to be a
Fixed-Float IR Swap
because one leg was
inferred to be fixed and one
leg was inferred to be
floating fulfilling the
definitions in the ontology
Inferred
Data for an undefined Swap
Contract before semantic
reasoning performs
classification and
identification
type type
type
type
An interest rate swap in which
fixed interest payments on the
notional are exchanged for
floating interest payments.
Human Facing Definition
Swap_Contract and
hasLeg FixedRateLeg and
hasLeg FloatingRateLeg
Machine Facing Definition
Fixed Float IR Swap (Ontology)
Semantic reasoning
Semantic reasoning
Semantic reasoning1 2
3
isTradingWith
isTradingWith is a new
property relationship that is
inferred based on a
semantic rule and can be
queried
Semantic reasoning4
fixedRateindex
• Data focused Ontology
• Internal Consistency
semantics (reasoning)

Regulatory Reporting Current State
76
FORMS FORMS
REPORTING ENTITY REGULATORY AUTHORITY
Reports (forms)
?

Regulatory Reporting Current State
77
FORMS FORMS
Reports (forms)
?
Uncertainty
• Content of the reports
• Are we comparing like with like?
• Data quality and provenance
Change in Reporting requirements =
• Redevelopment effort
• By each reporting entity
• For each system and form

Regulatory Reporting with Semantics
78
Thing
IR Swap CDS Bond
Contract
Common
ontology
Thing
IR Swap CDS Bond
Contract
Granular
data
Common
ontology
Data is mapped from each system of record into
a common ontology
Reported as standardized, granular data
Agnostic to changes in forms
Receives standardized, granular data aligned with
standard ontology (FIBO)
Uses semantic queries (SPARQL) to assemble
information
Changes to forms need not require re-
engineering by reporting entities
!
Ontology

Regulatory Reporting with Semantics
79
Thing
IR Swap CDS Bond
Contract
Common
ontology
Thing
IR Swap CDS Bond
Contract
Granular
data
Common
ontology
Data is mapped from each system of record into
a common ontology
Reported as standardized, granular data
Agnostic to changes in forms
Receives standardized, granular data aligned with
standard ontology (FIBO)
Uses semantic queries (SPARQL) to assemble
information
Changes to forms need not require re-
engineering by reporting entities
!
Ontology
Data focused Ontology
Foundational semantics

Ontology for Blockchain

Ontology for Blockchain
• Conceptual Ontology (legal)
• Foundational semantics• Physical API

Rationalizing Physical Data
The Ontology makes implicit contexts explicit. It provides contextual semantics, distinguishing concepts specific to relationships, historical records (e.g. loan
applications), current information for entities, and others. This is independent of the deployment benefits of semantic technology.
UPPER ONTOLOGY
Current
date
Contexts: Role / Relationship Records / history etc.
Address
Entity Data
Customer ID
Purchase history
Contact Phone
Customer ID
Drawdown date
Payment history
Customer ID
Purchase date
Country of collateral
First name
Family name
Current Credit rating
Date of Birth
Home Phone
Country of Birth
Address Line 1
..
Address line n
City
State
Country
Full name
Customer ID
Purchase date
Application Credit rating
Phone
Address Line 1
…
City
Country of Domicile
Relationship
(context) specific data
Records: Loan
application data
Independent entity
data
Non context specific data
becomes real-time entity data
Ontology provides the context
for each kind of data
Purchase
date
Time

Rationalizing Physical Data
The Ontology makes implicit contexts explicit. It provides contextual semantics, distinguishing concepts specific to relationships, historical records (e.g. loan
applications), current information for entities, and others. This is independent of the deployment benefits of semantic technology.
UPPER ONTOLOGY
Current
date
Contexts: Role / Relationship Records / history etc.
Address
Entity Data
Customer ID
Purchase history
Contact Phone
Customer ID
Drawdown date
Payment history
Customer ID
Purchase date
Country of collateral
First name
Family name
Current Credit rating
Date of Birth
Home Phone
Country of Birth
Address Line 1
..
Address line n
City
State
Country
Full name
Customer ID
Purchase date
Application Credit rating
Phone
Address Line 1
…
City
Country of Domicile
Relationship
(context) specific data
Records: Loan
application data
Independent entity
data
Non context specific data
becomes real-time entity data
Ontology provides the context
for each kind of data
Purchase
date
Time
• Conceptual Upper Ontology
• Foundational semantics

Summary / Recommendations
• Ontology as Conceptual Model
• May be in OWL or other forms
• The logic is what matters
• Represent real things in the world
• Semantic Web application ontology
• Separate artefact
• Focus on available data
• Derive from conceptual ontology (basic MDA)
• Understand and maintain the different kinds of
ontology model

This is a new discipline
• Points of reference include
• Knowledge Representation
• Applied Ontology
• Cognitive Science
• Artificial Intelligence
• Library science
• Skills and knowledge required:
• Language
• Philosophy
• Formal Logic
• System architecture
• If this seems a little artsy that’s because it is!

Thank you!
• Mike Bennett
• Director, Hypercube Ltd.
• Semantics Lead, EDM Council
• www.hypercube.co.uk
• Email: mbennett@hypercube.co.uk
• Twitter: @MikeHypercube

Understanding the semantics landscape

Recommandé

Recommandé

Contenu connexe

Similaire à Understanding the semantics landscape

Similaire à Understanding the semantics landscape (20)

Dernier

Dernier (20)

Understanding the semantics landscape

Notes de l'éditeur