Smart Resource Platform and Semantic Agent Programming Language

Smart. Resource Platform and Semantic Agent Programming Language (S-APL) Artem Katasonov and Vagan Terziyan University of Jyväskylä, Finland MATES, Leipzig 24 -26 September, 2007

Downside of the agent-based approach g Although the flexibility of agent interactions has many advantages when it comes to engineering complex systems, the downside is that it leads to unpredictability in the run time system; as agents are autonomous, the patterns and the effects of their interactions are uncertain. g It is common in specific systems and applications to circumvent these difficulties, i. e. to reduce the system’s unpredictability, – By using interaction protocols whose properties can be formally analyzed – By adopting rigid and preset organizational structures, – By limiting the nature and the scope of the agent interplay. g These restrictions also limit the power of the agent-based approach; thus, in order to realize its full potential some longer term solutions are required. N. R. Jennings. On agent-based software engineering. Artificial Intelligence, 117(2): 277– 296, 2000.

Major directions towards solution (1) 1. Social level characterization of agent systems g The need for a better understanding of the impact of sociality and organizational context on an individual’s behavior and of the symbiotic link between the behavior of the individual agents and that of the overall system (Jennings, 2000). g Methodologies for designing MAS, such as Gaia, TROPOS, and OMNI. – Modeling behavior of an agent as being defined by the roles the agent plays in one or several organizations. – Organizational policies, norms

Major directions towards solution (2) 2. Ontological approaches to inter-agent coordination g To enable individual agents to represent and reason about the actions, plans, and knowledge of other agents to coordinate with them (Jennings et al. , 1998) g Need for common vocabulary for coordination to enable agents to communicate their intentions with respect to future activities, and reason about them in real time (Tamma et al. , 2005) g Not much has been done so far. .

Ontologies that need to be shared Ext. Ont(A) - properties of the external world Ment. Ont(A) - internal mental properties of the agent Body. Ont(A) - properties of the agent's (physical) body In. Ont(A) - properties of the sensory input - properties of the communication input Out. Ont(A) - properties of the action output - properties of the communication output Bosse and Treur, 2000 Domain ontology E. g. BDI model Available sensors and actuators Sensing vocabulary E. g. FIPA’s ACL Acting vocabulary E. g. FIPA’s ACL Are not really treated

Motivation: APL for ontological modeling g Conclusion from the previous slide: Need to be able to ontologically describe not only the domain, but the agents themselves. g How to model agents? Agent Programming Languages (APLs) are an obvious and already elaborated candidate. g Normally, APL code is assumed to be written by the developer of an agent and either compiled into an executable program or interpreted in run-time but remaining an agents intrinsic and static property. g Normally, APL code is not assumed to ever come from outside of the agent in run-time, neither shared with other agents in any way.

Motivation: Externalization of APL code g g Methodologies like OMNI describe a role with a set of rules, and APLs are rule-based languages. So, using an APL for specifying a role is natural. Then, APL code corresponding to a role should naturally be a property of and controlled by the organization, and accessed by the agents enacting the role potentially even in the run-time. This would also enable the organization to modify the role code if needed. Additionally, the agents may access a role’s APL code not only in order to enact that role, but also in order to coordinate with the agents playing that role: – An agent can send to another agent a part of its APL code to communicate its intentions with respect to future activities. – If a role’s code is made public inside the organization, the agents may access it in order to understand how to interact with, or what to expect from, an agent playing that role.

Motivation: Semantic APL g g In other words, why normally the role of APL code is not considered beyond the development stage, we propose to do exactly that – to extend the role of APL into the run-time stage. Problems, if to consider existing APLs: – Semantics of n-ary predicates is difficult to explicitly define, e. g. Send. Message (A, B, C) – who sends what to who? – Code in existing APLs is, roughly speaking, a text. A database-based solution would be better: • To manage huge amounts of data (beliefs, rules) • To be able to easily access a part of the code, not the whole document g Solution: RDF-based APL – RDF data model, i. e. set of subject-predicate-object triples, allows explicit definition of semantics. Languages for that exist, such as OWL. – Triples can be stored in a database. Can be Oracle or free ones.

