Semantic Modeling for Information Federation describes the UML profile and methodology for conceptual modeling and using conceptual reference models for federation and integration of information, systems and organizations. This presentation contains both an introduction and detail appropriate for experienced architects.

1. Cory Casanave
Copyright © 2017 Model Driven Solutions
Licensed as creative commons, share-alike
https://creativecommons.org/licenses/by-sa/4.0/legalcode

2. To relate different
representations of the
same things, we need to
understand
• What are the
common concepts
• How do the various
information syntaxes
represent those
concepts
• What are the rules
for translating
between them in
various context
Semantic Mediation
Reference
Concepts
Information
Syntax
RepresentsInformation
Syntax
Information
Syntax
Conceptual Model
Mapping Rules
Information Model

3. Leveraging Federated Information
T
Reference
Concepts
Information
Syntax
RepresentsInformation
Syntax
Information
Syntax
Conceptual Model
Mapping Rules
Information Model

4. Modeling Concepts are the meta-concepts we use to build our models
Raising the level of abstraction
Conceptual models need not be limited to computational paradigms
• E.g. OWL-DL is limited by FOL, DL and unary “properties” (no relations)
Examples of modeling concepts (more detail below)
• Context
• First-class n-ary relationships
• Roles and phases
• Temporal friendly “situations” and relationships
Note: Ontology does not mean “OWL-DL”, Ontology is about conception of the world(s).
Note also that the above can be “painted over” OWL and UML with patterns.
High-Level Modeling Concepts

5. • Linked Data
• Ontologies (e.g. OWL)
• Rules
• Traditional DBMS / SQL
• Big Data
• NoSQL
• Traditional APIs and applications (e.g. Java)
• Functional Programming
• ETL / Data Wearhouse
• Publish/Subscribe
• SOA
• Application and web servers
Multiple technologies can be
leveraged, integrated and
combined based on the
same conceptual models
using model driven
architecture
MultipleTechnologies

6. Solution Architecture

7. What are the requirements for
conceptual modeling in support of
federation?

8. Role of the interpreter

9. Retention of meaning across languages, communities and cultures
Communicate what is said without judging, coloring or filtering it
Interpreters have substantial preparation, learning syntax, grammar, vocabulary and
cultural idioms.
Interpreters can only communicate what they understand and what can be understood in
the languages they deal with – the common concepts
They then communicate what other people said based on how those concepts are
expressed in different languages – they communicate the provenance
Interpreters are preforming semantic mediation
What we expect of interpreters
Common
concepts

10. Understandable and precise
Capture, disambiguate and precisely describe
stakeholder concepts such that they can
enable automation.
Represent these concepts so stakeholders can
understand and validate them.

11. Semantic mediation does
• Capture shared concepts, this includes types, relationships, individuals
and other concept kinds
• Define a relationship between patterns of these concepts and patterns of
data representations – it is not a word for word translation
• Respect the context of the concepts and rules
• Maintain the provenance of information
Semantic mediation does not
• Define applications that produce or consume information
• Assert policy about what is “right”, “common” or “legal”
• Structure information for an application perspective
• Filter for “data quality”
Implications for the role of semantic
mediation (conceptual reference models)

12. Conceptual models and mappings, intended for the federation role
• Should use stakeholder relevant terms and concepts presented in an understandable
way
• Should have minimal commitment – only committing to what is necessary to
understand and “map” information. E.g. specific units or data representations
• Should keep application specifics out of the concepts – how the information is
developed is not our concern.
• Should contain both the “most generic” sense of a concept as well as any specialization
required (and named appropriately) for precise communications
• Mappings should be able to be “mixed and matched” with multiple concept modules
based on context
• Should only contain semantics that have a “ROI” for federation.
• E.g. should not be implementing “application rules”, it is up to the “end applications” to enforce
rules prior to mediation
Conclusion: Conceptual models for federation may be a subset of (simpler than) conceptual
models or operational ontologies intended for applications.Their semantics only need
to support the mapping rules for representations.
Implications for SMIF

