Browsing Schedules An AgentBased Approach to Navigating the Semantic Web

1
Browsing Schedules An Agent-Based Approach to
Navigating the Semantic Web

• Terry R. Payne, Rahul Singh
• Katia P. Sycara

Carnegie Mellon University http//www.daml.ri.cmu.
edu/
2
Intro Stuff about agents SW
3
RCal RETSINA Calendar Agent

• Retsina Semantic Web Calendar Agent supports
• Browsing of agendas and schedules marked up in
  DAML RDF
• Invocation of simple tasks, such as scheduling
  meetings and email
• Integration of selected meetings and events into
  MS Outlook

http//www.daml.ri.cmu.edu/Cal
4
RCal RETSINA Calendar Agent

• Can parse markup using several ontologies,
  including
• Hybrid ICal Calendar Ontology
• Dublin Core Ontology
• Friend-of-a-Friend Ontology
• Can reason about similar semantic markup
• Navigates and resolves resource links
• Eliminates the need to duplicate information
• Consumer of services
• Contacts DAML-S registries to locate services for
  ontology translation and other tasks

5
Calendar Agent Architecture
6
(No Transcript)
7
(No Transcript)
8
More than simply browsing schedules

• Agent can reason about schedule and users
  existing calendar
• Identifies overlapping events
• Can confirm or discard events, based on users
  availability
• Availability based on location context to come
  soon
• Selected events and contact details can be
  imported directly into MS Outlook, initiated
• By Humans
• Entering the URL of a schedule
• By other Agents
• Receiving an import or browse message from a
  trusted agent
• such as ITTalks or agent-mediated web page

9
Importing Schedules into MS Outlook
10
Utilizing additional properties

• Markup about schedules, locations or attendees
  may include different properties
• E.g. attendee information may include
• email address
• web-page
• physical address
• phone, etc
• This information can be utilized to provide
  additional functionality
• Importing contact details
• Sending Email to event attendees
• etc.

11
Presenting additional tasks/services
12
Invoking simple services

• Markup may refer to other useful resources
• E.g. location may include
• Physical address
• Latitude / Longitude coordinates etc.
• An Anecdote trying to be smart
• If lat/long information was present, RCal would
  check to see if the Retsina Restaurant Agent was
  running, and present the service to the user.
• On invocation, the Restaurant Agent would, in
  turn, calls the Yahoo Restaurant Web Service
  using http calls
• The resulting html was scraped to elicit
  interesting information and return a map
  highlighting local restaurants
• worked until Yahoo changed the web page layout!

13
Too many ontologies?

• Several ontologies are emerging for marking up
  calendars, events, and contact details
• Schedules
• RCal (and SWWS01) uses the Hybrid-iCal Ontology
• DAML PI Meetings use the DAML Meeting Agenda
  Ontology
• ITTalks defines its own schedule ontology
• Contact Details
• RCal uses FOAF (ITTalks and DAML PI markup differ
  as well)
• vCard Ontology
• ISWC02 recommended another ontology for marking
  up abstracts.

14
Too many ontologies? (cont)

• Reasoning about new markup
• Using the ontologies themselves
• Assumes that the ontologies define the semantics
  of the new markup w.r.t. known semantics
• Using articulation rules
• Use rules to map from one ontology to another
• How are these rules found?
• Are such rules standard, or are there many
  schemes?
• Using translation services
• Locate and invoke services that translate markup
  between two ontologies

15
DMA2ICal Translation Service

• DMA2ICal Translation Service converts DAML
  Meeting Agenda Markup into ICal Markup
• Allows DAML meeting agendas to be understood by
  RCal Agent
• Based on Mike Deans genhtml client for
  generating html from DAML-based schedules
• Simple approach to translation
• Build graph based on DMA markup and semantics
• Traverse graph to generate and serialize new
  markup using iCal FOAF ontologies
• Worked at the document level
• Still encounters problems with heterogeneous
  markup

16
Invoking DMA2ICal Translation Service

• Service can be accessed via the web
• Form based interface for retrieving markup
• CGI interface for dynamic generation of markup
  via a URI
• Coming soon - SOAP interface and a DAML-S
  process/grounding model

• Service can be registered with a lookup service
  (e.g. DAML-S)
• Generate a request, and locate the translation
  service through service discovery registries such
  as the DAML-S Matchmaker

17
Talk Outline

• The Web, Agents and the Semantic Web
• RCal Retsina Calendar Agent
• Too many ontologies?
• Simple Markup Translation Services
• Locating Translation Services using DAML-S
  Profiles
• Discussion Questions

18
The Good ol Days

• The World Wide Web revolutionized information
  dissemination on the Net
• Distributed information space supporting seamless
  human navigation
• Documents can be rapidly linked to other
  information
• Provides gateways to Human-oriented Web Services
• Checking how much money is in your bank
• and finding places to spend it!

19
The Good ol Days (cont)

• Whilst, in theory, the Web is a rich repository
• Information is opaque to machine interpretation
• Lack of logical structure
• Heuristics could make inferences about
  hyperlinks, but
• Lack of formal semantics
• Information may be ambiguous
• Relies on context natural language
  interpretation
• To use this repository, autonomous agents need
• Domain specific descriptions of web pages and how
  to parse them
• Heuristics to determine interesting information
• Prone to failure due to changes in markup
  structure

20
The Good ol Days (cont)

• Agents can invoke human oriented Web Services,
  but
• Until recently, communication used http and html
• Interpreting results required prior knowledge
  about the resulting html structure
• Difficult to engage in services that follow some
  process model (e.g. Airline Reservation Sites)

21
Hyperlinks vs Resources
22
Agents The Semantic Web

