A Model for the Use of Social Paradigms in Mobile Ubiquitous Interactions

In a time where mobile devices usage is widespread and its usage for the internet, georeferenced (Global Positioning System- GPS) and for the use of services is expanding, the ability of these devices to establish cooperation networks and interacting in an intelligent and collaborative way in the surrounding environment is of growing interest. To Schmidt, the way people interact with devices is paramount for their success [6]. Mobile and ubiquitous computing may be characterized through the ubiquity of communications and devices with computational power, that become an integrating part of the physical space in which we live, as well as the various activities in our day-to-day lives [3].

Mobility of devices comes mainly from the mobility of its carriers, by so originating a constant change of the informatics environment that surrounds the device. More so the availability of public and private wireless network access, as well as ad hoc connections to other devices, provides integration opportunities for integrating devices in diversified contexts. To understand and capture the contexts automatically, in what is commonly named context sensible computing, to participate and cooperate with different context member elements, to supply and use services and information, seems relevant.

The main objective of this article is to propose a model which is capable to effectively represent the formal structure of one or several computing system in a mobile device, thinking on what role the device may perform in each system and their relation with other devices, so as to make it possible to be dynamically integrated in those systems, and the cooperation with other elements belonging to the system. In order to do so, we propose a minimum of functions and information inspired in concepts from the theory of organizations and sociology, as the notions of “social role”, “ownership” and “responsibility”, to be incorporated in each device.

We commonly call mobile computing the use of small dimension computer devices and laptops on wireless networks, connected to public and private servers, to the internet or other devices. Among these computing devices are laptops, notebooks, tablet PCs, palmtops and personal assistants (PDAs).

Ubiquitous computing is a way to improve computer usage, making many computers physically available and making them effectively invisible to the user [7]. Ubiquitous computing has as main objective to make person-machine interaction invisible, be it, to integrate in a whole informatics and people’s natural actions and behaviors [8]. By invisibility we mean to be able to interact with computing systems without realizing they are machines, rather as if one were talking with another person. In ubiquitous computing we assume that surrounding computing systems are proactive, and are connected, or are permanently trying to connect. This characteristic is often called “omnipresence”.

Context sensitive computing (Context-Aware Computing) appeared as an ubiquitous computing branch that studies the connection between environmental and informatics systems changes. Dey et al. [2]. It is a recent investigative area with difficult implementation techniques challenges, and one that has caught the attention of investigators everywhere in the world. In context sensible computing, the devices try to understand and capture automatically the surrounding contexts so as to provide a better interaction between the environment and the user, regarding hardware, software, and or communication [1].

In order to reach the dynamic integration of a device in a context sensitive computing system, with a pre-defined formal structure, it is necessary that the device has a minimal set of functionalities and a representation of different formal structures of the different context sensitive computing systems where it might fit. The representation of the system’s formal structure we propose in this article is based on the concepts of Role, Ownership and Responsibility that are liable to be reused in different computing contexts [5]. We call Role the particular connection of a device to the cooperative structure of a system that establishes, in that system, that determines a certain number of obligations and responsibilities to the device; Ownership will be the association of a device to a role to perform in the system; we call Responsibility task association to roles that bind role holders as responsible for the full task fulfillment, regardless of that fulfillment being assured by themselves or any other device in which the task execution is delegated.

