Artem Katasonov University of Jyv skyl 31.10.2007

1. Artem KatasonovUniversity of Jyv�skyl�31.10.2007

2. 2 Outline Benefits and drawbacks of Agent-Oriented Software Engineering (AOSE) Motivation for our approach SmartResource / Ubiware platform Semantic Agent Programming Language (S-APL)

3. 3 Roots of the agent technology

4. 4 Agent-Oriented Software Engineering (AOSE) From the implementation point of view, agents are a next step in the evolution of software engineering approaches and programming languages. It is a step following the trend towards increasing degrees of localization and encapsulation in the basic building blocks of the programming models Structures (e.g., in C) � localizing data Objects (e.g., in C++ and Java) � localizing, in addition, code, i.e. an entity�s behavior Agents � localizing, in addition, the purpose of existence, the thread of control and logic of action selection. An agent is a programming entity that is autonomous in run-time, does not need to be directly controlled. When we apply AOSE, not only the system as a whole, but also its components are autonomous, i.e. agents.

5. 5 AOSE vs. OOSE OOSE: Stakeholders, their goals, knowledge, intentions, collaboration, etc. Components, objects, their services, invocations, dependencies, etc

6. 6 Drawback of AOSE 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. Emergence of a solution that would allow flexible yet predictable operation of agent systems seems to be a prerequisite for wide-scale adoption of AOSE.

7. 7 Direction 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). Modeling agent organizations in a way similar to human organizations Researchers in multi-agent systems have contributed with, among others, various methodologies for designing MAS, such as Gaia, TROPOS, and OMNI. Such methodologies normally focus on the notion of an organizational role Organizational policies, norms

8. 8 OMNI Organizational Model for Normative Institutions (OMNI) �allows the balance of global organizational requirements with the autonomy of individual agents�. OMNI: elaborates on the organizational context of a MAS, defines the relationship between organizational roles and agents enacting those roles, discusses how organizational norms, values and rules are supposed to govern the organization�s behavior and thus to put restrictions on individual agents behaviors, defines abstract languages for specification of norms, values and rules.

9. 9 OMNI (2) OMNI touches only on a very abstract level the question about how the individual agents will be implemented or even function; the agents are treated as rather atoms. One reason is that it is (reasonably) assumed that the agent organization�s designer may have no direct control over the design of individual agents. The organization designer develops the rules to be followed and enforcing policies and entities, such as �police� agents, while development of other agents is done by external people or companies. One of few concrete implementation requirements mentioned in OMNI is that a rule interpreter must be created that any agent entering the organization will incorporate, somehow. OMNI framework also includes explicitly the ontological dimension, which is restricted, however, to a domain ontology only.

10. 10 Direction towards solution 2 2. Ontological approaches to inter-agent coordination To enable agents to communicate their intentions with respect to future activities, and reason about them in real time (Tamma et al.,2005). 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). Is not yet studied much by the scientific community. Tamma et al.,2005 is one of the first endeavors into this direction, which however only introduced and analyzed some of the relevant concepts, such as resource, activity, etc.

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

12. 12 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 (except approaches where the agents are able to communicate their plans encoded in an APL).

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

14. 14 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: Sesame, Joseki.

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

16. 16 SmartResource Platform Ongoing effort at the University of Jyv�skyl�. One of the results of the SmartResource project 2004-2007. Is further developed in the follow-up UBIWARE project 2007-2010. May be seen as extension of JADE with a cognitive agent architecture. Major distinctive features: Utilization of the RDF-based Semantic Agent Programming Language (S-APL), instead of common Prolog-like languages. S-APL programs are one per organizational role, not one per agent. Externalization of behavior prescriptions, i.e. agents access S-APL documents from organizational repositories. Perceptors and actuators (called reusable atomic behaviors) are dynamically managed and can also be accessed from organizational repositories.

17. 17

18. 18

19. 19

20. 20

21. 21

22. 22

23. 23 Starting SmartResource agents Following the JADE convention: <name>:ubiware.core.UbiwareAgent(<scripts>,<roles>) <scripts> is the star(*) separated list of the initial behavior models <roles> is plus(+) separated list of the roles. Platform provides the behavior model startup.sapl, which has to be loaded by an agent at startup in order to enable it to remotely access behavior models from an OntologyAgent. Parameter <roles> is needed only in startup.sapl is one of the scripts Includes also the rule for engaging DFLookupBehavior. Platform provides also the behavior model RABLoader.sapl, which has to be loaded by an agent in order to enable it to remotely access atomic behaviors from an OntologyAgent. It includes rules for requesting, receiving, and (if needed) unzipping the behavior files.

24. 24

25. 25

26. 26 Semantic Agent Programming Language (S-APL) Everything is a belief. All other mental attitudes such as desires, goals, commitments, behavioral rules are just complex beliefs. Every belief is either a semantic statement (subject-predicate-object triple, e.g. �John Loves Mary�) or a linked set of such statements. Every belief belongs to a context container that restricts the scope of validity of that belief. Beliefs have any meaning only inside their respective contexts (this convention goes beyond normal RDF where everything is global truth). Statements can be made about contexts, i.e. contexts may appear as subjects or/and objects of triples. Such statements give meaning to contexts. This also leads to a hierarchy of contexts (not necessarily a tree structure though). There is the General Context G, which is the root of the hierarchy. G is the context for global beliefs of the agent (what it believes to be true here and now ). Nevertheless, every local belief, through the hierarchical chain of its contexts, is linked to G.

