Ontology-Driven Information Systems: Past, Present and Future

Preview:

DESCRIPTION

This was a keynote talk given at the Formal Ontology in Information Systems conference in Saarbrücken, Germany in October 2008. We trace the roots of ontology-drive information systems back to early work in artificial intelligence and software engineering. We examine the lofty goals of the Knowledge-Based Software Assistant project from the 80s, and pose some questions. Why didn't it work? What do we have today instead? What is on the horizon? We examine two critical ideas in software engineering: raising the level of abstraction, and the use of formal methods. We examine several other key technologies and show how they paved the way for today's ontology-driven information systems (ODIS). We identify two companies with surprising capabilities that are on the bleeding edge of today's ODIS, and are pointing the way to a bright future. In that future, application development will be opened up to the masses, who will require no computer science background. People will create models in visual environments and the models will be the applications, self-documenting and executing as they are being built. Neither humans nor computers will be writing application code. Most functionality will be created by reusing and combining pre-coded functionality. All application software will be ontology-driven.

Citation preview

Ontology-Driven

Information Systems

Dr. Michael Uschold Originally given as Invited Talk: FOIS Conference

Presented on November 1, 2008

Past, Present and Future

My Background

Current

– Independent Consultant

Recent past: Media

– Internet advertising services

– Intelligent content provision

In a former life...

– Aerospace & Defense

– Supporting the Enterprise

2

What are Ontology-Driven Information Systems?

Just what it says!

Ontology-driven, not just ontology-inspired or just used in software engineering process (e.g. MDA)

[Ontology-Driven] Information System ontology not just small component in large system.

3

Who Cares and Why?

WHO?

Software developers, customers and end users

WHY:

Less coding,

More modeling

More Reuse

Faster

development Reduced costs

Reduced

maintenance

Agility &

Flexibility More functionality

4

Is there anything new?

YES

Cooperation across independent communities

Commercial maturity

and NO:

The core ideas are quite old

NB: the core ideas evolved independently.

5

Is ODIS just an Idea?

•It was for a long time…

•… then we saw significant research prototypes

•Now we are seeing commercial deployments.

6

What is the Future of ODIS?

•IS = Ontology-Driven IS

•Computing = Semantic Computing

•Seamlessly integrated [semantic] development platforms

–ontology development and reasoning

–application functionality and GUI

–transactional DB with versioning

–all under one hood, federated and distributed

7

Outline

Historical Roots

Today’s Bleeding Edge

The Future

8

Where did ODIS Come From?

Evolution of ongoing search for better software tools.

Two key ideas in software engineering:

1. Raise the level of abstraction

2. Use of formal methods and structure

Abstraction

9

Raising the level of Abstraction

Machine code

Assembly languages

‘Higher level languages’: – FORTRAN, COBOL

Object-oriented programming – Simula, Smalltalk

Logic Programming

Model-Driven [software] Development

Ontology-Driven Information Systems

10

Permeates almost everything in software engineering

Foundation for many subfields and communities

More on this later…

Formal Methods and Structure

11

Readings in AI and SE (1986)

Deductive Synthesis

Program Verification

Transformational Approaches

Natural Language Specifications

Very High Level Languages

AI Programming

One very influential paper/project:

Knowledge-Based Software Assistant

Programming by Example

Intelligent Assistants

Programming Tutors

Programming Knowledge

Domain Knowledge

12

A Grand Vision: KBSA (1986-1992)

“This annual conference provides a forum for exchanging technical and managerial views on ... developing a

knowledge-based life cycle paradigm for large software projects, the

Knowledge Based Software Assistant. ...

Software developed using the KBSA is expected to be more responsive to changing

requirements, more reliable, and more revisable than software

produced using current practices. The KBSA will improve software practices by providing machine-

mediated support to decision makers, formalizing the

processes associated with software development and project

management, and providing a corporate memory for projects. The

KBSA will utilize artificial intelligence, automatic

programming, knowledge-based engineering, and

software environment technology to achieve the [project] goal[s].”

13

Themes, Ideas, Features and Trends

Role of the models: design time vs. runtime

– Requirements analysis

– Drive parts of the application

– Drive the whole application

Evolution of Models and Applications

– Models left alone, while application evolves

– Models and application evolve in lock step

15

Themes, Ideas, Features and Trends

Code

– Human- vs. machine-generated (in what proportion?)

– Generated from models vs. executing directly from model

SE Environments:

– general vs. domain-specific - for programmers only vs. for non-programmers

16

Themes, Ideas, Features and Trends

Developers Users Developers Users

Distinction between user vs. developer

– crisp vs. Blurred

Use of formal methods

