Embed Size (px)
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
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
A Grand Vision: KBSA (1986-1992)
Early concept demo on 1992
Spawned series of conferences – KBSA
– ASE
Extremely influential
BUT: today, is still largely a vision
14
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
ST Solution, looking for a Problem
A dozen years later, still searching for commercial impact.
Main output:
– Long lists of potential benefits
– Lots of research prototypes
37
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
In the Future
Application development environments that have all of those characteristics.
Agents are critical to get the necessary intelligence & flexibility for tomorrow’s systems.
62
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
7. Scale Scale & Scale
The Future
82
7. Scale Scale & Scale
The Future
83
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