Ownership, (role/roles that are performed by the device and those it interacts with in a given context, can be represented as shown in Table 1. Ownership is a relation between a device and a role that can be expressed under the form: Owner (X,R1) where X is the device and R1 is the role performed by the device. A device can own more than one role as long as it implements per se all the required functionalities for the correct performance of all roles. On the other hand, there may be more than one device that owns the same role.

When a device owns a given role, a competency principle is admitted: the device implements per se all the functions that are required for the correct performance of the role(s). This means the device has the ability of executing all the necessary functions to fulfill the tasks it’s responsible for in the role(s) it owns.

Competency to execute a task associated to a role can be defined in the following way:

1. 1.

   Being Capac_Exec(X,F1) the ability to execute from X in order to execute the function F1

2. 2.

   Being Execute(R1,T1) the Responsibility to Execute the task T1 attributed to role R1

3. 3.

   Being Owner(X,R1) the relation of ownership of X to execute the function F1

So, if F1 is a function that pleases T1 we may conclude that the device X is competent to execute the task T1. The relation F1 pleases T1 can be expressed by: Pleases(F1,T1).

Formally, the competency to execute a task associated to a role is translated as: If Capac_Exec(X,F1) Ʌ Execute(R1,T1) Ʌ Pleases(F1,T1) => Competent_Exec_Task(X,T1). The competency to execute all the tasks associated to a role- Principle of competency for the performance of a role is translated as: ∀i ∈ n (Execution(R1, Ti) => Competent_Exec_Task(X,Ti)) => Competent_Exec_Papel(X,R1). In the conception of the knowledge representation model there is the possibility of a device belonging simultaneously to more than one system, to be able to change roles and to perform more than one role within the same context. Therefore, in order for the model to support this possibility, we need to contextualize the ownership representation as illustrated in Table 2.

Ownership is a relation between a device, a role and a context, expressed formally as: Owner(X,R1,Ca) where X is the device, R1 is the role performed by the device and Ca the context in which X owns the R1 role.

A device can own roles with the same name in more than one context. However, by considering a model that includes more than one context, the definition of the roles is contextualized, so the roles can have the same name in different contexts and have different aims, depending on its definition for each specific context. Different devices can be owners of the same role provides the model with the required hardiness to compensate performance flaws and to admit structural changes and role ownership.

In Fig. 1, we present, schematically a simplified model of the representation structure of knowledge relative to a given context.

Simplified model

Full size image

The association between tasks and roles that exist in a given context, where Owners are responsible for their fulfillment, regardless of it being assured by themselves or others in which the task is delegated, is called Responsibility. The Responsibility is a relation between a role and a task, in a Ca context, and may be formally defined as:

• Responsibility(R1,T3,Ca)

In Table 3, “Task 4” is of the responsibility of the device owner of “Role 1”, but the latter may choose not to perform it directly.in order to do so, it delegates the task, which means it must obligatorily know which roles are responsible for “Task 4”.

The way the device chooses between delegating or performing must be previously defined. In terms of model, any criteria may be implemented. A possible criteria is as follows:

“If the device knows any other device with the responsibility of Executing the task at hand, then delegate the task by producing a message with an order for executing the task for that device. Or, if you don’t know who is responsible of executing and has the ability to perform the task, then execute it”. To be responsible for a task, in a given context, admits that this may or not be a composite task. If the task is composite, then the device must be able to control and monitor the execution of subtasks, thus assuring these are successfully executed in the right sequence and appropriated timing.

So it is possible to coordinate the execution of composite tasks, to have control and monitor them, it is necessary that the communication language between the devices supports specific primitives destined to manage and coordinate tasks. The discussion of primitives destined to the coordination of tasks is complex, and is not included in this article.

Another designation is “Execution Responsibility”- Tasks associated to roles existing in Context, for which the Owners are responsible to ensure the fulfillment in terms of execution. In the presented model, being responsible for the execution by a task doesn’t consider this task to be composite.

Responsibility of Execution is a relation between a role and a task, in a context Ca, and is normally defined as: Execute(R1,T1,Ca).

In Table 4, T2, T4 and T5 are atomic tasks, i.e. they have no defined Break Down:

Execute(R1,T1,Ca), Execute(R1,T2,Ca).

“Task 2” may be executed by the Owner of “Role 2” or the Owner of “Role 3”.

A device is responsible for a given Task if it’s responsible for its fulfillment, regardless that fulfillment is assured in terms of execution by itself or a “subcontract” of other devices.

A device is responsible for executing a given task if the task length is assured in terms of execution by the device. A particular aspect occurs when the same device performs a role where it is simultaneously responsible for the fulfillment and execution of a task. Responsibility(R1,T1,Ca) Ʌ Execute(R1,T1,Ca). In this case, we must define which of the two relations is stronger and overlaps the other. The definition of this criteria must be programmed.

In the case where the strongest relation is Execute(R1,T1,Ca) then the task is executed and the Responsibility(R1,T1,Ca) is overlooked.

In the case the strongest relation is Responsibility(R1,T1,Ca), depending on the criteria used by the device in order to choose between executing or delegating, the relation Execute(R1,T1,Ca) may or not be used. If the criteria is to delegate the task in a device that is responsible for the execution, then it is possible that the device will delegate the task onto another one or on itself, once it is also responsible for the execution. In this case the relation Execute(R1,Y1,Ca) may or not be used.

If the criteria is to check first whether the device is responsible for the execution and only delegate in case it isn’t, then the relation Execute(R1,T1,Ca), if it exists, is used.

By trying to characterize the delegation, three important questions emerge [4]:

• What is the nature of the relations between which delegates and which accepts the relation;

• Through which types of communication can this delegation be made and how is it specified;

• Under which conditions is it possible to say the delegation was achieved successfully.

The answer to the first two questions comes from what is specified in the model itself. The answer to the third question is provided by using two mechanisms, used together or in separate. The first mechanism is based on message exchanges and between the device that delegates and the one the delegation is made onto.

When a device delegates a task it produces a message with an order to execute the task to the device it delegates the task onto. This one answers with a message like “Info”, indicating it received the order and tries to execute the task. If it is able to execute it sends a message and informs the delegating device of its success, otherwise it sends a message pointing out the flaw. This mechanism assumes the device trusts who delegates.

A second, more complex and fallible mechanism, consists on the attempt observation by the device that delegates, of the fulfillment of the task it delegated, in order to come to conclusions about the success of the delegation. Some tasks can be broken down into elemental tasks, as shown in Table 5.

In this example “Task 1” is made of 2 tasks. Since they have the same order to execute there is no specific sequence in its execution.

“Task 1” will only be finished when tasks 1.1 and 1.2 are both concluded.

“Task 2” isn’t made of any other tasks.

“Task 3” is made of 4 tasks that must be executed the following way: Tasks 3.2 and 3.3 can only be executed after the task 3.1 is finished. There is no particular execution sequence between them. However, task 3.4 can only be executed after tasks 3.2 and 3.3 are both concluded. Breaking down tasks is the relation between a task and others that break it down. It may defined as follows:

• Break down(T3,T3.1,1,Ca)

• Break down(T3,T3.2,2,Ca)

• ….

To each relation between roles a certain Contract is determined (set of rules). A relation between two roles is always one-way (Ex: “Role1” to “Role 2”). The definition of bi-directional relations is achieved through two one-direction relations, in opposite ways.

A relation between roles is defined by the expression Relation(R1,P2,Contract,Ca) which means there is formally a relation in context Ca, between the roles R1 and R2, from R1 to R2. This formal relation is, in this model, called “Contract” (Table 7).

A contract is defined by a set of rules. Rules define the contract relative to the interactions between roles it is associated with, namely, in what concerns processing the various types of message. We will formally come up with:

• Caract(ContractA,Rule1)

• Caract(ContractA,Rule2)

• Caract(ContractB,Rule1)

For each message sent from an emitter to a receiver, the latter makes an applicability test to the kind of message in question, the rules associated between emitter-receiver. This check is achieved in two phases. In phase one, when check if the rule, according to the relation between the emitter and the receiver, is applicable in the given context. The messages between devices have the following format: Msg(D1,D2,Tm,C). Where D1 is the emitting device, D2 is the receiving device, T is the type of message and C is the contents. The general condition for applying a Rule r in treating a message, as “Tm”, send from X to Y, in context Ca, can be expressed this way:

• msg(X,Y, Tm,C) Ʌ Owner(X,R1) Ʌ Owner(Y,R2) Ʌ Relation (R1,R2,) Ʌ Caract (ContractA, r)

If this check fails, we go on to the second phase, where we execute a check to the condition for applicability of the rule in a given context. The general condition for the applicability of a Rule r in any given context that determines a given message treatment as “Tm” can be seen in the expression: msg(X,Y, Tm,C) Ʌ Owner(X,R1) Ʌ Owner(Y,R2) Ʌ Relation (R1,R2, ContractA) Ʌ Caract (ContractA, r)

When a device owns a given role, we assume a competency principle: the device implements per se all the required functions for the correct performance of the role(s). this means the device has the ability to execute all the necessary functions to fulfill the tasks it’s responsible for in their execution in the role(s) it owns.

The competency for executing a task associated to a role can be defined in the following way:

• Be it Capac_Exec(X,F1) the Capacity for executing X to perform the function F1

• Be it Execution(R1,T1) the Responsibility for the Execution of task T1 attributed to Role R1

• Be it Owner(X,R1) the ownership relation of X by the Role R1, then, if F1 is a function that pleases T1 we can conclude that the device X is competent to execute task T1. The relation F1 pleases T1 can be expressed by: Pleases(F1,T1) [5].

Formally, the competency to execute a task associated to a role can be translated as:

If Capac_Exec(X,F1) Ʌ Execute(R1,T1) Ʌ Pleases(F1,T1) => Competent_Exec_Task(X,T1). The competency to execute all tasks associated to a role, illustrated in Fig. 2- Principle of competency for the role performance- is translated as:

Execution competency

Full size image

• ∀_i ∈ n, (Execução(R1, Ti) => Competente_Exec_Tarefa(X,Ti) => Competente_Exec_Papel(X,R1))

However, in the situation there is no device that implements per se all the functions required for the correct performance of a role R1, two hypothesis are to consider:

(A) The breaking down and recursive distribution of the tasks associated to Role R1 by new roles created for that effect until a set of Devices is identified that are able to fully satisfy the functional requisits of all the new roles, or until primary tasks are attained (impossible to break down as subtasks) as shown in Fig. 3, be it {T1.1, T1.2, … T1,i} the set of subtasks of T1 and {Da, Db, …Dn}the set of devices that perform the Roles {R1.1, R1.2,… R1.i} Then: ∀_i ∈ n, (Competent_Exec_Task(Xi,T1.i) => Competent_Exec_Role({Da, Db,..Dn},R1)).

Recursive breaking down of tasks (adapted from Cunha [9])

Full size image

In the example presented on Table 6, we can see that:

“Task 1” is composed of 2 other tasks (subtasks). Since they have the same order to execute, there is no particular sequence in its execution.

“Task 2” isn’t composed by other tasks.

“Task 3” is composed by 4 tasks that have to be executed the following way: Tasks 3.2 and 3.3 can only be executed after Task 3.1 is complete. Between them there is no particular sequence of execution. However Task 3.4 may only be executed after Tasks 3.2 and 3.3 are both concluded (Table 8).

Task breaking down is a relation between a task and others that break it down. It may be defined in this way:

• Breakdown(T3,T3.1,1,Ca)

• Breakdown(T3,T3.2,2,Ca)

• ….

(B) Attributing Ownership of R1 to several Devices where, although each one isn’t competent per se to satisfy de performance of the role R1, in their whole they satisfy in total the functional requisitions of R1, by complementing their functions. Be it {T1.1, T1.2, T1.3, … T1.i} the set of subtasks of T1 and {Da, Db… Dn} the set of devices that would at the same time perform the role R1, then: Competent_Exec_Task(Da,{T1.k,…}) ∪ Competent_Exec_Task(Db,{T1.p,…}) ∪ … ∪ Competent_Exec_Task(Dn, {T1.m,…}) => Competent_Exec_Role(Da + Db + …Dn, R1)).

