Agents, Rules, and the Semantic Web

In this assignment we will learn how to develop cooperative, service-oriented applications based on the agent metaphor. Intuitively, each service is an agent. An enterprise is represented by an agent. Thus, among other things, agents embody the decision-making processes of the enterprises they represent. You would normally encode the decision making logic of the agents in rules, but for simplicity we will hardcode them into the agents. We will also learn how the Semantic Web can be used to resolve heterogeniety in message parameters.

Tools

• We will use JADE (Java Agent Development Environment) 3.5 for creating a Buyer and a Seller agent who interact for making a purchase. Download the JADE_ALL distribution and look through the programming guide in the documentation.
• We will use Jena 2.5.5 for searching OWL ontologies.
• (Optional) You can use Protege 3.3.1 for viewing the OWL ontologies. This tool provides a graphical means by which to view the OWL ontology that is needed for the assignment.
• (Future) In the next assignment you will use Jess 7.0p2 (stable) to specify the decision making of the agents.

Tutorials

• JADE tutorial for beginners
• JADE programming for beginners
• Jena RDF API
• Jena OWL Inference Reasoner

Buyer / Seller Interactions

Below are the set of allowed interaction scenarios of the purchase protocol (all parameters are Strings)...

For simplicity, all the messages sent must be JADE ACLMessage instances using the FIPA INFORM performative. The exception to this rule is the requestForQuote message, which must be sent using the FIPA CFP performative. Each seller agent registers itself with the DF (Directory Facilitator) service. The buyer agent looks for a seller agent, selects one, and starts interacting. The interactions can be graphically observed in RMA (Remote Management Agent) by adding a sniffer agent.

However, agents' information systems might not agree on the message names (you can assume that the names of the message parameters do not change). Each message in our assignment is an instance of this class. It essentially is a message name and a collection of parameter names and parameter values. All agents must understand the message and parameter names from the above scenarios.

Hence, after receiving a message, an agent determines if it understands the message by applying the following criteria:

1. If the message is from the above scenarios, then its names are understood.
2. If a message name is not from the above scenarios, but the commonly available OWL ontology describes it as the same concept, then it is also understood. For example, if the message received is of type payByCredit and the receiver was expecting a message of type payment, then based on the provided ontology the receiver should accept the message.
3. If the above steps fail, then the message is not understood.

If a message is understood, the agent responds according to the protocol. If not, the agent responds with the "UNKNOWN" message with a single parameter that names the part that was not understood.

Conventions

To ensure compatibility, please follow these conventions in your agents.

1. The seller agent in the DF registry must have type = "SELLER".
2. The seller agent must be able to handle concurrent interactions with multiple buyers. (HINT: use conversationID)
3. The seller agent will generate a random price between $1 and $100.
4. The seller agent must follow these rules when receiving an acceptQuote message...
• if the agent is started with the argument[0] "goods", then send the goods 1 second after receiving the acceptQuote.
• if the agent is started with the argument[0] "pay" then wait until payment is received before sending the goods.
5. The buyer agent must follow these rules for determining whether or not to accept or reject a quote...
• if the agent is started with the argument[1] "accept" then send acceptQuote.
• if the agent is started with the argument[1] "reject" then send rejectQuote.
6. The buyer agent must follow these rules after sending an acceptQuote message...
• if the agent is started with the argument[0] "pay" then send payment 1 second after sending the acceptQuote.
• if the agent is started with the argument[0] "goods" then wait until the goods are received before sending payment.
7. The buyer agent must use the itemID that is provided by argument[2] at startup.
8. The agents print the messages they send and receive to the console.
9. The agents will use behaviors (java classes) to handle the execution of the protocol.
10. The agents will only pass instances of Standard Message as the message contents.
11. The ACLMessages will all use the INFORM performative with the exception of requestForQuote, which will use CFP.
12. The agents will use the common ontology available here.

Getting Started

Here is a helpful outline to get you started...

1. In the directory [jade-3.5 install location]/jade-bin-3.5/jade run 'java -jar lib/jade.jar -nomtp -gui' to start JADE
2. Create an java project in eclipse called [unity_id]_soc_p5
3. Follow the JADE tutorials and create a simple agent (i.e. java class)
4. In Eclipse go to Project --> Properties --> Java Build Path and add all of the jars from the jade-bin-3.5/jade/lib directory
5. In Eclipse go to Run --> Open Run Dialog... and create a new launch configuration
6. In the configuration set the project to [unity_id]_soc_p5 and the main class to "jade.Boot"
7. In the configuration arguments tab put "-container [localJADEName]:[yourPackage.yourAgentClass]([arguments])"
8. When JADE is running you can run this launch configuration to add your agent to the JADE runtime.
9. You can now go to the JADE RMA GUI and see that your agent is listed inside a newly created container.
10. Now you can begin coding the remainder of your assignment, which includes tasks such as...
• creating your agent behaviors
• adding the Jena lib/*.jar files to your eclipse project
• using the Jena API to traverse the ontology and determine message correctness
• ensure your sender can handle concurrent requests.

Deliverables

Submit a single eclipse project called [unity_id]_soc_p5 containing the buyer and the seller agents.

Testing and Grading

We will run someone else's buyer and seller agents against your submitted seller and buyer agents, respectively. We might change the relationships among the concepts in the commonly available ontology to see if your agents make the right inferences about understanding or not understanding the messages.

1. We will run your buyer and seller agents against each other and observe the outputs in their respective consoles and also through RMA sniffer graphically.
2. We will run someone else's buyer and seller agents against your submitted seller and buyer agents, respectively.
3. We will run multiple buyer agents from other students concurrently against your one seller agent.
4. We will have buyer and seller agents use different combinations of messages (both conforming to and violating the onotology) to ensure your agents make the correct inferences from the ontology.