Chapter 2 Related Work
2.2 Other Related Research
With the requirements of rendering the learning contents deployed on web server on mobile devices, the diverse content adaptation approaches have been proposed.
The simplest way is to utilize the native content adaptation functionalities of browsers of user’s handheld device [HFTS][PWB3C]. Currently, most browsers of mobile devices can automatically resize the web pages into the suitable small ones to fit the mobile screen size and try to eliminate the horizontal scroll bar to facilitate the web navigation. Obviously, this content adaptation mobile browsers support is too simple to meet the diverse handheld devices much less the user needs.
Although pre-authoring multiple versions of a content to fit variable mobile devices is a workable approach, it is very time consuming and cumbersome for content providers. Accordingly, many dynamic content adaptation approaches including Web Structural Analysis, Information Summarization, Pre-Annotation Process, and Context-aware Decision have been proposed to solve above issues.
Lemloumal and Layaida [TNS03] proposed a framework to deliver adapted content for different target contexts based on a Universal Profiling Schema (UPS) describing the environment characteristics and a profile exchange protocol. In their system, the descriptions of the client context, the server capabilities, the document profile, etc. are pre-annotated first. Thus, a negotiation strategy is used to find a suitable content variant according to the server capabilities and the client preferences.
Then, a dynamic adaptation approach employs the XSLT [XSLT] and transcoding approach to generate an appropriate adapted content variant. Hinz et al. [HMZ04]
proposed a system, called AMACONT, which defines an XML-based user model consisting of Device, Identification, and Preference profiles based on CC/PP
(Composite Capability / Preference Profiles) and an RDF grammar. AMACONT includes Static Adaptation and Automatic Layout Adaptation processes. The former generates a number of variants for each document component and the latter can attach an XML-based layout descriptions to describe the presentation of component-based Web documents. By the similar approach, Villard et al. [VLC04] also proposed the specification of a document presentation model to adapt the content for generic document production. Their presentation process also employs the XSLT approach to perform document adaptation according to the related constraint. However, their approaches stated above perform the content adaptation relying on pre-annotating all involved contents or documents, which results in the complex preprocessing and limits the flexibility and scalability. Besides, they could not take into account the user’s preference and situation of wireless network well.
For navigation on small display devices, a Hierarchical Atomic Navigation Concept, called HANd, was proposed by Gonzalez-Castano et al. [GF+02]. In HANd, a navigator page generated automatically is used to indicate some or all elements embedded in a WWW page. Therefore, in order to generate the navigator page, a web page has to be analyzed and fragmented into several separated “clipped” versions, which can be delivered to a small display device, according to an importance value for every page fragment. Here, low importance fragments are ignored when display space is limited. Similarly, Chen et al. also proposed a browsing convention and adaptation scheme to facilitate the navigation on mobile devices. Their approach organizes a web page into a two level hierarchy, where the top level with a thumbnail representation like a navigator page in [GF+02] for providing a global view and the bottom level with index to a set of sub-pages for detail information. Then, based on the concept of web structure analysis, Yin and Lee [YL04] focuses on the important parts of web pages to propose a ranking algorithm in order to reduce the number of
page fragments and delivery latency. Although the web structural analysis approaches proposed in [GF+02] [CWZ03] [YL04] can improve the delivery latency, the quality of content shown on mobile devices are limited on fixed page fragments and the user’s preference is not considered yet.
Buyukkokten et al. [OHA01] [OOH02] utilized the concept of information summarization to summarize the parts ofWeb pages and HTML forms. In this approach, each web page is broken into several text units of which each can be hidden, partially displayed, made fully visible, or summarized. Besides, they provided five methods, Incremental, All, Keywords, Summary, and Keyword/Summary, to control the navigation behaviors. However, not all web pages are suitable to do text summarization and the summarized statements as losy information may mislead users.
Furthermore, in order to consider the user’s preference, Lum and Lau [LL03]
proposed a decision engine to automatically determine an appropriate content adaptation version based on QoS-sensitive approach. Therefore, a typical score tree with several score nodes is created to be used for evaluating the QoS of the content versions in various quality domains. Nevertheless, the predefined score tree with limited content version may not meet the users’ needs and may constrain the flexibility and extensibility of system.
Chapter 3
Adaptive Content Delivery Mechanism (ACDM)
As mentioned above, with the rapid development of network technology and mobile device, how to efficiently provide a user with a suitable content according to the user’s hardware capability of mobile device, preference, and unstable bandwidth over the wireless environment has become an important issue. Therefore, in this thesis, based on the concept of providing a user with the adaptive content created from the previous similar request, how to efficiently manage these historical user’s requests are our concern. Therefore, the following three issues have to be solved: (1) how to define the useful data format to present the user’s request, (2) how to group several user’s requests with the similar user preferences into the same group, and (3) how to decide the suitable adaptive content with high fidelity for a new user’s request. Accordingly, we propose an Adaptive Content Delivery Mechanism, called ACDM, in this chapter.
3.1 The Framework of Adaptive Content Delivery Mechanism (ACDM)
The ACDM can efficiently manage a large number of historical user’s requests, and intelligently determine to deliver an existing adaptive content with higher fidelity from LOR to the user directly and then prepare a transcoded content version for next similar request. The ACDM Architecture is shown in Figure 3.1.
Figure 3.1: The Architecture of Adaptive Content Delivery Mechanism (ACDM)
The ACDM includes two phases described as follows:
1. Adaptation Data Format Definition Phase: we define firstly the adaptation data format including User Preference (UP), Hardware Profile (HP), and Media Parameter (MP) based upon Composite Capability/Preference Profiles (CC/PP) [CCPP], User Agent Profile (UAProf) [UAPROF], and FIPA Device Ontology Specification [FIPA02]. Here, the UP describes the desired preference of a user, e.g., the desired delivery time, image format, the ratio of audio to picture, etc., the HP describes the hardware capabilities of user’s mobile device, e.g., the device type, screen size, etc, and the MP describes how to transcode the image and audio within a requested learning objects.
2. Adaptive Content Delivery Phase: for efficiently delivering the suitable content with associated learning resources to users in accordance with their user preferences, hardware capabilities, and variable wireless bandwidth, we propose the following three modules.
z Content Adaptation Management Scheme (CAMS): for efficiently managing the historical user’s requests data, we firstly apply the distance based
clustering approach to group the historical user’s requests into several groups according to the User Preference (UP). After the clustering phase, every created cluster with similar user preference will be tagged with a cluster labels.
Thus, the Hardware Profiles (HP) within the history user requests with corresponding cluster label are used as training data to create a decision tree, called Content Adaptation Decision Tree (CADT). The CADT thus can be used to efficiently decide the appropriate adaptive contents.
z Adaptation Decision Process (ADP): for intelligently determining a suitable adaptive content version based on CADT, we propose a Adaptation Decision Process Algorithm, called ADPAlgo, which can decide a suitable version of the existing adaptive content.
z Content Synthesizer: according to the results of ADPAlgo, the content synthesizer will use the decided adaptation parameters to transcode the content if necessary.
The details of each phase will be described in the following chapters.
3.2 Adaptation Data Format Definition
For efficiently manage the existing user’s requests, we have to define a data format including the User Preference (UP), Hardware Profile (HP), and Media Parameter (MP), which will be recorded in database, to represent every user’s request based upon CC/PP [CCPP], UAProf [UAPROF], and Device Ontology Specification [FIPA02]. These definitions will be described in this chapter.
As mentioned in Chapter 2, a SCORM compliant Learning Object (LO) usually
consists of several content pages with associated learning resources. Therefore, a Learning Object (LO) can be defined as follows:
Definition 1: Learning Object (LO), LO = (P, R), where z P = {p1, p2,…, pn}: denotes the related pages in an LO.
z R = {r1, r2,…, rm}: denotes the related learning resources, e.g., HTML, images, and audio.
In this thesis, we assume that one user’s request will acquire a page consisting of an HTML file, several images, and a background audio only, which can be shown by browser at the same time. Consequently, a pj∈P can be represented as pj = (HTML, r1, r2,…,rk), where j≦n, k≦m. Thus, the LOij can denote the jth page (Pj) of the ith LO (LOi) in a SCORM compliant learning object repository (LOR).
Then, Table 3.1 shows the attributes with associated value in Hardware Profile (HP). We define the general value of every attribute to describe the diverse mobile device. In addition, the Symbol ＊ in Table 3.1 denotes this attribute’s value can not be automatic detected by UAProf and HTTP request header during the content delivery. Thus, the HP is defined in Definition 2.
Table 3.1: The Hardware Profile (HP) of Mobile Device Attribute Description and Related Value
Machine Type (MT) 0: Cell Phone, 1: Cell Phone/PDA, 2: Palm, 3: Pocket PC, 4:
Laptop
＊CPU Speed (CPU) The value within the range from 66 to 500.
＊System Memory (SM) The value within the range from 8 to 1024.
Screen Horizontal Size (SHS)
The value within the range from 40 to 800.
Screen Vertical Size (SVS) The value within the range from 40 to 800.
Color Depth (CD) 2: 2 bits, 4: 4 bits, 8: 8 bits, 16: 16 bits Sound Precision (SP) U: Unsupported, 8: 8 bits, 16: 16 bits
Sound Rate (SR) U: Unsupported, 4: 4 KHz, 8: 8 KHz, 11: 11 KHz, 22: 22 KHz, 44: 44KHz
Sound Channels (SC) U: Unsupported, M: Mono, S: Stereo
Networking (Net) Ir: IrDA, WL: Wireless LAN, GSM: GSM, GPRS: GPRS, BT: Bluetooth
Definition 2: Hardware Profile (HP) is as a vector with related hardware attributes.
z HP = <MT, CPU, SM, SHS, SVS, CD, SP, SR, SC, Net>, where every attribute denotes a specific capability of mobile device. For example, the MT denotes that the Machine Type of device is cell phone without or with PDA function (Cell Phone/PDA), or palm.
Furthermore, in order to deliver the suitable content to meet the user’s needs over wireless environment, we take not only the associated resources in a page of an LO, but also the delivery time depending on the bandwidth into account to represent the User Preference (UP). Table 3.2 describes the UP’s attributes and associated values.
Here, the Delivery Time (DT) and Ratio attributes have the maximum value which will be used to estimate the similarity between two UPs in Adaptive Content Delivery Phase, described in Chapter 4. Regarding the quality of associated pictures and audios in a page, users can use these attributes, PPO, PFO, and APO, to define the preferred priority of quality factors. For example, the string JPGB denotes that the user prefer the JPG picture format to the PNG.
Moreover, in general, the pictures embedded in a page can be divided into 2 categories: Foreground and Background pictures. In ACDM, for offering user to flexibly control the appearance of images, we define two additional image types, Icon, and Bar, which can be identified automatically according to their ratio of width to height from the Foreground pictures. User can thus use the switch attributes of UP to control whether showing it or not. In order to facilitate the UP setting process for users, the supported image and audio formats can also be automatically indicated from the information in UAProf [UAPROF] and Agent Header [RFC2616-14]. In other words, the setting of image and audio will be automatic disabled, if it can not be supported by user’s handheld device.
Table 3.2: The Description of User Preference (UP) Attributes Attribute Description and Related Value
Delivery Time (DT) The maximum delivery time which the user may tolerate.
The default maximum value is 30 seconds.
Ratio The expected ratio of audio to picture.
The default maximum ratio is 1:20.
Picture Property Ordering (PPO)
The order of three properties (D: Dimension, C: Color Depth, Q:
Quality).
For example, the string DCQ denotes that the priority order is D
> C > Q.
Picture Format Ordering (PFO)
The order of four formats (J: JPG, P: PNG, G: GIF, B: BMP).
For example, the string JPGB denotes that the priority order is J>P>G>B.
Audio Property Ordering (APO)
The order of three properties (S: Samples Rates, B: Bits, C:
Channels).
For example, the string SBC denotes that the priority order is S>B>C.
Foreground Picture Switch (FPS)
Show the foreground picture except Icon and Bar or not (0: false, 1: true).
Background Picture
Switch (BPS) Show the background picture or not (0: false, 1: true).
Icon Switch (IS) Show the icon picture or not (0: false, 1: true).
Bar Switch (BS) Show the picture of separation line or not (0: false, 1: true).
Audio Switch (AS) Play the background audio or not (0: false, 1: true).
Accordingly, UP can be defined as follows:
Definition 3: User Preference (UP) is as a vector.
z UP = < DT, Ratio, PPO, PFO, APO, FPS, BPS, IS, BS, AS>, where every attribute denotes a specific requirement of a user.
Therefore, based upon the LO, HP, and UP, a new User Request (UR) can be defined as UR = (LO, (B, HP, UP)). In addition, in ACDM, the media transcoding process will be triggered if there is no suitable adaptive content for a new UR. The transcoding process will employ the transcoding tools [IMAGICK][SOX] to transform the media format into different type and file size depending on given transcoding parameters, e.g., the value of picture properties (D: Dimension, C: Color Depth, Q: Quality) or audio properties (S: Samples Rates, B: Bits, C: Channels).
Therefore, for a new user’s request, every media resource will be associated with a Media Parameter (MP) including media type (T), resultant transcoded size (S), and transcoding parameters (TP). Consequently, the MP can be defined as: Media Parameter (MP) is as a vector, MP = <T, S, TP>.
Thus, based upon the LO, HP, UP, and MP definitions, we can define a Content Adaptation Rule, called CAR, to represent a processed user request transaction in our Adaptive Content Delivery Mechanism (ACDM).
Definition 4: Content Adaptation Rule (CAR), CAR = (LO, (B, HP, UP), MPset), where
z B: denotes the Bandwidth at the request time.
z MPset = {MP1, MP2,.., MPk}: denotes all associated MPs used to transcode all
physical media resources in a page.
For example, given a user request transaction, CAR 1 = ((LOi, Pj), (B, HP, UP), MPset) = (80, <3, 400, 128, 480, 640, 16, 16, 44, S, WL>, <5, 7, CQD, JGBP, CSB, 0, 1, 0, 0, 0>, MPset), which denotes that a user uses a Pocket PC (3) with 400 Mhz, 128 MB, 480×640 resolution, 16 color depth under 80 kbps bandwidth (B) to retrieve the page (pj) of LOi, then the ACDM uses the MPs in MPset, which are selected according to the B, HP, and UP, to transcode the physical resources in the Pj. Table 3.3 shows 14 CARs for the LOij.
Table 3.3: An Example of CAR for the same page (pj) in a Learning Object (LOi) ID Bandwidth
(B)
Hardware Profile (HP) User Preference (UP)
1 80 <3,400,128,480,640,16,16,44,S,WL> <5,7,CQD,JGBP,CSB,0,1,0,0,0>
2 120 <4,500,384,800,400,16,16,44,S,WL> <5,9,CDQ,GPBJ,SBC,0,0,0,0,0>
3 525 <4,133,96,360,400,16,16,4,S,WL> <10,10,DQC,BGPJ,SBC,0,0,0,0,0>
4 200 <4,133,768,360,400,4,U,U,S,WL> <20,10,DQC,BGPJ,SBC,1,1,1,0,0 5 150 <3,400,160,640,400,4,U,U,S,WL> <12,15,CQD,GPBJ,SBC,1,0,0,0,0>
6 180 <4,500,160,800,400,16,U,U,S,WL> <7,10,QDC,JBGP,BSC,1,1,0,0,1>
7 80 <3,400,128,480,640,16,16,44,S,WL> <5,7,CQD,JGBP,CSB,SBC,1,0,0,0>
8 100 <0,500,160,400,800,16,U,U,S,WL> <7,10,QDC,JBGP,BSC,1,1,0,0,1>
9 152 <1,100,160,400,800,16,16,8,S,WL> <7,10,QDC,JBGP,BSC,1,1,0,0,1>
10 90 <1,100,160,400,800,16, 16,8,S,WL> <14,5,DQC,JBGP,BSC,0,0,0,0,1>
11 75 <1,400,128,480,640,16, 16,44,S,WL>
<5,7,CQD,JGBP,CSB,0,1,0,0,0>
12 50 <1,400,128,480,640,16, 16,44,S,WL>
<5,7,CQD,JGBP,CSB,0,1,0,0,0>
13 70 <1,133,128,480,640,8, 16,44,S,WL> <5,7,CQD,JGBP,CSB,0,1,0,0,0>
14 72 <3,133,128,480,640,8, 16,44,S,WL> <5,7,CQD,JGBP,CSB,0,1,0,0,0>
Chapter 4
Content Adaptation Management Scheme (CAMS)
In this chapter, we will describe how to use the existing CARs to construct a Content Adaptation Decision Tree, called CADT, in CAMS. The CADT can be used to efficiently maintain, search, and retrieve the suitable adaptive content in LOR for users according to the user preference and then network bandwidth. As shown in Figure 4.1, The CAMS includes 3 processes to construct the CADT: 1) Clustering Process, 2) Decision Tree Construction, and 3) CADT Maintaining Process, described in the following sections.
Figure 4.1: The Process of Content Adaptation Management Scheme (CAMS)
4.1 The Clustering Process of CAMS
As mentioned in Chapter 3, every user request with her/his preference like a transaction can be represented by a Content Adaptation Rule (CAR). As shown in Figure 4.1, in CAMS, all new CARs users requested are stored in a CARs Pool.
Therefore, we can apply distance based clustering algorithm to group these historical CARs into several clusters according to the user preferences (UP) of users, where every user in the same cluster has the similar user preference. However, it is difficult to determine the number of clusters for applying clustering approach. A clustering algorithm, called ISODATA [Hall&Ball], can dynamically change the number of clusters by lumping and splitting procedures and iteratively change the number of clusters for better result. Therefore, in this thesis, we apply the ISODATA clustering approach to group CARs into different clusters.
4.1.1 The Similarity Measure of Clustering Process
In order to apply the ISODATA clustering ٛpproach, we propose a similarity measure to efficiently estimate the similarity value between two CARs based on the UP. Because the attribute of a UP consists of numerical attribute and symbolic attribute, the similarity measure of UP can be formulized as follows:
Given two UPi=<a1, a2,…, an> and UPj=<b1, b2,…, bn>, the similarity measure of numerical attribute can be formulized as follows:
SimofNumk =
, where 1≦k≦n, the Max and the Min are the predefined maximum and minimum values of kth attribute in a UP, respectively, described in the Definition 3.
Regarding the symbolic attribute in UP, such as the Picture Property Ordering (PPO), it has the value, CSB, which is like a string. Therefore, in order to compute the similarity between two symbolic attributes, their string based values can thus be divided into several pairs. For example, the string CSB can be divided into 3 pairs:
{CS, CB, SB}. Accordingly, the number of the same pairs in two strings can be used to estimate the similarity. Thus, the similarity measure of two symbolic attributes can
be formulized as follows:
, where 1≦k≦n, the , the Binominal Coefficient, denotes the maximum number of pairs and the function TheSamePairs() indicates the same pair between two strings.
n2
C
In addition, because different attributes in a UP may have different important degrees, we define a Weight Vector (WV) to adjust the important degree of every attribute in UP. Therefore, the Similarity Measure between two Ups can be formulated as follows: attribute Weight Vector WV = <0.35, 0.15, 0.05, 0.05, 0.05, 0.1, 0.05, 0.05, 0.05, 0.1>.
We can thus apply the above similarity measure to compute the similarity between UP1 and UP2. For example, the similarity of the numerical attribute, Delivery Time (DT), between UP1 and UP2 is SimofNum1=
Moreover, the similarity of the symbolic attribute, Picture Format Ordering (PFO), is
SimofSym4= 4
0.83. Therefore, by the same way, the similarity between UP1 and UP2 is the SimilarityUP(UP1, UP2) = 0.83×0.35 + 0.9×0.15 + 0×0.05 + 0.83×0.05 + 0.66×0.05 + 1×0.1 + 1×0.05 + 0×0.05 + 1×0.05 + 1×0.1 = 0.8.
4.1.2 The Clustering Algorithm based on ISODATA
In this thesis, the Delivery Time (DT) is the most important attribute in UP, so we use the DT value to estimate the centers of initial clusters of ISODATA.
Accordingly, a UP Clustering Algorithm (UPCALgo) based on ISODATA is proposed to group these Ups into several clusters according to the Similarity Measure, shown in Algorithm 4.1. The Table 4.1 shows that after applying the UPCALgo, these CARs in Table 3.3 can be grouped into 4 clusters.
Algorithm 4.1: UP Clustering Algorithm (UPCALgo) Symbols Definition:
DT: the Delivery Time (DT) in a user preference vectors (UP).
Upset: the set of UP.
K: the initial number of clusters.
T: the initial similarity threshold for selecting initial clusters.
C: a cluster with several user preference vectors (UP).
CC: the Center of Cluster.
Cset: the set of clusters I with the Center of Cluster (CC)
Cset: the set of clusters I with the Center of Cluster (CC)