13. Example from “Operational
threat/risk”

14. Is this a threat actor? (STIX)
STIX is a large XML Schema

15. What is a threat actor? (FBI)
The Federal Bureau of Investigation has identified three categories
of cyber threat actors:
“ [1] organized crime groups that are primarily threatening the
financial services sector, and they are expanding the scope of their
attacks; [2] state sponsors — foreign governments that are
interested in pilfering data, including intellectual property and
research and development data from major manufacturers,
government agencies, and defense contractors; and [3] increasingly
there are terrorist groups who want to impact this country the
same way they did on 9/11 by flying planes into buildings.They are
seeking to use the network to challenge the United States by
looking at critical infrastructure to disrupt or harm the viability of
our way of life.[1]

16. Is this a threat actor?
Threat
Actor?
Our conclusion:Only the “real world” perspective can
provide a pivot point between different representations.
Instances of a conceptual “threat actor” are real threat
actors, not data about them as data is structured for its
application purpose.

17. What is a threat actor? (Threat Model)

18. Data represents concepts
Represents
Model Representation

19. Example of Mapping Pattern (UML
Profile)

20. SMIF Components – conceptual models
and mappings to schema
Conceptual
Modeling UML
Profile
Mapping UML
Profile
Schema ProfileDependsOn MapTo
SMIF Conceptual
Metamodel
Mapping
Metamodel
SMIF Information
Metamodel
DependsOn MapTo
Represents
SMIF Conceptual Meta Model
UML Representation
Represents
Represents

21. As easy as possible for domain stakeholders to understand the models as
diagrams, tables or text
“First class” n-ary relationships that may have properties and participate in other
relationships
Recognition and representation of time and context – most relationships are
only true for a limited time and in specific situations
Roles, phases and other “non rigid” classifications that also may be time or
situationally dependent
Hierarchies of types, relationship types and properties
Business values as represented by various systems of units
Patterns as a basis for real-world situations as well as mapping rules
Note that while some of these features may be difficult for generic FOL
reasoners, they are practical for specific conceptual model and mapping rules
Important conceptual modeling and
mapping capabilities

22. Last years Ontology Summit focused on “Ontologies within Semantic
Interoperability Ecosystems ”. Full document: http://tiny.cc/Ontolog2016
Supports the value proposition of SMIF
• “The United States spent nearly $3.0 trillion on healthcare in 2014 [ . . . ] the efficient
use of health information technology will result in considerable cost savings, in addition
to saving thousands of lives per year”.
Supports the need for capabilities not currently provided, focused on
semantic interoperability
• "More mature conceptual modeling & knowledge engineering tools are required to
support the design, development and storage of ontologies and vocabularies. [ . . .
] these should be integrated into software development and data management tools
that provide support across the IT lifecycle and related operations.“
• "There was broad consensus within the Summit that improved software tools and
environments are required to support the integration of concepts and data."
Ontology Summit: Semantic
Interoperability Communique

23. SMIF Implementation for information
federation, sharing and analytics
Status: PoC
Federation Engine tm

24. Prototype model & semantics
implementation preview
“SMIF Full”
RDF Repository
SMIF
UML Models
SMIF Java API
UML
Facet
Eclipse
UML
Java
Facet
RDF/OWL
Facet
Rules
SW Rules
Facet
SQL
Facet
XML
Facet
“Flat”
Facet
Planned
API Generated
from SMIF
Model
CL/IKL
Facet
Each facet provides an adapter
between external data and a SMIF
counterpart at any meta-level. A
SMIFObject may have multiple
facets.
Mappings & federations are
(conceptually) between SMIF
objects.
Analytics
Implements
SMIF Semantics
as Java code
XMI
Facet

25. Java API for any SMIF model (Including those imported from other sources)
Production of “SMIF Full” RDF/OWL and rules
Bi-directional data mapping – SQL, XML, OWL
Semantic mapping between data repositories
User definable rules in SMIF or Java
Projection to “tabular” data formats for analytics engines
Full support for multiple inheritance and multiple classification
All of the above for FIBO, Concept Library and Threat/Risk
Capabilities (In Progress)

