-To deploy context-aware applications, there has been a steadily increasing interest in context model to efficiently represent various contexts in daily life. However, most ways of modeling context are specific to purpose of each service or give undue value to particular information, e.g. location. To loosen the coupling between contexts and services, we propose unified context that represent user-centric contextual information in terms of 5W1H (Who, What, Where, When, How, and Why), to be shared among services. The proposed context can simply model a user's context in environments by assorting complicated information into six categories. Also, the unified context can enable sensor, user, and service to differently generate or exploit a defined 5W1H-semantic structure. Furthermore, unified context is structured with elements of 5W1H and attributes of each element so that any service can easily exploit the context for improving service. As a result, the proposed unified context enables context-aware services to more quickly provide personalized services by exploiting unified user-centric context. Index Terms-Context model, unified context, user-centric context, and 5W1H
Uenvironments smarter to sense and to respond changes biComp-enabling technologies make our daily appropriately. In such environments, there has been a steadily increasing interest in context-aware applications which react to context of users or environments near them. To deploy context-aware applications, context model that simply represents complex contextual information plays an important role in creating, interpreting, and exploiting context.
A great deal of effort has gone into the understanding and
modeling context over the past few years in the world of
ubiquitous and pervasive computing. For example, Schilit and
Theimer (1994) refer to context as location, identities of
nearby people and objects and changes to those objects [
Additionally, various researches on context-aware
computing have evaluated context modeling. For example,
Held (2002) highlighted the requirement of context model for
gathering, transferring, storing, and interpreting contextual
information [
In this paper, we propose unified context that represents user-centric context in terms of 5W1H (Who, Where, When, What, How, and Why) and evaluate it with seven evaluation factors, i.e. structure, composition/decomposition, interchange, unification, extensibility, and scalability. The unified context is classified into ‘preliminary context’, ‘integrated context’, ‘final context, and ‘conditional context’ according to the subject of generating and exploiting context, i.e. sensor, service, or user. From sensor’s view, the preliminary context represents factual information about users in a service environment. From user’s view, the conditional context depicts contextual condition that users specify in services corresponding to their desire. From service’s view, the integrated context provides accurate information by means of fusing several preliminary contexts, and the final context triggers a service only if a correspondence occurs between integrated contexts and conditional contexts.
For implementing context-aware applications, unified context has the following advantages: First, unified context can simply model a part of user’s situations in environments by assorting complicated information into six categories. From an experiment investigating the usage frequency of each element of 5W1H, unified context provides a basic-element set of user-centric context. Secondly, the unified context can enable sensor, user, and service to differently generate or exploit a defined 5W1H-semantic structure. Unified context is differently generated or exploited by dynamically building 5W1H’s elements according to context hierarchy, i.e. preliminary, conditional, and integrated/final context. Finally, unified context is structured with elements and attributes so that any service can easily exploit the context for improving service. From an experiment comparing response time, attribute-exploited services react faster than non attribute-exploited services.
This paper is organized as follows: In section 2, we briefly introduce the user-centric context and the context-model requirement. In section 3, we propose unified context and explain how to represent and to exploit unified user-centric context. Experimental results and analysis on context model are described in section 4. Finally, the conclusion and future works are discussed in section 5.
The goal of context in computing environments is to improve
interaction between users and applications. This can be
achieved by exploiting context, which works like implicit
commands, enables applications to react to users or
surroundings without user’s explicit commands [
To solve these problems, we define user-centric context in context-aware computing as “user-centric information among a variety of contexts in service environments that is interpreted, in terms of 5W1H, by applications”. The user-centric context focuses on more user than the physical or the computational environments. This is because user-centric context can play an important role in providing fundamental clues about user’s implicit commands to trigger services with an assumption that users always shed interactive information with services to environments. In addition, the definition gives a way to simply model a user’s context by assorting complicated information into six categories. This context can be practically applied to context-aware applications.
In ubiquitous computing environments, context is gathered,
stored, and interpreted at different parts of the context-aware
system. We have surveyed previous researches [
•Structure: Context should be structured to represent huge
contextual information of a user. A structured modeling
provides a way to filter relevant information and to reduce
context ambiguity by manifest labels. In addition, a structured
model is necessary for context hierarchy since a context is
generated, interpreted, and exploited differently according to
sensors, users, and services [
•Composition/Decomposition: Many ubiquitous computing
systems are derivative from a distributed computing system.
Therefore, context model requires context composition in
order to generate or to exploit context accurately by merging
several contexts from distributed sensors or services. Besides,
context decomposition is also essential to provide only the
contexts required by each service among distributed services
in an environment [
•Interchange: Context should be exchangeable among
different components of the system, i.e., between sensors and
services, and among services. Interchanging context enables a
service to directly exploit contexts generated by sensors.
Furthermore, context model needs to ensure that a service
shares context in order to harmoniously cooperate with other
services without conflicts. Therefore, context model requires
interchanging context among context-aware entities [
•Unification: It is highly desirable for each participating party in context-aware computing to share the same interpretation of context. Unfortunately, complexity of context model or interpretation is increasing since a variety of contexts are used according to specific purpose of services. As a first step to unify context, essential items of context should be determined to harmonize services and resolve conflicts.
•Extensibility: The set of elements and attributes for
representing context that will satisfy all future applications
cannot be identified today. To ensure extensibility of context
representation, the context must support methods of adding,
modifying and deleting a set of elements and attributes for
future extensions [
•Uncertainty: The set of context describing situations of
users in service environment is usually incomplete or
ambiguous. Joint processing of contexts with varying
uncertainty results in vague interpretation of context. To keep
the uncertainty as low as possible, context model provides a
way to indicate incompleteness of the contextual information
[
•Scalability: In ubiComp environments, heterogeneous sensors and services run simultaneously, and service environments around a user change dynamically. Context model requires context scalability so that context works reliably with the increasing number of sensors and services. In addition, context model allows context to be reused in more diverse application areas than specific application area.
III. MODELING UNIFIED USER-CENTRIC CONTEXT A. Unified User-Centric Context “User-centric context” refers to information that decides which service and which action of the service will be automatically triggered. According to the subject of exploiting user-centric context, it can be folded into three kinds of context; sensor, user, and service. A context of sensor’s view, what we call preliminary context, describes the physical state of users in service environments. A context of user’s view, what we call conditional context, is a set of conditions to appropriately trigger services that a user requires. A context of service’s view, what we call final context, represents a reason that a service is automatically provided by observation of physical states satisfying user’s requirements. Context-aware applications transform such contextual information into context by means of the context flow from sensor to service and from user to service. Then, context-aware applications exploit context to trigger a service appropriately.
To easily generate user-centric context, it is necessary to uniformly represent contextual information about users in service environments without depending on specific sensors or services. 5W1H is a popular way to uniformly describe a fact with “Who, What, Where, When, How and Why”. 5W1H that is applied to user-centric context can depict “a certain user (Who) is”, “in a certain location (Where)”, “in a certain time (When)”, “paying attention to a certain object/service (What)”, “making a certain expression with physical signs (How)”, or “because of a certain intention or emotion (Why)”. This unified context enables sensor, user, and service to differently generate or exploit a uniformed 5W1H-semantic structure. A semantic structure of unified context from sensor’s view is “someoneWho is paying attention to somethingWhat or representing a certain expressions with some signsHow in some locationWhere on some timeWhen”. A semantic structure of unified context from user’s view is “I want to get a certain serviceWhat if IWho am in a certain locationWhere, on a certain timeWhen, with some expressionHow or in a certain moodWhy”. A semantic structure of unified context from service’s view is “a certain serviceWhat is automatically triggered if a userWho is in a certain locationWhere, on a certain timeWhen, with a certain signsHow or in a certain moodWhy”. Because all unified contexts share basic elements (5W1H) representing user-centric context, they can be easily converted to each other. Therefore, unified context, in terms of 5W1H, enables applications to recognize and exploit context conveniently.
Unified context is categorized into preliminary, integrated, final, and conditional context. Each context consists of elements representing 5W1H and attributes describing the features of each element. Elements depict user’s contexts in service environments. Attributes provide the meta-data related to an element or relationship with other elements. Examples of the attribute include ‘Generator’, ‘Confidence’ and ‘Uncertainty’. ‘Generator’ provides the identity of a sensor or service that makes elements of 5W1H. ‘Confidence’ means the physical or logical quality of being certain of abilities or capacities (i.e. 0~100%) of the generator. ‘Uncertainty’ describes the range (i.e. 0~100%) within which correct values of the element have a specified probability of being found. It is necessary to refer to attributes during the context flow in order to generate or exploit user-centric context more accurately. This is because even the same element has different values of confidence and uncertainty according to the context-aware subject. In addition, all contexts have ‘Working Area’ as an attribute that refers to the available range (e.g. geographical region or ownership between user and sensor/service, etc) of the context in a service environment. By exploiting ‘Working Area’, sensors deliver preliminary contexts to all services in the same working area and services share final contexts with each other. Especially, all sub-elements of final context have a special attribute, ‘HitRatio’, that is each element’s ratio of correspondence between integrated and conditional context. This is used to choose elements with high-ratio value among complicated sub-elements of 5W1H for simplifying the context comparisons. • Who ‘Who’ element of 5W1H provides identification of a user in service environments and is a basis for processing a set of 5W1H. As shown in Figure 1, ‘Who’ consists of ‘Name’ and ‘Profile’ as sub-elements. ‘Name’ has user name as a value and ‘UID’ and ‘PWD’ as attributes. ‘UID’ and ‘PWD’ refer to meta data for accessing services in home or office environments, e.g. social security number. ‘Profile’ is personal information that is open to environments by users. Personal information (e.g. favorite service lists, social relationships, etc) plays an essential role in triggering services harmoniously. However, it is difficult for applications to recognize personal information and to exploit it without user’s permission. Therefore, ‘Profile’ enables users to make such personal information open to service environments. ‘Profile’ consists of ‘FavoriteService’ and ‘Relationship’. ‘FavoriteService’ has service list as an element and ‘At’ and ‘Type’ as attributes. ‘At’ refers to service environments such as home and office. ‘Type’ alludes to a sort of service, e.g. movie, music, light, etc. ‘Relationship’ has social relationship with persons as a value and ‘Person’ and ‘Priority’ as sub-elements. ‘Person’ refers to identification of other person and ‘Priority’ shows the priority over the person. In case of ‘Priority’, it has a value range from -100 to 100. The positive means a user has higher priority than another and the negative means a user has lower priority than another.
Who • Where ‘Where’ element of 5W1H gives a user’s location in service environments. The location plays an import role in accessing available services near a user because all applications operate in a working range. As shown in Figure 2, ‘Where’ contains ‘Location’. Among various ways to represent location, coordinates-based and symbolic methods are popular in context-aware applications. ‘Location’ consists of ‘Coordinates’ and ‘Symbol’. In addition, it has ‘Type’ as an attribute which refers to whether a location is for indoor or outdoor places. ‘Coordinates’ has ‘X’, ‘Y’, and ‘Z’ sub-elements representing a 2D or 3D position. This also has ‘Granularity’ and ‘Origin’ as attributes. ‘Granularity’ specifies a unit of coordinates, e.g. centimeter (cm) or meter (m). ‘Origin’ refers to the origin of coordinates such as the door. ‘Symbol’ has abstract-level location corresponding to coordinates as a value and ‘Reference’ as an attribute. ‘Reference’ specifies a translator which converts a coordinates into symbol. • When ‘When’ element of 5W1H represents time when a context is available, i.e. a given context is generated or valid at a given time or interval. As shown in Figure 3, ‘When’ consists of ‘TimePoint’ and ‘Interval’ as sub-elements. ‘TimePoint’ has time point as a value. ‘Interval’ consists of ‘From’ and ‘To’ that represents time duration. All contexts can be indexed by time information and then they can be exploited such as indexing contexts with time for context pattern of triggering services. There are various ways to represent time like location. Among them, absolute and symbolic representations are popular. Both ‘TimePoint’ and ‘Interval’ have ‘Type’ and ‘Reference’ as attributes. ‘Type’ refers to whether time is absolute or symbolic. If time is symbolic, ‘Reference’ indicates a translator that converts absolute into symbolic time. • What ‘What’ element of 5W1H is information of an object which a user is paying attention to. As shown in Figure 4, ‘What’ consists of ‘Destination’ and ‘Manipulation’ as sub-elements. ‘Destination’ is comprised of ‘Identity’. ‘Identity’ has object name as a value and ‘Type’ as an attribute. ‘Type’ refers to a sort of service which the object provides. ‘Identity’ contains ‘Conflict’ as sub-element. ‘Conflict’ has identity of other object that the attended object collides with if they are triggered simultaneously, e.g. TV and Audio. In addition, it contains ‘Priority’ as sub-element that refers to the priority over the conflicted object. ‘Manipulation’ provides operational information of the object which a user is interested in. So it consists of ‘Function’ and ‘Parameter’. ‘Function’ has operations of the service as a value and ‘Parameter’ contains parameters that a function uses as input.
What attribute
Uncertainty element ? Manipulation attribute
HitRatio element Destination element Identity element * Conflict element Prority attribute attributes attribute
Type Type, HitRatio
HitRatio element Function element * Parameter • How ‘How’ element of 5W1H depicts a user’s expression with signs such as behaviors or bio-signals. As shown in Figure 5, ‘What’ consists of ‘Behavior’ and ‘BioCondition’ as sub-elements. ‘Behavior’ is comprised of ‘Gesture’, ‘Action’ and ‘Activity’. ‘Gesture’ has movements of the hands, legs, and body as values. ‘Action’ contains high-level information that is translated from successive gestures. ‘Activity’ shows abstract information that is interpreted from some actions. The reason why user’s behaviors are categorized into gesture, action, and activity is that they represent a hierarchy of user’s behaviors. For example, “a user gets a right hand up and down” is a gesture. However, if the gesture successively occurs, it is an action that means “a user swings right hand”. Also, if the action repeats for a period, an activity occurs with a meaning, “a user exercises”. ‘BioCondition’ provides indirect information of user’s expression through the changes of bio-signals such as pulses, temperature, and galvanic skin response. So ‘BioCondition’ consists of ‘PPG (photoplethysmogram)’, ‘GSR(galvanic skin response)’ and ‘SKT(skin temperature)’. All sub-elements of ‘BioCondition’ have ‘Type’ as an attribute because each bio-signal is differently represented according to measurements. • Why ‘Why’ element of 5W1H represents a mental state of the user such as intention or emotion. Because intention or emotion
How attribute
Uncertainty element ? Behavior element ? BioCondition element * element * element * element * element * element *
Activity attribute
Type, HitRatio
Action attribute
Type, HitRatio
Gesture attribute
Type, HitRatio
PPG attribute
Type, HitRatio
GSR attribute
Type, HitRatio cannot be detected by sensors, it is difficult to represent a state of user’s mind correctly. The goal of using ‘Why’ is not to be aware of full mentality but to provide a clue to trigger a service or to get user’s feedback on given services. As shown in Figure 6, ‘Why’ consists of ‘Intention’ and ‘Emotion’ as sub-elements. ‘Intention’ represents user’s mental states to manipulate service, e.g. turn on, tune off, etc. ‘Emotion’ represents user’s response to given services such as good, bad, happy, and unhappy. Both ‘Intention’ and ‘Emotion’ contain ‘Type’ as an attribute because they are represented with various values and in categories.
Why attributes
Uncertainty
Unified context is identified as ‘preliminary’, ‘integrated’,
‘final’, and ‘conditional’ context according to the subject of
generating or exploiting context [
rseno rsno S ro eS s n e S ryrayray tt anin txx iilnmliiremilremtexnoteonCteonC rePC P P
Preliminary context, generated by a sensor, represents contextual information about a user in a service environment. Figure 8 shows an example of preliminary context. From attributes of ‘Context’ element, this context is generated by ‘ubiTrack’, a sensor with confidence 80%, in working area ‘B’. ‘Who’ element represents user’s identification and certainty that a user is ‘Seiie Jang’ is 90% (or uncertainty: 10%). ‘Where’ element depicts that someone is located at (3,4) in coordinates whose origin is ‘Door’ and a unit of X and Y is 80cm. This location information is correct in certainty 60%. ‘When’ element indicates that this preliminary context is generated at 21:30 ~ 31, April 12, 2005 in certainty 80%. ‘What’ element provides information that the user gives attention on TV by detecting user’s head position or eye’s gazing in certainty 70%. This preliminary context can be interpreted with sensor’s semantic structure as “Seiie JangWho.Name is paying attention to TVWhat.Destination.Identity at (3,12) locationWhere.Location.Coordinates in 21:30~32When.Interval”. This unified context is delivered to all services in working area B.
Conditional context is a set of conditions in order to trigger personalized service. This is specified by users and updated by services according to user’s feedback on a given service. Figure 9 shows an example of conditional context. The context contains two conditions on TV and light services for a user, ‘Seiie Jang’. Conditional context on TV is in certainty 100% since the user specifies it by means of ‘WPS’, a personal device. In case of light service, meanwhile, certainty is 50% because it is modified by light service. The user sets ‘Who.Profile.Relationship’ in order to provide TV with conflict-resolved information if the user and another user, ‘Woontack Woo’, access TV service simultaneously. With this context, TV provides higher priority to ‘Woontack Woo’ than ‘Seiie Jang’. Also, the user specifies ‘Where.Location.Symbols’ and ‘What.Destination.Identity’ in order to represent that TV automatically takes an action if he is nearby TV and pays attention to TV. In addition, the user sets ‘What.Destination.Identity.Conflict’ to provide TV with conflict-resolved information if TV and Audio turn on simultaneously at the same working area. With this context, TV has higher priority to provide the user with a service than Audio. After specifying such conditions, the user sets ‘What.Manipulation’ for a kind of action of TV corresponding to the condition. This conditional context can be interpreted with a semantic structure of user’s view as “I want to get TV(Play: channel 9, volume 20)What.Manipulation if Seiie JangWho.Name is paying attention to TVWhat.Destination.Identity around the TVWhere.Location.Symbols and is standingHow.Activity.Action”. <?xml version="1.0" ?> <!DOCTYPE Context (View Source for full doctype...)> <Context Generator="WPS" Confidence="100"> <Conditional Service="TV" Uncertainty="0"> <Who> <Name UID="731219-xxxxx">Seiie Jang</Name> <Profile> <Relationship> Disciple <Person>Woontack Woo</Person> <Priority> -40</Priority> </Relationship> </Profile> </Who> <Where> <Location Type="InDoor"> <Symbols Reference="ubiHome">TV</Symbols> </Location> </Where> <What> <Destination Type="Object"> <Identity Type="MultiMedia"> TV <Conflict>Audio</Conflict> <Priority>30</Priority> </Identity> </Destination> <Manipulation>TV <Function>TurnOn</Function> <Parameter>Channel 9</Parameter> <Parameter>Volume 20</Parameter> </Manipulation> </What> <How> <Activity>
<Action>Standing</Action> </Activity> </How> <Why>
<Intention>Turn On</Intention> </Why> </Conditional> <Conditional Service="Light" Uncertainty="50"> <Who> <Name UID="731219-xxxxx">Seiie Jang</Name> </Who> <Where><Location Type="InDoor"> <Symbols Reference= "ubiHome"> TV</Symbols> </Location> </Where> <What> <Manipulation> Set <Parameter>Brightness 2</Parameter> </Manipulation></What> </Conditional> </Context>
Integrated context generated by a service is a result of fusing each element of 5W1H of preliminary contexts from all sensors in the same working area. Figure 10 shows an example of integrated context. Each 5W1H element of the context has different uncertainty. This is the reason why context-fusion method is different according to each element of 5W1H. In addition, sensors in working area B have their own confidence and all elements of a preliminary context have different uncertainty. As a result of selecting elements with high certainty (low uncertainty) among fused context in order to provide accurate user-centric context accurately, a set of integrated context is generated. This integrated context can be interpreted with a semantic structure of service’s view as “Seiie JangWho.Name is paying attention to TVWhat.Destination at (3,12) locationWhere.Location.Coordinates in 21:30~32When.Interval and is standingHow.Activity.Action for turning on TVWhy.Intention”.
Final context is generated by a service that searches conditional contexts in correspondences with a set of integrated context and then combines conditional and integrated context if accord occurs. Figure 11 shows an example of final context. To simplify comparison between integrated and conditional context, elements with higher hit ratio such as ‘Who.Name’, ‘Where.Location.Coordinates’, and ‘How.Activity.Action’ are determined with first priority. This final context is interpreted with a semantic structure of service’s view as “TV (Play: channel 9, volume 20)What.Manipulation is triggered if Seiie JangWho.Name is paying attention to TVWhat.Destination.Identity in the TVWhere.Location.Symbol and is standingHow.Activity.Action (for turning on
However, the service checks possibility of this service causing a certain conflict before triggering the service. For this, all services in the same working area share the final context with each other.
We have implemented ‘ubiHome’, a test bed for
ubiComp-enabling home environment[
To investigate usefulness of unified user-centric context, we gathered integrated, final, and conditional context from services (i.e. cPost-It, c-MP, ubiTV, and TMCS) used by 5 volunteers (3 males and 2 females) for 30 days. All volunteers are in 20~30 years old range and are familiar with using the services. Each volunteer can specify a set of conditional contexts with his/her PDA. The PDA provides graphic interface which enables volunteers to select sub-elements among 5W1H for conditional contexts and to combine them with services. The conditional contexts are delivered from the PDA to all services in a working area where a user is located. After the user is out of the working area, the services remove the user’s conditional contexts. A goal of this experiment is to determine basic sub-elements of 5W1H for modeling unified user-centric context. We measured the usage frequency of each element of conditional context for all services and analyzed it according to service and user. The reason why we investigate the usage frequency of elements of conditional context is that conditional context directly influences triggering of a service.
As shown in Figure 13, some sub-elements in 5W1H are referred more frequently than others by users to trigger services. In case of “Who” element, “Name” is the frequently used sub-element since users generally let a service to identify themselves for personalized service. In case of “Where”, “Symbols” is mostly used as sub-elements since users prefer representing location symbolic with daily objects, e.g. home appliance, furniture, etc. In case of “When”, “TimePoint” is mostly used because many services are triggered in synchronization with some events such as TV or radio program that start on specific time. In case of “What”, “Identity” is mostly used to represent user’s interested object and “Manipulation” is often referred to specify actions of service with proper parameters. In case of “How”, “Gesture” is mostly used since users are familiar with manipulating simple services with hand or body gestures. In case of “Why” that is least frequently used among others of 5W1H, “Intention” is used to represent command for terminating or modifying services by force as user’s feedback. Indeed, it does not mean that only these highly-frequently used sub-elements of 5W1H contexts can be shared by all kind of services. However, “Name” in “Who”, “Symbols” in “Where”, “TimePoint” in “When”, “Identity” in “What”, “Gesture” in “How” and “Intention” in “Why” are the basis of user-centric context since they are mostly referred by users regardless of service’s purpose. Therefore, to simply represent user-centric context for services, it is necessary to investigate basic elements to trigger or manage service effectively while resolving service conflicts or linking services based on user’s task.
To evaluate context representation for efficient comparison between integrated and conditional context, we measured average response time of two types of service; one type is based on a search method that finds correspondences between integrated and conditional context by exploiting an attribute, ‘HitRatio’, of sub-elements in final context. The other is based on a search method without exploiting the attribute. cPost-it c-MP ubiTV TMCS 40
InteSntuiobn-elemeEntct of 5W1H
As shown in Figure 14, average response time of services is different for each service. All ‘HitRatio’ search-based services react faster to user’s context than non-‘HitRatio’ search-based services. This is because ‘HitRatio’ search-based services reduce search time, which determine a correspondence between integrated context and conditional context, by comparing sub-elements according to the order of ‘HitRatio’ priority as shown in Table 1. If a sub-element ‘Name’ of ‘Who’ element exists in an integrated context, in case of cPost-it, a set of conditional context having the equal value of ‘Name’ of ‘Who’ element of the integrated context is extracted. Then, a ‘Symbols’ of ‘Where’ is searched in the extracted set of conditional contexts since the ‘Symbol’ has the second highest ‘HitRatio’ among the other sub-elements. As a result, such a search process reduces more comparison time than that of non- ‘HitRatio’ search-based service. Especially, the difference between average response times is larger if the complexity of conditional context is increased, e.g. number of conditional context in a service, various sub-elements usage, etc. If the number of a set of conditional context in a service is N, complexity of search exploiting ‘HitRatio’ can be O(NlogN). Otherwise, search complexity without exploiting any attribute such as ‘HitRatio’ is O(N2). As the number of a set of conditional context increases, the difference of average response time between ‘HitRatio’ search-based and non-’HitRatio’ search-based service become larger. Therefore, it is necessary to represent meta data (i.e. hit ratio, uncertainty, confidence, etc) as well as user-centric information (i.e. 5W1H) in context to provide faster context-aware services cPost-it c-MP ServiceubiTV
TMCS
We evaluate the 5W1H-based context model with seven 600 ) 500 s (em400 m i eT300 s n op200 s e R100 0 HitRatio Search Non HitRatio Search factors. Table 2 shows the results of the evaluation.
Structure of Unified Context: Unified context consists of elements and attributes. An element represents user’s situations and an attribute describes features of the element. Unified context enables an element to include sub-elements representing user-centric situations in details. In addition, all elements and attributes are labeled to reduce the ambiguity that may occur during interpreting context.
Composition/Decomposition of Unified Context: Unified context is classified into preliminary, integrated, final, and conditional context. This is adaptable to create, interpret, and exploit context in distributed computing environment. Pervasive sensors in daily life generate contextual information as preliminary context and deliver it to all services in the same working area. Each service composes preliminary contexts and interprets integrated context to trigger actions. To support such a process, unified context guarantees the composition of context. Also, user-specified conditional contexts are distributed to services that reside in same active area with the user. This requires unified context to support decomposition of context representation.
Interchange of Unified Context: Unified context guarantees the serialization of context representation because it is implemented by XML. Unified context enables any service to use context from any sensor in the same working area. In addition, it guarantees harmonized services that share the state of operation with others by exchanging final context.
Unification of Unified Context: Unified context represents user-centric context in terms of 5W1H and is exploited according to the view point of sensor, user, and service. 5W1H-based unified context has ability to simply represent user’s complicated situations. However, it requires formalizing relationships among sub-elements of 5W1H enabling users (or services) to easily specify(exploit) conditional(integrated/ final) context.
Extensibility of Unified Context: Unified context guarantees extensibility of context by means of structural representation that enables an element to contain sub-elements. However, there is a restriction that all elements must fall into six categories. In addition, unified context must be extended to represent user-centric information to both physical and computing environments.
Uncertainty of Unified Context: Unified context represents a way to quantify level of the ambiguity of user-centric context because each element has special attributes such as confidence and uncertainty. However, it lacks quantitative measurement of confidence and uncertainty. To solve the problem, we need to standardize the level of context-awareness and requirement per context level.
Scalability of Unified Context: Unified context has been
applied to several sensors and services working in a test bed.
Furthermore, unified context representing user-centric context
has played an important role in seamlessly connecting
applications in heterogeneous area such as home[
In this paper, we proposed unified context that represents user-centric context in terms of 5W1H and evaluated it with seven factors. Experiments showed that the proposed context can simply represent a user’s context in environments by assorting complicated information into six categories. Also, the unified context can enable sensor, user, and service to differently generate or exploit a defined 5W1H-semantic structure. Finally, unified context is structured with elements of 5W1H and attributes of each element so that any service can easily exploit the context for improving service. As a result, the proposed unified context enables context-aware services to quickly provide personalized services by exploiting unified user-centric context.
However, there is still a need to improve unified context in future works. This includes categorizing usage patterns of 5W1H according to kind of service and investigating useful meta data for better service performance. Furthermore, we should complement unified context since it has produced inefficient rate on extensibility and uncertainty among seven evaluation factors.