17

Major Subfields and Communities

1. Domain modeling

2. Knowledge representation and reasoning

3. Automatic programming & Executable specifications

4. Model-driven software development

5. Semantic technology (ontologies and the semantic web)

18

Domain Modelling

Explicit models of the domain of the software application.

Early Work: LaSSIE

– Reverse engineered a domain model (using DL)

– Link to code

– Benefits: • Improve software comprehension

• Increase agility

• Reduce maintenance costs

Need to forward engineer the models!

19

Knowledge Representation and Reasoning

Long history in AI

Supports many phases of SE lifecycle

– Requirements elicitation

– Checking design consistency

– Intelligent program analysis

– Program planners

– Proving correctness of code

– Generating code

20

Major Subfields and Communities

1. Domain modeling

2. Knowledge representation and reasoning

3. Automatic programming & Executable specifications

4. Model-driven software sevelopment

5. Semantic technology (ontologies and the semantic web)

21

Automatic Programming

GOAL: Avoid human coding

Very hard problem

Technology is mature today

– Theorem proving for generating large schedules

– Avionics software

Sometimes human still in the loop

Strong use of formal methods, sometimes driven from a formal model/ontology. (e.g. category theory)

22

GOAL: Avoid human coding

Very hard problem

Technology is mature today

– Theorem proving for generating large schedules

– Avionics software

Sometimes human still in the loop

Strong use of formal methods, sometimes driven from a formal model/ontology. (e.g. category theory)

Automatic Programming

23

Executable Specifications

Logic Programming

– Write “code” that looked like a domain model plus rules.

– Specification = Program

– A radical idea!

Like automatic programming, but …

– no code generation step,

– the specification executes directly. (executing vs.. executable)

Tight link between model and application.

Clocksin/Mellish

25

Declarative Specification of Problem (WHAT)

Add Data & Ask Question

Inference engine figures out HOW.

Example Logic Program

26

descend(X,Z):- child(X,Z). child(anna,bridget).

descend(X,Z):- child(X,Y), descend(Y,Z). child(bridget,caroline).

child(caroline,donna).

child(donna,emily).

Software Development by Non-Programmers

Tools are close to domain expert’s way of thinking.

Forward engineered models

Visual environments: – elements have pre-coded functionality.

– function calls generated automatically

Programming without even knowing it.

For specialized domains

Mix: automatic programming & executable specifications

27

Visual Programming With AMPHION

A planetary scientist draws diagrams that are close to their own way of thinking to

specify the objects relationships and functions to get the desired results.

Components on the diagram and their relationships specify the requirements that

are automatically complied into FORTRAN code. The final program largely

consists of calls to pre-coded subroutine. The diagram is an executable model; this

is ‘model programming’ for a narrow domain of applications. Courtesy of NASA.

28

Major Subfields and Communities

1. Domain modeling

2. Knowledge representation and reasoning

3. Automatic programming & Executable specifications

4. Model-driven software development

5. Semantic technology (ontologies and the semantic web)

29

Model-Driven Software Development

Models are basis for software development

Raises level of abstraction above code

Most common today: Model Driven Architecture (MDA)

30

Model-Driven Architecture

Platform Independent Model (PIM) specifies functionality of application.

PIM transformed into platform specific models that are much closer to code.

UML: most widely used MDA language 3 uses:

– Sketch preliminary designs

– Blueprint for grand design

– Model programming (model is executable)

31

Model Programming

Executable specification, where the specification is a model.

Explicit link to end software Potential for large maintenance savings

– UNLESS: only generate stub code

e.g. AMPHION

32

MDD / MDA In Practice

Active standards group: OMG

Significant use in industry

Far from mainstream

UML lacked a formal semantics originally just a ‘diagramming notation’.

OMG meets the Semantic Web

33

Major Subfields and Communities

1. Domain modeling

2. Knowledge representation and reasoning

3. Automatic programming & Executable specifications

4. Model-driven software development

5. Semantic technology (ontologies and the semantic web)

34

Semantic Technology

Separate community emerged, separate from SE and OMG/UML communities

Roots in AI / KR / Ontologies and W3C

Not concerned with software engineering in general

Concerned with how to engineer software that uses ontologies and inference.

A solution looking for a problem.

35

ST: Solution looking for a Problem

ST community searched and searched

Build more and more ontologies and more and more tools

36

Then Everything Changed (circa 2000)

Explosion of commercial interest and deployments began as a trickle around 2000.

Around 2006, more and more reports of actual benefits.

Mostly software engineering benefits that users don’t care about.

Surprise: reported benefits same as predicted

39

UML vs. Ontologies / Semantic Web

