Q#1: According to the uploaded paper, point out what additional features Hybrid Approaches provide than Imperative and Declarative languages. [10]

Q#2: On what languages paradigm most research in agent-oriented programming languages is based on either Declarative or Imperative languages? Give reasons to support your answer according to the uploaded paper. [10]

SOLUTION:

Q#1: According to the uploaded paper, point out what additional features Hybrid Approaches provide than Imperative and Declarative languages. [10]

The first part of the paper is devoted to the presentationof agent-oriented programming languages, structured according to the existing paradigm on which they build.

In Section 2, we present declarative agent-oriented languages, while Section 3 covers the imperative languages and Section 4 some hybrid languages. The second part will cover various implementations of software infrastructure for agents. These will be structured according to whether Some of the features available in Jason are:

(i) speechact based inter-agent communication (and belief annotation of information sources);

(ii) annotations on plan labels, which can be used by elaborate (e.g., decision-theoretic) election functions;

(iii) fully customisable (in Java) selection functions, trust functions, and overall agent architecture (perception, belief-revision, inter-agent communication, and acting);

(iv) straightforward extensibility (and use of legacy code) by means of user-defined “internal actions”;

(v) a clear notion of a multi-agent environment, which is implemented in Java (this can be a simulation of a real environment, e.g., for testing purposes before the system is actually deployed). Jason has a simple IDE which is discussed in Section 5.

Q#2: On what languages paradigm most research in agent-oriented programming languages is based on either Declarative or Imperative languages? Give reasons to support your answer according to the uploaded paper. [10]

This paper surveys recent research on programming languages and development tools for Multi-Agent

Systems. It starts by addressing programming languages (declarative, imperative, and hybrid), followed by integrated development environments, and finally platforms and frameworks. To illustrate each of these categories, some systems were chosen based on the extent to which European researchers have contributed to their development. The current state of these systems is described and, in some cases, indications of future directions of research are given.

………………………………………….