26. Using the SMIF UML profile – one
projection of the SMIF model

27. Entities & Facets Propositions
FoundationalConceptualTools (Meta-Concepts)
Characteristics
Associations (Always true between entities)
Relationships (Independent/Contextual)
Rigid (Entity)Types
Roles
Phases

28. • Reference models are conceptual, information models are application specific
• Multiple inheritance & multiple (instance) classification is required
• A type can have multiple Supertypes
• A thing may have multiple types, these types may change over time and in differing context
• Everything has metadata – source (including derivations), provenance & timeframe
• Things change – time matters (the world is not static or a snapshot)
• E.G. Relationships, situations and characteristics are temporal
• Information is contextual (the world is not first order)
• Statements are not “deleted”, they go in and out of context (Allows functional)
• The world is open, conclusions (computations) are contextual
• Trust in information varies, not everything that can be inferenced should be
• Independence from representation (e.g. schema) and processing technologies
(including inference engines)
• But, we can bind to any of these technologies
Type Based ModelTheory

29. Roles define what something is for or how it behaves in a certain context,
not “what it is”.
A role is a <<Facet Of>> what it can be a role of.
An entity can play any number of roles and these roles may change over
time.
Roles can be contextual and specialize other roles
Roles are usually established by relationships
Roles

30. Phases (or states) are classifications of objects over their lifetime. A
“Relative thing”
Examples: Child,Teenager, Adult or Invoiced, Late, Paid
May be combined with other types using unions and intersection (e.g.
teenage driver)
Phases

31. Relationships are meaningful atomic concepts involving a set of other entities or
relationships. A “Mediating thing”.
There can be any number of related “ends”, but two ends is most common
Relationships are atomic & static “Situations”, the involved ends do not change over
the lifetime of the relationship. The context and “truth value” of the relationship may
change.
Relationships are temporal – exist for a timeframe. The timeframe of a relationship
may or may not match the timeframe of the “ends”
Relationships may be involved in other relationships and may have characteristics
We refer to these independent relationships as “first class” relationships.
Relationships

32. Modeling with first class roles & relationships
(Note that relationships can be temporal
– be “true” only for a time period)

33. Associations are similar to relationships but:
• Not “first class”
• Not temporal – they exist for the lifetime of the related “ends”
• Limited to binary
• Also known as “Formal Relations”
• Map most directly to simple properties (e.g. OWL or Java)
Associations

34. Characteristics are features inherent in another type
Most like “properties” in many languages
Usually have a value type as their range
John has a weight of 60 KG
Characteristics are temporal (have a timeframe) & identifiable
John weighed 60kg on March 3rd, 2011
In conceptual reference models quantity kinds (e.g. Mass) are preferred over
specific units (e.g. kg) or data types (e.g. “Real”) as the types of characteristics
Characteristics

35. Properties encompass the “ends” of associations and relationships, and
characteristics
Like everything else – properties have types (property types) and instances
(called bindings)
Properties can be specialized and restricted
Models typically define property types
Specialized properties may be “virtually derived”, not define a new concept
but restrict an existing one. These have no name or the same name as their
super-property
Property specialization is either a “subset” or redefines (equivalent set)
Specializing properties

36. Subset properties define subtypes of other property types (ends of
associations or relationships, characteristics, etc).
Extent of subset property is a subset of super-property
May tighten constraints – multiplicity, type, etc.
Subset properties

37. Redefined properties define subtypes of other property types (ends of
associations or relationships, characteristics, etc) and replace the super-
property in the given context.
Extent of redefined property is the same as the extent of super-property
May tighten constraints – multiplicity, type, etc.
Redefined Properties
Restriction Example

38. Disjoint defines a set of classifications
that can never be combined in the same
thing.
• e.g. you can’t have a cat/dog
Complete defines that a set of things
can’t have any more members.
Incomplete says there can be more in a
set.
• Certainly there are more kinds of
animals than cats and dogs.
Incomplete and Disjoint
Note: Disjoint may also use a dependency

