Business Intelligence
Knowledge Base
Project Acronym UNDERSTANDER
Document-Id D.4
File name
Version Final document
Date start: 01 November 2013
end: 31 December 2013
Author(s) Violeta Damjanovic (SRFG)
Wernher Behrendt (SRFG)
QA Process Verteiler:
Prüfung durch: Genehmigung durch:
Table of Content
1. Introduction1.1. Motivation 1.2. Scope
1.3. Structure of the Document
2. A Knowledge Base for Agent Communication in UNDERSTANDER
3. Scenario Description: Technology Scouting and Introspection of Home Heating Technology
4. Design and Development of Home Heating Knowledge Base 4.1. Home Heating Ontology Design
4.2. Home Heating Ontology Development 5. Conclusion
1. Introduction
The table below summarizes the main project goals, description of the content, methods and milestones related to Work Package 4 (WP4) of UNDERSTANDER.
Goals The main goal of this task is to develop a knowledge base to ensure persistent storage of the knowledge statements collected by one or more agents, in one or more harvesting campaigns.
Description of the content
Software to manage the knowledge base and to make it queryable via RESTful services, over the WWW. We will develop a specific knowledge representation for Conceptual Dependency (CD) scripts to be able to reason over the CD representation. Export to RDF will also be supported.
Method Design and development via prototyping, followed by testing and write-up. Note that development of agents and knowledge base is likely to be intermingled because we want basic persistence functionality early, and we can develop further functions at a later stage.
Project milestones
● Domain specific vocabulary for BI (full taxonomy)
● Overview paper on the overall architecture and design consideration
1.1. Motivation
This document presents the process of designing and the development of the application-specific knowledge base in UNDERSTANDER, which aim is to support the agent-based communication while searching for home heating technologies and manufacturers. Majority of currently existing business systems use a certain amount of structure (mainly database structures), but rarely the “actual knowledge”. Hence, our motivation in UNDERSTANDER is to ontologically support (i) gathering of the pre-existing knowledge of the business, and (ii) provide agent-based form of intelligent behaviour both for the interpreting and subsequently, for any “intelligent” acting on the new information. Ontological support means defining an ontology that specifies own vocabulary and semantics for the content of the messages that the agents are going to exchange.
1.2. Scope
UNDERSTANDER knowledge base is designed and developed in JADE multi-agent platform, which allows for communication and interaction between agents running on various platforms. It covers those elements of the knowledge base that needs to be known to (i) stimulate agent communication about home heating technologies and manufacturers, and (ii) perform the knowledge in a way that brings more understanding about its context.
1.3. Structure of the Document
Section 2 discusses the main elements of a knowledge base enabling the agent communication (the exchange of messages between the agents). It includes the discussion on the elements such as language, protocols and vocabulary, and introduces the reader to the design and the development process of a knowledge base in UNDERSTANDER. Section 3 discusses our concrete scenario that is about technology scouting and introspection of home heating technology and the most prominent manufacturers of home heating technology. Section 4 presents the design and the development of our knowledge base. After Section 4, we refer the reader to Work Package 3 and its Deliverable D3 “Business Intelligence Seeker - User Agent”, which continues with the development of Multi-Agent System in UNDERSTANDER. Section 5 concludes the document.
2. A Knowledge Base for Agent
Communication in UNDERSTANDER
In order to achieve a proper communication (the exchange of messages), it is necessary for agents to share the same language, protocols, and vocabulary (knowledge base). It is also crucial for them to agree on format and semantics of messages they’re going to exchange, as well as to have the possibility to build complex tasks (behaviour) by composing simple ones, and to create conversations that are ruled by the interaction protocols.
In UNDERSTANDER, we’re using JADE multi-agent platform for the agent development and testing of their communication. JADE (c.f. http://jade.tilab.com/) implements FIPA standards, which allow for communication and interaction between agents written in various languages, thus running on various platforms, not exclusively JADE-based. By following FIPA standards, JADE implicitly supports the use of FIPA communicative acts and the Coder/Decoder classes for Semantic Language (SL)-based languages, which also determine the form of the messages exchanged between agents (Poslad, 2007). FIPA’s SL is a LISP-like encoding that contains
concepts, actions and predicates.
It is essential for the agent’s message as a whole to respect a common format. For example, in JADE, messages adhere strictly to the ACL (Agent Communication Language) standard which allows several possibilities for the encoding of the actual content, through defining a set of performatives (also known as Communicative Acts). For example, the actual information that is transferred from the sender to the receiver of an ACL message is included in the content slot of the message. Agent messages also contain: the intended recipients, the sender and the message type. In simple cases, the content of the message contains only the title of the book or the price of the book. In more complex cases, the agents need to manipulate complex content expression by means of ontologies and content language codecs. The ontology validates the information to be converted from a semantic point of view, while the codec performs the translation into strings (or sequences of bytes) according to the syntactic rules of the related content language (Bellifemine et al., 2004).
In other words, agents need to share understanding of the set of concepts and the symbols used to express the concepts - which is known as an ontology. An ontology for a given domain is a set of schemas defining the structure of the predicates, concepts and agent actions that are pertinent to that domain (Bellifemine et al., 2004):
● Predicates are expressions about the status of the world, and can be either true or false; ● Concepts are entities with a complex structure that can be defined in terms of slots; ● Agent actions are special concepts that indicate actions that can be performed by some
JADE provides three ways to represent the content of messages and implement communication between agents (JADE, 2004):
1. The first and most basic way is to use strings to represent the content of messages. This is convenient when the content of messages is atomic data, but not so convenient in the case of abstract concepts, objects or structured data. In such cases, the string needs to be parsed to access its various parts.
2. The second way exploits Java technology to transmit serialized Java objects directly as the content of messages. This is often a method convenient for a local application where all agents are implemented in Java. One inconvenience is that these messages are not readable by humans. The other one is that Java serialization is only applicable in Java environment, and if a JADE agent has to communicate with another agent outside of the JADE platform, they might not understand each other.
3. The third method involves the definition of the objects to be transferred as extension of predefined classes so that JADE can encode and decode messages in a standard FIPA format. This allows JADE agents to interoperate with other agent systems as well. Depending on the types of message content, different methods can be used to set and get content. The Table 1 below presents the correspondence.
Table 1: Set and Get methods used to implement communication between agents Content type Getting content Setting content
Strings getContent() SetContent()
Java Objects getContentObject() SetContentObject() Ontology Objects extractContent() fillContent()
Creating a message content includes indicating its type (its performative) and setting the content. For example (JADE, 2004):
ACLMessage msg = new ACLMessage( ACLMessage.INFORM );
msg.setContent("I sell seashells at $10/kg" );
The most common performative in JADE is INFORM (as shown in the above example), whereby one agent gives another some useful information. Other types are: QUERY to ask a question, REQUEST to ask the other to do something and PROPOSE to start bargaining. Other performatives in use to provide answers include: AGREE or REFUSE. In the following, we also present a list of attributes that might be used within a JADE ACL message (JADE, 2004):
● Performative - FIPA message type (INFORM, QUERY, PROPOSE, ...) ● Addressing:
○ Receiver
○ Sender (initialized automatically) ● Content - The main content of the message
● ConversationID - Used to link messages in same conversation ● Language - Specifies which language is used in the content ● Ontology - Specifies which ontology is used in the content ● Protocol - Specifies the protocol
● ReplyWith - Another field to help distinguish answers ● InReplyTo - Sender uses to help distinguish answers ● ReplyBy - Used to set a time limit on an answer.
To make agents understand each other, they need to speak the same language, and to have a common ontology. An ontology is a part of the agent's knowledge base that describes what kind of things an agent can deal with and how they are related to each other. Defining an ontology means defining own vocabulary and semantics for the content of the messages that will be exchanged between the agents. Hence, in Section 3 of this report, we firstly describe our home heating technology scenario, and afterwards, in Section 4, we design and develop an ontology in JADE, allowing agents to communicate and reason about facts and knowledge related to the scenario.
3. Scenario Description: Technology
Scouting and Introspection of Home
Heating Technology
We start with an introspective method, asking the following question:
How would we do a manual process of technology scouting? We want to know which firms
around home heating technology are competing in the German speaking markets, and what technologies they are selling. We are particularly interested in how they address the issue of integration of their technologies into home automation systems. One possible approach is to first look for heater system manufacturers and then assemble a portfolio of technologies from their offerings. Another option would be to first look for technologies related to heating systems, and then look for manufacturers and their use of the technologies. The latter approach might yield more technologies than those currently on offer. Neither approach is likely to yield the specific issue of integration into home automation systems. On the contrary, we might be better off looking at pages about home automation in order to find those heating system manufacturers that are recognised as competent players in the home automation market.
Our introspection method mixes the above strategies through the following steps: ● Step 1: Who is competing?
● Step 2: For each manufacturer, which types of heating systems (and relevant technology choices and developments) are they producing?
● Step 3: For each manufacturer, which offerings for home automation currently exist? ● Step 4: Who are the main providers of home automation and what technologies and
systems they are able to integrate into their solutions and how? Step 1: Who is competing?
By using German for Google queries, we get a first approximation to this question. We’re searching for the term: “Heizungsanlagen Hersteller”. The best type of answer are those web pages that give aggregations of manufacturers, preferably put together by a knowledgeable source, c.f. http://www.hottenrott.de/heizung.htm which cross-references dozens of manufacturers.
Step 2: For each manufacturer, which types of heating systems are they producing? For the purpose of this introspection, we investigate just three of the producers, one from Germany (Buderus), Austria (KWB) and Switzerland (Elcotherm). For each of them, we find out which of heating systems they produce.
Buderus KWB Elcotherm Wärmepumpen
(heat pumps)
+ +
Solarkollektoren
(solar energy collectors)
+ +
Gasheizkessel (gas heater systems)
+ +
Ölheizkessel (oil heater systems)
+ +
Holz/ Stückgut (log wood heater)
+ + +
Holz/Pellets
(wood pellets heater)
+ +
Holz/Hackgut
(wood chippings heater) + +
Speicher
(energy storage systems) + +
Brenner (burner chambers) + + Heizflächen (heater panels) + Regelungssysteme (control systems) + PV-Systems +
Step 3: For each manufacturer, which offerings for home automation currently exist? With dozens of heating system vendors, the task of compiling a dossier on heating technologies and home automation will soon become rather labour-intensive. Looking at the product portfolios, we can derive a taxonomy of heating system technologies and components.
Step 4: Who are the main providers of home automation and what technologies and systems they are able to integrate into their solutions and how?
The complexity of this step supposes the use of mechanisms supporting reasoning and intelligent behavior of agents.
4. Design and Development of Home
Heating Knowledge Base
To support message exchange between the agents, we design and develop the agents as classes. The conversations between the agents follow a simple protocol: To implement searching functionality for technology, or searching for manufacturer, the ClientAgent sends a REQUEST message to the ServerAgent. The ServerAgent responds with an INFORM performative after processing the request, or with an NOT_UNDERSTOOD if it cannot resolve the content of the message. To query information about a specific technology or manufacturer, the ClientAgent sends a QUERY_REF to the ServerAgent which responds with an INFORM after processing the query or with a NOT_UNDERSTOOD if it cannot decode the content of the message.
Both agents, the ServerAgent and the ClientAgent, are designed as classes, implementing a common interface (HomeHeatingVocabulary) that defines the main terms that constitute the specific language of the agents. Unlike content languages that are typically domain independent, ontologies are typically specific to a given domain. For example, the concept of heating technology, or heating manufacturer, is relevant within the domain of home heating technology in UNDERSTANDER, but not in the health, or other domains. Defining domain-specific ontology is achieved through the following common steps (Bellifemine et al., 2004):
● Step 1: Identifying an ontology (as an instance of the
jade.content.onto.Ontology class) and its schema, which additionally describes the types of predicates, agent actions, and concepts relevant to the domain;
● Step 2: Developing Java classes for all types of predicates, agent actions, and concepts in the ontology;
● Step 3: Selecting a content language;
● Step 4: Registering the ontology and the selected content language with the agents; ● Step 5: Creating and handling content expressions as Java objects, which are instances
4.1. Home Heating Ontology Design
In order to model the interaction between agents, we need to identify the concepts and agent actions, which are required to express the agent behaviour.
● The concepts are entities with a complex structure that can be defined in terms of slots, e.g. (Person :name John :age 33);
● The agent actions are special concepts indicating actions that can be performed by some agents, e.g. (Sell (Person:name John)).
Firstly, we create a class diagram that extracts specific concepts and agent actions based on our home heating scenario (see Figure 1).
Figure 1: Class diagram for the home heating scenario The following concepts and agent actions have been identified:
● HomeHeatingTechnology: concept of the list of various home heating technologies (specifies technology ID and the name of technology);
● HomeHeatingManufacturers: concept of the list of various home heating manufacturers (specifies manufacturer ID and its name);
● Searching: concept of searching mechanisms for both technology and manufacturers; ● Problem: concept of list of failures;
● SearchingTechnologiesOperation: action of investigating specific home heating technologies,
● SearchingManufacturersOperations: action of investigating specific home heating manufacturers;
● TechnologyInformation: action of the list of messages related to home heating technologies;
● ManufacturerInformation: action of the list of messages related to home heating manufacturers;
● Information: action of the list of messages.
4.2. Home Heating Ontology Development
Defining an application-specific knowledge base (ontology) is a way to provide the basic elements to support agent communication, i.e., to provide content of agent messages. A knowledge base (ontology) contains (i) individuals (instances, or objects,), (ii) classes (sets, collections, sets of things), (iii) relations that relates classes and individuals to each other, (iv) function terms, (v) rules and axioms, (vi) restrictions.
In JADE, defining an ontology means creating a vocabulary that describe the terminology of concepts used by agents in their space of communication, and the relationships between these concepts, which are used to describe their semantic and structure. The implementation of an ontology in JADE extends the predefined class Ontology, and adds a set of element schemas describing the structure of concepts, agent actions, and predicates used to compose the content of messages. In other words, defining an ontology in JADE deals with three interfaces: Concept, AgentAction, and Predicate. The corresponding classes to be used in ontology class are respectively: the ConceptSchema, AgentActionSchema and PredicateSchema. These interfaces have a common superclass which is the ObjectSchema class.
Which of the three interfaces will be used depends on particular case of agent communication (JADE, 2004). For example:
● if agent A requests from agent B to perform a specific task: according to FIPA, the content of the message that A sends to B must be an action. Hence, the task will be defined by a java object implementing the AgentAction interface;
● if agent A request from agent B to check specific proposition: in JADE, a proposition is defined by a java object implementing the interface Predicate;
● if agent A request from agent B to perform a specific task that will result in creating some results, or a problem if the task failed: in JADE, the objects Result and Problem are neither agent actions nor propositions; rather they are concepts implementing the interface Concept.
Besides these three interfaces, JADE provides support for defining atomic elements that constitute the slots of the abstract concepts, such as String, Integer, Float, etc. The support for these atomic types of objects is provided through the PrimitiveSchema class and is handled by the BasicOntology class.
In the following, we define the HomeHeatingOntology class with the aim to support communication between two agents: the ServerAgent and the ClientAgent. This process requires the following steps to be performed:
● Step 1: Defining the vocabulary (HomeHeatingVocabulary) based on a given agents communication space (from home heating scenario);
● Step 2: Specifying the structure and semantic of the objects identified to be a part of the vocabulary;
● Step 4: Setting up ontology to be used by the agents.
The rest of this section provides step-by-step development of HomeHeatingOntology in
UNDERSTANDER.
Step 1: Defining the vocabulary (HomeHeatingVocabulary) based on a given agents communication space.
The following interfaces can be identified from Figure 1:
● the HomeHeatingTechnology class that implements the Concept interface; ● the HomeHeatingManufacturer class that implements the Concept interface; ● the Searching class that implements the Concept interface;
● the SearchingTechnologiesOperation class that implements the AgentAction
interface;
● the SearchingManufacturerSOperation class that implements the AgentAction
interface;
● the TechnologyInformation class that implements the AgentAction interface; ● the ManufacturerInformation class that implements the AgentAction interface; ● the Problem class that implements the Concept interface.
The HomeHeatingVocabulary interface specifies the terminology of all the above mentioned
Concept interfaces and AgentAction interfaces:
public interface HomeHeatingVocabulary{
// --- Basic vocabulary
public static final int SEARCH_MANUFACTURER = 1; public static final int SEARCH_TECHNOLOGY = 2;
public static final String SERVER_AGENT = "Server agent";
public static final String ILLEGAL_OPERATION = "Illegal operation";
//---> Ontology vocabulary
public static final String HH_TECHNOLOGY = "Technology"; public static final String HH_TECHNOLOGY_ID = "tId"; public static final String HH_TECHNOLOGY_NAME = "tName"; public static final String HH_MANUFACTURER = "Manufacturer"; public static final String HH_MANUFACTURER_ID = "mId";
public static final String HH_MANUFACTURER_NAME = "mName";
public static final String SEARCHING = "Searching"; public static final String SEARCHING_TYPE = "sType"; public static final String SEARCHING_TERM = "sTerm";
public static final String SEARCHING_TECH_ID = "stId"; public static final String SEARCHING_MANU_ID = "smId"; public static final String SEARCHING_DATE = "sDate";
public static final String SEARCHING_TECHNOLOGY =
"SearchingTechnologies";
public static final String SEARCHING_TECHNOLOGY_TYPE = "sType";
public static final String SEARCHING_TECHNOLOGY_TERM = "sTerm";
public static final String SEARCHING_TECHNOLOGY_ID = "stId"; public static final String SEARCHING_TECHNOLOGY_NAME = "stName";
public static final String SEARCHING_MANUFACTURER =
"SearchingManufacturers";
public static final String SEARCHING_MANUFACTURER_TYPE = "mType";
public static final String SEARCHING_MANUFACTURER_TERM = "mTerm";
public static final String SEARCHING_MANUFACTURER_ID = "smId";
public static final String SEARCHING_MANUFACTURER_NAME = "smName";
public static final String TECHNOLOGYINFORMATION =
"tInformation";
public static final String TINFORMATION_TYPE = "tType"; public static final String TINFORMATION_ID = "tId"; public static final String TINFORMATION_NAME = "tName";
public static final String MANUFACTURERINFORMATION =
"mInformation";
public static final String MINFORMATION_TYPE = "mType"; public static final String MINFORMATION_ID = "mId";
public static final String MINFORMATION_NAME = "mName"; public static final String PROBLEM = "Problem";
public static final String PROBLEM_NUM = "num"; public static final String PROBLEM_MSG="msg"; }
Herein, we continue with the specification of the interfaces from Figure 1. In this step, we also consult a set of “Ontology Vocabulary” parameters from HomeHeatingVocabulary (Step 1), as basis for the development of HomeHeatingOntology. The rest of this section presents the major interfaces, either implementing Concepts or AgentActions.
HomeHeatingManufacturer Interface (HHManufacturer.java) implements Concept interface:
public class HHManufacturer implements Concept {
//
private String mId;
private String mName;
private int mType;
public int getManufacturerType() {
return mType;
}
public String getManufacturerId() {
return mId;
}
public String getManufacturerName() {
return mName;
}
public void setManufacturerType(int mType) {
this.mType = mType;
}
public void setManufacturerId(String mId) {
this.mId = mId;
}
public void setManufacturerName(String mName) {
this.mName = mName;
}
public boolean equalsManufacturer(HHManufacturer manu) {
return manu.getManufacturerId().equals(this.mId);
}
public String toString() {
return mName + " # " + mId;
}
}
public class HHTechnology implements Concept{ //
private String tId;
private String tName;
public String getTechnologyId() {
return tId;
}
public String getTechnologyName() {
return tName;
}
public void setTechnologyId(String tId) {
this.tId = tId;
}
public void setTechnologyName(String tName) {
this.tName = tName;
}
public boolean equalsTechnology(HHTechnology tech) {
return tech.getTechnologyId().equals(this.tId);
}
public String toString() {
return tName + " # " + tId;
}
}
SearchingTechnologiesOperation (SearchingTechnologiesOperation.java) implements
AgentAction interface:
public class SearchingTechnologiesOperation implements AgentAction,
jade.content.AgentAction {
private static final long serialVersionUID = 1L; private int tType;
private String tTerm; private String tId; private String tName;
public int getTechnologyType() {
return tType;
}
public String getTechnologyTerm() {
}
public String getTechnologyId() {
return tId;
}
public String getTechnologyName() {
return tName;
}
public void setTechnologyType(int tType) {
this.tType = tType;
}
public void setTechnologyTerm(String tTerm) {
this.tTerm = tTerm;
}
public void setTechnologyId(String tId) {
this.tId = tId;
}
public void setTechnologyName(String tName) {
this.tName = tName;
}
}
TechnologyInformation (TechnologyInformation.java) implements AgentAction interface:
public class TechnologyInformation implements AgentAction {
// private int type;
private String technologyId;
public int getType() {
return type;
}
public String getTechnologyId() {
return technologyId;
}
public void setType(int type) {
this.type = type;
}
public void setTechnologyId(String technologyId) {
this.technologyId = technologyId;
} }
Step 3: Defining the schema of the object.
In this step, we define the HomeHeatingOntology class, which is based on
HomeHeatingVocabulary (defined in Step 1) and classes specifying the structure and the semantics of objects (Step 2).
public class HomeHeatingOntology extends Ontology implements
HomeHeatingVocabulary {
private static final long serialVersionUID = 1L; // ---> The name identifying this ontology
public static final String ONTOLOGY_NAME = "Home-Heating-Ontology";
// ---> The singleton instance of this ontology
private static Ontology instance = new HomeHeatingOntology(); // ---> Method to access the singleton ontology object public static Ontology getInstance() { return instance; } // Private constructor private HomeHeatingOntology() { super(ONTOLOGY_NAME, BasicOntology.getInstance()); try { // --- Add Concepts // HH_Technology
ConceptSchema cs = new ConceptSchema(HH_TECHNOLOGY);
add(cs, HHTechnology.class); cs.add(HH_TECHNOLOGY_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); cs.add(HH_TECHNOLOGY_NAME, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); // HH_Manufacturer
add(cs = new ConceptSchema(HH_MANUFACTURER),
HHManufacturer.class); cs.add(HH_MANUFACTURER_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); cs.add(HH_MANUFACTURER_NAME, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); // Problem
add(cs = new ConceptSchema(PROBLEM), Problem.class); cs.add(PROBLEM_NUM, (PrimitiveSchema) getSchema(BasicOntology.INTEGER), ObjectSchema.MANDATORY); cs.add(PROBLEM_MSG, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); // Searching
add(cs = new ConceptSchema(SEARCHING), Searching.class);
cs.add(SEARCHING_TYPE, (PrimitiveSchema) getSchema(BasicOntology.INTEGER), ObjectSchema.MANDATORY); cs.add(SEARCHING_TERM, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); cs.add(SEARCHING_TECH_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); cs.add(SEARCHING_MANU_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); cs.add(SEARCHING_DATE, (PrimitiveSchema) getSchema(BasicOntology.DATE), ObjectSchema.MANDATORY); // --- Add AgentActions // SearchingTechnologies AgentActionSchema as = new AgentActionSchema(TECHNOLOGYINFORMATION); add(as, SearchingTechnologiesOperation.class); as.add(SEARCHING_TECHNOLOGY_TYPE, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(SEARCHING_TECHNOLOGY_TERM, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(SEARCHING_TECHNOLOGY_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(SEARCHING_TECHNOLOGY_NAME, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); // SearchingManufacturer
add(as = new AgentActionSchema(SEARCHING_MANUFACTURER),
SearchingManufacturersOperation.class); as.add(SEARCHING_MANUFACTURER_TYPE, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(SEARCHING_MANUFACTURER_TERM, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(SEARCHING_MANUFACTURER_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(SEARCHING_MANUFACTURER_NAME, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY);
// TechnologyInformation
add(as = new AgentActionSchema(TECHNOLOGYINFORMATION),
TechnologyInformation.class); as.add(TINFORMATION_TYPE, (PrimitiveSchema) getSchema(BasicOntology.INTEGER), ObjectSchema.MANDATORY); as.add(TINFORMATION_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(TINFORMATION_NAME, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); // ManufacturerInformation
add(as = new AgentActionSchema(MANUFACTURERINFORMATION),
ManufacturerInformation.class); as.add(MINFORMATION_TYPE, (PrimitiveSchema) getSchema(BasicOntology.INTEGER), ObjectSchema.MANDATORY); as.add(MINFORMATION_ID, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); as.add(MINFORMATION_NAME, (PrimitiveSchema) getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY); }
catch (OntologyException oe) {
oe.printStackTrace();
}
}
}// HomeHeatingOntology
We are using getInstance() method to access the singleton instance of an ontology object. Also, within the class AgentActionSchema, add(...) method allows for the name of the slot to be added, as well as the schema of the slot and the optionality. The optionality might have two values:
● MANDATORY that indicates the value of the slot must not be null; ● OPTIONAL indicating slot that can have a null value.
Step 4: Setting up the HomeHeatingOntology to be used by the agents.
In order to enable the ontology to be used by the agents, the Agent’s Content Manager must be registered with (i) the ontology registerOntology(ontology) and (ii) the language that will be used for assembling and parsing (or coding/decoding) the content of messages registerLanguage(codec). In UNDERSTANDER, we use the codec language which is implemented in JADE via the class SLCodec.
For more details about this step, we refer reader to Work Package 3, Deliverable D3 “Business Intelligence Seeker - User Agent” that describe the agents development.
5. Conclusion
UNDERSTANDER knowledge base is designed and developed in JADE multi-agent platform, allowing for communication and interaction between agents running on various platforms. It covers a set of elements of the knowledge base that needs to be known to (a) stimulate agent communication about home heating technologies and manufacturers, and (b) perform the knowledge in a way that brings more understanding about its context.
References
(Bellifemine et al., 2004) Bellifemine, F., Caire, G., Greenwood, D., Developing Multi-Agent Systems with JADE. Wiley series in agent technology. 2004.
(Poslad, 2007) Poslad, S., Specifying Protocols for Multi.Agent Systems Interaction. 2007. (JADE, 2004) Building Multi-Agent Systems with JADE. Online:
