Console User Interface

The text-based console interface is in fact the required interface because it permits many advanced and privileged management tasks, such as the creation of metaphors. To illustrate the use of the console, we consider an experiment that uses single-trial event-related potential (ERP) to recognize different brain potentials with five degrees of drowsiness. We will show how to design a resource relative to a function in the experiment with metaphor and its interpreter and then use workflow to composite the resource to perform the entire experiment.

With the support of JMatLink we can already perform the function of the experiment mentioned above, if we know the exactly correct command format for the function. But this will not be an acceptable and user-friendly user interface. With the workbench, we need to design metaphors for this basic function to increase reusability and user friendliness. Consider a basic function, called “loadset”, that is provided by EGLAB. Through JMatLink, the function can be invoked in Java as shown below:

JMatLink engine = new JMatLink();

engine.engOpen();

engine.engEvalString(“EEG = loadset(...);”);

To incorporate EEGLAB’s “loadset” function into our system, for example, we would like to have a service that handles requests in terms of XML (i.e. using XML as the standard message format) and translates them in the form recognized by JMatLink. A simple metaphor can be defined for the purpose:

<Loadset>

JMatLink engine = ...; // get engine service elsewhere String cmd = convertCommand(m);

engine.engEvalString(cmd);

return Metaphor.OK;

} }

In this case, the Loadset service can interpret input messages and dispatch them to the Matlab engine. Note that we also use m

The metaphor and service above represent one of the resources managed by the container.

How to access these resources depends on the availa

<loadset>

etaphors to represent XML messages in our implementation, and services that process metaphors are modeled as IMetaphorService.

ble clients, which themselves can also be services managed by the container. For example, below is a “command-line” control service that serves as a client to invoke other resources.

<m:is m:uri="/bci/core/EEGLabControl"/>

<command tag="loadset"/>

<m:is m:uri="//meta/java/JavaObject"/>

<class name="cclab.matlab.eeglab.ctrl.LoadsetControl"/>

<commandTemplate command="loadset">

<loadset path="Path_Arg"/>

<Path_Arg>

<prompt label="Please input data set file path: "/>

<default type="String"/>

</Path_Arg>

</commandTemplate>

</loadset>

The control is among the other similar objects managed by yet another console-based command dispatcher. Specifically, the dispatcher recognizes metaphors that have the type

"/bci/core/EEGLabControl” and includes the associated control object (here a

“LoadsetControl” object) into its own control pool. The dispatcher receives user’s requests as plain texts (in console mode), translates them into metaphors, and dispatches them to proper controls according to the filter information provided in the control metaphor. In the example above, the “loadset” control will accept metaphors with tag <loadset> and interacts with the user using a sequence of questions, as illustrated in Figure 6 below. It help user to complete the required parameters for the loadset function.

Figure 6. A simple console-based client

Similarly, we can design other resources/metaphors for the other functions needed in the EEGLAB analysis process, and put these resources in a container named Matlab container.

Besides these, we need some other services for user to manage their resources.

To conduct an EEG signal data analysis, we first record the raw data from the instrument first, and then send the data to a computer with higher computational power for processing.

Accordingly, we deploy our e-Science workbench in a distributed system that contains these two kinds of containers: project containers that maintain raw and analysis data, and Matlab container containing Matlab computing resources. As shown in Figure 7, all these containers have a common core called VOS that serves as the coordination engines, and through the console we can remotely control this container to perform actions. Interestingly, the VOS core is a resource tree that contains common definitions (metaphors) that are kept identical for each container in our implementation.

Project container1

Matlab container

Internet

Project container2

VOS core

perform the analysis we need. In case the communication can be done through metaphor exchange, as in our implementation, standard channels among these services can be established. In case higher performance data transmission is required, special channels such as FTP combined with data compression techniques can be used.

Besides running manually the complete entire experiment step by step, we can also group required activities in a workflow and run it automatically. We break the analysis experiment into separate tasks such that each task takes an input, processes the input, and produces the output for the next task. As mentioned before, each task type can be defined and denoted as a metaphor to be used inside workflows. For example, below shows a task type declaration for the same “loadset” function described previously. Instead of being a function to be invoked by other clients directly, here it becomes “asynchronous” in the sense that the workflow engine should interpret such a task and invoke the “loadset” function at a proper time with required input/output data.

<LoadsetTask>

<m:is m:uri="//meta/service/TaskType"/>

<m:is m:uri="//meta/java/JavaObject"/>

<class name="eeglab.LoadsetTaskType"/>

</LoadsetTask>

For illustration purpose, below we show a simple workflow that includes the Loadset task.

<loadset.flow>

<m:is m:uri="/task/Flow"/>

<flow>

<var name="loadset" type="String" default=”…”/>

<var name="use_engine" type="String"/>

<task type="./LoadsetTask">

<bind name="path" var="loadset"/>

<bind name="engine" var="use_engine"/>\

</task>

</flow>

</loadset.flow>

In this example, the overall flow requires two input variables that should be filled before it is activated, and the information will be passed to the Loadset task accordingly. The Loadset task will perform a call to the Loadset service described previously. The duty of LoadsetTask is to collect the needed parameters for the relative function in EEGLAB and send these information as metaphors to Loadset service for further process.

Figure 8 sketches a complete workflow that performs an ERP experiment for the study of drowsiness.

Extract drowsiness

<var name = "path“ type= "String“ />

<var name = “engine“ type= "String“ />

.

Figure 8. A ERP data analysis flow