improving portlet interoperability through deep annotation

Improving portlet interoperability through

deep annotation

Oscar Díaz, Jon Iturrioz, Arantza IrastorzaONEKIN Research group

University of the Basque Country San Sebastián (Spain)

May 10th, 2005

The 14th International World Wide Web Conference

O. Díaz, J. Iturrioz, A. Irastorza 2

Agenda

Introduction

Portlet interoperability process

Portlet and Portal ontology

Portlet annotation

Portlet feeding

Conclusions


XMLRequest

XMLResponse

Business Logic

Web Services

Web Services Client

Application User Interface

WS Proxy

2nd Hand Car Database

Search for Cars

Car Search Service

<carQuery> <make>Ferrari</make> <model>360</model></carQuery>

request<carList> <car>360 Spider</car> <car>360 Modena</car></carList>

response

Client application

From web services


… to portlets

Web Services Client

Application User Interface

Web Services

WS Proxy

2Hand Car Database

Search for Cars

Car Search Service

Client application

<carQuery> <make>Ferrari</make> <model>360</model></carQuery>

requestXMLRequest HTML

Fragment

Flow+

Presentation

Business Logic

response


Portlets definition

2Hand Car Database

Search for Cars

“Portlets are user-facing, multi-step interactive Web Services that can be plugged into third-party

applications.”

Flow +Presentation

BusinessLogic

Data

Complete Web Application


The portal integrator “front-end” of applications

Portal= aggregation of portlets


The challenge: how to interoperate between portlets ?

Portlet-1 Portlet-2

OUTPUT INPUT

OUTPUT

INPUT


getMarkup()

XHTML

“Output Process” Annotation

inst

ance

Of

PortalOntologyregistry registry

integrate integrate

Extended PortalOntology

ontology ontology

+ Rules

En

actm

ent

Tim

e

Reg

istr

atio

nT

ime

Qu

ery

Tim

e feeding

XTMHL

getMarkup(query mode)

bookHotel+data

A portlet interoperability proccessSource Portlet

role: backend ownerPortal

role: annotatorTarget Portlet

role: querying party


registry registryPortal

Ontology

integrate integrate


ontology ontology

+ Rules

En

actm

ent

Tim

e

Reg

istr

atio

nT

ime

Qu

ery

Tim

e Registration time

Source Portletrole: backend owner

Portalrole: annotator

Target Portletrole: querying party


Portlet’s ontology

So far, portlet description does not include an ontology

However, this is a natural extension. WSs have one

For our purposes:

Portlet ontology = domain ontology + process ontology


<owl:Class rdf:ID="Flight"/><owl:ObjectProperty rdf:ID=“origin">

<rdfs:domain rdf:resource="#FlightBooking"/><rdfs:range rdf:resource="&airport;Airport"/>

</owl:ObjectProperty><owl:ObjectProperty rdf:ID=“destination">

<rdfs:domain rdf:resource="#FlightBooking"/><rdfs:range rdf:resource="&airport;Airport"/>

</owl:ObjectProperty><owl:ObjectProperty rdf:ID=“flightNumber">

<rdfs:domain rdf:resource="#FlightBooking"/><rdfs:range rdf:resource="&xsd;dateTime#day"/>

</owl:ObjectProperty>………

Domain ontology


Two kinds of processes (OWL-S):• Output atomic proccess • Input atomic proccess

<owl:Class rdf:ID="departureFlightsAvailable_OS"> <owl:subClassOf rdf:resource="&owl-s;AtomicProcess"/></owl:Class><owl:Property rdf:ID=“departureFlightAvailable"> <owl:subPropertyOf rdf:resource="&owl-s;output"/> <owl:domain rdf:resource="#departureFlightsAvailable_OS "/> <owl:range> <rdf:bag>

<rdf:li rdf:resource=”#Flight” "/> </rdf:bag>

</owl:range></owl:Property><owl:Class rdf:ID="returnFlightsAvailable_OS"> <owl:subClassOf rdf:resource="&owl-s;AtomicProcess"/></owl:Class>

<owl:Class rdf:ID="departureFlightChoice_IS"> <owl:subClassOf rdf:resource="&owl-s;AtomicProcess"/></owl:Class><owl:Property rdf:ID=“departureFlightInput"> <owl:subPropertyOf rdf:resource="&owl-s;input"/> <owl:domain rdf:resource="#departureFlightChoice_IS "/> <owl:range> <rdf:li rdf:resource=”#Flight” "/> </owl:range></owl:Property>

<owl:Class rdf:ID="returnFlightsChoice_IS">...</owl:Class>

Process ontology


Process ontologyAtomicProcess(OWL-S)

-departureFlightsAvailable

departureFlightsAvailable_OS

-departureFlighstInput

departureFlightsChoice_IS

-returnFlightsInput

