Semantic Modeling Notation (Scanlon, SemTech 2010)

Semantic Modeling
Notation
Making Ontologies Human-Accessible
Bob Scanlon, SVP Development

25 Jun 2010
V2, 30 Jun 2010

We have this.. We want this..

Ontology

Or this...

We'll talk about 2 aspects of this problem:

1. Visualization techniques/considerations

2. Reference graphical notation
22

Why are we talking about this?

● Visualization is critical to understanding complex things
“a picture is worth 1000 words”

● Ontologies are complex things

⇒ Visualization is critical to understanding ontologies

“I have an ontology, what do I have?”
“I want an ontology, how do I build one?”

23

and...
● We have a contract with the U.S. Department of
Defense (DoD) to
– build domain models using RDF & OWL
– integrate data from many sources using a
SPARQL-based federation engine and rules
– analyze & report on the federated data
● in terms of the domain model
● So, we and our customers need ontology
visualization, and we're building it
– but we'd really prefer it be a generally-accepted
standard, so we can focus on data integration
and analysis
24

The BPMN analogy
● Helped drive uptake of BPM

● Goal: intuitive notation that can represent
complex semantics

● Goal: to support both business stakeholders
and technical users

Business analysts
Technical users

2005 2010
25

Why not UML?
● Non-intuitive and verbose representation*
– BPMN also went with a non-UML solution
● Not flexible enough to handle ontologies
– First-class properties vs embedded attributes
– Complex relationships of OWL axioms
– Types and instances mixed
● General-purpose, so it's complex*
– Only need structural representation
– Stereotyping, profiles – not widely used*
● UML tools expensive, not integrated w/ semantic tools

* For non-techs. Our goal is to lift ontology visualization beyond the realm of only
technical ontologists – to enable business analysts, as was done with BPMN.
26

Visualization research
2
OWL2UML/OWLGrEd,
DLG [2005]
2
OntoTrack [2005] Protege [2010]

OntoVis, Protege [2007] OWLVis, Protege [2005] OWLPropViz, Protege [2008]

Growl [~2006] EzOWL [2006] Jambalaya, Protege [2009]

27

Uses of visualization
● Collaboration during model development
– Between ontologists and domain SME's
● Documentation and dissemination of models
– For users, managers, etc
● Basic understanding of the domain
– For everyone!
● Building and editing of a model
– For ontologists and domain SME's

All of these deal with communication!
29

The human element
● An ontology is
– an engineering artifact
– a social agreement

● Therefore it must
– be human understandable
– facilitate communication and collaboration
– be buildable by non-technical people

● To do this we need
– pictures!

30

Target humans...
● Model definers
– Ontologists
– Domain SME's
● Managers / Governance Parties
– To understand a domain
– To approve of changes to domain representation
● Application developers
– To write queries and views
– To understand the terms and relationships in the domain
● Domain users
– To analyze data in their domain
– Using applications written in terms of the model

31

Enabling and facilitating

communication
between ontologists and SME's

is critical

for a successful modeling effort.

32

So, to restate our goal today...

We're interested in a ('standardized') way to

visualize the structural aspects of ontologies

to facilitate

ontology modeling and human understanding

33

Ontology Visualization

34

Visualization

=
Element
Display
Structure
+
Layout

+ Viewing &
Navigation

35

Visualization

=
Element
Display
Structure
+
Layout

+ Viewing &
Navigation

36

Diagram element display
● How should each ontology construct be
represented?
– graphical notation introduction

● How can we abstract and simplify using
clustering/collapsing of elements?
– show properties under classes & instances
– show properties as labeled edges rather than
nodes
– collapse complex nodes until user drills in

37

Benefits of a (standardized)
graphical notation
● Uniform means of representing an ontology in
all tools
– Makes exchange of information between
systems 'flow' better – interoperability
● Formalizes how people visualize models
– Ties into language better, which allows...
● A means to graphically edit models
– More intuitive than editing text representations
– Dovetails with the whole 'collaborative modeling'
idea
38