Q#1: According to the uploaded paper, point out what additional features Hybrid Approaches provide than Imperative and Declarative languages. [10]Hybrid ApproachesVarious well-known agent languages combine declarativeand imperative features. In this section we describe agentprogramming languages which are declarative while at thesame time providing some specific constructs allowing forthe use of code implemented in some external imperativelanguage. These constructs serve as a means for the use oflegacy code. The languages chosen to illustrate the hybridapproach are: 3APL, Jason, IMPACT, Go!, and AF-APL.3APL (An Abstract Agent Programming Language“triple-a-p-l”) is a programming language for implementingcognitive agents that have beliefs, goals, and plansas mental attitudes, can generate and revise their plans toachieve their goals, and are able to interact with each otherand with the environment they share with other agents. Thefirst version of 3APL was designed by Hindriks et al. atUtrecht University [28]. Since its initial design, the 3APLprogramming language has been subject to continuous development[17, 16].One of the main features of 3APL consists of programmingconstructs to implement mental attitudes of an agentas well as the deliberation process which manipulates them[15]. In particular, 3APL allows direct specification ofmental attitudes such as beliefs, goals, plans, actions andreasoning rules. Actions form the basic building blocks ofplans and can be internal mental actions, external actions,or communication actions. The deliberation-related constructsallow the implementation of selection and executionof actions and plans through which an agent’s belief basecan be updated and through which the shared environmentcan be modified. It also allows the selection and applicationof reasoning rules through which the plan base can bemodified.The 3APL programming language is designed so as torespect a number of software engineering and programmingprinciples such as separation of concerns, modularity,abstraction, and reusability. It also supports the integrationof Prolog (declarative) and Java (imperative) programminglanguages. Interested readers will find in the 3APLuser guide (3APL HomePage) a numberof illustrative toy-problem applications such as the “blocksworld”, Axelrod’s tournament, an English auction system,and the Contract Net protocol. 3APL has also been appliedto the implementation of the high-level control of mobilerobots. In particular, 3APL is being used for controlling thebehaviour of SONY AIBO robots and to implement smalldevicemobile applications.Jason is an interpreter, implemented by R.Bordini andJ.Hübner, for an extended version of AgentSpeak(L), alogic-based agent-oriented programming language introducedby A. Rao in [43]. The language is influenced bythe work on the Beliefs-Desires-Intentions (BDI) architectureand BDI logics [44]. The semantics of the extendedlanguage (which we call simply AgentSpeak), given byBordini and colleagues, was recently revised and appearsin [55]. The core of the interpreter available with Jasonis in fact an implementation of that operational semantics.Jason is available Open Source under GNU LGPLat http://jason.sourceforge.net [6]. Althoughthe documentation is available at that URL, the best mate rial for an overview of the work on Jason is [7].Some of the features available in Jason are: (i) speechactbased inter-agent communication (and belief annotationof information sources); (ii) annotations on plan labels,which can be used by elaborate (e.g., decision-theoretic)selection functions; (iii) fully customisable (in Java) selectionfunctions, trust functions, and overall agent architecture(perception, belief-revision, inter-agent communication,and acting); (iv) straightforward extensibility (anduse of legacy code) by means of user-defined “internal actions”;(v) a clear notion of a multi-agent environment,which is implemented in Java (this can be a simulation of areal environment, e.g., for testing purposes before the systemis actually deployed). Jason has a simple IDE whichis discussed in Section 5.IMPACT is a system developed by Subrahmanian etal. [49], with the main purpose of providing a frameworkto build agents on top of heterogeneous sources of knowledge,i.e., to transform legacy code into agents that cancommunicate and act. To “agentise” such legacy code, IMPACTprovides the notion of an agent program written overa language of so-called code-calls. A code-call can be seenas an encapsulation of whatever the legacy code is, representedlogically through conditions and queries on the resultsproduced by such code. These are used in clauses,that form agent programs, determining constraints on theactions that are to be taken by agents. Actions in IMPACTuse some deontic notions such as agent actions being, ata certain time, “obligatory”, “permitted”, “forbidden”, etc.Such agent programs and their semantics resemble logicprograms extended with deontic modalities. The semanticsis given by the notion of a rational status sets, whichare generalisations of the notion of stable models in logicprogramming.The IMPACT platform provides a number of features,including agent deployment over a network, registrationof available agent services and yellow-pagefacilities. Information on the IMPACT platform isavailable at http://www.cs.umd.edu/projects/impact/. The framework has been extended to supportalso temporal or probabilistic reasoning [20]. A recentoverview of the IMPACT language and platform can befound in [21].Go! [12] is a multi-paradigm agent programming language,with a declarative subset of function and relationdefinitions, an imperative subset comprising action proceduredefinitions, and rich program structuring mechanism.Based on the symbolic programming language April [36],Go! extends it with knowledge representation features oflogic programming, yielding a multi-threaded, stronglytyped and higher order (in the functional-programmingsense) language.Inherited from April, threads primarily communicatethrough asynchronous message passing. Threads, executingaction rules, react to received messages using patternmatching and pattern-based message reaction rules. Acommunication daemon enables threads in different Go!processes to communicate transparently over a network.Typically, each agent will comprise several threads, eachof which can directly communicate with threads in otheragents. Threads within a single Go! process, hence in thesame agent, can also communicate by manipulating sharedcell or dynamic relation objects. As in Linda tuple stores,these elements are used to coordinate the activities of differentthreads within an agent. Go! is strongly typed, whichcan often reduce the programmer’s burden, and compiletimetype checking improves code safety. New types canbe declared and thereby new data constructors can be introduced.The design of Go! took into consideration critical issuessuch as security, transparency, and integrity, in regards tothe adoption of logic programming technology. Featuresof Prolog that lack a transparent semantics, such as the cut(‘!’) were left out. In Prolog the same clause syntax isused both for defining relations, with a declarative semantics,and for defining procedures which only have an operationalsemantics. In Go!, behaviour is described usingaction rules that have a specialised syntax.Agent Factory Agent Programming Language (AFAPL)is the core programming language that resides at theheart of Agent Factory, which will be reviewed in Section5. AF-APL is originally based on Agent-Oriented Programmingas first put forward by Y.Shoham [48], but wasrevised and extended with BDI concepts, such as beliefsand plans. The syntax and semantics of the AF-APL languagehave been derived from a logical model of how anagent commits itself to a course of action. Details of thismodel can be found in [13, 46]. Specifically, the modeldefines the mental state of an agent to be comprised oftwo primary mental attitudes: beliefs and commitments.In AF-APL, the belief set is comprised of a set of declarationsabout the current state of the environment. Agentsare situated, given that an AF-APL programmer can declareexplicitly, for each agent, a set of sensors referredto as perceptors and a set of effectors known as actuators.Perceptors are realized as instances of Java classes that definehow to convert raw sensor data into beliefs that maybe added to the belief set of the agent. Similarly, an actuatoris realized as an instance of a Java class, which hastwo responsibilities: (1) to define the action identifier thatshould be used when referring to the action that is realizedby the actuator, and (2) to contain code that implements theaction. Collectively, these declarations are termed the embodimentconfiguration of the agent, and they are specifiedwithin the agent program.Q#2: On what languages paradigm most research in agent-oriented programming languages is based on either Declarative or Imperative languages? Give reasons to support your answer according to the uploaded paper. [10]Most research in agent-oriented programminglanguages is based on declarative approaches. Thereare many declarative solutions, most of them logic based.Purely imperative languages are unusual in the Agents literature,as in essence they are inappropriate for expressingthe high-level abstractions associated with agent systemsdesign. On the other hand, as we saw above, agent-orientedprogramming languages tend to allow for easy integrationwith (legacy) code written in imperative languages. Interestingly,the characteristics of the underlying agent architecturesdetermine that it is often more appropriate to useinterpreters rather than compilers.