39. It is essential that we understand what quantities
represent .
For numeric characteristics, we want to know
what it means (e.g.Temperature), not the kind of
number (Real).
<<Quantity Kind>> is an aspect common to
mutually comparable quantities represented by
one or more units.
A “unit value” represents a quantity kind, there
are multiple units representing temperature.
A physical representation would then represent
the unit as some kind of number in a specified
unit.
Quantity Kinds & Units

40. Situations contextualize one or more
propositions – relationships, associations,
characteristics or rules
Situations are “mediating things”
Situations are temporal
Relationships are atomic situations
Situations types / patterns and individuals
may be defined
Situations may be
• Static or dynamic
• Past, present or possible future
Situations

41. Kinds of situations

42. Situations capture “truth” in context (any
such truth is subject to trust and likelihood)

43. Models may be organized into packages (sub-graphs) and reference or assert
other packages
Model Organization

44. Expressions
• Define computations
Patterns
• Define sets of entities and relationships with variables, acts as a type.
• May be asserted for a type or context
• Used as the basis for mapping
• In UML, uses structured classifiers
Rules
• Define constraints or implications for a context. E.g. Multiplicity.
Mapping Rules
• Defines how an information model relates to a conceptual reference model
• Based on pattern matching
• Multiple mappings are combined to federate or translate information
AdditionalCapabilities, not detailed here

45. SMIF provides a framework for defining a semantic model
In the general sense of the word, this is an “Ontology”
Tools can generate ontologies in various languages, such as OWL
As the focus of SMIF is federation and integration, not general inference,
there are some differences
• SMIF allows things some ontology languages do not – context, “second
order” relationships and time.
• It includes higher level concepts such as first-class relationships, roles and
phases
• It does not include some capabilities of first order logic, it does not
provide for general inferencing based on arbitrary expressions
SMIF is a good match for the “semantic web” and linked data
Semantics and SMIF

47. The concept library is defined in and specializes SMIF, it is not
defined as part of SMIF. Concept libraries are open source.
These are candidate concept – refinements and alternatives are
welcome.
https://github.com/ModelDriven/ConceptLibraries/
SMIF
Concept Library
DefinedUsing
Extends
Domain Concept
Models
Extends
Application Model References

48. To facilitate cross domain and cross system interaction, we must have
concepts common across those domains and systems
We know they will be represented differently and may have different
purposes, but we must understand what things mean
We should be reusing concepts rather then building new stovepipes
There will never be “one true” concept set, but we can define concepts for
broad use and acceptance
Concepts are introduced as:
• They are needed in a domain of interest
• They are an abstraction of one or more concepts needed to fully define
another concept
Concept Library Principles

49. TopLevel(AnyLevel)
SMIF

50. Identifiers

51. Values
Meta

52. EntityRelationships

53. SocialAgents

54. Persons

55. PhysicalEntities

56. Places

57. Organizations

58. Time&TemporalThings

59. SituationPartitions

60. SituationInterdependencies

61. Occurrences

62. Process(Base)

63. Containment

64. MoveBetweenContainment

65. Information&InformationActions

66. Control

67. Resource

68. GeopoliticalEntities

69. Corporations

70. Objectives

71. Assessments

72. Policy

73. Quantity Kinds

75. Common Units (2)

76. The above models were done with two “profiles” of
UML.
Profiles specialize UML for a specific purpose.

77. Any UML tool can be used with the SMIF
profile
Our preferred tool is Magicdraw®
The “Concept modeler” can produce and
consume OWL ontologies based on
conceptual models
ModelingTools

78. ConceptualModelProfile

79. SMIF Rules Profile

80. http://www.modeldriven.com
https://github.com/ModelDriven/SIMF/
https://github.com/ModelDriven/ConceptLibraries/
SMIF is an “standard in progress” in the Object Management Group (omg.org)
It is currently being used and implemented