General requirements
of a graphical notation
● Concise – minimal 'footprint', maximal info/sq in
● Complete – OWL 2, OWL 1, RDF/S, RDF
● Consistent – representations in different diagrams
and contexts
● Simple – to use; uncluttered; hand-drawable
● Extensible – can be used for other ontology
languages, or as core set evolve
● Intuitive – matches what people “expect”
● Multi-modal – can auto-gen diagrams or manually
build custom views NOTE: Last item added based on audience feedback.
NOTE: Last item added based on audience feedback.
39

Map of the (owl 2) universe
Concepts/Categories Roles/Relations Instances Data types
(individuals, (data ranges,
(classes) (properties)
literals) datatypes)

Simple named class
named class named object property
named object property named individual
named named datatype
named datatype
Expressions named data property
named data property anonymous individual
anonymous individual
(defined via declarations)
(defined via declarations) literal value
value
enumeration
enumeration inverse (anonymous)
inverse (anonymous) enumeration
enumeration
Boolean compositions
Boolean compositions Boolean compositions
Boolean compositions
Complex - intersection
- intersection - intersection
- intersection
Expressions - union
- union - union
- union
- complement
- complement - complement
- complement
(defined via Restrictions (obj,data)
Restrictions Restrictions
Restrictions
constructors) - universal, existential
- universal, existential - datatype restriction
- datatype restriction
- value, local reflexivity
- value, reflexivity
- cardinality (qualified)
- cardinality (qualified)
TBox RBox ABox TBox ?
Class relationships
Class relationships domain, range
domain, range class (rdf:type)
class datatype definition
datatype
- subclass
subclass Property relationships
Property relationships Instance equality
Instance equality
- equivalent classes
equivalent classes - subproperty [chained]
- subproperty [chained] - same individuals
same individuals
Axioms - disjoint classes - equivalent properties - different individuals
disjoint classes - equivalent properties different individuals
- disjoint union
disjoint union - disjoint properties
- disjoint properties Property assertions
Property
(defined via key - inverse (obj only)
- inverse (obj only) - object property, pos
object property, pos
statements) Object property char.
Object property char. - data property, pos
data property, pos
- functional, inverse func. - object property, neg
- functional, inverse func. object property, neg
- symmetric, asymmetric - data property, neg
- symmetric, asymmetric data property, neg
- reflexive, irreflexive
- reflexive, irreflexive
- transitive
- transitive
40

Visualization techniques
diagram element generation

Formal language model OWL 2, in this case

To graphical notation
Translate

'Direct' representation Verbose

May use 'identity' abstraction –
Abstract get formal representation

Abstract representation Concise

41

Graphical notation overview
notation primitives
Expressions
Expressions Expression Composite Expression
Decorators Operators
resource object operator
data
relation i annotation

complex
instance
! deprecated

Statements Special
Axiom Connectors
and Decorations ontology
n-ary
definition
binary

(decorators) unary
42

examples of entities & literals
Primitive Base
Examples Notes
Construct Shape
Person
Object (class) decorator is
Class Person label = “Person”
optional.
fname

xsd:int Type information for literal
Datatype xsd:int
values.
minInclusive = 5

Fred
Object (individual) decorator is
Individual “value” Fred rdf:type = Person
optional.
fname = “Fred”

Data values, which may be tied
Literal “green” “10”^^xsd:int
to datatypes.

hasParent Property that has an individual
Object hasParent (object) as its range. Object
Property label=”parent”
property indicator is optional.

Data hasColor Property that has a datatype as
hasColor
Property label=”color” its range.

MyOnt
Ontology htpp:/revelytix.com/vocab/mydomain/

43

composite expression operators

Composite Expression restrictions
Operators
∀ universal
operator
∃ existential

϶ value
set composites Ι intersection
U
intersection =n exact cardinality
U union ≤n max cardinality
¬ complement ≥n min cardinality

enumerations
{} enumeration

44

axiom connectors & decorators
Axiom Connectors
n-ary axiom connectors

n-ary ↔ equivalent

