280 likes | 404 Views
The 14th International World Wide Web Conference. Improving portlet interoperability through deep annotation. Oscar Díaz, Jon Iturrioz, Arantza Irastorza ONEKIN Research group University of the Basque Country San Sebastián (Spain) May 10th, 2005. Agenda. Introduction
E N D
The 14th International World Wide Web Conference Improving portlet interoperability through deep annotation Oscar Díaz, Jon Iturrioz, Arantza Irastorza ONEKIN Research group University of the Basque Country San Sebastián (Spain) May 10th, 2005
Agenda • Introduction • Portlet interoperability process • Portlet and Portal ontology • Portlet annotation • Portlet feeding • Conclusions
request response <carQuery> <make>Ferrari</make> <model>360</model> </carQuery> <carList> <car>360 Spider</car> <car>360 Modena</car> </carList> XML Response XML Request From web services Application User Interface Web Services Client Client application WS Proxy Car Search Service Web Services 2nd Hand Car Database Business Logic Search for Cars
Client application request <carQuery> <make>Ferrari</make> <model>360</model> </carQuery> XML Request response HTML Fragment Car Search Service Flow + Presentation 2Hand Car Database Search for Cars … to portlets Application User Interface Web Services Client WS Proxy Web Services Business Logic
Complete Web Application Flow + Presentation Portlets definition “Portlets are user-facing,multi-step interactive Web Services that can be plugged into third-party applications.” Business Logic 2Hand Car Database Data Search for Cars
Portal= aggregation of portlets The portal integrator “front-end” of applications
Portlet-2 Portlet-1 OUTPUT INPUT INPUT OUTPUT The challenge: how to interoperate between portlets ?
Source Portlet role: backend owner Portal role: annotator Target Portlet role: querying party Portal Ontology registry registry ontology ontology Registration Time integrate integrate + Rules Extended Portal Ontology getMarkup() instanceOf Enactment Time XTMHL XHTML “Output Process” Annotation getMarkup(query mode) feeding Query Time bookHotel+data A portlet interoperability proccess
Source Portlet role: backend owner Portal role: annotator Target Portlet role: querying party Portal Ontology registry registry ontology ontology Registration Time integrate integrate + Rules Extended Portal Ontology Enactment Time Query Time Registration time
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
Domain 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> ………
Process 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 <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? Events are realisations of portlet processes Eventual events are potential realisation of portlet processes Event 1 Event 2 Eventual event 1 Eventual event 2
XHTML+Data Eventual events Events Pipe rule XHTML+OWL A portal ontology <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>
Eventual events Events Pipe rule XHTML+OWL XHTML+Data A portal 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> <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>
Source Portlet role: backend owner Portal role: annotator Target Portlet role: querying party Registration Time getMarkup() instanceOf Enactment Time XHTML “Output Process” Annotation Query Time Enactment time Portal Ontology registry registry ontology ontology integrate integrate + Rules Extended Portal Ontology
Flight Search portlet -> Select Step 1 2 3 Selected Departure Flight Flight TR0123 Departs BIO at 12:55, arrives LHT at 19:00 Flexible web fare 12:00(phone fare 15:00 Selected Return Flight Flight TR0561 Departs LHT at 12:45, arrives BIO at 14:00 Flexible web fare 22:50(phone fare 01:50 Output Proccess instances <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> 1.- Portlet ontology instantiation
Flight Search portlet -> Select Step 1 2 3 Selected Departure Flight Flight TR0123 Departs BIO at 12:55, arrives LHT at 19:00 Flexible web fare 12:00(phone fare 15:00 Selected Return Flight Flight TR0561 Departs LHT at 12:45, arrives BIO at 14:00 Flexible web fare 22:50(phone fare 01:50 Annotation: mapping with the portal ontology <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> <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>
Source Portlet role: backend owner Portal role: annotator Target Portlet role: querying party Registration Time getMarkup() instanceOf Enactment Time XHTML XTMHL “Output Process” Annotation Feeding Query Time bookHotel+data Query time Portal Ontology registry registry ontology ontology integrate integrate + Rules Extended Portal Ontology piping
getMarkup() instanceOf XHTML XTMHL “Output Process” Annotation Feeding bookHotel+data Piping - Feeding • Piping: deriving eventual events from events • Feeding: inlaying parameters of input forms from eventual events piping
Eventual events Events // 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) ]"; Jena2 Rule Mechanism (Prolog-like) 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) XHTML+OWL XHTML+Data Piping Pipe rule
<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> 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>
Feeding <hotelBook:searchHotel_IS> <hotelBook:cityName/> <hotelBook:hotelName/> …… </hotelBook:searchHotel_IS> <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> <form> <input type=“text” name=“hotelBook:cityName” /> <input type=“text” name=“hotelBook:hotelName”/> ……….. </form>
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íaz jipdigao@si.ehu.es Jon Iturrioz jipitsaj@si.ehu.es Arantza Irastorza arantza.irastorza@ehu.es http://www.onekin.org