Two separate communities

Overlap: modeling languages and goals

40

Model-Driven evolving to Ontology-Driven

Communities coming together

41

Outline

Historical Roots

Today’s Bleeding Edge

The Future

42

Ontology-Driven IS Coming of Age

Progress accelerating

Transitioning to industry

Not just toy problems

Low hanging fruit:

– Map mashups and ontology driven forms

– True ontology-driven functionality

Bleeding Edge:

– putting it all together

– almost …

43

Ontology-Driven Map Mashups

A local geolocation ontology is used as a data model for storing lat/long coordinates for various locations. The local ontology is linked to a public geolocation ontology (with namespace ‘geo’) that drives public mapping tools. This enables locations from several datasets to be placed on the same map. Figure courtesy of TopQuadrant.

44

Ontology-driven Forms: Simple / Elegant

Change the ontology, or change the data, and the interface changes automatically

Customers love it.

Ontology-driven application functionality, not just used at design time.

“The rich declarative semantics of ontological data models can be exploited to drive user interfaces and to control an applications behavior” [Top Quadrant]”

45

User vs. Developer Distinction Blurs

Application functionality w/o writing code. ‘Programming’ without even knowing it

Users can be their own developers, if right hooks are in place.

Everyday examples: – Personalized portals (iGoogle and many others)

– Excel applications

Known state of the art:

– only possible for isolated pieces of functionality,

– not for fully general application development.

46

User vs. Developer Distinction Blurs

Application functionality w/o writing code. ‘Programming’ without even knowing it

Users can be their own developers, if right hooks are in place.

Everyday examples: – Personalized portals (iGoogle and many others)

– Excel applications

UNknown state of the art: (with some caveats)

– YES: possible for whole applications

– YES: general application development

47

Breakthrough Capabilities Recently Announced

Application development w/o writing much code.

Majority of application is model-driven

Integrated frameworks leveraging open standards

General purpose environments

Delivering mature commercial-scale software

SURPRISE: from Industry, not Academia!

Mission Critical IT

Visual Knowledge

48

Mission Critical IT - ODASE

The most advanced ontology-driven software development environment with code-generation

"ODASE [is] an ontology-driven development approach and

platform, which cleanly separates the Business Domain

knowledge (at the description level) from the Software Engineering

knowledge (at the execution level). The process for transferring the Business knowledge

from the ontology to the programming language is by automatic generation of

source code. The power of ODASE is that the model specification, the

code generation, and the runtime reasoning use the same

formal description. [21]."

49

Ontology Driven Software Engineering

Formal ontology as requirements contract with business users

Convert to logical/functional

programming language (Mercury)

50

Logic-driven automatic code

generation

Clean Separation of Business & Software Levels

Business Level

Domain Experts Knowledge Engineers

OWL, SWRL, Petri Nets

51

Software Level

Add software knowledge to ontology executable spec

Code generation

ODASE™ Breakthroughs

52

Ontology and program evolve in lock step

Ontology as formal requirements contract; part of the program source code

When requirements change: the ontology changes and new code is generated

Ontology is long term reusable business asset

Based on standards

Implementation-independent

ODASE™ Breakthroughs

53

Majority of code is automatically generated (70%)

Warranty on the code

Unified formal declarative approach: model definition, code generation and run-time reasoning

Dramatic cost savings in development & maintenance

General purpose development environment

Visual Knowledge

Fully driven by ontologies and metamodels

Visual Tools – no code for normal application development

Application development functionality exposed through a Wiki

54

Visual Application Development

55

Visual Knowledge

18 years of engineering

Industrial strength ontology-driven solutions in numerous business sectors

– Finance

– Energy

– Biomedical

– 3D Computer Games

BUT: currently only being used in house…

56

How Far have we Come?

Role of the models: design time vs. runtime

– Requirements analysis

– Drive parts of the application

– Drive the whole application

Evolution of Models and Applications

– Models left alone, while application evolves (loose coupling)

– Models and application evolve in lock step (tight coupling)

57

How Far have we Come?

Code

– Human- vs. machine-generated (in what proportion?)

– Generated from models vs. executing directly from model

SE Environments:

– general vs. domain-specific

– for programmers only vs. for non-programmers

Distinction between user vs. developer

– crisp vs. blurred

Use of formal methods

58

Challenges Ahead

Scale, Scale and Scale

Mostly limited in generality

Complex architectures, too many pieces

Can ontologies drive whole applications?

Application development for the masses

How far can formal methods take us?

59

Outline

Historical Roots

Today’s Bleeding Edge

The Future

60

Currently

