Ref: F088
Words: 4221
NOTE: This is a sample taken from an Encyclopedia, and is shorter that full chapter size (8,000-10,000) words.
Adaptive Web Portals: Models and Technologies
Lorenzo Gallucci
Exeura S.r.L., Italy
Mario Cannataro
Università “Magna Græcia” di Catanzaro, Italy
Pierangelo Veltri
Università “Magna Græcia” di Catanzaro, Italy
Adaptive Web Portals: Models and Technologies
Lorenzo Gallucci
Exeura S.r.L., Italy
Mario Cannataro
Università “Magna Græcia” di Catanzaro, Italy
Pierangelo Veltri
Università “Magna Græcia” di Catanzaro, Italy
Introduction
In modern Web-based Information Systems (WIS), the personalization of presentations and contents is becoming a major requirement. Personalization means both adaptation to user’s requirements and goals, as well as adaptation to user’s technology and environment (Levene, Poulovassilis, 2004). Application fields where content personalization can be useful are manifold, they comprise e-government, on-line advertising, direct web-marketing, electronic commerce, on-line learning and teaching, etc. The need for adaptation arises from different aspects of the interaction between users and web/hypermedia systems. User classes to be dealt with are increasingly heterogeneous due to different interests and goals, large-scale deployment of information and services, and so on. Furthermore, WIS should be made accessible from different user’s terminals, which can differ not only at the software level (browsing and elaboration capabilities) but also in terms of ergonomic interfaces (scroll buttons, voice commands, etc.). Finally, different kinds of network (e.g. wired or wireless) and other network-related conditions (e.g. bandwidth, latency, error rate, etc), should be considered to obtain a comfortable and useful interaction.
To face some of these problems, in the last years the concepts of adaptive systems and hypermedia have converged together into the Adaptive Hypermedia (AH) research theme. An Adaptive Hypermedia System (AHS) is defined as “an hypertext and hypermedia system which reflects some features of the user in a user model and applies this model to adapt various visible aspects of the system to the user” (Brusilovsky, 2001). The AH approach is more and more used to support adaptivity and content personalization in modern WIS. An Adaptive Web Portal (AWP) is defined as an AHS which adapts and delivers the contents of an information systems through the Web, i.e. by using the transport and application protocols of the World Wide Web.
Adaptive Web portals can be used in many application domains where users can be classified in different groups and they usually access the system through different devices. For instance, in e-government web portals, users like administrators, managers or citizens have different informative requirements and goals, and they can access the system by using different devices and networks (Acati et al., 2005). Similarly happens in e-health, where doctors, health personnel and patients have to see different portions of electronic patient records.
The chapter introduces general aspects of Adaptive Hypermedia Systems and Adaptive Web Portals, and presents a middleware software that can be used to implement Adaptive Web Portals. Main characteristics of the proposed system are the continuous detection of network and user’s terminal features and the dynamic adaptation of the contents of an information system with respect to such quantities. Foundation model, architecture, and system prototype are presented.
Background
The basic components of AHSs are the Application Domain Model (DM), the User Model (UM) and the Adaptation Model (AM) (Brusilovsky, 2001, Cannataro, Pugliese, 2004).
The Application Domain Model is used to describe the hypermedia contents. In addition to well known data models, the modelling of AH must consider the different sources that affect the adaptation process and must allow for an effective observation of users' actions, with respect to each particular application domain, in order to gather significant data for user modelling.
The User Model (also said profile) attempts to describe the user’s characteristics and preferences and his/her expectations in the browsing of hypermedia; user models are generally distinguished into overlay models, which describe a set of user’s characteristics (typically represented by a set of name-value pairs), and stereotype models which indicate the user’s belonging to a group.
The Adaptation Model is related to content selection, i.e. a selection of parts of hypermedia to be presented to the user, content adaptation, i.e. a manipulation of information fragments, and link adaptation, i.e. a manipulation of the links presented to the user.
Whenever a user interacts with an AHS, the system builds a User Model on the basis of user’s interaction. When the user requests a new page, the Adaptation Model applies the adaptation rules to the portions of the page defined through the Domain Model. Finally, the adapted page is delivered to the user. In these last years many AHSs have been developed, Cannataro and Pugliese (2001) survey architectures and models used to build adaptive systems.
The XML Adaptive Hypermedia Model (XAHM) is specifically concerned with a complete and flexible data-centric support of adaptation (Cannataro, Cuzzocrea, Pugliese, 2002). It is focused on: (i) the description of structure and contents of an adaptive hypermedia in such a way that it is possible to easily point out the components on which to perform adaptation; (ii) a characterization of the hyperlinks useful to single out users' preferences and goals in a non-invasive way; (iii) a simple representation of the logic of the adaptation process, distinguishing between adaptation driven by technological constraints and adaptation driven by users' needs.
In XAHM the application domain is modelled along three abstract orthogonal adaptivity dimensions.
User's behaviour comprises data about browsing activity and preferences of the user; such data are used to build the User Model as a stereotype profile;
External environment comprises data about the environment where the user is, such as time-spatial location, language, socio-political issues, status of external Web sites;
Technology comprises data describing the network and device technology used by the user, such as kind of network, bandwidth, characteristics of user's terminal.
Such adaptivity dimensions define the Adaptation Space, i.e. the set of all information fragments of the application domain, such as pages, images, etc., that can be adapted with respect to the adaptivity dimensions. The position of the user in the adaptation space is denoted by a tuple of the form [B, E, T]. Each of the values B, E and T varies over a finite alphabet of symbols. The B value, related to the User’s Behavior dimension, captures the group the user belongs to; the E and T values respectively identify environment location and used technologies. As an example, B could vary over {novice, expert}, E over {english-place, italian-place} and T over {HTML-low, HTML-high, WML}. A personalized view over the Application Domain corresponds to each point of the adaptation space, e.g. when the user reaches the point [expert, english-place, HTML-high], the adaptive system should deliver to the user the selected portion of the domain model, such as a page, adapted to those values of B, E, T.
Recently, there has been an effort in the World Wide Web (W3C) community to define a standard for the modelling of the contents of an AHS. In particular, the Device Independence group (W3C Device Independence Working Group) defined the Content Selection for Device Independence (DISelect) W3C Working Draft that specifies a syntax and a processing model for general purpose content transformation (filtering as well as manipulation) on an XML (eXtensible Markup Language) document (Lewis, Merrick, 2005).
Usually, the condition part of a DISelect construct is evaluated with respect to device and network conditions, as well as to other author-defined variables (e.g. user’s profile). The Composite Capabilities/Preferences Profile (CC/PP) is a W3C Recommendation that allows to express user device capabilities and user preferences, according to a shared structure and vocabulary of terms stored in RDF (Resource Description Framework) format, that can be used to guide the adaptation of content presented to that device (W3C CC/PP, 1999). Figure 1 shows a fragment of content selection DISelect code that produces a non empty result when screen width, i.e. a CC/PP value, is greater than 800 pixels.
Figure 1. An Example of DISelect Code Showing a Content Selection Construct
DISelect and CC/PP are the basic building blocks to develop novel and standard-aware adaptive web portals: DISelect can be used to realize the adaptation rules, whereas CC/PP can be used as reference framework to manage data and metadata needed to realize adaptation.
DISAS: a library for developing adaptive web PORTALS
The main requirement for building an adaptive web portal is to support adequately the evolution of an existing web application towards an adaptive one, through introduction of a small amount of modules and progressive insertion of adaptation constructs into pages conceived as non-adaptive ones. Thus, we worked on three objectives while designing the system:
allowing for an automatic user profile detection software which could be easily integrated in a web system;
providing a component, able to work “behind the scenes”, whose role is to mix content adaptation subparts into an adapted hypermedia;
allowing a developer to write content adaptation rules in dynamic web pages (e.g. Java Server Pages), without worrying about details on information source for user profile data used in rules, as well as on adaptation core.
Following these requirements, a working prototype of an adaptive web portal library called DISAS (“DISelect Adaptive System”) has been fully implemented. The system, built upon a set of standard Sun™ Java2 Enterprise Edition components, is based on the XAHM model and follows the W3C Device Independence Working Group recommendations (W3C Device Independence, 2003).
DISAS sits between a Web-based Information System and a standard web browser (i.e. the user), and is able to:
1. automatically and dynamically detect characteristics of the user’s terminal (e.g. browser and computer capabilities) and user’s context (e.g. geographic location, available network bandwidth, etc.), in a CC/PP compliant way[1]; additional user preferences can be statically defined;
2. deliver the contents of the Information System, expressed as XML documents containing DISelect code, to the user device, by applying a filtering engine that processes DISelect code and adapts contents with respect to user devices capabilities and user profile.
The architecture of DISAS is depicted in Figure 2 and comprises two main components: the Profile Manager and the DISelect Engine, this one implemented by using two complementary approaches. The Profile Manager supports user profile testing, reading and storing, and collects such user data in a user’s session store named Profile Store. Such profile management core can be seamlessly integrated in most J2EE applications. In particular, it:
detects, collects and stores a sketch of measured user profile parameters, such as user agent capabilities, network speed, etc., employing a corresponding Profile Manager agent running on the client side;
makes available to the DISelect Engine values taken from the user profile, reading from the Profile Store.
Content adaptation and delivery is implemented by the DISelect Engine through two approaches:
the DISelect Engine can transparently adapt hypermedia coded in a well-formed XML embedding DISelect adaptation rules (DISelect tags), by means of a DISelect adaptation J2EE filter (DISelect Filter) which is capable to apply the full DISelect model. This is feasible on Information Systems whose content is available as well-formed XML either dynamic (and nothing prevents or discourages computation of every piece of information) or static;
the DISelect Engine can exploit a significant subset of DISelect language for non-XML coded hypermedia (such as HTML 4.0 code, JavaScript or Cascading Style Sheets), by means of a JSP (Java Server Pages) DISelect Tag Library. The library allows DISelect constructs calls to be merged into active pages (e.g. Java Server Pages - JSP); this allows adapting not only usual content, but also JSP code flow (possibly skipping some computations based on user profile values).
Figure 2. DISAS Architecture
User Profile Detection and Content Delivery Strategies in DISAS
To accomplish adaptation of content, a dedicated agent has to combine adaptable hypermedia (i.e. XML documents with embedded DISelect rules coming from an Information System or a web application), with user and terminal information. Adaptation of content is triggered by some events, such as first page load, user profile variations or forced redisplay.
Two operations modes are possible: responsibility of adaptation is either entirely left to the User Agent (an “adaptation-aware” web browser, which is not currently available), or performed by the server.
In the first scenario, the user profile itself is detected and monitored only on the client side, not sharing it with the web server. This operating mode implies that the code to perform adaptation is either provided by the user agent, or mixed into the HTML page by the web application. An appropriate code must be available for each browser, as a plug-in or built-in. This could lead to better performances and shorter response times than in the latter case, where a platform-independent code, executable from HTML pages, is needed and, thus, a client-side scripting language as the not-so-fast Javascript has to be used.
So, the former solution for client-side processing is not viable in the mid term, due the heavy load imposed on the browser, while the latter requires both libraries for performing efficiently XML transformations inherent to DISelect constructs, and a fast client-side scripting (e.g. JavaScript) runtime, which is not always the case, especially for handheld devices.
In DISAS we chose a rather different approach, following the second scenario (server-side adaptation):
the page gets adapted before the server sends it to the client, thus content transformations can be carried out one time only (at first page load event, in the list above), but on server side;
as usual, client side (web browser) detects user profile parameters (via small, platform-independent Javascript code), but only the server stores related information;
at each time, only most recent parameters are available, instead of current parameters, which would be the case in a “pure client DISelect” approach. At any time, a snapshot of latest measured parameters is available; this is updated at discrete times, when, in response to a page load request, DISAS considers profile information as unreliable (e.g. too old or incomplete).
The profile detection logic is based on light JavaScript code sent from the server to the client, which aims at being as much unobtrusive as possible, to avoid breaking user’s experience.