Read lecture # 29.

6 Common Attributes of Knowledge Work and Knowledge Workers

The fact that knowledge workers primarily rely on their brains in their jobs rather than their bodies means that they have some attributes in common. These aren’t terribly surprising, and they all follow from a few basic principles and observations, but they need to be stated. Most derive from the fact that knowledge work is less structured and perhaps less structurable than administrative or production work.

The basic principles and observations follow below:

1. Knowledge Workers like Autonomy
One important aspect of knowledge workers is that they don’t like to be told what to do. Thinking for a living engenders thinking for oneself. Knowledge workers are paid for their education, experience, and expertise, so it is not surprising that they often take offense when someone else rides roughshod over their intellectual territory.

Of course, knowledge workers don’t like for their work to be ignored, and there are some things they like to be told, such as the broader significance and implications of their tasks and jobs. But they’d generally like the details to be left to them.

This autonomy is in part a natural result of the nature of knowledge work. Since it’s difficult to tell whether a knowledge worker is actually thinking at any given moment, supervisors pretty much have to take their word for it.

The knowledge worker also knows the circumstances in which he or she thinks best. If a computer programmer tells the boss that he is most productive working from 8PM to 4AM, smart bosses would try to facilitate that arrangement. The outputs of knowledge work are also difficult to specify in great detail, so that is generally left up to the worker.

2. Specifying the detailed steps and flow of knowledge-intensive processes is less valuable and more difficult than for other types of work.
This is a corollary of my first generalization about knowledge work.

Knowledge workers don’t like to be told what to do, and they also don’t like see their jobs reduced to a series of boxes and arrows.

Typically, when we want to improve performance we begin by breaking down the structure of the task into its constituent elements. This has been the case at least since Frederick Taylor’s day, if not before. The idea is that when broken into piece-parts, knowledge work processes can be more easily followed and measured, and unnecessary steps eliminated altogether.

However, this approach often doesn’t work very well for knowledge work and workers.

In my experience, knowledge workers will often resist describing the steps they follow in their work. The more complex and knowledge-intensive the work, the more likely this will be true. Perhaps there are so many variations that describing the typical flow of work is impossible. Knowledge work also often involves a high degree of iterative collaboration among knowledge workers, and this may be difficult to describe or model.

Even if you can get a knowledge worker to describe his or her work process, it may not be a very helpful description. First, the work flow may not be very similar to another worker’s description of the supposedly same process.

Secondly, the steps may seem maddeningly inefficient: “First I come up with an idea. Then I think about it for a while. Then I talk to my lab partner about it. Then I think about the reactions she’s given me.” Such a process would be anathema to a stopwatch-packing Taylorist, but it’s often how knowledge workers – particularly those involved in knowledge creation activities – work.

3. “You can observe a lot by watching.” (Lawrence Peter Berra)
A natural follow-on to the previous attribute of knowledge workers is that if you can’t get them to describe their work in detail, you have to observe it in detail. Systematic observation – also known as “shadowing” or “ethnography” – is often a way to better understand how knowledge workers do their work.

4. Knowledge workers usually have good reasons for doing what they do.
In the days of business process reengineering, we assumed that smart analysts could quickly figure out better ways of doing work. This was, in fact, often true. Nobody had ever thought about many administrative and operational processes before, and improvements were easily identified.

It’s not so easy with knowledge work, which is one of the reasons why we have to observe it closely. Knowledge workers have typically thought about why and how they do their work, and have made many of the obvious improvements to it. There is probably a reason behind almost everything they undertake (or at minimum a logical rationalization).

If improvements are going to be identified, it’s probably only after serious and deep study.

5. Commitment matters.
In the industrial economy, one could do a job with one’s body even when the brain and heart weren’t committed to the job.

But this isn’t the case for knowledge work. It’s unlikely that you’ll get great performance out of a knowledge worker if he or she isn’t mentally and emotionally committed to the job.

This fact has a number of ramifications. Chief among them is that knowledge workers need some say in what they work on and how they do it.

There is nothing that limits commitment like being told what to work on by someone else. This factor is behind, for example, the famous 3M approach of giving researchers 15% of their time to work on something they think is important to the company.

Obviously knowledge workers are generally willing to do some things that others ask (or even tell) them to do, but a degree of voluntarism helps a lot.

6. Knowledge workers value their knowledge, and don’t share it easily.
Knowledge is all that knowledge workers have – it’s the tool of their trade, the means of their production.

It’s therefore natural that they would have difficulty relinquishing or sharing it in such a way that their own jobs might be threatened.

In the early days of knowledge management, when companies were beginning to talk about sharing knowledge within and across organizations, I used to say, “Sharing knowledge is an unnatural act.”

I also mentioned that, “Of course, unnatural acts are committed every day.”

Companies just needed to put the necessary incentives and assurances in place to ensure that people were willing to share their knowledge.