This section documents IRIS service beans that are most commonly used. Plugins can refer to these beans using Spring. The core bean definitions live in the following files:
These are beans that get used for both IRIS server and client.
Serevr beans. This config file also loads other common config files. This config file also contains the server plugin application context:
<bean id="com.sri.iris.plugins.ApplicationContext"
class="org.springframework.context.support.FileSystemXmlApplicationContext"
autowire="no" dependency-check="none" init-method="refresh">
<constructor-arg>
<list>
<value>${iris.plugins.dir}/*/plugin.xml</value>
</list>
</constructor-arg>
<constructor-arg>
<value>false</value>
</constructor-arg>
<constructor-arg>
<ref bean="com.sri.iris.ApplicationContext"/>
</constructor-arg>
<property name="classLoader">
<ref bean="com.sri.iris.ClassLoader"/>
</property>
</bean>These are IRIS server beans that need to be converted to proper IRIS plugins. These beans have been singled out for conversion but it is not crtitical that they be converted anytime soon.
Loads client beans and contains the client plugins application context:
<bean id="com.sri.iris.plugins.client.ApplicationContext"
class="org.springframework.context.support.FileSystemXmlApplicationContext"
autowire="no" dependency-check="none" init-method="refresh">
<constructor-arg>
<list>
<value>${iris.plugins.dir}/*/plugin-client.xml</value>
</list>
</constructor-arg>
<constructor-arg>
<value>false</value>
</constructor-arg>
<constructor-arg>
<ref bean="com.sri.iris.ApplicationContext"/>
</constructor-arg>
<property name="classLoader">
<ref bean="com.sri.iris.ClassLoader"/>
</property>
</bean>Contains beans that are used for the IRIS Knowledge Base and ontology access.
Supports RQ-CORE-PLUGIN by allowing IRIS knowledge bases to be annotated with RDF data (to specify whether or not learning data is stored, for example).
These are beans that plugins can inherit from to get references to IRIS knowledge bases and knowledge base connections.
Common queries using SPARQL syntax. Plugins can inherit beans from these abstract beans to run queries.
This is a common place to put port definitions. Currently most server ports are hard-wired in IRIS. This file is a work-in-progress to define ports in one common place. The port definitions can then be changed in the future to allow selection of first available ports to avoid conflicts with other programs. This technique is coupled with port discovery using the keychain server to completely avoid port conflicts. This is still a work-in-progress and ports are still mostly hard-wired in IRIS.
This file is a common place to refer to any UI plugin registered with the viewer host. This XML file specifies the ordering of plugins and shortcut keys. Note that it is not required to specify a UI plugin in this file. Only the core IRIS UI plugins are specified here.
IRIS core services are built from the following requirements:
One of the mission statements of CALO is to integrate existing systems. This is a big requirement and some systems that comprise CALO existed before CALO (for example SPARK, PLOW, TaskTracer, etc.). This requirement is loosely defined to the extent that the system has to work well, but obviously total integration can be unfeasible unless rewrites are done. Part of the CALO project has also been to rewrite software where appropriate in order to meet this requirement. This requirement implies:
Allowing existing and newly built components to share data.
Sharing of messages, or event data about data.
Process for assimilating new data and making that data work with the rest of the system.
Import/export of data, and query/update facilities should exist
The base architecture should be built on a standard that others can use/extend. This is required because one of the mission statements of CALO is to open source IRIS and make it available to the larger community.
Before the CALO project was started we knew there was a need for task learning activities, and that from this need stems the requirement to observe the user. The O in CALO stands for Observer or Organize. CALO doesn't observe in the sense of being intrusive; it observes with the intent to organize and prepare information, and to help the user work better.
This requirement applies to all office applications the user works with: mail, browser, microsoft office, calendar, etc. IRIS must have hooks into these applications to observer user events.
For task learning to succeed, the ability must be present to execute tasks. For an instrumented event there needs to be an automation capability so that CALO can perform the event.
Care must be taken when dealing with sensitive data. IRIS cannot automatically save passwords for example, but the user can tell IRIS what their password is if they want automation facilities to work (or IRIS can prompt the user).Also required for task learning activities is concept learning. IRIS must be able to receive new concepts at runtime. IRIS is not responsible for the concept learning, but it is the core platform and must be able to work with new concepts (ie, it is possible to add new concepts and they get applied the same way any pre-existing concepts are applied).