ONTOLOGICAL MIDDLEWAREEnabling Semantically-aware Networking

Ben Tagger and Dirk Trossen (presenting)

2

The Role of Middleware (simplified!)

User/App

Core Architecture

pub

lish

Sco

pe

pub

lish

Dat

a

subs

crib

eSco

pe

subs

crib

eIte

m

and

so

on …Middleware

current proposed

3

What we hope to achieve…• Provide middleware that matches and builds on our goal

of information centricity.• Enhance the usability of the core architecture.• Exploit the functionality of the core architecture.• Separate user-space and network-level data/metadata

requirements.• Incorporate formal modelling of metadata.

• Promote collaboration and discussion within the group!

4

The Principal Design Challenge• Understand the (meta)data flow through our system (the

blue bit).• What data/metadata can be provided to the middleware?

• i.e., what does the user know?

• What data/metadata is required at the network level?• What does the network need to know?

Core

Architecture

Meta(data)

5

Exploring the Design Space• At the extreme left, we have a flat

mapping of metamodels.• (+) Distinct separation of middleware/

network metadata.• (-) Removes the possibility of network

optimisations.

• At the extreme right, we have an exactmapping of metamodels.

• (+) All metadata is preserved at the network level – enables optimisations.

• (-) Replicating metadata that may not be required. Must compromise on expressiveness of metamodel.

✔ We are looking for the optimum design.

6

Separation of Metadata• The metadata of publications exists

between layers.• User-interesting metadata exists at

the middleware level.• Network-interesting metadata exists

at the network level.• Some metadata will be of interest to

both parties.

Questions:

• What metadata should be placedat which level?

• How is metadata modelled withinthe middleware?

• How is metadata modelled withinthe network?

• We have some answers…

ontologies!

SIds, RIds, etc.

7

Design Overview

videopublish

Content QoS Security Other…

Stock Ontologies

Annotations

User/App

Network

Ontological Metamodel

RendezvousMetamodel

Presentations

annotate

Key Points:• publications are

annotated with ontological concepts.

• ontologies can be built on any relevanttopic and easily integrated.

• If we wish to include a new feature, we need only build a new ontology.

8

Benefits of the Design 1• Formal Metamodelling

• All metadata is placed within a structure.• We can demonstrate the correctness of a metamodel. And we can

demonstrate the incorrectness!• Consistency is passed down to the Network level (Network metamodel

is built by the middleware).

• Formal Publication• Every publication has a formal definition.• Every bit of data in our network has a meaning. “The what is more

important than ….”

• Advanced Subscriptions• subscribe to publications using expressive queries.

• “give me all the photos uploaded in the last 2 days within ½ mile of me”• “give me videos that feature Madonna and in high definition.”

• The capabilities of the queries depend on the expressiveness of the publications. The more you put in, the more you get out…

9

Benefits of the Design 2• Metadata Management

• Thorough analysis of metadata; what metadata exists?• Separation of metadata; what metadata goes where?

• Leverages the Current Metamodel• Puts only the right semantics at the Network layer.• Opens the possibility to optimise operations while enhancing

functionality.

• Decouples Data and Metadata• Modularity of transport/signalling mechanisms.• Middleware contains no data. It’s all in the network layer (where it

belongs!)

10

Challenges• Expressiveness vs Complexity tradeoff

• We do not advocate an entirely ontology-based design!• Strength of the architecture allows for choosing different level of

realisations, depending on the desired tradeoff• For each area, we have to determine this tradeoff, e.g., in QoS

• Demonstrate the strength• Simplify network-level operations is only one area• Other, more user-level areas are candidates

• But these are mainly not in the scope of PURSUIT

• Demonstrate the inherent architecture advantage• Prove our ‘impedance mismatch’ claim• Need metrics to determine efforts for middleware development

• More than just complexity

11

Thanks, Questions and Discussion