PubSub is an IRIS sub-system that satisfies RQ-CORE-INSTRUMENTATION and RQ-CORE-AUTOMATION.
The best way to get started with PubSub is to read the javadoc for com.sri.iris.pubsub.IPubSubService. The rest of this section assumes the Javadoc has been read and understood.
The PubSub task hierarchy exists as an OWL spec located at iris/data/tasks.owl. The base class which represents a task is task:Task. This is not to be confused with clib:Task, which is a represntation of a user's work Task in the office environment. task:Task instances represent some event in the system that is instrumented and/or automated.
IRIS distinguishes a message about a task using the OWL representation ps:TaskMessage. This contains meta-data about what action the task is involved in. For example, a message can be sent indicating a task should be executed, paused/resumed, or that a task occurred, failed, or was rejected.
When IRIS observes the user's interaction in the office environment, each interaction is encapsulated as an instrumented event. In PubSub terminology an instrumented event is a tuple of:
This task message informs any listeners that a task was executed successfully. The "taskIs" points to the task instance, and other meta-data is also specified such as the PubSub URI of the sender, the sent date, and whether or not the task is executed by the user (or is executed programmatically by some IRIS component).
The task instance.
For example, consider the instrumented event that a user selects an email message. This sends an ExecutionSucceededMessage with the task SelectEmail, and the SelectEmail message points to the clib:EmailMessage instance which is the upper-ontology instance for the email.
ps:ExecutionSucceededMessage falls into the broad category of instrumentation messages and subset response messages.
In addition to the execution succeeded message, there is a family of control messages. When a task is executed the following steps task place:
An instance of ps:ExecuteMessage is constructed which points to the task that should be executed.
The message is dispatched to the handler using PubSubService. Note that the current PubSub model only allows for one subscriber to a control message ( but many subscribers can receive instrumentation messages such as execution succeeded).
The handler can shoose to accept or reject the message. It must do one of these by sending back a ps:ExecutionAcceptedMessage or ps:ExecutionRejectedMessage instance.
When execution is finished the handler sends back a ps:ExecutionSucceededMessage or a ps:ExecutionFailedMessage instance.
Note that control/response messages also exist for suspend/resume/cancel, but they are not used. They are part of the larger design to accomodate long-running tasks and are in place for future development.
See the section on generating task parameters for an overview of what task parameters are. In regards to PubSub, IRIS never uses task parameters internally. Instead they are available to any client as ontology data that can be queried. In particular, task learning components in the CALO system query task parameters to obtain meta-data about tasks.
Note that PubSub uses a memory graph for all data eschanged. This is done because messaging data is almost always transient and this also performs well. IRIS will purge old entries in the memory graph. See the section on memory graphs for more information on how to control purging and write purged data to a database. PubSUb uses the "events" memory graph.
See the section on running PubSub tests for more information.