The first case, breaking down and distributing subtasks by different Devices presents as main disadvantage the difficulty in controlling the execution of the delegated tasks, mostly if it is recursive. In the second case, distributing of the same role through several Devices, that are not competent on their own to perform the role, but are together, recursive breaking down is not needed. This fact tends to simplify the control over task execution. Thus, having for basis the situation shown in Fig. 4, considering T1 as the set of tasks associated to Role R1 and Ta, Tb and Tc as being the set of tasks able to be satisfied respectively by devices a, b and c, it suffises that T1 ⊂ (Ta ∪ Tb ∪ Tc), as shown in Fig. 5.

Set of functions made available by Devices a, b and c

Full size image

Contribution of the Devices A, B and C for the performing of Role R1

Full size image

The fact that different Devices owners of the same Role make available some same functions (intersection zones in Fig. 5) gives enough hardiness to the model so it is possible to compensate an eventual flaw of performance in those functions. In Table 9, we examplify the application of this strategy by illustrating saved information for a situation where the performance of role R1 is assured by two devices X and Z.

With the transcribed model in this article, we aim to contribute to the debate on mobile and context-sensible computation, by proposing a model that allows us to integrate dynamically devices in computerized systems distributed in a pre-defined formal structure. The model, structured on concepts originated from organizations and sociology theories, brings with a minimal of functions and information to be incorporated in each device.

In this paradigm, when a device is owner of a given role, we admit that the device implements per se all the required functions for the correct performance of the role(s). Be it: the device has the ability to execute all the necessary functions to fulfill all the tasks for which it is responsible for, in the role(s) it’s responsible for.

However, such a principle: ∀i ∈ n, (Execute(R1, Ti) => Competent_Exec_Task(X,Ti) => Competent_Exec_Role(X,R1)), may complicate the use and integration of devices in contents, once it forces availability functions of the devices to cover in full the roles’ requirements. In this article we seek, without resourcing to the classical and always complex recursive breaking down of tasks, to point out a new way in order to minimize this problem, by proposing a set of minimal personal capabilities that a Device should have to be able to perform with success a role in a formal mobile and ubiquitous computing structure in which it is partially competent, considering the possibility of cooperation with other Devices totally or partially competent for this role.

As future work, we aim to adapt the model in the use of Service Oriented Model models, an effective development of a system that implements the suggested model and the building of a web site where it is possible, using this model, to register and obtain information on the valence of different devices and, to define and import formal structures on computing systems.