• The Semantic Web heralds a new approach to
  providing annotations and markup
• Information has associated semantics
• Richer reasoning environment
• Richer structure facilitates meaningful
  elicitation
• Resources on the Semantic Web
• Ability to reference related information, rather
  than duplicate it
• Dynamic update of information
• Reasoning over time and resolution of resources
  maintains freshness of information

23
Translating resources DMA2FOAF

• Simple translation service that converts
• ltdmaSpeakergt concepts into ltfoafPersongt

ltdmaSpeaker rdfID"payne"gt ltdmanamegtTerry
Paynelt/dmanamegt ltdmaemailgtterryp_at_cs.cmu.edu
lt/dmaemailgt ltdmahomePagegt
http//www.cs.cmu.edu/terryplt/dmahomePagegt lt/dma
Speakergt
ltfoafPerson rdfID"payne"gt ltfoafnamegtTerry
Paynelt/foafnamegt ltfoafmbox
rdfresource"mailtoterryp_at_cs.cmu.edu" /gt
ltfoafworkplaceHomepage rdfresource"http//www.c
s.cmu.edu/terryp"/gt lt/foafPersongt
24
Locating Translation Services using DAML-S

• DAML-S A DARPA Agent Markup Language for
  Services
• DAMLOIL Ontology for Web services
• Provides an upper ontology for describing
  properties capabilities of agents Web
  services in an unambiguous, computer
  interpretable markup language.
• Supports discovery, invocation, selection,
  composition, interoperation and execution
  monitoring of services on the Semantic Web.

http//www.daml.org/Services
25
DAML-S Upper Ontologies
26
DAML-S Service ProfileOverview
Functionality or Capability Description
Provenance Description
Functional (pragmatic) Attributes
27
DAML-S ProfileService Matchmaking

• DAML-S Matchmaker Service Registry
• Matches DAML-S requests with advertised DAML-S
  profiles
• Uses simple subsumption-based inference engine
• Augments UDDI registry services
• Current inference engine reasons about taxonomic
  hierarchies and equivalence relationships
• Current matching engine assumes
• Requests should be more general than
  advertisements w.r.t inputs
• Requested outputs should be more specific than
  the advertised outputs

28
Constructing a Request

• ltprofileNeededService rdfID"my_request"gt
• ltprofileserviceCategory rdfID"categoryOnto
  logyTranslation" /gt
• ltprofileinputgt
• ltprofileParameterDescription
  rdfID"inSpeaker"gt
• ltprofileparameterNamegtinSpeakerlt/profilepa
  rameterNamegt
• ltprofilerestrictedTo rdfresource"dmaSp
  eaker" /gt
• lt/profileParameterDescriptiongt
• lt/profileinputgt
• ltprofileoutputgt
• ltprofileParameterDescription
  rdfresource"outPerson"gt
• ltprofileparameterNamegtoutPersonlt/profilepa
  rameterNamegt
• ltprofilerestrictedTo rdfresource"foafP
  erson" /gt
• lt/profileParameterDescriptiongt
• lt/profileoutputgt
• lt/profileNeededServicegt

29
DAML-S ProfileService Matchmaking (cont)

• DAML-S Matchmaker maintains abstraction between
• Protocol (eg broker vs yellow-pages)
• Matching Engine
• Inference Engine

Service Providers
Matchmaker
30
Invoking the Translator

• Once the service is found, it is currently
  invoked via a KQML message
• Assumes prior knowledge
• Response contains new markup that can then be
  added to the Agents model, and be reasoned about
• Next step
• Describe using a DAML-S Process Model and
  Grounding Model
• Invoke using WSDL generated SOAP messages
• Evaluate using several translators for different
  resources used by a large meetings or conferences

31
Rounding up

• Agents are consumers of Web Services
• Need to locate these services using a semantic
  framework
• Need a way of reasoning about the returned
  information
• Agents will be consumers of Semantic Web markup
• Use of distributed resources
• May be possible to reason about markup using
  known ontologies
• May require assistance in reasoning about markup
  using new ontologies

32
Future Issues

• Reasoning with temporal logics
• Reasoning about context, when seeking services
• Knowledge of location could provoke a search for
  local services, but these should be contextually
  relevant
• Use of articulation rules
• Is the use of translation services scalable?
• Other ways of reasoning between markup.

33
DAML-S ProfileSubsumption Matching

• Service Requestors have knowledge about their
  request, but no knowledge of the available
  service providers.
• Current matching engine assumes
• Requests should be more general than
  advertisements w.r.t inputs
• Requested outputs should be more specific than
  the advertised outputs
• Current inference engine reasons about taxonomic
  hierarchies and equivalence relationships
• However, alternative engines that utilize the
  full power of DAML are being investigated

34
DAML-S Capability Matching

• Use logic inference (inheritance)
• Match succeeds when
• outputs of request are subsumed by outputs
  advertisement
• the service provides all the outputs expected by
  the request
• inputs advertisement are subsumed by inputs of
  the request
• the service expects all the information that the
  requester is willing to provide

35
Resources on the Web

• RCal
• http//www.daml.ri.cmu.edu/RCal
• DAML-S
• http//www.daml.org/Services

36
PresentingService Profiles
DAML-S

• Service Profile
• Presented by a service.
• Represents
• what the service provides
• One can derive
• Service Advertisements
• Service Requests

37
Marking up Events and People in RDF
38
Translating at the concept level

• DMA2ICal worked nicely for well managed markup,
  but
• Ignores markup not defined using DMA ontology
• Cannot translProblems still exist for schedules
  referring to existing resources
• Existing resources may be defined by different
  ontologies
• Need to translate at the concept or resource level