Grid Computing

Need to add examples and need to work on motivating the reader to read my thesis! Grid Computing was suggested, i.e. the sharing, selection and aggregation of distributed and ubiquitous resources and services. As an example: universities making available their idle processors (?) for access by other universities.

Passed my viva

Huge relief. Got a month or so's worth of changes/additions/removals but passed and very nearly almost there! alhamdulillah.

Viva preparation advice

Six points of advice from (Dr) Sarah Junaid passed on (summarised) to me by Soumaya:

1. Read up throughly all the papers written by examiners that are relavant to your thesis;
2. Read up thoroughly the 5-6 papers that you quote most, and if you have time the other papers that are important but do not read them so thoroughly;
3. Read up on the basics;
4. Read up on the difficult concepts - make a plan of all the concepts that you need to know about;
5. Prepare a 10 min intro about why your research is important, what is the big picture;
6. Put notes in your thesis where you know there are issues so that you IF they bring it up you can show them that you are aware about them.

PhD Submitted, Updating CV, MEng Modules

Submitted my PhD thesis today. Huge sense of relief maa sha Allah. Updating my CV now getting ready for the inevitable job hunt.

Removing the MEng course modules from my CV and Blogging here for the record...

4th Year Modules: Computing for Optimal Decisions, Grid Computing, Intelligent Data and Probabilistic Inference, Knowledge Representation, Management (Economics and Law), Modal and Temporal Logic, Multi-Agent Systems, Network Security

3rd Year Modules: Advances in Artificial Intelligence, Bioinformatics, Computational Finance, Concurrent Programming, Decision Analysis, Operations Research, Organisations & Management Processes, Software Engineering Methods

2nd Year Modules: Artificial Intelligence, Compilers, Complexity and Computability, Computational Techniques, Concurrent Programming, Networks and Communications, Operating Systems, Software Engineering, Statistics

1st Year Modules: Computer Systems, Databases, Discrete Mathematics, Hardware, Logic, Mathematical Methods and Graphics, Programming, Reasoning about Programs

... 8 good long years at Imperial College coming to an end!

PhD application

As well as the patient-appointments scenario which I have, i.e. making as many patients as possible happy with their allocated appointment, another one could be to give as many employees as possible a task which they like (or a task which is within their capacity perhaps).

Deadlock in Implementation

After quite a few days debugging finally spotted the problem...

Consider the following case:

1) a1 initiates a proposal with a3 and a4.
2) a2 initiates the same proposal with a3 and a4.
3) a3 responds to a1 with acceptance.
4) a4 responds to a2 with acceptance.

In this situation a3 cannot respond to a2 and a4 cannot respond to a1. Both are stuck.

Now need to think what to do about it!

Assumptions as contraries of assumptions

I wanted the desirable property of not allowing two conflicting assumptions to hold simultaneously and thus added conflicting assumptions to the set of contraries for each assumption, e.g. asmHas(X,R) is set as a contrary of asmNotHas(X,R) and vice versa.

This introduces a couple of problems though:
(1) The defences of arguments get really large since there are now so many more attacks to consider/counter.
(2) Incorrectness! e.g. the contrary of asmHas(a2,r5) is notHas(a2,r5) supported by asmNotHas(a2,r5), but asmHas(a2,r5) counter-attacks asmNotHas(a2,r5) so the initial attack doesn't hold (wrongly).

I have commented out for now (in the implementation) assumptions as contraries of assumptions.

Attempts at summing up my PhD

A couple of attempts with two different people from the last two days to sum up my PhD...

Attempt 1:

... the rough area is "distributed artificial intelligence". The concept of "artificial intelligence" (AI) is to make smart computer programs. Within AI is the concept of "agents" - autonomous, proactive, reactive computer programs - that, given a goal or task, should be able to go off, work out how best to achieve it and achieve it. I look at a specific problem (can explain upon request) making use of "multi-agent systems", where multiple "agents" have to collaborate/cooperate/dialogue (can elaborate upon request) to achieve their individual goals, and as a result the "society" of agents also benefits...

Attempt 2:

... the rough area is "distributed artificial intelligence", or, more specifically "multi-agent systems". An "agent" is an "autonomous", "proactive", "reactive" computer program - that, given a "goal" or "task", should be able to go off, work out how best to achieve it and achieve it. I model my agents, their internal reasoning/decision-making mechanisms, using a form of logic based on "argumentation", and the interactions between the agents by means of communication protocols termed "dialogues". Concretely, I am trying to apply my framework to a specific problem (the "resource reallocation problem" - can explain upon request) where multiple agents have to collaborate/cooperate/dialogue to achieve their individual goals, and as a result the "society" of agents also benefits...

I thought I was getting better at explaining my PhD topic. From the responses I received, apparently not!

Karunatillake's Thesis - Chapter 3

My first set of questions sent to Nishan C. Karunatillake regarding chapter 3 of his thesis:

Thanks for the response.

Sorry if my questions are really technical/low-level. It's just that I am developing a model for multi-agent argumentative negotiation, I came across your work and I am trying to see if my model could map to your language, protocol etc. I have not read beyond Chapter 3 yet, so I apologise if some of my questions are answered later. Please let me know if that is the case.

I'll try ask only a few questions at a time, as occurred to me whilst working sequentially through the chapter, so as not to bombard you and in case questions that occurred later become clear.

Here goes...

- Looking at the 'Challenge' communicative predicate described as part of the protocol (page 79), one of the pre-conditions for challenging a rejection (or assertion) is that there be no 'reason' for the rejection (assertion respectively) in the agent's knowledge-base. Could it not be possible (in the context of this thesis) that there is a reason for rejecting, as well as a (counter-)reason for not rejecting in the agent's knowledge-base at the same time? Or is it meant here that 'the reason for rejecting' is stronger than 'the reason for not rejecting' in an argumentative semantic/heuristic sense?

- Also, the only valid response following a Challenge is for the other agent to Assert the justification (H). Could it not be possible (in the context of this thesis) for the agent that is to respond to *not* have a justification? What if the agent has no justification (if possible), how would the dialogue then proceed? What is meant by justification - that the justification is 'valid' according to the agent's knowledge-base, or is justification here meant more simply in a kind of deductive sense?

Hope that makes sense.

The response...

I see. I reckon it should be not that difficult. You may need to define your own domain language (one that describes your context or argumentation schema/modal). Then link that domain language with the comm. language and protocol defined in the thesis. If you wish to do this formally, then, you might need to alter some of the rules of the axiomatic and operational semantics to suit your application.

OK. Before I get to your specific question, I would recommend you to read the AIJ paper, which followed this thesis (instead of the thesis). This is better than reading the version in the thesis, as I introduced some minor alterations afterwards to both the axiomatic semantics and the operational semantics. Since AIJ doesn't allow on-line appendices we also published the complete semantics as a different technical paper. The links to both these documents are:

AIJ paper - http://users.ecs.soton.ac.uk/nnc/docs/aij09.pdf
Tech report - http://eprints.ecs.soton.ac.uk/16851/2/techreport.pdf

Now to your question.

In defining the comm. language I used a notion similar to operation overloading. In other words, certain language predicates are used for more than one, similar, but not identical, purpose. The objective is to limit the number of language predicates and not unnecessarily duplicate. For instance both the proponent and respondent can use the Open-Dialogue predicate, but they would have different pre- and post- conditions. Thus, the distinction becomes clear at the semantics level (both axiomatic and operational semantic level) and not necessarily at the syntax level. Both Challenge and Assert are used this way. In particular, Challenge locution can be used for two purposes (i) by the proponent to challenge the reason for rejecting a proposal (ii) by either the proponent or respondent to challenge the reason for a particular assertion. This is also there in the use of Assert, Close-Dialogue locutions.

Q1

As mentioned above, Challenge is used for two purposes. This question, as I understand it, is related to the first purpose, Challenging the reason for rejection (the second being Challenging a particular Assertion)

In more detail, the respondent may chose to either accept a particular proposal or reject it. This decision is based on the respondent's R2 decision mechanism (see page 951 on the AIJ paper or page 85 on the thesis).

