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 | SubordinatesA later I-Space tool might support information about capabilities and authorities in an alternative presentation that might show all known panels/agents in a table and for each give:
These are used to set up a number of things in I-P2...
In the general model the following are available... "I-World" - all panels and agents known or made known to the current panel/user.
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.
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.BAT answered:
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).