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

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.

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

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..

Ontologies that need to be shared 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 Domain ontology E.g. BDI model Available sensors and actuators Sensing vocabulary E.g. FIPA’s ACL Acting vocabulary E.g. FIPA’s ACL Bosse and Treur, 2000 Are not really treated

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.

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.

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.

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)

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

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

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

I Know Alice I Know Alice </gb:Belief>... <gb:class>smartresource.non_existing.GiftingBehavior</gb:class> &ex;Date &ex;Is &ex;Date &ex;Is I Know *X* I Know *X* *X* Is Woman *X* Is Woman *X* Likes *thing* *X* Likes *thing* I Gifting *X* I Gifting *X* I Gifted *X* I Gifted *X* I Bought *thing* I Bought *thing* I Gifting *X* I Gifting *X* <x:receiver>*X*</x:receiver><x:object>*thing*</x:object> I Gifted *X* I Gifted *X* </gb:Behavior> <gb:class>smartresource.non_existing.BuyingBehavior</gb:class> I Bought *thing* I Bought *thing* <x:object>*thing*</x:object> </gb:Behavior> An S-APL example (current stage)

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.

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?