Yes, you are right the respondent may have zero or more reasons for accepting a particular proposal and also zero or more reasons for rejecting. The decision is based on which is the more compelling reason.

My agents are computational agents who attempts to maximise utility. So, they calculate what is the cost vs benefit in this proposal. If the benefit is more accept otherwise reject. From an argumentation sense this can be if the reason(s) for accepting is more stronger than the reason(s) for rejecting accept otherwise reject.

So when the proponent Challenges (the reason for rejecting a particular proposal), the respondent will pass on its reason(s). It would say it was compelled to reject because of this and this reason (to reject) was much stronger than this and this reason (to accept).

If this reason is in conflict with the Proponent's knowledge-base, then the dialogue may shift an persuasive dialogue trying to correct any inconsistencies in each others reasons (proponents reasons why the proposal should be accepted vs respondents reasons on why it was rejected).

Q2

Yes, the only valid response to a Challenge locution is an Assert. See also Figure 4 (page 948 in the AIJ) and in more detailed level Figure B1 (page 979 in the AIJ).

Case 1: If the challenge was a challenge the reason for reject, then that reason is asserted. In my context, it would say I believe the benefit of the proposal due to this and this reason is this, but the cost of accepting this proposal due to this and this reason is this. So cost is higher than the benefit. Thus, the reason for rejection.

Case 2: If the challenge was the justification for a particular assertion he has made, then the reason behind such an assertion will be returned. This follows the schema in the form of deductive equations (5) and (6) in page 943 if the AIJ.

Yes, theoretically the reason can be null.

In the first case, may simply mean, of reason for rejection, I don't have any reason to accept (no reward), so I rejected. It doesn't make much complication. The proponent will analyse why it thinks it should accept (proponent's reason, if he have any) vs this given null reason from the respondent. If there is a conflict, argue that (why for instance he may have misunderstood the reward) or give an alternative proposal with a reward.

In the latter case, may mean, I don't have a reason for asserting X, but I believe X to be true. Again the other party will compare this with its own reason (why X should be false) and will either argue to correct the oponents' knowledge or correct its own knowledge.

Hope this clarifies things a bit.

Will continue skimming through the thesis anyway, despite the suggestion otherwise, before moving on to check out the journal paper and technical report.

Assumption-based Argumentation for Multiagent Systems

Had my paper ('Assumption-based Argumentation for Multiagent Systems', 2009, Adil Hussain, Francesca Toni) accepted at the 'Computational Uses of Argumentation' workshop to take place as part of the AAAI 2009 Fall Symposium Series, 4-7th November 2009, Washington DC. Need to make a few small changes before submitting the second/final version, as requested by the reviewers.

Note: In future work, building upon and taking this paper further, I need to think about and work on the following:
1) Agents having incorrect, out of date or inconsistent beliefs, as well as inconsistent beliefs.
2) Allowing general inference rules in the private belief base of agents, and not just facts.

PrologBeans Intro

I use PrologBeans to interface Jade (built on Java) and Prolog. Google it for details. Roughly, what you need to do is:

1. Start up an agent (a Java file). E.g. 'AgentNegotiatior.java' as contained in my 'argmas09modified' directory.
2. From this, make a connection to a Prolog server using 'PBConnect.java' (leave this unchanged) which requires a Prolog file like 'run.pl'. The Prolog file (in my case 'run.pl') loads up 'pbconnection.pl' (which I have modified for my purposes) and whatever other Prolog files you need to load (containing your Prolog clauses) before calling 'main' (defined in 'pbconnection.pl').
3. Run your queries from the Java file using a 'PrologSession' instance.
4. Shut down the server upon completion from your Java file.

Hope that makes sense.

maraIRAgents

Just finished the first version of the 'maraIRAgents' implementation (2 agents, 1+ resources each, 1 goal each, distributed fulfils plans).

Seems to run and not loop infinitely but identified a problem case, as follows:

-----