∅ disjoint
binary
binary axioms ∅U disjoint union
(decorators) unary a
class assertion Κ key
pname property
assertion (+) = individual equality
unary axioms pname property
≠ individual inequality
f functional assertion (-)
f inverse functional inverse props.
D
symmetric property domain
R
asymmetric property range

transitive
reflexive
irreflexive 45

representation of complex classes
● Two types of complex class expressions
– composites – nested arbitrarily deep
● Set constructors
● Restrictions
– enumerations
● Always anonymous (except when we use abstraction)
● Decorated to indicate 'complex'
c1
U
a:Anne c1 c2
U
{} b:Beau c2
c3
c:Chuck
U c4
c5

46

Visualization techniques
information overload management
● Information hiding (static or interactive)
– collapse/expand complex class, abstractions
– hide/show neighborhood properties
– allow user to manually build custom model
● Abstraction (static or interactive)
– allow 'interning' of properties under
class/instance
● De-cluttering (static or interactive)
– allow for duplicates of same construct
– use rdfs:labels or local names in place of IRIs
when available NOTE: Additions made based on audience feedback.
NOTE: Additions made based on audience feedback.
47

Multiple forms to manage info overload
class details

Decorators to expand and contract
to expand and contract
shown only on-screen, on mouse
over.
over.

Person Person label and/or IRI

i label “Person” [en]
metadata (annotations)
i label “Persona” [sp]

asAddress
birthDate 'interned' properties
ssn

collapsed expanded

48

Abstraction to manage info overload
interned properties

“externed” properties “interned” properties

hasAddress
Address Person
birthDate hasAddress
Person xsd:date
birthDate
ssn ssn
my:ssn

49

User interaction to manage info overload
interning/externing of properties

Person Person
i label “Person” [en] i label “Person” [en]
hasAddress
i label “Persona” [sp] i label “Persona” [sp]
Address
hasAddress birthDate
birthDate ssn drag property in
(“intern”)
ssn

Person Person
i label “Person” [en] i label “Person” [en]
hasAddress
i label “Persona” [sp] i label “Persona” [sp]
Address
hasAddress birthDate
birthDate drag property out ssn
ssn (“extern”)

50

Abstraction to achieve simplification
class inheritance relationships

Animal

Animal

subclass
is-a

Person
Person

51

Abstraction to achieve simplification
class-property relationships
Formal

Person rdfs:domain hasAddress rdfs:range Address

Abstraction 1
R Property
D
Person hasAddress Address or class
diagram

Abstraction 2
hasAddress Class
Person Address diagram

Abstraction 3
Person Class
('interned') hasAddress diagram
52

Diagram constructs for
defining abstractions/simplifications

diagram expression 1

diagram diagram
expression expression
1 2
diagram expression 2

Similar to substitution mechanism in
Wang, Xiaoshu and Almeida, Jonas S., Techniques for Ontology Visualization, Chapter 9
in Semantic Web: Revolutionizing Knowledge Discovery in the Life Sciences, 2007

53

Diagram expression equivalence

Class
Class

rdf:type
is-a

Class
Class

54


Class
Class

rdf:type a

Individual
Instance

55

property domain → labeled edge

Person rdfs:domain hasAddress

Property view

D
Person hasAddress

56

property domain & range → labeled edge

D R
Person hasAddress Address

Class view

hasAddress
Person Address

57

named-anonymous equivalent type merging
ABC

ABC
↔ A
U B
A C

U B
C
Class view

my:smallnum
my:smallnum

↔ base = xsd:int
mMaxInclusive = 20

xsd:int
mMaxInclusive = 20
Type view
58

Visualization

=
Element
Display
Structure
+
Layout

+ Viewing &
Navigation

59

Presenting ontology structure
● Directed labeled graphs (DLG)
We're interested in
– layered hierarchical graphs this
– 'neighborhood' graph

● Layout accounts for:
– Hierarchical nature of terms
– 1-M nature of class-property relations

