170 likes | 286 Views
What We Need for Describing Web-based Services. Drew McDermott, Dejing Dou Yale Mark Burstein BBN Doug Smith Kestrel. What’s an Agent?. For our purposes, an agent is a program accompanied by descriptive material that allows other programs to know
E N D
What We Need for Describing Web-based Services Drew McDermott, Dejing Dou Yale Mark Burstein BBN Doug Smith Kestrel
What’s an Agent? For our purposes, an agent is a program accompanied by descriptive material that allows other programs to know what it does and how to interact with it. In other words, agents are run-time composable programs.
Example Agent told: Buy paperback edition of Robo Sapiens for less than $25. • Find partner agent (“brokering”) • Get its service description (in DAML? + or – OIL?) • Translate ontologies if necessary • Find interaction plan Steps:
Example, cont. Buy Robo Sapiens for less than $25. (do-for-some (b – Book a – Agent p – Price) (and (title b “Robo Sapiens”) (sells a b 1 p) (< p (dollars 25))) (buy b a 1 p))
Brokering Find “advertisements” by other agents that use terms found in the current goal description (buy, book, ...) Agent Interoperation Across Multagent System Boundaries J.A. Giampapa, M. Paolucci, and K. Sycara Proceedings of the Fourth International Conference on Autonomous Agents (Agents 2000),
Now What...? Each agent must have an behavior description, a formal description of what it does and how to interact with it. Internal and external forms: Logic: (book-isbn book21 “0-262-13383-0”) DAML: <rdf:Description about=“#book21”> <pub:book_isbn>0-262-13383-0 </pub:book_isbn> </rdf:Description>
Ontology Mismatch What if two agents don’t speak the same language? -- I.e, don’t share the same ontology. This translation problem was to be our main focus, but existing ontologies aren’t interesting enough yet.
Now what…? (cont.) Satisfy Agent1’s goal by finding a series of actions that, according to Agent2’s behavior description, will achieve that goal. This is a planning problem: Given a system description, and initial-state description, find a way of achieving the goal using available actions.
Agent Behavior Description Two sorts of things: • Legal actions, including preconditions and effects • “Scripts:” Hierarchical structures of actions The latter allow for easier planning, the former for more robust planning.
Scripts vs. Actions Script example: How to buy a book from Amazon.com. (series (tag s1 (send Amazon (tuple “in-stock?” isbn-number))) (tag s2 (receive Amazon (step-value s1))) (test (= (step-value s2) book-in-stock) (series (send credit-card...) ...)))
Scripts vs. Actions, cont. Action example: Definition of send and receive: (:action (send ?agt – Agent ?msg - DAML-list) :value (?i - Send-id) :effect (reply-pending ?i ?msg)) (:action (receive ?agt – Agent ?i – Send-id) :precond (reply-pending ?i ?msg) :value (?reply – DAML-list) :effect (when (= ?reply book-in-stock) (know-val-is (in-stock) true)))
Note: Merchants might prefer us to use scripts, so all we can do is buy something. Third parties might supply finer-grained behavior descriptions in terms of actions (for comparison shopping, seeing if a book is in print, etc.).
How Do We Move Forward? Obstacles to planning in DAML-S: • There are too many notations around (DAML+OIL, RDF, N3, XML, RuleML, ….). • None of them is a likely candidate, mainly because all are shy about “expressivity.” • There are specialized subfields (e.g., planning) where people find reasonable tradeoffs between expressivity and tractability. • These subfields have little apparent role in the Semantic Web.
Some Constructive Suggestions • Let DAML+OIL be mainly a type-declaration sublanguage • Agree on (a) a notation that has no obvious expressivity limitations; (b) an XML serialization of that notation. • Define official “chunks” of the language that not everyone will be able to handle. Tools can advertise which chunks they claim to be able to cope with.i
Is Planning Hard in the DAML-S Universe? Hot stuff! Apparently not too hard. It’s not as if Amazon.com wants to present a challenging puzzle to its customers. The main new wrinkles are Come to Daml-s Demo! • Have to plan to gather information (e.g., product id numbers) • May have to loop • Many plans will plausibly work, but will require run-time replanning Challenges!
Extensions to Unpop • New information is generated by some actions, capture as (step-value step-3) • During regression and projection, assume “normal” step values where appropriate. (“Yes, we’ve got that.”) • Insert steps to verify that normal value actually occurred; if not, replain from new situation.
An Example (series (tag s1 (send Amz (in-stock “Wind Done Gone”))) (tag s2 (receive Amz (step-value s1))) (verify (= (first(step-value s2)) in-stock)) (tag s3 (send Amz (buy 1 (second (step-value s2))))))