a1: goal(a1,g1), has(a1,r1), fulfils(r2,g1)
a2: goal(a2,g2), has(a2,r2), fulfils(r1,g1), fulfils(r2,g2)

-----

If a2 can communicate fulfils(r1,g1) to a1 then both agents end successfully but this doesn't happen.

Solution: Responding agent should only agree to a response if one of the two agents end up better off (similar to the condition for initiating a request). Otherwise it should refuse providing argument as such.

Deliberation Examples

I need to think of an example for a multi-agent deliberation-like dialogue to include in a forthcoming paper. Here are some first tries:

--- 1 ---

swapAppointments(Ag1,Ag2,App1,App2) <- requires(Ag1,Req1), fulfils(App2,Req1), has(Ag1,App1), ¬fulfils(App1,Req1), canSwap(Ag2,App2,App1)

cantSwap(Ag,App1,App2) <- ¬has(Ag,App1)

cantSwap(Ag,App1,App2) <- has(Ag,App1), requires(Ag,Req), fulfils(App1,Req), ¬fulfils(App2,Req)

Assumptions = {¬fulfils(App,Req), canSwap(Ag,App1,App2)}

Contrary(¬fulfils(App,Req)) = fulfils(App,Req)
Contrary(canSwap(Ag,App1,App2)) = cantSwap(Ag,App1,App2)

Consider two concrete agents, ag1 and ag2, with initial private beliefs as follows:
Priv(ag1) = {has(ag1,app1), requires(ag1,fridayAppointment), fulfils(app1,morningAppointment), fulfils(app2,fridayAppointment)}
Priv(ag2) = {has(ag2,app2), requires(ag2,morningAppointment), fulfils(app2,morningAppointment)}

--- 2 ---

buy(House) <- withinBudget(House), goodLocation(House)

badLocation(House) <- farFromWork(House), badTransportLinks(House)

goodTransportLinks(House) <- nearBusStop(House), frequentBusService(House)

Assumptions = {goodLocation(House), badTransportLinks(House), frequentBusService(House)}

Contrary(goodLocation(House)) = badLocation(House)

Contrary(badTransportLinks(House)) = goodTransportLinks(House)

Contrary(frequentBusService(House)) = infrequentBusService(House)

Consider two concrete agents, ag1 and ag2, with initial private beliefs as follows:
Priv(ag1) = {withinBudget(house1), nearBusStop(house1)}
Priv(ag2) = {farFromWork(house1)}

--- 3 ---

watch(Ag1,Ag2,Film) <- criticallyAcclaimed(Film), willLike(Ag1,Film), willLike(Ag2,Film)

wontLike(ag2,Film) <- actor(Film,timRobbins), boring(Film)

¬boring(Film) <- actor(Film,morganFreeman), goodUserRating(Film)

Assumptions = {willLike(Ag,Film), boring(Film), goodUserRating(Film)}

Contrary(willLike(Ag,Film)) = wontLike(Ag,Film)

Contrary(boring(Film)) = ¬boring(Film)

Contrary(goodUserRating(Film)) = badUserRating(Film)

Consider two concrete agents, ag1 and ag2, with initial private beliefs as follows:
Priv(ag1) = {criticallyAcclaimed(shawshankRedemption), actor(shawshankRedemption,morganFreeman)}
Priv(ag2) = {actor(shawshankRedemption,timRobbins)}

------

Reviewing the eumas08 negotiation policy

Consider an agent system consisting of 2 agents and 2 resources as follows:

a1 has r1 and needs r1, r2
a2 has r2 and needs r1, r2

According to the eumas08 negotiation policy (simple and reason-based procedures) both agents end unsuccessfully. However, a1 could end successfully if a2 gave it r2. Likewise, a2 could end successfully if a1 gave it r1. However, according to the policy, neither will make this sacrifice and thus an optimal (maximal) number of agents that end successfully is not reached.

Consider including offers/arguments of the form: "Your goal G of obtaining R1, ..., Rn is not achievable because ... so give me Ri".

Changes to Prolog deduction program

Made changes to my Prolog 'deduction' program to (properly) allow 'member', '\==' and '>' prefix predicates/operators to be used in the 'body' of 'rule' predicates.