returnFlightsChoice_IS

-returnFlightsAvailable

returnFlightsAvailable_OS

<owl:Class rdf:ID="departureFlightsAvailable_OS"> <owl:subClassOf rdf:resource="&owl-s;AtomicProcess"/></owl:Class><owl:Property rdf:ID=“departureFlightsAvailable"> <owl:subPropertyOf rdf:resource="&owl-s;output"/> <owl:domain rdf:resource="#departureFlightsAvailable_OS "/> <owl:range> <rdf:bag>

<rdf:li rdf:resource=”#Flight” "/> </rdf:bag>

</owl:range></owl:Property>


¿Portal ontology?

The portal acts as a portlet mediator

The portal bridges the semantic gap between portlet’s ontologies• FlightBook’s depart date HotelBook’s entry

date

The portal acts as a pipe between portlets• FlightBook’s event HotelBook’s eventual

events


¿Eventual event?

Event 1Event 2

Events are realisations of portlet processesEventual events are

potential realisation of portlet processes

Eventual event 1Eventual event 2


XHTML+OWL EventsXHTML+Data

Pip

e r

ule

Eventual events

<owl:Class rdf:ID="Event"/> <owl:ObjectProperty rdf:ID="timeStamp"> <rdfs:domain rdf:resource="#Event"/> <rdfs:range rdf:resource="&OWLTime;Instant"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="process"> <rdfs:domain rdf:resource="#Event"/> <rdfs:range rdf:resource="&OWL-S;AtomicProcess"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="data"> <rdfs:domain rdf:resource="#Event"/> <rdfs:range rdf:resource="&OWL;Thing"/> </owl:ObjectProperty>

<owl:Class rdf:ID="EventualEvent"/> <owl:ObjectProperty rdf:ID="process"> <rdfs:domain rdf:resource="#EventualEvent"/> <rdfs:range rdf:resource="&OWL-S;AtomicProcess"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="data"> <rdfs:domain rdf:resource="#EventualEvent"/> <rdfs:range rdf:resource="&OWL;Thing"/> </owl:ObjectProperty>

A portal ontology


XHTML+OWL EventsXHTML+Data

Pip

e r

ule

Eventual events

<ontopipe:Event> <ontopipe:timeStamp> <time:Instant> <time:inCalendarClockDataTyperdf:datatype="&xsd;dateTime"> 2004-04-13T11:30:05 </time:inCalendarClockDataType> </time:Instant> </ontopipe:timeStamp> <ontopipe:process>departureFlightSelected_OS</ontopipe:process> <ontopipe:data> <flightBook:Flight rdf:ID="flight1"> <flightBook:origin>BIO</flightBook:origin> <flightBook:destination>LHT</flightBook:destination> <flightBook:departTime>12:55</flightBook:departTime> <flightBook:departDate>04/04/2005</flightBook:departDate> </flightBook:Flight> </ontopipe:data></ontopipe:Event>

<ontopipe:EventualEvent> <ontopipe:process>searchHotel_IS</ontopipe:process> <ontopipe:data> <hotelBook:Hotel rdf:ID="hotel1"> <hotelBook:entryDate>04/04/2005</hotelBook:entryDate> <hotelBook:cityName>London</hotelBook:cityName> <hotelBook:hotelName>Palace</hotelBook:hotelName> <hotelBook:duration>1</hotelBook:duration> </hotelBook:Hotel> </ontopipe:data></ontopipe:EventualEvent>

A portal ontology instantiation


getMarkup()

XHTML


inst

ance

Of


Ontology

integrate integrate


ontology ontology

+ Rules

En

actm

ent

Tim

e

Reg

istr

atio

nT

ime

Qu

ery

Tim

eEnactment time

Source Portletrole: backend owner

Portalrole: annotator

Target Portletrole: querying party