● Some other considerations:
– Cloning constructs to reduce link tangles
– Incremental adjustments when user adds to,
removes from, or shifts items on diagram
60

Composition of a diagram
● A diagram consists
of views
View 3.1
View ● Views composable
View 1 ● Views have different
'types', which
influence layout, etc
- class
View 3
- property
- instance
View 3.2
View
- class-instance
View 2
-

61

View types

Properties
View Type Classes
(1st Class)
st Instances Inheritance

Class View √
Property View √
Class Inheritance View √ √
Property Inheritance View √ √
Class-Instance View √ √
Instance View ~ √

62

Layout considerations
● Type inheritance –
Inheritance
lay out vertically
● Type relationships
lay out horizontally is-a

● Type-instance relationships A
lay out types vertically, with
is-a is-a
instances horizontally
B C
● Instance graphs
not in scope

63

Visualization

=
Element
Display
Structure
+
Layout

+ Viewing &
Navigation

64

User interaction / navigation
How can these diagrams be used?

Presentation “you know what is there”

Analysis “you know what you are
looking for”
Discovery “you have no idea what you
are looking for”

Ref: Bergeron 1993.

65

Information management
(on a diagram being viewed)
● Show/hide details
● Show/hide inheritance
● Show/hide related properties
– By type, etc
● Show inferred vs asserted axioms
● Filtering – to remove non-essential features
● Highlighting – to focus on essential features, in
context
● Faceted search
● Navigation – changing context
66

Viewing & navigation techniques
● Zooming
– geometric
– fish-eye – graph remains intact
● Filtering – selective display of info
– type-based
– depth-based
– attribute-based

67

Graphical Notation
Reference

68

General requirements
of a graphical notation

● Concise
● Complete
● Consistent
● Simple
● Extensible
● Intuitive
● Multi-modal
69

Graphical notation
overview of notation primitives
Expressions
Expressions Expression Composite Expression
Decorators Operators
resource object operator
data
relation i annotation

complex
instance
! deprecated

Statements Special
Axiom Connectors
and Decorations ontology
n-ary
definition
binary

(decorators) unary
70

Graphical Notation
expressions

Diagram 'Object' 'Data'
Represents... Notes
Shape Representation Representation

Schema-level,
Type
all views

Schema-level,
Property
property views

Data-level,
Instances
type views

These are the building blocks for composite expressions and axioms.

Object-Data decorators optional; lack of decorator always means 'Object' unless context
denotes otherwise. 71

Class expressions
enumeration and set expressions

Class Connector /
Examples OWL 2 Functional-Style Syntax
Expression Decorator

a:Anne
enumeration {} {} b:Beau ObjectOneOf(a1...an)
c:Chuck

c1
intersection U U
c2 ObjectIntersectionOf(C1...Cn)
c3

c1
union U U c2 ObjectUnionOf(C1...Cn)
c3

c1
complement ¬ ¬ c2 ObjectComplementOf(C1...Cn)
c3

72

Class expressions
general property restrictions

Restriction Connectors Examples OWL 2 Functional-Style Syntax

p1 ObjectAllValuesFrom(P C)
universal ∀ ∀ DataAllValuesFrom(R1...Rn D)

p1 ObjectSomeValuesFrom(P C)
existential ∃ ∃
∃ xsd:int
xsd:int DataSomeValuesFrom(R1...Rn D)

value p1 ObjectHasValue(P a)
(individual, literal) ϶ ϶ 7^^xsd:int DataHasValue(R v)

local reflexivity Ι Ι p1 ObjectHasSelf(P)

73

Class expressions
cardinality property restrictions
Connector /
Restriction Examples OWL 2 Functional-Style Syntax
Decorator
ObjectExactCardinality(n P)
exact cardinality =n =5 p1
DataExactCardinality(n R)

p1 ObjectExactCardinality(n P C)
qualified cardinality =n =5
DataExactCardinality(n R D)

ObjectMaxCardinality(n P)
maximum cardinality ≤n ≤2 p1 DataMaxCardinality(n R)