Make goals known at outset?

Why not make agents' goals (as well as the initial system-wide resource allocation and resource-goal fulfils plans, as is currently being done) known at the outset, given that agents declare their goals freely during negotiation anyway?

Testing the time-stamp negotiation policy

Compiled and started tested the MARA (mutiagent resource allocation) time-stamp negotiation policy. Seems to be working fine except that agents seem to accept two or more requests/proposals for the same resource simultaneously... instead of delaying. Problem! Looking into it now.

The importance of stupidity in scientific research

"... What makes it difficult is that research is immersion in the unknown. We just don’t know what we're doing. We can’t be sure whether we're asking the right question or doing the right experiment until we get the answer or the result..."

Good article summarising what PhDs are about.

Revising the 'argmas09' negotiation policy to use time-stamps

Started revising the 'argmas09' negotiation policy to use time-stamps such that beliefs of agents are accumulated only rather than revised (i.e. added/removed). The case for investigating into trust (for verifying arguments/utterances of agents) and related matters seems more interesting than first anticipated.

Progress So Far

eumas 07 ('revised') paper

• Agents have beliefs and desires over single resources, as well as (retractable) commitments to other agents over beliefs, desires and dialogue. Attaining any one of its desired resources achieves the agent's overall goal.
• (Request-Response) Information-seeking dialogues are used to communicate beliefs and desires.
• (Request-Response) Negotiation dialogues are used to swap single resources. An agent accepts a request to exchange resources if the resource to be received is one that it desires.
• The negotiation policy is not complete. The case for reasons/argumentation to accompany the negotiation is put forward.
  

eumas 08 ('revised') paper / ('modified') implementation

• The goal of an agent is to obtain a certain fixed set of ("needed") resources (one at a time).
• Negotiation only (i.e. a Request followed by Accept or Refuse). No separate Information-seeking.
  
• A request of an agent is to be given a certain resource by a certain agent, with an (optional) accompanying reason (i.e. "I need the resource and do not have it").
• An acceptance has no accompanying reason. An agent accepts a request (to give away a resource) if it has and does not "need" the resource.
  
• A refusal may have an accompanying reason, i.e. "I do not have the resource", "Some other agent has the resource", "I have but need the resource".
• Two negotiation policies are compared for "effectiveness" and "completeness" - one in which agents exchange reasons, and one in which they don't. Both policies are complete but providing reasons improves "effectiveness" of an agent achieving its goal if possible or failing if not possible.
• (See 'readme' file of 'eumas08modified' implementation for implementation notes.)
  

aamas 09 ('revised') paper / ('modified') implementation

• Each agent has a (/one) named goal. Goals are fulfilled by single resources. A certain goal may be fulfilled by a choice of different resources. A certain resource may fulfil a choice of different goals.
• Agents do not necessarily share "plans" (as to which resources fulfil which goals) at the outset. These are communicated (partially, as necessary) during negotiation.
• Negotiation only (i.e. a Request followed by Accept or Refuse).
• A request of an agent to another is either to be given a certain resource or to swap (single) resources, with (optional) accompanying reasons/arguments (i.e. a mixture of "needsToObtain", "notNeeds", "useful").
• An acceptance has no accompanying reason. Agents agree to give away a resource if either they do not "need" it or they receive in return a resource of equal value.
• A refusal may have accompanying reasons/arguments (i.e. a mixture of "needsToRetain", "notHas") plus useful additional information (i.e. alternative plans).
• Two negotiation policies are compared for "effectiveness" and "completeness" - one in which agents exchange reasons/arguments, and one in which they don't. The policy that makes use of reasons/arguments is demonstrated to be more (but not fully) complete and more effective in identifying solutions. No formal proofs.
• (See 'readme' file of 'aamas09modified' implementation for implementation notes.)
  

argmas 09 (in progress) paper / implementation

• See New Argument-Based Negotiation Policy for explanation of paper/policy.
• (See 'readme' file of 'argmas09' implementation for implementation notes.)