Proactive Future Internet
“Smart Semantic Middleware
for Overlay Architecture”
Resource
Agent
“Device”
Resource
Agent
“Expert”
Resource
Agent
S-APL
University of Jyväskylä
Industrial Ontologies Group
“Service”
Vagan Terziyan
Dmytro Zhovtobrykh
Artem Katasonov
ICNS-2009, Valencia, Spain
22 April, 2009
Web of Humans (Social Web, Web 2.0)
Human
Communities
Facilitates
Human-toHuman
interaction
Web of Things
Machines,
devices,
computers, etc.
Facilitates
Machineto-Machine
interaction
Web of Services
Software and
Services
Facilitates
Softwareto-Software
interaction
Web of Knowledge (Semantic Web, Web 3.0)
Knowledge and
Data Collections
Facilitates
Knowledge-toKnowledge
interaction
Web of Intelligence (Distributed AI, Web 4.0)
Intelligent
Agents and
Applications
Web of intelligent entities
(intelligence services),
browseable, searchable,
composable, selfmanaged, dynamic, mobile
…
Facilitates
Intelligenceto-Intelligence
interaction
GUN Concept
GUN – Global
Understanding
eNvironment
GUN
=
Global Environment
+
Global Understanding
=
Proactive Self-Managed
Semantic Web of
Everything
Global Understanding Environment (GUN)
GUN can be considered as a kind
of Ubiquitous Eco-System for
Ubiquitous Society – the world in
which people and other intelligent
entities (ubiquitous devices,
services, software, organizations,
etc) “live” together and have
equal opportunities (specified by
policies) in mutual understanding,
mutual service provisioning and
mutual usability.
Human-to-Human
Human-to-Machine
Machine-to-Human
Machine-to-Machine
Software-to-Human
Software-to-Machine
Software-to-Software
…
Human-to-Software
Agent-to-Agent
“Semantic Wave” (Web X.0) and GUN
We may add here:
Web 5.0 will come
finally and it is about
connecting models
in a “Global
Understanding
Environment” (GUN),
which will be such
proactive, selfmanaged evolutionary
Semantic Web of
Things, People and
Abstractions where all
kinds of entities can
understand, interact,
serve, develop and
learn from each other.
[Vagan Terziyan]
“The semantic wave embraces four stages of internet growth:
Web 1.0, was about connecting information ...
Web 2.0 is about connecting people.
Web 3.0, is starting now… and it is about … connecting knowledge…
Web 4.0 will come later … and it is about connecting intelligences in a ubiquitous web
where both people and things can reason and communicate together.”
[“Semantic Wave 2008” , Mills Davis ]
What is UBIWARE ?
(1)
• UBIWARE (important step towards GUN) is a generic,
domain independent middleware platform, which is
meant to be able to provide the following support:














integration;
interoperability;
proactivity;
communication, observation, negotiation, coordination and
collaboration;
automation, design and installation;
lifecycle management, execution monitoring, diagnostics,
maintenance;
self-descriptiveness, semantic search, discovery, sharing, reuse;
planning and decision-making;
adaptation;
learning, mining, knowledge discovery;
context-awareness;
self-management including self-configuration;
security, privacy and trust;
etc...
• …for … (see next slide)
What is UBIWARE ? (2)
• … for the following resources, systems and
components (including their groups):












data information and knowledge: data, metadata, knowledge, logic,
ontologies;
software and services: software components, software agents, software
and information systems, services including Web-services;
humans: users, operators, experts, administration, customers, patients,
doctors, etc;
hardware: machines, devices, networks, embedded electronics, RFID;
organizations;
intangibles: human and organizational capital, innovations, property rights,
trust and reputation, brand recognition, etc.;
processes: behaviors, technologies and business models;
interfaces;
intelligence: reasoning, inference, planning, learning, data-mining,
knowledge discovery, etc… engines;
ecosystems: environments, smart spaces, other middleware and CSCW
tools;
abstractions and mathematical models;
etc.
What is UBIWARE (in short)
• UBIWARE is a tool to support:



design and installation of…,
autonomic operation of…
interoperability
and
among…
• … complex, heterogeneous, open, dynamic and
self-configurable distributed industrial systems;…
• … and to provide following services for system
components:







adaptation;
automation;
centralized or P2P organization;
coordination, collaboration, interoperability and negotiation;
self-awareness, communication and observation;
data and process integration;
(semantic) discovery, sharing and reuse.
UBIWARE Project
• Due to heterogeneity of provided services and supported
components, UBIWARE is based on integration of several
technologies: Semantic Web, Distributed Artificial Intelligence and
Agent Technologies, Ubiquitous Computing, SOA (ServiceOriented Architecture), Web X.0, P2P and related concepts.
• The research and design on UBIWARE is started by Industrial
Ontologies Group within UBIWARE project: “Smart Semantic
Middleware for Ubiquitous Computing” (June 2007 – May 2010)
funded by Tekes and industrial companies.
• Project web page:
http://www.cs.jyu.fi/ai/OntoGroup/UBIWARE_details.htm
Why Semantic Web? (Ora Lassila)
• “Semantic Web is about to reach its full potential and it
would be too costly for companies not to invest to it…”
(Ora Lassila, Nokia Research Center (Boston), IASW-2005, Jyvaskyla)
Why Agents?
•
Growing complexity of computer systems and networks
used in industry  need for new approaches to manage
and control them
•
IBM vision: Autonomic computing – Self-Management
(includes self-configuration, self-optimization, selfprotection, self-healing)
•
Ubiquitous computing, “Internet of Things”  huge
numbers of heterogeneous devices are interconnected
• “nightmare of pervasive computing” when almost
impossible to centrally manage the complexity of interactions,
neither even to anticipate and design it.
•
We believe that self-manageability of a complex system
requires its components to be autonomous themselves,
i.e. be realised as agents.
•
Agent-based approach to SE is also considered to be
facilitating the design of complex systems
Challenges and Solutions
• Very heterogeneous resources
• Different nature (devices, Web services, humans).
• Different organizations.
• Not always the exact same domain.
• Data-level heterogeneity
• Calls for the Semantic Technology.
• Protocol-level heterogeneity
• GUN approach through the Agent Technology.
• Each resource has a representative – software agent (not
necessarily intelligent or even fully autonomous, but at least
able to act as a programmable proxy).
• Interactions among resources go through their agents.
Challenges and Solutions (2)
• Coordination
• When considering physical devices (e.g. future Internet
components), in contrast to purely digital world of Web
services, coordination is critical.
• Coordination is about resources planning their activities
while attempting to avoid negative interactions (e.g. collision
over a non-shareable resource) as well as exploit positive
interactions (re-using each other results).
• Enabling coordination among heterogeneous resources is
even harder problem than data-level or protocol-level
heterogeneity – communication about actions.
• GUN approaches through semantic programming
• Agents are programmed in RDF-based Semantic Agent
Programming Language (S-APL).
• Agents communicate their action plans in S-APL as well.
Current UBIWARE Agent Architecture
S-APL
S-APL –
Semantic
Agent
Programming
Language
(RDF-based)
S-APL – is a hybrid of semantics (metadata /
ontologies/ rules) specification languages,
semantic reasoners, and agent programming
languages. It integrates the semantic
description of domain resources with the
semantic prescription of the agents' behaviors
http://users.jyu.fi/~akataso/sapl.html
UBIWARE Agent: Possible Future Architecture
RBE –
Reusable
Behavior
Engine
SoftSoul
“Life” Behavior
HardSoul
RAB –
Genome is part of
semantically marked-up
agent configuration
settings, which can
serve as a tool for agent
evolution: inheritance
crossover and mutation
“Visible” to
other agents
through
observation
RBE
RBE
RBE
(facts, rules, policies, plans)
SoftBody
RAB
Shared
RABs
Beliefs
RAB
Shared
Beliefs
SoftMind
HardMind
RAB
Shared
RBEs
RBE
Meta-Beliefs
RAB
contained, self-described,
semantically marked-up
proactive agent capability
(agent-driven ontonut),
which can be “seen”,
discovered, exchanged,
composed and “executed”
(internally or remotely)
across the agent platform
in a task-driven way and
which can perform social
utility-based behavior
(GENOME)
Ontobility is self-
Meta-Beliefs
(preferences)
Shared
Configuration
Reusable
Atomic
Behavior
HardBody
Shared
Hardware
Environment
May be
an agent
GENI – Next Generation Internet ?
• GENI - Global Environment for Networking
Investigations (proposed 25 August 2005)
• The U.S. National Science Foundation (NSF) has
proposed a next-generation Internet with built-in
security and functionality that connects all kinds of
devices, with researchers challenging the government
agency to look at the Internet as a "clean slate.“
• GENI is a programmable, heterogeneous, networked
system. It will consist of a collection of physical
networking components, including links, forwarders,
storage and processor clusters, and wireless subnets.
These components will be programmable which is
radically different from today's Internet architecture
and protocols. GENI is equally likely to result in
alternative protocols and architectures running inside
the network.
GENI Programmable Components
Future Internet Management
• GENI management framework supposes overlay network
architecture, where each application is run in a slice of the
network. Overlay networks will also improve Internet
routing and enable routing messages to destinations not
specified by IP addresses.
• The most important attribute of the management framework
is its support for autonomous and decentralized control.
Individual building blocks will be largely autonomous and
self-managing and will be included in a slice by invoking a
well-defined interface adapter on each. Collections of
building blocks can be managed independently of each
other.
• The management framework also includes a set of
independent services that will be used to embed a slice in a
particular set of resources; monitor the behavior of both
slices and building block components; collect, aggregate,
and archive measurement data; and so on.
[GENI Development Team]
Active networks, overlay networks
and declarative networking
• Active networks (http://www.sds.lcs.mit.edu/darpaactivenet) allow a user injecting customized programs
into the nodes of the network. Active architectures
enable a massive increase in the complexity and
customization of the computation that is performed
within the network.
• Any widely-distributed system needs to track its
participating nodes, and be able to send messages
among those nodes. This facility is often called an
overlay network, since it provides an application with
customized networking functionality (naming, topology,
routing) that runs as a layer over traditional IP
networking.
• Declarative networking: (a) declarative language: “ask
for what you want, not how to implement it” ; (b)
declarative specifications of networks, compiled to
distributed dataflows; (c) runtime engine to execute
distributed dataflows (http://p2.cs.berkeley.edu/ )
Perfect target for GUN and UBIWARE ?
• If the future internet is really going to be a
complex distributed self-managed system
with decentralized control consisting of
heterogeneous, autonomic and
programmable components, as GENI
initiative suggests, then GUN / UBIWARE
approach (with S-APL language for
declarative networking) might be the right
enabling technology for that.
PROFI: Agent-Driven Middleware
for Overlay Networks
Languages for Declarative Networking
• Declarative languages are known to encourage programmers to
focus on program outcomes (what a program should achieve)
rather than implementation (how the program works). Recently
declarative approaches have proven useful in a number of new
domains, including program analysis, trust management, and
distributed system diagnosis and debugging. Of particular interest
is recent work on declarative networking, which presents
declarative approaches for protocol specification and overlay
network implementation. Declarative logic languages have been
promoted for their clean and compact specifications, which can
lead to code that is significantly easier to specify, adapt, debug,
and analyze than traditional procedural code. Snlog is a dialect of
Datalog, a well known deductive database query language. A
typical user (whether an end-user, service implementer or system
builder) writes only a short declarative specification using Snlog.
The main language constructs are predicates, tuples, facts and
rules. Snlog programs consist of period-terminated statements.
D. Chu, L. Popa, A. Tavakoli, J.M. Hellerstein, P. Levis, S. Shenker, I.
Stoica, The Design and Implementation of a Declarative Sensor
Network System, SenSys’07, November 6–9, 2007, Sydney, Australia
Declarative network
messages
Dataflow
Dataflow
messages
Dataflow
Dataflow
messages
Dataflow
Distributed
recursive query
Dataflow
Traditional Networks
Network protocol
Network messages
Declarative Networks
Recursive Query Execution
Distributed Dataflow
http://p2.cs.berkeley.edu/
Approach: Declarative Networking
• A declarative framework for networks:
language: “ask for what you
want, not how to implement it”
 Declarative specifications of networks,
compiled to distributed dataflows
 Runtime engine to execute distributed
dataflows
 Declarative
• Observation: Recursive queries are a
natural fit for routing
http://p2.cs.berkeley.edu/
Semantic Agent Programming
Language (S-APL)
• Need to be able to ontologically describe not only the
domain, but the agents themselves.
• Our approach: RDF-based (more precisely, Notation 3)
APL.
• In a nutshell:



Let’s start treating agents’ programs as data
If it is data, let’s use the semantic approach (advantages are wellknown)
Use Notation 3 (extension of RDF by Tim Berners-Lee) to overcome
limitations of basic RDF.
S-APL
• It is a hybrid of semantic reasoners like CWM and agent
programming languages like AgentSpeak, AFAPL.
• From APLs point of view: S-APL is a language that
provides all the features (and more) as normal APLs,
while being RDF based and thus providing advantages
of semantic data model and reasoning.
• From semantic reasoning point of view: S-APL is CWM
extended with common APL features such as:

Beliefs-Desires-Intentions (BDI) architecture, i.e. ability to describe
goals and commitments - data items presence of which leads to some
executable behavior, and
 Ability to link to sensors and actuators implemented in a procedural
language, namely Java.
Options for S-APL use
• The developers of a specific application can
use S-APL in different ways:
 Semantic
Reasoning. S-APL rules operating on SAPL semantic data.
 Semantic Data. RABs (i.e. Java components)
operating on S-APL semantic data.
 Workflow management. RABs operating on Java
blackboard objects, with S-APL used only as
workflow management tool, specifying what RABs
are engaged and when.
 Any combination of the three options above.
S-APL data model
G
_C1 accordingTo John
_C1
_C2 implies _C3
_C2
_C3
Time is Summer
Sun is Shining
S-APL: simple beliefs
• Simple belief
:John :Loves :Mary
• Complex belief
{:John :Loves :Mary} :accordingTo :Bill
• Goal / desire:
gb:I gb:want {:John :Loves :Mary}
The prefix gb: is used here to denote the ontology of S-APL.
In S-APL, making a statement has the meaning of adding it to the agent’s
beliefs.
S-APL: Rules
• Conditional commitment:
 {:John :loves ?x} => {...}
=> is the shorthand for sapl:implies. If the left side of => is truth (beliefs
are connected with AND), the right side is copied into G. The
commitment is removed after that (as fulfilled). Otherwise, it stays in
beliefs and checked again and again until becomes true.
• Persistent behavior rule (not removed upon execution)
 { {...} => {...} } sapl:is sapl:Rule
• Conditional action
 {...} -> {...}; sapl:else {}
-> is the shorthand for sapl:impliesNow. Such a condition will be
checked only once and will be removed even if the condition was
false. Adding gb:else block defines what should be added to beliefs if
the condition was false.
S-APL: Rules (2)
• Exclusive condition:
 {:John :Loves ?x .
sapl:I sapl:doNotBelieve {?x .. ..}
} => {...}
If the object of sapl:doNotBelieve matches G, the left side of => is false.
If there are several sapl:doNotBelieve, they are connected with OR
• Commitment with a guard condition:
 { {...} => {...} } sapl:is sapl:true ;
sapl:existsWhile {...}
If the object of sapl:existsWhile is false, its subject is removed – in this
case, the commitment is dropped.
S-APL as communication content language
• We use S-APL also as inter-agent communication content language:
 One agent sends a query as sapl:I sapl:want
{ {sapl:You sapl:answer {..query..} }} , the other
answers with the matching part of its beliefs
 One agent requests another agent to perform an action plan by
sending the plan with sapl:I sapl:want { sapl:You
sapl:do {..plan..} }
• Such interaction is easily programmed with S-APL itself. The platform
includes a set of “standard” models: Listener, Believer, Informer and
Follower.
Conclusion
• The primary point behind the PROFI
approach is a declarative networking
overlay architecture comprising
programmable network components and
associated agent-based semantic
management system. This particular
middleware solution adds to overall
network system flexibility, openness,
context-awareness and manageability.