qualified maximum p1 ObjectMaxCardinality(n P C)
cardinality ≤n ≤2
∃ xsd:int DataMaxCardinality(n R D)
xsd:int

ObjectMinCardinality(n P)
minimum cardinality ≥n ≥1 p1
DataMinCardinality(n R)

qualified minimum p1 ObjectMinCardinality(n P C)
cardinality ≥n ≥1 DataMinCardinality(n R D)

Note: for convenience, single, simple cardinality NOTE: Audience question – do we have an example of a 'simplified'
NOTE: Audience question – do we have an example of a 'simplified'
restrictions will be displayed as decorations restriction representation? – Not here, but there was some in our
restriction representation? – Not here, but there was some in our
beneath the restriction representation. prototypes up-front.
prototypes up-front. 74

Property expressions
object property expressions

Property
Decoration Examples OWL 2 Functional-Style Syntax
Expression

inverse [p]
[ ] c1 c2 ObjectInverseOf(P)
(anonymous)

There is only a single property expression, for defining an anonymous property as an
inverse of an existing property. This must be on a Class Representation View.
75

Data range expressions
Data Range Decorator/
Expression Connector

literal “7”^^xsd:int
{} {} DataOneOf(v1...vn)
enumeration “11“^^xsd:int

data range U xsd:integer
DataIntersectionOf(D1...Dn)
U
intersection xsd:int

data range xsd:float
U U DataUnionOf(D1...Dn)
union xsd:double

data range
complement ¬ ¬ xsd:int DataComplementOf(D)

datatype xsd:int
(none) DatatypeRestriction(DN f1 v1...fn vn)
restriction minInclusive = 5

These axioms define how properties are related to Classes. They must be on a Property
Representation View.
76

Class axioms TBox

'class-to-class' relationships
Class Decorator/
Characteristic Connector

is-a
subclass is-a c1 c2 SubClassOf(C1,C2)

c1
equivalent class ↔ ↔ c2 EquivalentClasses(C1…Cn)
c3

c1

disjoint classes ∅ ∅ c2 DisjointClasses(C1…Cn)
c3

cn c1
disjoint union ∅U ∅U c2 DisjointUnionOf(CN C1...Cn)
c3

These axioms are all relate two (or more) Classes to each other. They are applicable only
on a Class Representation View.
77

Class axioms TBox?

class keys
Feature Connector Examples OWL 2 Functional-Style Syntax

p1
Κ
key Κ C1 HasKey(C (P1...Pm) (D1...Dn))
p2
Κ
p3

NOTE: Audience feedback – try to stay away from using letters that tie the notation to the English
Language, and may not be meaningful in all international locales.

This axiom defines the object and/or data properties that are the keys for a Class. It is
applicable on any of: Class, Property, and Data Range Views.

78

Property axioms RBox

'property-to-class' relationships

Property
Axiom

D ObjectPropertyDomain(P,C)
domain D p1 c1 DataPropertyDomain(D,C)

R ObjectPropertyRange(P,C)
range R p1 c1
DataPropertyRange(D,C)


These axioms relate a Property to a Class. A Property can have more than 1 domain or
can domain or
range. These are applicable only on a Property View.

79


'property-to-property' relationships
Property Decoration/
Axiom Connector
is-a
p1 p2
SubObjectPropertyOf(P1,P2)
subproperty is-a
p1 type SubDataPropertyOf(P1,D2)
p2

p1
equivalent EquivalentObjectProperties(P1…Pn)
properties ↔ ↔ p2
EquivalentDataProperties(D1...Dn)
p3

p1
disjoint DisjointObjectProperties(P1…Pn)
properties ∅ ∅ p2
DisjointDataProperties(D1...Dn)
p3

p1
inverse p2
inverseOf InverseObjectProperties(P1,P2)
properties p1 p2

These axioms are all relate two (or more) Properties to each other. They are applicable
only on a Property view. 80


property 'characteristics' (unary)
Property
Characteristic
f f FunctionalObjectProperty(P)
functional f p1 p1
FunctionalDataProperty(P)
f f
inverse functional f p1 p1
InverseFunctionalObjectProperty(P)

