This paper presents a conceptual model which aims to account for context-sensitivity in a comprehensive and integrated fashion for Web engineering processes. The model permits the combination of a domain ontology with context-relevant parameters, with a degree of relevance. In the subsequent development of the Web application, the Web engineer can then choose to make use of the context-sensitive model where it is deemed useful, and at varying levels: navigation, content display and services presented to the user.
The next generation of Web software holds the promise of mass customization ([
Several approaches to integrating such context-awareness within software
applications have been used in the past. Hypermedia applications have typically focused on the
areas of learning and information retrieval, with the goal of guiding the user's
navigation and presenting relevant information. An overview of this eld of research, usually
called adaptive hypermedia, is given in [
We believe that context modeling is potentially useful in all types of applications, and that therefore a more general model, including mechanisms for context integration and usage, which would cover a wide variety of application domains, would be bene cial. Attempting to integrate context and adaptation capabilities in a comprehensive approach poses a number of interesting challenges. An integrated conceptual model based on a multitude of context factors is needed. This raises the question of how to structure and systemize the analysis and design processes. There is the risk of high complexity resulting from a large number of interactions between context factors. Generally speaking, modeling context is a dif cult and time-consuming task, so an important question is how it can be made more effective, with the help of an appropriate base model and tools.
Our speci c focus is the area of Web engineering, which advocates a process and a
systematic approach to development of Web-based systems ([
Recent studies have shown that a systematic engineering approach is often lacking in
the development of Web software [
In our modeling approach, the domain ontology plays a central role and may already have been developed in the overall engineering process. The goal is then to connect the domain ontology with context information. Context parameters are classi ed and connected with a certain weight to elements of the domain ontology, resulting in a relevance space. This approach is detailed in this section; the subsequent section will focus on how this model may be used by a Web application.
It should be noted that, although we shall aim at having as big a part as possible of the model generated by the system, we consider it indispensable for an expert user to be able to validate and extend the model. Therefore the model will need to be exible with regard to representing context information, and yet remain comprehensible by an expert user. The goal of attaining this compromise will motivate the decisions presented here. 2.1
Our general notion of context is that elements of the conceptual design space of an application, such as concepts of the domain ontology, can be contextualized through relations to elements of the context space. A certain information object may be, for example, particularly relevant for a speci c geographic region or location. This relation is reciprocal: the information object is relevant if the current context is determined by the speci c location; conversely, a speci c location may be relevant if the current context focus is on a particular information object.
Context is thus determined by a set of context factors and a current perspective on these factors, an integrated ontology, a structuring of the context factors. 2.2
The question of how to integrate context elements, or parameters, within an application model can be approached in two different ways. First, it is conceivable to allow for arbitrary de nition of context parameters, and arbitrary combination with elements of the domain ontology. This would provide for maximum exibility in the linking of context parameters and domain elements, and ensure that the model has a theoretically unlimited expressive power.
The second approach is to de ne a categorization of context parameters, and require speci c values relevant to the application domain at hand to be assigned to one of these classes. This would seem to be a major restriction for the conceptual model, however, for the practical usage, we postulate that such a grouping of parameters is unavoidable, from the modeling perspective and from the usage perspective. Since we assume that some form of human interaction will be required to complete and adjust the model, the grouping of parameters is indispensable for the user to maintain an overview of the model. On the other hand, we assume that not all context elements will be linked with the domain ontology. This means that there will be a concept of neighborhood between context elements, such that certain elements will be relevant in a given context, even though they are not directly linked to the domain. In order to achieve a neighborhood, some form of categorization is required. Furthermore, such a categorization will allow for a large degree of re-use, through the possibility of context catalogues.
Given that we wish to classify context elements, we now should ask which, and how many, classes are useful. Existing approaches in mobile scenarios, as described above, usually focus on one or two classes, which are key to the scenarios they wish to cover: these are typically Location and/or Device, sometimes Time. The limitation to one or two classes has the advantage of ensuring that the model will remain understandable, however is less expressive and limits the combination possibilities. For context modeling representing a broad variety of Web application scenarios, we propose the following categories of context parameters: User & Role: a categorization of users according to their role, such as various types of customers, or different types of employees. Process & Task: the functional context, such as work items for employees. Location: a categorization of locations relevant to the application, in the desired granularity: for some applications, the country may be suf cient location information, for others, the city, and so forth. These locations are not to be confused with the locations sensed by the system, such as by GPS positioning, user input, or network address (IP address or the like). Furthermore, this location categorization does not refer to locations in the information space (i.e. where is a certain Web media located) nor their proximity location-wise to other elements in this space: in our terminology, this type of relationship is part of the domain ontology, not of the context dimensions. Time: different types of time information may be relevant, such as the time-zone of the client, the actual time, a virtual time, etc. Device: device information may be a relevant context parameter (such as in mobile scenarios), e.g. the device type, display properties, etc. The modeling for a speci c application domain will consist of linking elements of the domain ontology with elements of the context model, and assigning a relevance factor to this link. We term the resulting model the relevance space (an example is provided in the next section).
Elements of context are also linked to services which are available to the Web application, or, more precisely, to service descriptions. By service, we understand a mechanism through which the application will provide the user with a dynamic offering: e.g., a reservation service through which the user can book a ight. Typically, the Web application would offer such a service to the user, and to implement the service would rely on an actual, back-end service, which is either locally implemented or is a third-party offering. These services could in turn be Web services, for which the Web application would act as consumer, but could in fact be supported by various back-end technology. Thus, in our model, service descriptions are used for describing a service which is relevant in the given context.
Note that not all parts of the context model need be explicitly relevant in the modeling process. However, they remain available to the application, and may become a part of the decision-process even if they are not directly linked to the domain resources.
The actual context parameters might come from various sources: prede ned context catalogs, such as categories of time like spring, summer, fall and winter; geographic zones; user roles typical to certain business domains; etc. the domain ontology, as it may already contain elements pertaining to context. For instance, geographic zones might already be represented in the ontology, if inherent to the business domain. custom additions by experts of the domain.
Our aim is that much of the model will be automatically generated using the available sources, and then ne-tuned by a business expert. This generation activity is however not the focus of this article. 2.4
Given the above categorization of context parameters, the context space C may be dened as the combination of context parameters, domain ontology elements and service descriptions:
C = fU; P; L; T ; D; I ; Sg where U is the set of user & role factors, P the processes & tasks, L the locations, T the time factors, D the device factors, I the available information items, and S the available services (or service descriptions).
The relevance space R can then be de ned as the product of the context space with a relevance factor:
R = C
R
Relevance factors are associated with items in the hierarchy, i.e. context parameters and elements from the domain ontology, including service descriptions. Sub-items in the hierarchy implicitly carry the same factor, unless overridden by a more speci c value. (1) (2)
Figure 2 provides an example of a context model and the associated relevance space. Consider a construction market servicing various geographical areas (as an online store and/or as actual outlets). A product from the domain ontology is modeled to be relevant (marked as +) in a geographical area. All sub-areas, i.e. sub-items of the hierarchy are implicitly of the same relevance. Furthermore, within a more speci c geographic area, and for a speci c user pro le, the element of the domain ontology is modeled to be even more relevant (marked as ++), making it more susceptible in appearing e.g. in a customized offering.
As shown in this example, the business user may model the relevance factors in the granularity of her choosing; not all elements need be explicitly linked with relevance factors. However, the elements' presence is useful even if not explicitly linked: such elements can nonetheless carry a relevance factor, by their proximity in hierarchies to elements which are linked. Note also that although our de nition of context allows for arbitrary relevance values, we presume that a higher-level de nition as shown in the example will yield more meaningful results, given that the relevance factors will need to be veri ed by a business expert in a sensible manner.
At this stage of context modeling, the services to be integrated are viewed as simple
domain elements, in analogy to elements of the information space. A service can be
associated to the context parameter hierarchy, with a certain relevance, just as the other
elements. A more detailed speci cation of the service will later be necessary in order
to provide a meaningful mapping of application parameters (such as a GPS location)
to a context parameter used in the model (such as a geographical zone relevant to the
current business domain). [
The availability of several dimensions in the context model obviously raises issues of
practicability. Potentially, an item of the relevance space may need to be displayed in as
many dimensions as there are parameters, making this display very dif cult to interpret.
Yet, a useful interpretation for a user is necessary, as we believe user adjustments to the
model should be possible at any time. We postulate that the modeling in such a manner
is nonetheless useful: a given relevance link will usually not be a link between all
dimensions, but more likely between two or at most three, and recent research offers new
tools such as [
The issue of precision of the relevance setting is also important, and was introduced by the example in Fig. 2. In principle, it is necessary to maintain the possibility of arbitrary precision for a relevance setting: a relevance setting need not be explicitly speci ed by the user, but could either be the result of automated extraction from company resources, or be a result of an item's proximity to other items which do have explicit relevance factors. For the latter, an algorithm will compute the actual relevance factor. For such items for which the user will want to set a relevance factor, the possibility of entering a high precision value (such as a probability value) may be counter-productive, as it is more likely to result in confusion and errors. Instead, the business expert might specify the relevance factor at a high-level, perhaps in ve categories: ++ meaning very highly relevant, + meaning highly relevant, no marking meaning somewhat relevant, meaning rather irrelevant, meaning totally irrelevant. A or setting would indicate items which are inappropriate in a given context, and thus may bother or even offend the end-user if presented in that context.
Modeling relevance relations between context parameters and domain ontology
elements is conceivably a lengthy task, which we believe can be considerably supported
by the system, through mining of the data stock available at the customer's site. One
approach would be to look for co-occurrences and set relevance factors according to
statistical values. The expert user would then be asked to verify the accuracy of the model.
For an applied example of generation of a concept network through data mining, see
[
Once de ned, the contextual model is available to the remainder of the Web engineering process. One can distinguish between two types of approaches: complete integration or part-wise integration. By complete integration, we understand that all parts of the Web application would be context-sensitive, i.e. all menu navigation and information presented would be generated according to context. In a part-wise integration, the application would in some parts be context-independent, and in other, selected parts, present context-sensitive menu navigation and information.
We believe that, typically, not all parts of a Web application will require a contextsensitive model. On the contrary, for some aspects adaptation may be counter-productive. Therefore it is an issue of the Web engineering process to determine in which parts, which types of context-sensitive resources will be useful. It should be noted that, in any case, context parameters will need to be modeled in an integrated fashion with the application domain if a useful usage of context factors is to be achieved: in this light, the decision whether a Web application should be fully or partly context sensitive is secondary. 3.1
Given speci c context parameters (such as described in the previous section), the system will provide resources which are deemed to be relevant in this context - these are what we term the context-sensitive resources. Reciprocally, given a speci c resource, the system can provide context factors for which this resource is deemed to be particularly relevant - this information could then be used e.g. to search for other resources relevant in the context.
We distinguish three types of context-sensitive resources (see Fig. 3): N avigation refers to navigation possibilities which are relevant to this context, through a menu or through other types of links. For instance, the context-model can Given that there is a categorization of context parameters in the model (see above) and thus a concept of neighborhood, a request to the context model for relevant resources may have different results. The request may be more or less granular; typically not only exact matches will be wanted, but also neighboring resources. Since the relevance space is linked with a relevance factor, any element of the context space will have a certain relevance factor. We propose the use of a context lter or context lens, which will have a certain relevance setting; according to the setting, those elements of the context space will be matched which have a relevance factor equal to, or greater then the lens setting. Once the conceptual model has been established as described above, several inference mechanisms for the generation of the adaptation model might be used; however, the issue of inference is beyond the scope of this paper and a subject for future work. 4
In our Web-engineering scenario, the context system is an independent module, which may be plugged into the Web software where deemed useful by the engineering process. Indeed, experience, most notably in the adaptive hypermedia eld, has shown that adaption, respectively context-sensitive behavior, is not useful in all situations and can in fact be counter-productive. The context system we propose is meant to integrate with a Web engineering process which includes the creation (or usage) of a domain ontology. The context system also uses this domain ontology, upon which the relevance space is based (see above). The application design process will then determine at which points context-sensitive resources are useful. The application would thus provide the context system with current parameters, and receive in return the desired context-sensitive resources.
Figure 5 provides an overview of the context system's interior workings. Parameters provided by the Web application can be of two types. The rst type are elements of the domain ontology: given that the Web application is built upon a domain ontology, it knows which elements of the ontology are currently relevant. One basis for this knowledge is ontology-based navigation, where parts of the menu navigation structure were constructed from an ontology, and the user has navigated through such a structure. This information is provided as parameters to the context system. The second type of parameters are classical Web application parameters, such as client device parameters. Such parameters are transformed into context parameters as known by the context engine (de ned here as ContextP arameters). For instance, the Web application may provide a time context in date, hours and minutes; however in the relevance space only higher-level distinctions of time, such as spring, fall etc. are used, so this parameter is transformed accordingly. The same mappings may be needed for the other types of parameters as well. The context parameters are then passed on to the ContextDynamo, which determines which resources are relevant in this context, according to the RelevanceSpace and the current context- lter setting. These resources are then returned to the Web application, which may then present them to the user. 5
The goal is to provide an environment for the development of Web software which takes into account context in a comprehensive and integrated fashion; to achieve this goal, one can distinguish two types of approaches.
Using a network approach, the network in itself would hold knowledge about which
information and which services are relevant in which context. This network approach
is explored e.g. by ([
The other approach is data-centric, meaning that context data needs to be modeled
completely at the application level, and made available to the Web application. Thus,
relevant context data is modeled in the Web application environment, and within the
Web application certain decisions will be based on this information. Cannataro et al.
([
Our approach is also data-centric, and has similarities to XAHM in that it attempts
to model context information in a general, integrated manner. A signi cant difference
in our approach is the integration within a general Web engineering activity, speci
cally with a domain ontology. Furthermore, our goal of service integration would allow
for inclusion of context relevant services and/or information on a discovery basis, thus
overcoming somewhat the limitation of the data-centric approach. We further agree with
([
From a modeling perspective, the approach of modeling terms in connection with
a relevance value bears a resemblance to Bayesian networks, in which terms can be
connected with probabilistic values. Tipping ([
We believe the development of an integrated conceptual model for context-aware Web engineering to be a promising approach: from an engineering perspective, the integration with a domain ontology can enable the systematic development of a Web application for which context factors may be used; it can support the automatic generation of the context model in a signi cant proportion; and it can lead to the creation of context catalogs pertinent for speci c business domains. It is thus reasonable to assume a meaningful degree of re-usability may be achieved not only for the domain ontologies, but also for the context models. From a usability perspective, the end-user can be presented with relevant information and menu navigation possibilities, and furthermore can interact with available, relevant services, thus providing for Web applications better tailored to the user's needs and, hopefully, raising the productivity of people working with these applications.
Future work will focus on the following issues: (1) detailed de nition and prototyping of the relevance space, (2) to what degree can the context-sensitive conceptual application model be automatically generated, and with what kind of tools? (3) which representation(s) are adequate for the context network? (4) the development of useful context catalogs, depending on application domains (e.g. business catalogs, geographical catalogs, etc.)