Have you seen any fully functional general purpose application development environments that have any of the following characteristics:

Fully visual ?

Fully agent-based ?

Fully model-driven ?

Fully ontology-driven and declarative ?

61

Giant Networks of Context-Aware Agents

Formal and declarative “down to the metal”

Ecosystems of intelligent context-aware “semantic agents” representing:

– Models / Ontologies

– Algorithms

– User interfaces

– Data

– Any other functionality

Applications will be manifest as giant networks of such agents residing in transactional stores.

63

Domain Modeling Functionality

64

Agent

Domain agent

owl:Class

rdf:Class

subClassOf

Person

instanceOf

subClassOf

subClassOf NicolaGuarino

papersAuthored

hasProperty

Foaf:Knows

instanceOf

MichaelGruninger

PatHayes

User Interface Functionality

65

Agent

GUI agent

Form

rdf:Class

subClassOf

Foaf

Form

hasComponents

checkBox1

hasProperty

Foaf:Knows

text23

textInput2

checkBox1

menu73 listOfOptions

parameter21 actionToExecute

subClassOf

subClassOf

Programming Logic Functionality

66

Agent

Behavior agent

Loop

Loop o’er

attendees

eachAttendee

incomingSet

FOIS

Attendees

Email-FOIS-

Announcement

subClassOf

subClassOf

instanceOf

instanceOf

Loop over

Submitted Papers

All Linked Together

67

All Linked Together

68

In a transactional store

Executing Ontologies / Models

Models will be executing as they are being built. – No code-generation, compile, debug cycle

– dramatic speed up

Key functionality will be pre-coded.

Choose and relate existing functionality modules

AMPHION approach generalized

69

Visual Application Development

Unlocks elusive potential of visual environments – Experts can go fast

– The code runs fast

Visual debuggers

Dramatic productivity speed up

User vs. Developer distinction blurs

Application development for the masses.

Crowd-sourced applications!

70

Semantic Computing -- Challenges

Complex system architectures, nothing integrates with anything.

Ontology versioning and evolution.

Ontology-based data stores with full complement of reasoning, do not scale.

71

Semantic Computing: the Future

Agent Ecosystems replace complex architectures with modules and engines etc.

Seamlessly integrated semantic development platforms

– ontology development and reasoning

– application functionality and GUI

– transactional DB with versioning

– all under one hood, federated and distributed

Computing = Semantic Computing

72

Versioning: The Future

Versioning Solved What does that mean exactly?

When elements of an ontology change, the corresponding agents track the changes and ensure sytem integrity.

Extend idea to the whole application, which is also represented by semantic agents.

73

Versioning: The Future

Versioning Solved What does that mean exactly?

Fully transactional stores for each model element, and thus each application element.

Unit of versioning changes

– From coarse grain flat text files with code

– To fine grained semantic agents

74

Scale: The Future

Terabyte and Petabyte sized?

Are there theoretical limits?

Either way, the key is going to be parallization of inferencing algorithms to make use of the multi-core CPUs

75

Summary and Conclusion

ODIS are just starting to have commercial impact

Before too long, they will be mainstream

76

Early software engineering & AI

– Raise level of abstraction

– Use formality and structure

– Domain modeling,

– KR&R

– Automatic programming & executable models

– MDD / MDA

– Semantic technology, ontologies / semantic web

Roots of ODIS

77

The Bleeding Edge

ODASE: Mission Critical IT

Visual Knowledge

Commercial systems

General purpose

Majority of applications are ontology-driven

Majority of application developed w/o writing code

Dramatic speed improvement

Integrated frameworks

78

The Future

1. Applications are manifest as giant networks of semantic agents.

2. Semantic agents are fully version-controlled in transactional store

3. No code generation, models are executing as they are being built.

79

The Future

4. The Application IS the Model / Ontology an executing Model / Ontology

5. Visual Application Development

6. Application Development by the masses

Developers Users

80

4. The Application IS the Model / Ontology an executing Model / Ontology

5. Visual Application Development

6. Application Development by the masses

The Future

Developers Users

81

Acknowledgements

I’m grateful to

Conor Shankey, Reinvent Technology for most of the ideas in the future vision section.

Michel Vanden Bossche, Mission Critical IT for introducing me to ODASE and sharing his slides.

Dean Allamange at TopQuadrant for sharing his thoughts and slides on ontology-driven software.

And Google Images!!!

84

85

c/o Google Images

References

[21] M. Vanden Bossche, Ontology-Driven Software Development for Business-

Critical Enterprise Applications, presented at the 2008 Semantic Technology

Conference, San Jose, CA. http://www.semantic-conference.com/session/586/

86

Recommended