symmetric p1 p1 SymmetricObjectProperty(P)

asymmetric p1 p1
AsymmetricObjectProperty(P)

transitive p1 p1
TransitiveObjectProperty(P)

reflexive p1 p1 ReflexiveObjectProperty(P)

irreflexive p1 p1
IrreflexiveObjectProperty(P)

These axioms define characteristics of properties. They are all unary 'operators'.
They are realized as decorations on a Property construct, on a Property view, or
optionally as decorators on a binary relation on a Class view.. 81

Datatype definition axioms

Property OWL 2 Functional-Style
Decoration Examples
Characteristic Syntax

my:smallnum
my:smallnum
my:smallnum
my:smallnum

↔ base = xsd:int
base = xsd:int
datatype definition ↔ DatatypeDefinition(DN D)
maxInclusive=20
maxInclusive=20
xsd:int
xsd:int
maxInclusive=20
maxInclusive=20

There is only 1 axiom related to datatypes. This axiom can be used to define a new named
datatype in terms of an existing datatype with additional facet restrictions. This must
be on a type-level diagram – either a Class diagram or a Datatype diagram.
82

Assertion axioms ABox

(axioms about instances)
Assertion Decoration Examples OWL 2 Functional-Style Syntax

a a
class (type) a1 c1 ClassAssertion(C a)

pname ObjectPropertyAssertion((PN a1 a2)
property assertion pname a1 a2 DataPropertyAssertion(R a v)

negative pname pname NegativeObjectPropertyAssertion((PN a1 a2)
NegativeObjectPropertyAssertion((PN a1 a2)
property assertion a1 a2 NegativeDataPropertyAssertion(R a v)
NegativeDataPropertyAssertion(R a v)

a1
Individual equality = = SameIndividual(a1...an)
a2

a1
Individual inequality ≠ ≠ DifferentIndividuals(a1...an)
a2

These axioms are all related to instances. The class (type) and property assertions
are the common RDF-style axioms. These all must be on either a Class view or an
Instance view.
83

Annotations

Not shown for now...

84

Key takeaways
● Visualization is critical to

– Collaborative ontology development
– Communication & understanding
– The widespread adoption of OWL

● The community needs to get behind

– A formal graphical notation

86

References
Select visualization papers
● Wang, Xiaoshu and Almeida, Jonas S.; Techniques for Ontology
Visualization; Chapter 9 in Semantic Web: Revolutionizing
Knowledge Discovery in the Life Sciences; 2007.
● Krivov, Serguei, et al; On Visualization of OWL Ontologies;
Chapter 10 in Semantic Web: Revolutionizing Knowledge
Discovery in the Life Sciences; 2007.
● Katifori, Akrivi, et al; Ontology Visualization Methods – A Survey;
ACM Computing Surveys; 2007.
● Gaines, Brian R.; An Interactive Visual Language for Term
Subsumption Languages; IJCAI 1991.
● Bergeron, D.; Visualization Reference Models; 1993.

87

References
UML-related papers
● Brockmans, S., et al; Visual Modeling of OWL DL Ontologies
Using UML; ISWC, 2004.
● Kiko, K. and Atkinson, C.; A Detailed Comparison of UML and
OWL; 2008.
● Xu, Wei, et al; Modelling emergency response processes:
Comparative study on OWL and UML; 2008.
● Harel, D. and Rumpe, B.; Meaningful Modeling: What's the
Semantics of “Semantics”?; 2004.

88

Thank you for your time and attention! 89

Semantic Modeling
Notation
Bob Scanlon
[ svp development, rscanlon @ revelytix.com ]

Jim Irwin
[ svp development, jirwin @ revelytix.com ]

SemTech, 25 June 2010
90

Semantic Modeling Notation (Scanlon, SemTech 2010)

More Related Content

Similar to Semantic Modeling Notation (Scanlon, SemTech 2010)

Recently uploaded

Semantic Modeling Notation (Scanlon, SemTech 2010)