SmartResource Platform and Semantic Agent Programming Language (S-APL)

1. SmartResource Platform and Semantic AgentProgramming Language (S-APL) Artem Katasonov and Vagan Terziyan University of Jyväskylä, Finland MATES, Leipzig 24-26 September, 2007

2. Downside of the agent-based approach • 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. • 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. • 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.

3. Major directions towards solution (1) 1. Social level characterization of agent systems • 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). • 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

4. Major directions towards solution (2) 2. Ontological approaches to inter-agent coordination • 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) • 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) • Not much has been done so far..

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

6. Motivation: APL for ontological modeling • Conclusion from the previous slide: Need to be able to ontologically describe not only the domain, but the agents themselves. • How to model agents? Agent Programming Languages (APLs) are an obvious and already elaborated candidate. • 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. • 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.

7. Motivation: Externalization of APL code • 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.

8. Motivation: Semantic APL • 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. SendMessage (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 • 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.

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

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

11. Feeder 1 Directory Facilitator Ontology Interaction scenario: Agent creation 6. Load received scripts 5. 1. Load 4. Give scripts for the roles “FeederAgent”, “Feeder1” and “RABLoader” startup.rdf 3. Agent named “Ontology” 0. 2. Who plays the role “OntologyAgent”? In run.bat: Feeder1:smartresource.core.SmartResourceAgent(DB/startup.rdf, FeederAgent+Feeder1+RABLoader)

12. LS2 LS1 Operator Ontology Scenario: Auction for service selection 7a. I have that role already 7b. “Operator” has right of doing such requests. I need to load that role 10. LS1 and LS2 make offers 11. Operator selects, say, LS1 12. Operators makes service transaction with LS1 9. 5. Load Role “Auction Seller” 8. 6. Make Offer on Price 5. 6. 3. What is the rule for resolving this? 2. Agents “LS1” and “LS2” 1. Who plays the role “LocalizationService”? 4. Starting Auction Directory Facilitator

13. An S-APL example (current stage) <gb:Belief rdf:about="belief1"> <gb:statement>I Know Alice</gb:statement> </gb:Belief> ... <gb:Behavior rdf:about="behavior1"> <gb:class>smartresource.non_existing.GiftingBehavior</gb:class> <gb:trueIf>&ex;Date &ex;Is 08.03</gb:trueIf> <gb:trueIf>I Know *X*</gb:trueIf> <gb:trueIf>*X* Is Woman</gb:trueIf> <gb:trueIf>*X* Likes *thing*</gb:trueIf> <gb:falseIf>I Gifting *X*</gb:falseIf> <gb:falseIf>I Gifted *X*</gb:falseIf> <gb:trueIfGoalAchieved>I Bought *thing*</gb:trueIfGoalAchieved> <gb:addOnStart>I Gifting *X*</gb:addOnStart> <x:receiver>*X*</x:receiver> <x:object>*thing*</x:object> <gb:removeOnEnd>I Gifting *X*</gb:removeOnEnd> <gb:addOnSuccess>I Gifted *X*</gb:addOnSuccess> </gb:Behavior> <gb:Behavior rdf:about="behavior2"> <gb:class>smartresource.non_existing.BuyingBehavior</gb:class> <gb:achievesGoal>I Bought *thing*</gb:achievesGoal> <x:object>*thing*</x:object> <gb:addOnSuccess>I Bought *thing*</gb:addOnSuccess> </gb:Behavior>

14. S-APL (very near) future • Problem: Inability of RDF to restrict the scope of a statement. Every statement is treated as a global truth. • 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 N3 notation. • 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.

15. Other questions for future work • 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)? • What mechanisms are needed for flexibly treating the potential (and likely) conflicts among the roles played by one agent? • 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? • 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?