Flight Search portlet -> Select Step 1 2 3Selected Departure Flight Flight TR0123 Departs BIO at 12:55, arrives LHT at 19:00 Flexible web fare 12:00(phone fare 15:00Selected Return Flight Flight TR0561 Departs LHT at 12:45, arrives BIO at 14:00 Flexible web fare 22:50(phone fare 01:50

<flightBook:departureFlightSelected_OS> <flightBook:departureFlight> <flightBook:Flight rdf:ID="flight1“> <flightBook:origin>BIO</flightBook:origin> <flightBook:destination>LHT</flightBook:destination> <flightBook:departTime>12:55</flightBook:departTime> </flightBook:Flight> </ flightBook:departureFlight></flightBook:departureFlightsAvailable_OS><flightBook:returnFlightSelected_OS>

Output Proccess instances

1.- Portlet ontology instantiation


<ontopipe:Event> <ontopipe:timeStamp> <time:Instant> <time:inCalendarClockDataTyperdf:datatype="&xsd;dateTime"> 2004-04-13T11:30:05 </time:inCalendarClockDataType> </time:Instant> </ontopipe:timeStamp> <ontopipe:process>departureFlightSelected_OS</ontopipe:process> <ontopipe:data> <flightBook:Flight rdf:ID="flight1"> <flightBook:origin>BIO</flightBook:origin> <flightBook:destination>LHT</flightBook:destination> <flightBook:departTime>12:55</flightBook:departTime> <flightBook:departDate>04/04/2005</flightBook:departDate> </flightBook:Flight> </ontopipe:data></ontopipe:Event>

<flightBook:departureFlightsSelected_OS> <flightBook:departureFlight> <flightBook:Flight rdf:ID="flight1“> <flightBook:origin>BIO</flightBook:origin> <flightBook:destination>LHT</flightBook:destination> <flightBook:departTime>12:55</flightBook:departTime> </flightBook:Flight> </ flightBook:departureFlight></flightBook:departureFlightsAvailable_OS>

Annotation: mapping with the portal ontology

Flight Search portlet -> Select Step 1 2 3Selected Departure Flight Flight TR0123 Departs BIO at 12:55, arrives LHT at 19:00 Flexible web fare 12:00(phone fare 15:00Selected Return Flight Flight TR0561 Departs LHT at 12:45, arrives BIO at 14:00 Flexible web fare 22:50(phone fare 01:50


getMarkup()

XHTML


inst

ance

Of


Ontology

integrate integrate


ontology ontology

+ Rules

En

actm

ent

Tim

e

Reg

istr

atio

nT

ime

Qu

ery

Tim

e

XTMHL

Feeding

bookHotel+data

piping

Query timeSource Portlet

role: backend ownerPortal

role: annotatorTarget Portlet

role: querying party


getMarkup()

XHTML


inst

ance

Of

XTMHL

Feeding

bookHotel+data

piping

Piping - Feeding

Piping: deriving eventual events from events

Feeding: inlaying parameters of input forms from eventual events


XHTML+OWL Events

Pip

e r

ule

Eventual eventsXHTML+Data

Piping

pipeRule= "[fromBookFlightToBookHotel: (?departureEvent rdf:type ontopipe:Event), (?departureEvent ontopipe:process 'departureFlightSelected_OS'), (?departureEvent ontopipe:data ?depFlight), (?depFlight flightBook:departDate ?depDate), (?depFlight flightBook:passenger ?depPassenger), (?depFlight flightBook:destination ?destAirport), (?destAirport airportCodes:city ?destCity)

Jena2 Rule Mechanism (Prolog-like)

// The new Eventual Event is created " (?newEE rdf:type ontopipe:EventualEvent), " + " (?newEE ontopipe:process 'searchHotel_IS'), " + " (?newEE ontopipe:data ?newData)," + // The hotel booking is created using // the data from flight bookings " (?newData rdf:type hotelBook:Hotel)," + " (?newData hotelBook:entryDate ?depDate), " + " (?newData hotelBook:guest ?depPassenger) ]"; " (?newData hotelBook:city ?destCity) ]";


Piping<ontopipe:Event> <ontopipe:timeStamp> <time:Instant> <time:inCalendarClockDataTyperdf:datatype="&xsd;dateTime"> 2004-04-13T11:30:05 </time:inCalendarClockDataType> </time:Instant> </ontopipe:timeStamp> <ontopipe:process>departureFlightSelected_OS</ontopipe:process> <ontopipe:data> <flightBook:Flight rdf:ID="flight1"> <flightBook:origin>BIO</flightBook:origin> <flightBook:destination>LHT</flightBook:destination> <flightBook:departTime>12:55</flightBook:departTime> <flightBook:departDate>04/04/2005</flightBook:departDate> </flightBook:Flight> </ontopipe:data></ontopipe:Event>



<form> <input type=“text” name=“hotelBook:cityName” /> <input type=“text” name=“hotelBook:hotelName”/> ……….. </form>

Feeding<hotelBook:searchHotel_IS> <hotelBook:cityName/> <hotelBook:hotelName/> ……</hotelBook:searchHotel_IS>



Conclusions Portlet interoperability is a must to enhance the

user experience Deep annotation provides a seamless approach

• Transparent to the portlet provider (provides provider independence)

• All the burden rests on the portlet consumer (i.e. the portal)

Separation of concerns:• Annotation• Piping• Feeding

… accounts for easy evolution of the portal (addition/removal of portlets)


Issues

Portlet fragments should be enhanced with ontology instantiations• Is this a big burden?

It is now up to the portal master to define the piping rules• Is this a big burden?


Thank you!

Oscar Dí[email protected]

Jon [email protected]

Arantza [email protected]

http://www.onekin.org

improving portlet interoperability through deep annotation

Documents