Motivation: Summary In a nutshell: g Let’s start treating agents’ programs as data g If it is data, let’s use the semantic approach (advantages are well-known)

Smart. Resource Platform Architecture . class Activity Assign Role . class Behavior Models activity Live activity Smart. Resource Agent Beliefs and goals storage Reusable atomic behaviors (RABs) g g g Role-based behavior models, in S-APL Externalization of behavior models On-demand access of RABs Pool of Atomic Behaviours Ontology of the Roles

Interaction scenario: Agent creation 6. Load received scripts 5. 1. Load startup. rdf Feeder 1 In run. bat: Feeder 1: smartresource. core. Smart. R esource. Agent(DB/startup. rdf, Feeder. Agent+Feeder 1+RABLoader) Ontology y” og ol nt “O ed le ro ? am tn he nt ” s t ge en ay A Ag pl ogy 3. ho ol W nt 2. “O 0. r 4. Give scripts fo the roles t”, “Feeder. Agent”, “Feeder 1” and r” “RABLoader” Directory Facilitator

Scenario: Auction for service selection 7 a. I have that role already 7 b. “Operator” has right of doing such requests. I need to load that role 10. LS 1 and LS 2 make offers 11. Operator selects, say, LS 1 3. W ha ti re s th so e lvi rul ng e th for is? 12. Operators makes service transaction with LS 1 Operator LS 1 5. Load Role “Auction Seller” 6. Make Offer on Price 5. 9. LS 2 8. Ontology 6. 2. Agents “LS 1” and “LS 2” 1. Who plays the role “Localization. Service”? 4. Starting Auction Directory Facilitator

An S-APL example (current stage) <gb: Belief rdf: about="belief 1"> <gb: statement>I Know Alice</gb: statement> </gb: Belief>. . . <gb: Behavior rdf: about="behavior 1"> <gb: class>smartresource. non_existing. Gifting. Behavior</gb: class> <gb: true. If>&ex; Date &ex; Is 08. 03</gb: true. If> <gb: true. If>I Know *X*</gb: true. If> <gb: true. If>*X* Is Woman</gb: true. If> <gb: true. If>*X* Likes *thing*</gb: true. If> <gb: false. If>I Gifting *X*</gb: false. If> <gb: false. If>I Gifted *X*</gb: false. If> <gb: true. If. Goal. Achieved>I Bought *thing*</gb: true. If. Goal. Achieved> <gb: add. On. Start>I Gifting *X*</gb: add. On. Start> <x: receiver>*X*</x: receiver> <x: object>*thing*</x: object> <gb: remove. On. End>I Gifting *X*</gb: remove. On. End> <gb: add. On. Success>I Gifted *X*</gb: add. On. Success> </gb: Behavior> <gb: Behavior rdf: about="behavior 2"> <gb: class>smartresource. non_existing. Buying. Behavior</gb: class> <gb: achieves. Goal>I Bought *thing*</gb: achieves. Goal> <x: object>*thing*</x: object> <gb: add. On. Success>I Bought *thing*</gb: add. On. Success> </gb: Behavior>

S-APL (very near) future g Problem: Inability of RDF to restrict the scope of a statement. Every statement is treated as a global truth. g We now move to a data model, where every statement belongs to some context (and has meaning only inside it) – Expressible in plain RDF, but requires different reasoning engines. – To keep readability of code, we give-up on RDF/XML and move to N 3 notation. g Significantly increased expressive power and symmetry: – No need for Belief, Goal, Behavior constructs. Everything is just a belief, either simple or complex. – Complex (in context) beliefs can be used as e. g. a rule’s preconditions. – E. g. : A rule, upon execution, can create another rule.

Other questions for future work g Is it important and, if yes, how to implement the separation between a role’s capabilities (individual functionality), and the business processes in which this role can be involved (complex functionality)? g What mechanisms are needed for flexibly treating the potential (and likely) conflicts among the roles played by one agent? g What would be concrete benefits of and what mechanisms are needed for accessing and using a role’s script by agents who are not playing that role but wish to coordinate or interact with an agent that does? g How to realize an agent’s roles as higher-level commitments of the agent that restrict its behavior, still leaving freedom for learning and adaptation on lower-levels, instead of totally and rigidly prescribing the behavior?