I-Space

I-Space is the concept for managing organisational structures and relationships especially in I-X Process Panels which support their user in task related activities. I-Space is one of the features of our I-X approach to process panels and (semantically) augmented messaging that has been initially developed on the DARPA/CoAX work and which will be expanded upon in the CoAKTinG project and perhaps on Natasha Lino's PhD with her interests in activity/plan and performing agent visualisations.

We have included a simple but very useful initial facility in I-P2 version 2.0 that allows any panel to be made aware of its superiors, subordinate, peers and contacts. This is done using the configuration Java props file at the moment, but we expect the I-Space to eventually be stored in XML form, and to be able to be loaded, modified and saved. An I-Space tool will be created to allow for management of this I-Space description. Loading an I-Space description is meant to set the interaction space or I-X Organisational Space (I-Space) for a panel or any agent.

At the moment, the meaning of superior, subordinate, peer, and contact are built into the I-P2 code, and are used to program action menus, "send to" contact lists in messaging, etc. Panel relationships related to contacts are used to present the possible recipients of messaging through the I-X Augmented Messenger (I-AM) tool. These can be added to by the user of our process panels and the messenger tool. More is expected to be done on the CoAKTinG project in this respect.

In due course the intention is that "capability" descriptions for each panel/agent will be available for each external agent. This says what the other system is capable of. Also an "authority" to use the various capabilities of the other systems will be maintained. So the idea is that you can use a capability of another system which you have the authority. Seeking authority (from an appropriate authority giving capability system) where you do not have it will be something we would wish to allow.

An initial I-Space tool might simply show the relationships graphically...

                       Superiors
                           |
     Peers -------------   Me -------------  Contacts
                           |
                      Subordinates

1. panel/agent name
2. relationship (superior, peer, subordinate, contact or none)
3. "gate" pattern giving a capability description as provided by the other agent/system
4. "guard" check to allow a check on whether the other system will authorise use of a capability by the sending agent. This might be partially declarative (to allow for reasoning and menu creation by the panel/agent), and partially an indication of how to ask the other agent to perform the check.

More Detailed Suggestions

• superiors
• peers
• subordinates
• contacts

These are used to set up a number of things in I-P2...

1. Action lists to respond to issues and activities are set up as follows:
   • superiors - escalate (without report-back) to <superior>
   • peers - pass with report-back to <peer> pass without report-back to <peer>
   • subordinates - delegate (with report-back) to <subordinate>
2. "Send to" lists in the I-X Augmented Messenger (I-AM) are set up to include the relations and "me". "Me" is encoded for sending notes to oneself and as a convenient way to add to your own activity and issue lists for example).

In the general model the following are available... "I-World" - all panels and agents known or made known to the current panel/user.

• "I-Room" which specifies a single configuration of relationships between the current panel ("me") and any "relations" which may be specific or generic classes of panels or agents in the I-World. There can be multiple alternative I-Rooms, but one is selected as the current one. Rooms can have a name which is used to identify the context. One room is identified as the "home" (though this too can be altered).
• Capability models (which may dynamically alter) describing what each panel advertises it is willing to do and under what constraints for some other agents/panels.
• Authority descriptions and checking mechanisms (which may dynamically alter) which state whether some agents/panels have authority to use the stated capabilities of other agents/panels and if so under what constraints.

1. I-World = union of superiors, peers, subordinates, contacts and me.
2. A single unnamed current I-Space (a single unnamed I-Room)
3. Action menu behaviour as stated above for the 4 differntly names sets of agents/panels.
4. Send to lists based on the whole I-World.

An alternative specification of the I-Space may be stated using a property i-space=pathname (URL syntax) which can be used to give an XML I-Space file that is loaded when a panel is started. This can specify an I-World, and one or more I-Rooms (any named relations not included in the I-World are added automatically). One room (or the only one provided) could be identified as the "home" room - and be the default preselected at startup. It is not clear yet if behaviour, authority and capability information should be kept separately.

An I-Space tool can be used to view and amend the I-Space. A tabbed approach could be taken in which the tabs are labelled with each I-Room name, and one will be shown as the selected one in some way. The current selection could be altered to "go into another room" or select another working context. It should be clear which is the "home" room to help the user maintain context. The relations within an I-Room can be defined from any agent/panel in the last known or initially loaded (but unchecked) I-World. Checking an I-World could be a supported facility to edit out unwanted entries. But note that unavailability of a relative or other I-World entry does not necessarily mean that the I-Space is to be altered - it could just be that the user or agents is unavailable or off-line. Research to link these concepts to presence systems will be looked at. Ways to add, delete and edit entries and relationships could be provided. The results could be saved to an XML I-Space file for future use. This file should have an XML version number included to ensure that changes to I-Space configurations can be managed over time and legacy I-Spaces handled by later systems. [For coding the I-X version 2.1 Simple Domain Editor might have much of the required infrastructure to make a start on this].

A tool to manage authorities for the current panel ("me") to make use of the other capabilities, and to map these to desired action and other menus and lists in the process panels would be available within the I-Space tool.

In terms of visualisations, one way to view the relationships will be graphically with "me" at the centre and to show the "direct relations" only. One can imagine tools to show organisational structures if this becomes of interest to some members of the I-X research team. Another visualisation can use a tabular form to show more details and allow for more flexible specification of relationships.

Questions and Ansswers

This reminds me of the communication ability buttoms, such as "send to". Are they sensitive to different processes. E.g. some processes are internal to themselves and therefore such communication facilities are not applicable.

in due course its suggested that all these things be sensitive to the type of entry (issue or activity, etc), the pattern involved, perhaps constraints that are satisfied or not, the capabilities of the I-Space relationships in force (in the currently selected I-Room), and the authorities believed to be available to the current panel (though these are subject to checks when you actually try to use them).