27. 27 S-APL notation (subset of Notation3): A statement is a white-space-separated sequence of subject, predicate and object, i.e. S P O Dot ( . ), followed by a white space, separates statements of the same level, i.e. S P O . S P O Semicolon ( ; ) , followed by a white space, allows making several statements about the same subject, i.e. S P O ; P O Comma ( , ) , followed by a white space, allows making several statements having common subject and predicate, i.e. S P O , O { } denotes reification, it may appear as the subject or the object of a statement and has to include inside itself one or more other statements, e.g. S P { S P O } or { S P O } P { S P O }. Reification always implies a context; however, the relation is not necessarily 1-to-1. E.g. {S P O} P O ; P O implies that the statement in {} is linked to two different contexts defined as given. Colon ( : ) is used to specify an URI as a combination of the namespace and the local name, i.e. ns:localname There can be default namespace, the colon is used anyway, i.e. :localname @prefix prefix: namespace links a prefix to a namespace URIs given directly are to be inside < >, i.e. <http://someaddress> Literals containing whitespaces are to be inside � �, i.e. �some literal� Comments are java-style, i.e. /* */

28. 28 S-APL: simple beliefs Simple belief (two below are equivalent) :John :Loves :Mary {:John :Loves :Mary} gb:is gb:truth Complex belief {:John :Loves :Mary} :accordingTo :Bill Goal / desire: gb:I gb:want {:John :Loves :Mary} The prefix gb: is used here to denote the ontology of S-APL In S-APL, making a statement has the meaning of adding it to the agent�s beliefs.

29. 29 S-APL: commitments Unconditional commitment to an action: {gb:I gb:do java:ubiware.shared.RequestSenderBehavior} gb:configuredAs {x:receiver gb:is :John . x:content gb:is �bla bla� . gb:Success gb:add {:John :was :notified} } Special statements to add or remove beliefs: the subject can be gb:Start, gb:End, gb:Success, and gb:Fail. The predicate is either gb:add or gb:remove. Sequential plan: {gb:I gb:do ...} gb:configuredAs { ... gb:Success gb:add {gb:I gb:do ...} }

30. 30 S-APL: commitments (2) Unconditional commitment to removing a belief: gb:I gb:remove {:John :Loves :Mary} Conditional commitment: {:John :Loves :Mary} => {gb:I :state :busy . {gb:I gb:do a:SendMail} gb:configuredAs {...} } => is the shorthand for gb:implies. If the left side of => is truth (beliefs are connected with AND), the right side is copied into G. The commitment is removed after that. Conditional commitment that creates another conditional commitment: {...} => { {...} => {...} }

31. 31 S-APL: additional conditions Exclusive condition: {:John :Loves :Mary . gb:I gb:doNotBelieve {:John :was :notified} } => {...} If the object of gb:doNotBelieve matches G, the left side of => is false. If there are several gb:doNotBelieve, they are connected with OR) Commitment with a guard condition: { {...} => {...} } gb:is gb:truth ; gb:existsWhile {...} If the object of gb:existsWhile is false, its subject is removed � in this case, the commitment is dropped.

32. 32 S-APL: additional conditions (2) Prerequisites: { {...} => {...} } gb:requires {...} If the left side of => is truth but some of the conditions in the object of gb:requires are false, those are wrapped as gb:I gb:want .. (i.e. as goals) and added to G Action that attempts achieving a goal: {gb:I gb:want {:John :Loves :Mary}} >> {...} >> is the shorthand for gb:achievedBy. It works similar to => but, in addition, the goal is removed (technically, it is moved to context for goals under work). Persistent behavior rule (not removed upon execution) { {...} => {...} } gb:is gb:Rule

33. 33 S-APL: querying constructs Matching with variables {{:John :Loves ?x} :accordingTo ?y. ?x gb:is :Girl} => {gb:I gb:do a:SendMail} gb:configuredAs {x:receiver gb:is ?x...} If there can be found some values of ?x and ?y so that the beliefs are present in G, the rule will be executed. The variables will be bind to the first found matching values, and those will be used in the right side of => In future, we plan to introduce {�} gb:All ?x so the rule will be executed for all matching values of a variable. Matching with * (gb:Anything) {:John :Loves *} => {�} Filtering predicates (evaluated by the agent�s engine rather than matched against G): ?x > 5. ?y gb:regex �S.*h� (< ,<= , >=)

34. 34

35. 35 Inter-agent communication Uses S-APL as well E.g. request gb:I gb:want { gb:You gb:answer { {?x :Loves ?y } gb:All ?x }} Response is one of :John :Loves :Mary gb:I gb:doNotBelieve {?x :Loves ?y} Request for action: gb:I gb:want { {gb:You gb:do ...} gb:configuredAs {...} }

36. 36 Advantages of S-APL Simple model (triples in hierarchical contexts) that allows implementing any feature found in existing APLs. Expressive power is even greater than in existing APLs, because of full symmetry (everything is a belief): e.g. rules upon execution can add other rules of any complexity. Behavior specification is done using semantic predicates (e.g. implies, existsWhile) Formally defined in an ontology. Language is extensible with other such predicates. Reusable Atomic Behaviors and their parameters are also resources that can (and should) be ontologically modeled. So, there is a basis for sharing all 5 ontologies (Ext, Ment, Body, In and Out), and thus for better understanding among agents.

37. 37 SmartResource Platform: Future work What mechanisms are needed for flexibly treating the potential (and likely) conflicts among the roles played by one agent? 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 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?