Phosphorus: Ontology-Based Matchmaking Hans Chalupsky Yolanda Gil Tom Russ Surya Ramachandran Information Sciences Institute

Ontology-based Matchmaking Research goals  Description-based advertisements and requests –EXPECT’s goal and capability descriptions  Vocabulary within descriptions derived from –Performative/Action Ontology –Domain ontologies –Broad coverage ontology (e.g., SENSUS)  Classifier match and partial match –PowerLoom classifier –Chameleon partial matcher (combines deduction and neural nets)  Adaptive (trainable) matching  Multilingual descriptions

Find route from location1 to location2 Find egress route from Ryad to Kuwait city Calculate RTT for transport aircraft Calculate round-trip time (RTT) for aircraft Calculate RTT for combat aircraft A) Subsumption-based match: the request is subsumed by an agent’s capability B) Reformulation-based match: the request can be satisfied by combining the capabilities of two or more agents Find route from city1 to city2 Find route from location1 to location2 C) Reverse subsumption-based match: an agent can satisfy some aspect of the request Find addresses of US citizens in Kuwait Find phone numbers of US citizens in Kuwait D) Partial match: an agent has a capability that is similar/related to the original request Classifier Match and Partial Match

Agent Matching Problem I: topic matching (e.g., interests matcher; e.g., roses)  Given: - thousands/millions of agent descriptions - a request  Find: a set of agents that can fulfill the request (and/or something similar to the request) (and/or can understand some of the request) (and/or could help reformulate the request) Problem II: task-based matching (e.g., activities matcher)  Given: - a few dozens/hundreds agent descriptions - a request  Find: the few agents that can fulfill the request (and refinements of it with additional requirements)

Matcher Architecture Ontology-Based Matching Shell Topic-Based Matcher Topic-Based Matcher Task-Based Matcher Agent Descriptions Requests subsumptionreformulationabstraction Topic Ontology (e.g., research interests) Activities Ontology (e.g., research activities) Term(s) (e.g. CoABS) Task description (e.g. give demo of TC) ml scai vs aa rn qo rs tv ps scheduling agent printer agent researcher information gathering agent Agents

Matching Task-Based Capabilities and Requests Represent task descriptions more declaratively (give (obj (spec-of demonstration)) (of Teamcore)) (process (obj (spec-of reimbursement)) (for (set-of receipt))) (demo (obj Teamcore)) Reformulations of requests: class partition & sets (setup (obj (equipment))) (setup (obj (lcd))) (setup (obj (vcr))) (demo (obj (Ariadne Teamcore))) (demo (obj (Ariadne))) (demo (obj (Teamcore))) task qualification parameter matches concept in goal further specifies task to be done (i.e., how action is done) allows same method to be used for variety of tasks exploits definitions during matching (demo (obj sw)) = (give (obj (spec-of demonstration)) (of sw))

Benefits Loose coupling  Flexible invocation: requests do not have to mirror the agent descriptions as originally stated  Semantics of the task and its arguments are at the core of the matching process through subsumption and reformulations Declarative representation of task descriptions  Not only data parameters but also task qualification parameters Automatic organization of agent capabilities  Object and task taxonomies are basis for indexing agents Can support partial matching  Suggests alternative formulations of requests when requests do not match exactly the capabilities of available agents

Topic Matching with PowerLoom Express advertisements and requests as logical descriptions Domain ontologies provide term definitions Representation language is KIF (use XML-rendering to embed advertisements on Web pages) Use standard PowerLoom inference and classification mechanism to support matchmaking Use subsumption hierarchy and KILTER partial match technology to support relaxed matching

Example PowerLoom Advertisement Advertisement: (advertises Yolanda-Gil (kappa (?i) (exists (?p) (and (research-interest ?p ?i) (subset-of ?i Knowledge-Acquisition))) Example Query: ”Who is interested in knowledge-based systems?” (retrieve ?p (and (Person ?p) (exists (?ad) (advertises ?p ?ad) (subset-of ?ad (kappa (?i) (exists (?p) (and (research-interest ?p ?i) (subset-of ?i Knowledge-Based-Systems))))))))

Future Work Extend descriptions of agent capabilities: Tasks agents can perform (including results returned) Agent invocation guidelines (including inputs to be provided) Ontological commitments made by the agent Additional agents involved  Agents consulted or invoked to get additional information  Subtasks delegated to other agents Qualifications of the agent  Reliability, efficiency, resources available,… Model of how tasks are performed by the agent Differential properties (comparisons with other agents)

Description of Task-Based Capabilities: Related Work Agent capability languages  LARKS Describing Problem-Solving Methods (e.g., a scheduler)  HPKB PSM Jumpstart  UPML  EXPECT Process Descriptions  NIST PSL  EO Workflow  Process handbook Software reuse

Issues in Task-Based Matching (I) A single agent can perform a wide range of tasks  Currently, agents can do at most a handful (i.e., one)  Nominate alternative agents Flexible invocation  A request to “Register for local conference” is treated by a PA as “Arrange travel to a meeting” Invocations of other agents  Advertise delegation to other agents, consultations to get additional information Describing people’s capabilities  Project assistants as “everything agents” (information agents, matching services, proxies of travel agents, etc.)

Issues in Task-Based Matching (II) Requesters will not provide exact description of required capability e.g.: find route to San Diego  Missing input data: from where?  Imprecise specs: surface route? air route?  Qualification of results expected: 3ft segments? major points? Third parties may need to be invoked to help specify all inputs needed e.g.: find route from LA to San Diego  Route planner agent needs a map as an input  Route planner agent takes lat/long as input, not city names

Research Topics Description of agent capabilities Using ontologies  Which ones  What makes a good ontology Partial match Learning from experience  Refining agent descriptions over time Negotiation  Refining a request based on available agents

Sample KB Sizes WG + ucWG + Cyc’s IKB ‘98 CC + Cyc’s IKB ‘ sec no rep req sec no rep req sec with rep req

Task-Based Matchmaking Yolanda Gil Surya Ramachandran Hans Chalupsky Tom Russ Information Sciences Institute