Accès et adaptation de contenus multimédia pour les

Transcription

Accès et adaptation de contenus multimédia pour les
No d’ordre 06 ISAL 0056
Année 2006
Thèse
Accès et adaptation de contenus multimédia pour les systèmes pervasifs
Présentée devant
L’Institut National des Sciences Appliquées de Lyon
Pour obtenir
Le grade de docteur
Ecole Doctorale: Informatique et Information pour la Société (EDIIS)
Spécialité: Documents Multimédia, Images et Systèmes D’Information
Communicants (DISIC)
Par
GIRMA BERHE HAGOS
Soutenue le 25 Septembre 2006 devant la Commission d’examen
Composition du jury
Président:
Günter Haring, Professor, University of Vienna, Austria
Rapporteur:
Harald Kosch, Professeur, Université de Passau, Allemagne
Hervé Martin, Professeur, LSR, Université Joseph Fourier
Examinateur:
Günter Haring, Professeur, Université de Vienne, Autriche
Ahmed Mostefaoui, Maître de conférences, (LIFC) UFR-STGI, Montbéliard
Directeur de thèse:
Lionel Brunie, Professeur, INSA de Lyon
Co-directeur de thèse: Jean-Marc, Pierson, Professeur, IRIT, Toulouse
Ordering number 06 ISAL 0056
Year 2006
Thesis
Access and adaptation of multimedia content for pervasive systems
Submitted to
National Institute of Applied Sciences of Lyon
In fulfilment of the requirements for
Doctoral Degree
Doctoral school of Computer Science and Informatics for Society (EDIIS)
Specialized in Multimedia Documents, Images and Communication Information Systems
Prepared by
GIRMA BERHE HAGOS
Defended on 25 September 2006 in front of the Examination Committee
Committee Members
President:
Reviewer:
Examiner:
Supervisor:
Co-supervisor:
Günter Haring, Professor, University of Vienna, Austria
Harald Kosch, Professor, University of Passau, Germany
Hervé Martin, Professor, LSR, University Joseph Fourier
Günter Haring, Professor, University of Vienna, Austria
Ahmed Mostefaoui, Associate Professor, (LIFC) UFR-STGI, Montbéliard
Lionel Brunie, Professor, INSA de Lyon
Jean-Marc, Pierson, Professor, IRIT, Toulouse
In memory of my father
Acknowledgements
Many people assisted in the preparation of this thesis both directly and indirectly. I would like
to thank all of them for their contribution and support.
First and foremost, I would like to forward my gratitude to my first advisor Prof. Lionel
Brunie for accepting me as one of his PhD students. His valuable guidance and support was
very important for the progress of my study. I always had very interesting and important
discussions with him which contributed a lot for my research. His help was not limited to
academic works, his friendly and lovely characteristics made me to spend very memorable
events with him and his family. In this regard I do not want to pass without mentioning the
hospitality I have got from his wife Benedicit and their children. I would like to thank them.
My thanks also go to my second advisor Prof. Jean-Marc Pierson. He provided me with a lot
of ideas and concepts to realize my research. He was always there to help me advance my
study and provided me valuable ideas to bring up the important issues in my research and
finally enable me to publish many articles. I would also like to thank his family for the
hospitality they provided me during my stay in France.
Thanks should be given to French Embassy in Ethiopia, Addis Ababa and Dr. Dawit Bekele
for establishing a very good contact and cooperation between the Department of Computer
Science in AAU and INSA de Lyon that made possible for Ethiopian Students including me
to pursuit our PhD with the financial support of the Embassy. I would like to thank the
Embassy for the support and request for their cooperation in the future.
I would like to thank Prof. Harald Kosch and Prof. Hervé Martin for reviewing my work and
being member of the examination committee. I would also like to extend my thanks to Prof.
Günter Haring and Dr. Ahmed Mostefaoui who are also members of the examination
committee.
I wish to thank all my colleagues and staffs in the LIRIS/INSA with whom I have had very
good scientific discussions and have spent very memorable times: Solomon Atnafu, Dejene
Ejigu, Marian Scuturici, Faiza Najjar, Tarak Chaari, Ludwig Seitz, David Coquil, Yonny
Cardenas, Ny-Haingo Andrianarisoa, Rachid Saadi, Julien Gossa, Yassir Fawaz, Addisalem
Negash, Talar Atechian, Kader Keita, Rami Rifaieh. I would like to thank undergraduate
computer science students Yann Gripay and Christope Litzinger for their participation in the
development of the prototype to validate my research. I would also like to thank Frederique
ex-secretary of Ecole Doctoral, Mabrouka secretary of Ecole Doctoral and Mme. Ripon
secretary of LIRIS/INSA.
I would like to thank all my family and friends in Europe, America and Ethiopia for their
indispensable encouragement they provided me to work hard on my research. Lastly but not
least, my thanks go to all the Ethiopian family leaving in France for their enjoyable time they
have given me.
Remerciements
De nombreuses personnes m'ont assisté pour la préparation de cette thèse, à la fois
directement et indirectement. Je voudrais les remercier tous pour leurs contributions et leur
soutien.
Tout d'abord, je voudrais tout particulièrement transmettre ma gratitude à mon directeur de
thèse Pr. Lionel Brunie pour m'avoir accepté comme doctorant. Ses conseils précieux et son
soutien ont été très importants pour la progression de ma thèse. J'ai toujours eu avec lui des
discussions importantes et très intéressantes qui ont beaucoup contribué à mon travail de
recherche. Son aide ne s'est pas limitée au travail académique, son amitié et sa gentillesse
m'ont fait passer des moments vraiment inoubliables avec lui et sa famille. A cet égard, je
tiens à mentionner l'hospitalité que j'ai reçue de la part de sa femme Bénédicte et de leurs
enfants. Je souhaite les remercier tous.
Mes remerciements s'adressent également à mon deuxième directeur de thèse Prof. Jean-Marc
Pierson. Il m'a apporté beaucoup d'idées et de concepts pour la réalisation de mes recherches.
Il a toujours été présent pour m'aider à avancer dans mon travail et m'a apporté de précieuses
idées pour aborder les points importants de mes recherches, et m'a finalement permis de
publier de nombreux articles. Je voudrais également remercier sa famille pour leur hospitalité
à mon égard durant mon séjour en France.
Je tiens à remercier l'Ambassade de France en Éthopie, à Addis Ababa, ainsi que le Dr. Dawit
Bekele pour avoir établi de très bons contact et une très bonne coopération entre le
Département d'Informatique de l'Université d’Addis Ababa et l'INSA de Lyon, qui ont rendu
possible pour des Étudiants Éthiopiens, dont je fais partie, de poursuivre notre thèse avec le
soutien financier de l'Ambassade. Je voudrais remercier l'Ambassade pour leur soutien et
souhaiterais poursuivre cette collaboration pour l'avenir.
Je voudrais remercier Pr. Harald Kosch and Pr. Hervé Martin pour avoir évalué mon travail et
pour être membres du jury de thèse. Je voudrais également élargir mes remerciements au Pr.
Günter Haring et au Dr. Ahmed Mostefaoui qui sont également membres du jury de thèse.
Je souhaite remercier tous mes collègues et autres membres du LIRIS à l'INSA de Lyon avec
qui j'ai eu des discussions scientifiques de très bon niveau et ai passé des moments très
agréables : Solomon Atnafu, Dejene Ejigu, Marian Scuturici, Faiza Najjar, Tarak Chaari,
Ludwig Seitz, David Coquil, Yonny Cardenas, Ny-Haingo Andrianarisoa, Rachid Saadi,
Julien Gossa, Yassir Fawaz, Addisalem Negash, Talar Atechian, Kader Keita, Rami Rifaieh.
Je voudrais remercier les étudiants en Informatique Yann Gripay et Christophe Litzinger pour
leur participation au développement du prototype afin de valider mes recherches. Je voudrais
également remercier Frederique, ancienne secrétaire de l'École Doctorale, Mabrouka,
secrétaire de l'École Doctorale, et Mme Ripon, secrétaire du LIRIS à l'INSA de Lyon.
Je voudrais remercier toute ma famille et mes amis en Europe, en Amérique et en Éthiopie
pour leurs encouragements indispensables qu'ils m'ont donnés pour que je puisse travailler dur
sur mes recherches. Enfin, mes remerciements s'adressent à toutes les familles éthiopiennes
vivant en France pour les bons moments que nous avons passés ensemble.
Résumé
L’information numérique et les réseaux informatiques occupent aujourd'hui une place centrale dans
l’ensemble des composants de la vie professionnelle et, même, personnelle. Le très rapide
développement de l'informatique mobile (téléphones mobiles, assistants personnels, ordinateurs
portables…) permet aujourd'hui d'envisager la mise en œuvre de systèmes d'information ubiquitaires :
quelle que soit sa localisation, l'utilisateur dispose, à tout moment, d'un accès au réseau mondial (accès
“anywhere - anytime”). L'enjeu des systèmes pervasifs (ou ubiquitaires) est, dans cette perspective, de
fournir les cadres méthodologiques et les mécanismes protocolaires à même de permettre une
utilisation fiable, pertinente et efficace de ces systèmes.
La gestion des données en représente clairement l’une des composantes-clefs, recouvrant de nombreux
aspects: extensibilité du système, accès et intégration des données (en termes d’indexation et
d’exécution de requêtes dans un environnement distribué fortement hétérogène), optimisation de
l’utilisation des ressources et de la qualité de service (bande passante réduite, discontinuité du service),
cohérence de l’information (l’utilisateur pouvant se trouver en mode déconnecté, comment assurer la
cohérence et la pérennité des données qu'il manipule ?). Enfin, l'adaptation de contenus multimédias
constitue certainement l'un des mécanismes centraux dans la mise en œuvre effective des systèmes
d'information pervasifs. La très grande hétérogénéité des moyens de connexion et des conditions de
communication (bande passante notamment), la très grande variabilité des préférences utilisateur
imposent en effet de fournir des outils d'adaptation des contenus transmis aux utilisateurs. Dans ce
contexte, beaucoup de travaux de recherche ont été effectués que l’on peut classer en trois approches
principales selon le site d’exécution des mécanismes d'adaptation.
Dans une première approche, dite approche “orientée client”, le dispositif du client est responsable
d'adapter le contenu selon les caractéristiques du dispositif, les préférences de l'utilisateur et le
contexte opérationnel (e.g. bande puissante disponible). Néanmoins, en raison de la capacité des
performances limitées des dispositifs client, cette approche est difficile à mettre en place et souvent
impraticable.
Dans l’approche “orientée serveur”, le serveur de contenus fournit lui-même des fonctionnalités
d'adaptation. Cette approche a comme conséquence une consommation accrue des ressources du
serveur, ralentissant de facto le traitement des requêtes.
Enfin, alternative aux approches précédentes, l’approche “orientée proxy” place un proxy entre le
client et le serveur de contenus. Ce proxy est alors responsable de l'adaptation des contenus avant
qu'ils soient fournis à l'utilisateur. Même si cette approche résout à un certain degré les problèmes
II
rencontrés avec les approches orientées serveur et client, elle présente des limitations en termes
d’extensibilité en raison du coût élevé des opérations d’adaptation. En outre, les techniques
d'adaptation évoluent et l’intégration de ces nouvelles techniques au proxy peut s’avérer difficile,
celui-ci n’étant pas extensible.
Dans cette thèse, nous présentons une architecture logicielle d'adaptation de contenus multimédia
(nommée DCAF: Distributed Content Adaptation Framework). Cette architecture est fondée sur
l’utilisation de services d'adaptation accessibles sur l'Internet. A l’inverse des approches précédentes
où le client, le serveur de contenu ou un proxy est responsable du processus d'adaptation, ce sont ici
des services développés extérieurement qui effectuent la transformation des contenus. DCAF fournit
ainsi une solution générique d'adaptation de contenus offrant flexibilité, extensibilité et
interopérabilité.
La principale problématique introduite est la détermination du scénario optimal d’adaptation
(également appelé chemin optimal d'adaptation), plusieurs services d'adaptation pouvant fournir les
mêmes fonctionnalités. Cette thèse propose d’adopter une technique issue de l’intelligence artificielle
pour optimiser la planification, la composition et l’exécution des services impliqués dans l’adaptation
d’un contenu. L’algorithme proposé prend en compte le profil des utilisateurs, les caractéristiques des
dispositifs, la connectivité du réseau, le format des contenus échangés et les spécifications (coût,
qualité) des services d'adaptation disponibles pour construire un graphe d'adaptation modélisant le
scénario d’adaptation choisi.
Parallèlement, nous avons développé une ontologie dédiée à la description des services d'adaptation.
Cette ontologie permet de décrire la sémantique des services d’adaptation enfin de faciliter la
découverte et la composition des services. Elle permet également de passer facilement de la
description d’un service à la représentation de l’opérateur d’adaptation.
Pour démontrer la faisabilité de l’architecture DCAF, un prototype a été développé et évalué. Les
expériences conduites montrent que le temps de construction du graphe d'adaptation et la durée
moyenne d'adaptation sont compatibles avec les contraints des environnements pervasifs.
Mots-clés : Systèmes Pervasifs, Adaptation de Contenu Multimédia, Composition de Services,
Planification, Contexte.
Abstract
Nowadays, computing technologies are part of our daily life. The advancement of mobile computing
(mobile telephone, PDA, Portable) enables users to access data wherever and whenever they want
them: at work, at home, in a meeting, or even when travelling. In this perspective, pervasive
(ubiquitous) systems provide the necessary tools and protocols to allow reliable, appropriate and
effective content access by heterogeneous users and devices using different network connections.
In pervasive systems, the management of data represents one of the key components covering many
aspects: extensibility of the system, data access and integration (in terms of indexing and query
execution in heterogonous distributed environment), optimization of the use of the resources and
quality of services (low band-width and disconnection), consistency of information (e.g how to ensure
consistency in case of disconnection?). Finally, the adaptation of multimedia contents constitutes
certainly one of the central mechanisms in implementing effective pervasive information systems.
Heterogeneity of network connections and conditions of communication (in particular bandwidth),
variability of user’s preference and heterogeneity and limitation of access devices demand tools of
adaptation to transmit the content to the user. Many research works were carried out to develop
adaptation tools which can generally be categorized into three major approaches based on the location
of the adaptation process. These approaches are: client-based, proxy-based and server-based.
In the first approach, client device is responsible to adapt the contents according to the characteristics
of the device, the preferences of the user and the operational context (e.g. available bandwidth).
Nevertheless, because of limited capacity the client device, this approach is difficult to implement and
often impractical.
In the second approach, the content server provides the functionalities of adaptation. This approach
results in computational load and resource consumption on the server so decreases performance of the
content delivery.
To tackle the problems of both approaches, the third approach uses proxy. In this approach, a proxy
between the client and the content server is responsible for the adaptation of the content before it is
delivered to the user. While to some degree this approach solves some of the problems with the two
approaches, it has limited scalability because of high computational needs of adaptation operations.
Secondly, the list of content adaptation tools is not exhaustive and might include other in the future
and accommodating these new tools may not be possible if especially the proxy is not extensible.
II
Finally, putting all adaptation functionality into the proxy requires a machine with powerful CPUs and
a lot of memory.
In this thesis, we present a software architecture of multimedia content adaptation (called DCAF:
Distributed Content Adaptation Framework). This architecture is based on the use of Internet
accessible adaptation services. Unlike in the previous approaches where the client, content server or a
proxy is responsible for the adaptation process, in this architecture externally developed services carry
out the content transformation. DCAF thus provides a general content adaptation solution offering
flexibility, scalability, extensibility and interoperability.
The principal problem is the determination of optimal service configuration (also called optimal
adaptation path) provided that there are a number of possible service configurations and several
adaptation services can provide the same functionalities. This thesis proposes to adopt an Artificial
Intelligence (AI) technique to optimize the planning, the composition and the execution of the services
to adapt the content. The algorithm proposed takes into account the profile of the user, the
characteristics of the devices, the connectivity of the network, the format of the exchanged contents
and the specifications (cost, quality) of the available adaptation services to build a graph of adaptation
modelling the selected scenario of adaptation.
In parallel, we developed an ontology for the description of adaptation services. This ontology makes
it possible to describe the adaptation services semantically and finally to facilitate the discovery and
the composition of the services. It also makes it possible to translate easily the services description to
planning operator representation.
To demonstrate the feasibility of DCAF, a prototype has been implemented and tested. In addition to
the openness, scalability, flexibility and interoperability of the framework, experiments show that the
average processing time for adaptation services and the adaptation graph construction time suggest
that with some performance enhancement such as optimization of message exchange the service-based
framework is of a reasonable performance and can be used in pervasive computing environments.
Keywords: Pervasive Systems, Multimedia Content Adaptation, Service Composition, Planning,
Context.
Table of Contents
Table of Contents ............................................................................................................I
List of Figures .................................................................................................................I
List of Tables...................................................................................................................I
Résumé étendu ................................................................................................................... 1
1. Introduction ............................................................................................................ 1
2. État de l’art ............................................................................................................. 3
3. Description de métadonnées................................................................................... 7
4. Description des services d’adaptation de contenu multimédia .............................. 8
4.1
Hiérarchie de classes ...................................................................................... 8
4.2
Propriétés des services ................................................................................. 11
5. Proposition d’une architecture d’adaptation de contenu orientée service............ 13
5.1
L’Architecture DCAF .................................................................................. 13
5.2
Module de négociation et d’adaptation de contenu (CNAM) ...................... 15
5.2.1 Générateur du graphe d’adaptation multimédia (MAGG) ....................... 15
5.2.1.1 Définitions et notations utilisées dans MAGG...................................... 16
5.2.1.2 Algorithme ............................................................................................ 19
5.3
Recherche d’un chemin /plan d’adaptation optimal..................................... 26
5.4
Evaluation de performances ......................................................................... 29
6. Implémentation du prototype ............................................................................... 31
6.1
Composants du prototype............................................................................. 31
6.2
Bases de données utilisées dans le prototype ............................................... 35
6.3
Interfaces visuelles ....................................................................................... 37
6.3.1 Interface de saisie du profil client ............................................................ 37
6.3.2 Interface d’affichage de données adaptées............................................... 38
7. Conclusion et perspectives ................................................................................... 40
Chapter 1 Introduction and Motivation...................................................................................... 1
1.1
Introduction ........................................................................................................ 1
1.2
What is Pervasive Computing? .......................................................................... 6
1.3
The Need for Content Adaptation ...................................................................... 8
1.4
Motivation ........................................................................................................ 10
1.5
A Short Overview of Our Approach ................................................................ 12
1.6
Organization of the Thesis ............................................................................... 14
Chapter 2 Related Work on Content Adaptation ..................................................................... 15
2.1
Introduction ...................................................................................................... 15
2.2
Content Adaptation .......................................................................................... 17
2.2.1
Content Adaptation Techniques ............................................................... 18
2.2.1.1 Semantic adaptation .............................................................................. 20
2.2.1.2 Physical adaptation................................................................................ 21
2.2.2
Content Adaptation Approaches .............................................................. 26
2.2.2.1 Server-Based (or Source) Adaptation Approach................................... 26
2.2.2.2 Client-Based (or Receiver) Adaptation Approach ................................ 28
2.2.2.3 Proxy-Based Adaptation Approach....................................................... 30
II
2.2.2.4 Distributed and Agent Based Adaptation Approach ............................. 32
2.2.2.5 Ongoing Standardization for Content Adaptation................................. 35
2.2.3
Content Adaptation Systems .................................................................... 36
2.2.3.1 Commercial/Open Source Products ...................................................... 36
2.2.3.2 Research Prototypes .............................................................................. 40
2.3
Summary .......................................................................................................... 49
Chapter 3 Service-Oriented Architecture & Web Services...................................................... 51
3.1
Introduction ...................................................................................................... 51
3.2
Benefits of Service-Based Development.......................................................... 53
3.3
Web Services: Standards and Related Technologies ....................................... 54
3.3.1
Web Service Languages ........................................................................... 56
3.3.2
Semantic Web Service Description.......................................................... 57
3.4
Web Service Composition................................................................................ 60
3.4.1
Workflow Technique................................................................................ 61
3.4.2
AI planning............................................................................................... 63
3.5
Summary .......................................................................................................... 66
Chapter 4 Content Metadata Description ................................................................................. 67
4.1
Introduction ...................................................................................................... 67
4.2
Dublin Core ...................................................................................................... 70
4.3
SMPTE Meta-Dictionary ................................................................................. 72
4.4
MPEG 7............................................................................................................ 73
4.5
Other standards................................................................................................. 79
4.6
Summary .......................................................................................................... 80
Chapter 5 Context Metadata Description ................................................................................. 81
5.1
Introduction ...................................................................................................... 81
5.2
Composite Capabilities/Preference Profiles..................................................... 84
5.3
IETF Media Feature Sets.................................................................................. 87
5.4
Comprehensive Structured Context Profiles .................................................... 89
5.5
MPEG 21.......................................................................................................... 90
5.6
Summary .......................................................................................................... 94
Chapter 6 Service-Based Content Adaptation.......................................................................... 97
6.1
Introduction ...................................................................................................... 97
6.2
Why Service-Based Content Adaptation?........................................................ 98
6.3
Functional Model of Adaptation System ......................................................... 98
6.4
Overview of the DCAF Architecture ............................................................... 99
6.5
Context and Content Descriptions.................................................................. 101
6.5.1
Context Description................................................................................ 102
6.5.2
Content Description (Metadata) ............................................................. 103
6.6
Multimedia Content Adaptation Services Description................................... 104
6.6.1
Adaptation Service and Multimedia Data Entities................................. 105
6.6.2
Class Hierarchy ...................................................................................... 106
6.6.3
Properties of Entities .............................................................................. 109
6.7
Content Negotiation and Adaptation Module ................................................ 112
6.7.1
Constructing Content Adaptation Graph................................................ 113
6.7.2
Multimedia Adaptation Graph Generator (MAGG)............................... 122
6.7.2.1 Definitions and Notations Used in MAGG ......................................... 122
6.7.2.2 Algorithm to Construct Adaptation Graph.......................................... 125
6.7.3
Searching an Optimal Adaptation Path/Plan.......................................... 130
6.7.4
Performance Evaluation ......................................................................... 133
6.8
Summary ........................................................................................................ 137
Table of Contents
III
Chapter 7 Prototype Implementation ..................................................................................... 139
7.1
Components of the Prototype......................................................................... 139
7.2
Sample Database Used in the Prototype ........................................................ 146
7.3
Visual Interfaces............................................................................................. 148
7.3.1
Client Profile Entry Interface ................................................................. 148
7.3.2
Patient Record Search Interface ............................................................. 151
7.3.3
Adapted Data Display Interface ............................................................. 151
7.4
Summary ........................................................................................................ 155
Chapter 8 Discussion.............................................................................................................. 157
8.1
DCAF Architecture ........................................................................................ 157
8.2
Semantic Adaptation Services Description .................................................... 159
8.3
Adaptation Service Composition ................................................................... 160
8.4
Prototype Implementation .............................................................................. 162
Chapter 9 Conclusion and Future Work................................................................................. 163
9.1
Conclusion and Contributions........................................................................ 163
9.2
Future Work ................................................................................................... 165
Annexes.............................................................................................................................. 169
Annex A: Context Profile........................................................................................... 171
Annex B: Proposed Services Description Ontology .................................................. 183
Annex C: OWL-S Profile Schema ............................................................................. 193
Annex D: Modified Dijkstra’s Algorithm.................................................................. 201
Annex E: Classes Hierarchy of Local Proxy.............................................................. 205
Annex F: Glossary...................................................................................................... 211
Bibliography....................................................................................................................... 213
Bibliography............................................................................................................... 215
Curriculum Vitae........................................................................................................ 237
Liste des publications ................................................................................................. 239
I
List of Figures
List of Figures
Figure 1 : Hiérarchie de classes (services d’adaptation de multimédia) .................................... 9
Figure 2 : Représentation de la classe MultimediaAdaptationServices en OWL....................... 9
Figure 3 : Hiérarchie de classes pour les services d’adaptation d’audio.................................. 10
Figure 4 : Extrait de la représentation de la classe AudioAdaptationServices en OWL .......... 11
Figure 5 : Exemple d’une description de service de transcodage (audio vers texte) .............. 12
Figure 6: Architecture DCAF................................................................................................... 13
Figure 7: Comparaison de différents ordres d'exécution.......................................................... 30
Figure 8: Temps de construction du graphe ............................................................................. 31
Figure 9: Schéma fonctionnel du proxy local .......................................................................... 33
Figure 10: Modèle conceptuel des données ............................................................................. 37
Figure 11: Capture d’écran de l’interface de sélection du matériel. ........................................ 38
Figure 12 (a) : Capture d’écran d’une donnée-image sur un PC standard (sans adaptation)... 39
Figure 12 (b) : Capture d’écran d’une donnée-image sur un Smartphone (après adaptation).39
Figure 1.1: Goal of Content Adaptation................................................................................... 10
Figure 2.1: Server-Based or Source Adaptation....................................................................... 27
Figure 2.2: Client-Based or Receiver Adaptation .................................................................... 29
Figure 2.3: Proxy-Based Adaptation........................................................................................ 31
Figure 3.1: A service-Oriented Architecture (SOA) [Ort05] ................................................... 53
Figure 4.1: Dublin Core Metadata Element Set ....................................................................... 72
Figure 4.2: Scope of the MPEG Standard ................................................................................ 75
Figure 4.3 Schema Definition of VideoSegmentType ............................................................. 76
Figure 4.4: MPEG-7 Description Example .............................................................................. 78
Figure 5.1: CC/PP Context Representation Model .................................................................. 85
Figure 5.2: Example of CC/PP Profile in XML/RDF Format.................................................. 86
Figure 5.3: UAProf Main Components. ................................................................................... 87
Figure 5.3: CSCP Profile Example .......................................................................................... 90
Figure 5.4: A Representation of the MPEG-21 Multimedia Framework [Maga04]................ 92
Figure 5.5: The Adaptation of Digital Items ............................................................................ 94
Figure 6.1: Functional Model................................................................................................... 99
Figure 6.3: Partial Structure of Context Profile Representation ............................................ 102
Figure 6.4 Partial Example of Context Profile....................................................................... 103
Figure 6.5 Sample Multimedia Content Description in XML Format ................................... 103
Figure 6.6: Class Hierarchy of Top-level of Multimedia Content Adaptation Services........ 107
Figure 6.7: OWL Representation of MultimediaAdaptationServices Class........................... 108
Figure 6.9: A Small Excerpt of OWL Representation for AudioAdaptationServices Class .. 109
Figure 6.10: An Example of Service Description for Audio to Text Adaptation Service ..... 111
Figure 6.11: Content Adaptation Process............................................................................... 112
Figure 6.12: Sample Transformation Rules in XML Format................................................. 117
Figure 6.13: An XML Encoding of a Transformation Prescript ............................................ 118
Figure 6.14: A Graphical Representation for the Transformation Prescript .......................... 119
Figure 6.15: An example of Adaptation Graph for Text to Audio Transformation............... 120
Figure 6.16: A Fully-Connected Adaptation Graph............................................................... 121
Figure 6.17: Algorithm for Adaptation Graph Construction (AGC) ..................................... 129
Figure 6.18: Comparison of Different Execution Orders....................................................... 134
Figure 6.20 Example of an adaptation graph ......................................................................... 135
Figure 6.19: Graph Construction Time .................................................................................. 136
Figure 7.1: Components and Interaction of DCAF Architecture ........................................... 141
II
Figure 7.2: Block Diagram of the Local Proxy...................................................................... 144
Figure 7.3: Classes of Local Proxy Implementation. ............................................................. 145
Figure 7.4: Conceptual data model. ....................................................................................... 148
Figure 7.5: Screenshot of the Device Selection Interface ...................................................... 149
Figure 7.6: Screenshot of the New Device Entry Interface.................................................... 149
Figure 7.7: Screenshot of the Network Characteristics Entry Interface................................. 150
Figure 7.8: Screenshot of User Preferences Entry Interface .................................................. 150
Figure 7.9: Screenshot of Patient Record Search Interface.................................................... 151
Figure 7.10: Graphical Assistant: AWD graphical representation......................................... 152
Figure 7.11 (a): Screenshot of an Image data on a Standard PC (without adaptation) ......... 153
Figure 7.12 Screenshot of text data (a) original in French (b) the translated data in English 154
I
List of Tables
List of Tables
Tableau 1 : Propriétés de MultimediaAdaptationServices...................................................... 11
Tableau 2 : Propriétés de la classe MultimediaDatatypeFormat............................................. 12
Table 2.1: Media Types and Content Adaptation Techniques [Lei01 and Shaha01] .............. 19
Table 2.2: Summary of Content Adaptation Systems Features ............................................... 47
Table 2.3: Architectural Characteristics of Adaptation Approaches........................................ 49
Table 6.1: Types of Audio Adaptation Services .................................................................... 105
Table 6.2: Multimedia Data Types......................................................................................... 105
Table 6.3: Properties of MultimediaAdaptationServices ....................................................... 110
Table 6.4: Properties of MultimediaDatatypeFormat Class................................................... 111
Table 6.5: Sample Transformation Rules............................................................................... 115
Table 6.6: Constraint Processing............................................................................................ 117
Résumé étendu
1.
Introduction
Le très rapide développement de l'informatique mobile (téléphones mobiles, assistants
personnels, ordinateurs portables…) permet aujourd'hui d'envisager la mise en œuvre de
systèmes d'information ubiquitaires : quelle que soit sa localisation, l'utilisateur dispose, à
tout moment, d'un accès au réseau mondial (accès “anywhere - anytime”). L'enjeu des
systèmes pervasifs (ou ubiquitaires) est, dans cette perspective, de fournir les cadres
méthodologiques et les mécanismes protocolaires à même de permettre une utilisation fiable,
pertinente et efficace de ces systèmes.
La gestion des données en représente clairement l’une des composantes-clefs, recouvrant de
nombreux aspects : extensibilité du système, accès et intégration des données (en termes
d’indexation et d’exécution de requêtes dans un environnement distribué fortement
hétérogène), optimisation de l’utilisation des ressources et de la qualité de service (bande
passante réduite, discontinuité du service), cohérence de l’information (l’utilisateur pouvant
se trouver en mode déconnecté, comment assurer la cohérence et la pérennité des données
qu'il manipule ?).
Enfin, l'adaptation de contenus multimédias constitue certainement l'un des mécanismes
centraux dans la mise en œuvre effective des systèmes d'information pervasifs. La très grande
hétérogénéité des moyens de connexion et des conditions de communication (bande passante
notamment), l’hétérogénéité des dispositifs (en termes d'affichage, de stockage, de puissance
de calcul, d’environnement logiciel), la très grande variabilité des préférences utilisateur
imposent en effet de fournir des outils d'adaptation des contenus transmis aux utilisateurs.
Considérons le cas d’un médecin de garde dans un établissement de soins à Lyon. Ce centre
est équipé d’un système informatique de gestion de données patients moderne (dossier
médical, images, résultats d’analyses…), connecté à d’autres centres de soins en Europe. Ce
système permet aux médecins, infirmiers, personnels de soins et autres équipes hospitalières
d’accéder aux données relatives aux patients. Le médecin de garde se rend au chevet d’un
2
patient originaire d’un Etat européen tiers. Ce patient présente des signes d’infection
pulmonaire. Avant d’établir une nouvelle prescription, le médecin veut, à partir de son
dispositif sans fil de poche (par exemple : un assistant personnel numérique), consulter le
dossier médical du patient, dans lequel figurent des données multimédias intégrant du texte,
des images, des séquences dynamiques d’images (ex : coronarographies). Il se connecte au
système, récupère les données répertoriées lors des précédents séjours dans d’autres
établissements, note que le patient est, d’une part, déjà sous traitement pour une hypertension
artérielle et des problèmes cardiaques et, d’autre part, allergique à la pénicilline. Il se sert
alors de son dispositif de poche pour consulter une base de données de médicaments en ligne
afin de prescrire un traitement compatible avec les médicaments actuellement observés par le
patient. Le médecin remplit enfin sur l’écran de son assistant personnel un petit formulaire
visant à autoriser et émettre une prescription auprès d’une pharmacie par un réseau sans fil.
Le scénario précédent illustre la mobilité d’un utilisateur, l’hétérogénéité des dispositifs de
connexion, l’hétérogénéité des connexions réseaux utilisées, la grande variété des sources
d’information mises en œuvre stockant des données multimédias (texte, images, séquences
vidéo et audio).
L’accès à l’information, dans ce scénario soulève, en pratique, des problématiques de
compatibilité et de pertinence : compatibilité du format des données avec les formats
supportés par le dispositif de connexion, pertinence vis-à-vis des préférences de l’utilisateur
(ex : langues parlées par le médecin), compatibilité des données transmises vis-à-vis de la
capacité du réseau et du dispositif de connexion, ergonomie de l’affichage sur le dispositif de
connexion.
L'adaptation de contenu est considérée comme une solution efficace et intéressante à cette
problématique [Held02]. Elle consiste en la transformation et la personnalisation du contenu
afin qu’il soit compatible avec les préférences de l‘utilisateur et les contraintes du contexte
d’exploitation [Lum02b, Hori00].
Dans cette thèse, nous proposons un cadre architectural d’adaptation de contenu distribué
fondé sur l’utilisation de services tiers. Les idées à la base de l’architecture proposée sont :
3
État de l’art
d’une part, de placer le moteur décisionnel chargé d’optimiser et de
planifier l’adaptation à mettre en œuvre sur un proxy (mandataire) situé entre
le consommateur et le fournisseur d’informations ;
d’autre part, d’utiliser des services-tiers accessibles sur Internet (services
Web) pour exécuter physiquement l’adaptation ;
enfin, de proposer une ontologie décrivant les caractéristiques
(sémantique, coût, qualité…) des services d’adaptation multimédia. Cette
ontologie est utilisée pour sélectionner et composer les services d’adaptation
les plus appropriés au contexte d’utilisation.
Cette architecture constitue une solution ouverte et générique pour les problèmes d'adaptation
de contenus qui peut être déployée dans le cadre de différentes applications. Afin de valider
la faisabilité de notre proposition, nous avons développé et évalué un prototype ciblé sur
l’accès au dossier médical réparti, domaine d’application privilégié de l’équipe.
Ce résumé étendu est organisé comme suit. Dans la section 2, nous présentons un état de l’art
sur l’adaptation de contenu. Dans la section 3, nous analysons les modèles de métadonnées
utilisés pour la description du contexte d’exécution et du contenu des données. Ces
métadonnées sont essentielles pour identifier les caractéristiques des données et les
contraintes contextuelles et, in fine, décider du nombre et du type d’adaptations ou de
transformations requises. Une ontologie des services d’adaptation multimédia est proposée en
section 4. La section 5 présente notre proposition d’architecture distribuée d’adaptation de
contenus fondée sur des services tiers et en donne une description formelle.
L’implémentation d’un prototype et les résultats expérimentaux sont analysés dans la section
6. Enfin, La section 7 conclut ce document et présente les principales perspectives à nos
travaux.
2.
État de l’art
Depuis l’émergence des systèmes pervasifs, l'adaptation de contenu multimédia a fait l’objet
d’importantes recherches et plusieurs techniques d'adaptation ont été développées. Les
techniques actuellement disponibles reposent principalement sur la transformation textuelle
4
[Nagao01, Hous96, Lilj95], le transcodage d’image [Wee03, Lee03, Chandra00, Smith98] et
le traitement vidéo et audio [Libse04, Shan00, Vetro02, Bolot98].
Une des questions majeures en terme d’architecture d’adaptation est de savoir où se réalise la
prise de décision et, surtout, où s’exécutent les opérations d’adaptation. Trois approches
élémentaires ont été proposées dans la littérature pour la localisation des processus
d’adaptation sur le parcours de transmission des données, entre la source des données
(serveur de contenu) et la destination des données (client final) : (i) au niveau de la source,
(ii) au niveau du destinataire ou client et (iii) au niveau d’un intermédiaire, quelque part sur le
réseau, sur des sites spécifiques présentant des propriétés intéressantes, par exemple, à la
frontière des parties filaire et non filaire du réseau.
Dans la première approche, où l’adaptation est opérée au niveau de la source - approche dite
centrée serveur - [Marg01, Mogul01, Mohan99, Bhrag98, Bolot98], le serveur se charge de
découvrir les capacités du client et la bande passante disponible. Il décide alors de la
meilleure stratégie d’adaptation. Cette approche permet davantage de contrôle car
l’adaptation, liée au traitement du contenu stocké sur le serveur, permet à l’auteur (créateur)
du contenu de formuler des conseils ou des contraintes sur l’adaptation. Un auteur peut ainsi
pré-visualiser et valider le résultat de l’adaptation selon différentes préférences et conditions.
De plus, les solutions centrées serveur permettent la mise en œuvre de mécanismes
d’adaptation de contenu dynamique (à la volée) ou statique (hors ligne). Cependant, ces
approches présentent deux inconvénients majeurs : d’une part, elles imposent aux
fournisseurs de contenu d’intégrer des mécanismes d’adaptation ; d’autre part, les processus
de transformation induisent une charge de calcul et une consommation de ressources
importantes sur le serveur que celui-ci n’a souvent pas la capacité de fournir.
Dans la seconde approche, où l’adaptation est réalisée au niveau du destinataire - approche
dite centrée client - [Marr02, Lei01, Björk99, Yosh97, Fisher97], le processus d’adaptation
est effectué par le terminal client, en fonction des capacités de celui-ci. Le serveur demeure
donc inchangé et transmet ses contenus dans leur format d’origine. Le terminal du client
utilisateur, à la réception du contenu, transforme celui-ci de manière à pouvoir l’afficher
correctement. Deux méthodes d’adaptation peuvent être envisagées : sélection par le terminal
des contenus (ou des versions de contenus) compatibles avec ses caractéristiques, ou
transformation ad hoc effectuée par le terminal lui-même. La sélection des contenus
État de l’art
5
compatibles peut être réalisée dans le cadre d’un protocole de négociation avec les serveurs
de contenus : en réponse à une requête client, le(s) serveur(s) transmette(nt) la liste des
variantes disponibles pour les contenus répondant à la requête ; le terminal client sélectionne
les (variantes des) contenus compatibles (et pertinentes) ; enfin, le(s) serveur(s)
transmette(nt) les contenus sélectionnés. Notons que certains dispositifs clients transforment
par défaut certains contenus ; par exemple, certains terminaux Windows CE (comme le
SmartPhone) modifient la résolution chromatique des images (passage d’une profondeur de
couleur de 24 bits à un niveau de gris sur 4 bits).
L’adaptation centrée client requiert des modifications minimales au niveau du terminal de
connexion et peut être extrêmement efficace dans la personnalisation du contenu et
l’adaptation aux caractéristiques du terminal. Toutefois, cette solution est très mal adaptée
aux situations où les contraintes de transmission réseaux sont prégnantes, ce qui est
typiquement le cas de nombreuses applications pervasives intégrant des dispositifs nomades.
En outre, la complexité souvent élevée des mécanismes d'adaptation interdit l’utilisation
générique de cette solution [Perk01] dans la mesure où une proportion considérable des
dispositifs pervasifs reste limitée en termes de puissance de calcul, de mémoire, d’énergie et
de stockage. Ainsi, les approches centrées client ne sont en pratique pertinentes que vis-à-vis
de problématiques simples d’affichage lorsque les contraintes réseaux sont traitées par
ailleurs [Nand99].
La troisième approche tente de constituer un compromis entre les deux solutions précédentes
; l’adaptation est ainsi exécutée sur un nœud intermédiaire habituellement qualifié de proxy,
(ou mandataire)1. Des exemples de systèmes à base de proxys se trouvent dans [Sing04,
Wee03, Kim03, Chandra00, Fox98a Angin98, Bick97, Noble97]. L’idée de base de cette
approche est la suivante : le proxy intercepte la réponse du serveur, décide et effectue
l’adaptation en fonction des préférences de l’utilisateur, des capacités des terminaux et de
l’état du réseau, puis envoie le contenu adapté au client.
L’adoption d’une solution centrée proxy présente plusieurs avantages. D’abord, la charge de
calcul du serveur de contenus est déplacée vers le proxy. En second lieu, le proxy peut être
positionné au point le plus critique du chemin de données. On considère habituellement que
1
On parle également de passerelle (gateway).
6
la bande passante entre un proxy et un serveur est plus large que celle qui est disponible entre
un client (souvent mobile) et un proxy [Antonio97]. Le placement sur le dernier maillon de la
chaîne permet au proxy de disposer d’une vue globale sur les ressources de l’environnement,
telles que la latence du réseau, la bande passante, la taille du contenu à transporter avant la
livraison finale, les préférences de l’utilisateur, toute modification survenant dans le temps,
etc. Le serveur proxy joue aussi un autre rôle majeur de mise en cache des résultats de
l’adaptation de contenus afin d’éviter des allers-retours vers le serveur de contenu et la
répétition d’opérations de transcodage coûteuses lorsque les ressources peuvent être
accessibles depuis le cache [Singh04, Fox97a].
Les approches orientées proxy présentent aussi des inconvénients. En premier lieu, elles
passent mal à l’échelle du fait de coûts de calcul considérables induits par les opérations
d’adaptation [Lumb02b] imposant des unités de calcul puissantes et beaucoup de mémoire.
En second lieu, le fait de passer par un intermédiaire pour la transmission d’un contenu
soulève des problèmes de sécurité. Le tiers manipulant le proxy doit être digne de confiance
auprès de l’utilisateur et de la source. De plus, le proxy est susceptible de facturer son service
et l’utilisation des ressources sollicitées pour la réalisation de l’adaptation. Des mécanismes
de traçage (accounting) doivent dans cette hypothèse être intégrés au système afin
d’enregistrer la quantité de ressources utilisées et l’usage des données. Enfin, la liste des
outils d’adaptation de contenu n’est pas exhaustive et est amenée à évoluer ; l’intégration de
ces nouveaux outils risque de ne pas être possible si le proxy n’est pas fonctionnellement
extensible.
En résumé, de nombreux efforts ont été menés pour développer différentes approches et
techniques d’adaptation de contenu multimédia dans les environnements pervasifs (cf.
chapitre 2 du manuscrit pour une analyse complète de l’état de l’art). Des produits
commerciaux (IBM Transcoding [IBM00], Web Clipping [3Com], WebSphere [Rodr01],
etc.) et des prototypes issus de travaux de recherche (TranSend [Fox98b], Odyssey
[Noble00], Conductor [Yarvis01], Digestor [Bick99], etc.) ont été parallèlement développés.
Ces solutions ont contribué à l’élaboration de nombreuses stratégies, d’architecture et de
techniques d’adaptation. Cependant aucune ne résout de manière satisfaisante les
problématiques d’interopérabilité, d’extensibilité, de flexibilité, de passage à l’échelle qui
sont des points essentiels dans un environnement pervasif (voir les tableaux 2.2 et 2.3
(chapitre 2) pour les résultats de cette analyse). En outre, ces systèmes sont conçus pour la
Description de métadonnées
7
plupart pour des besoins spécifiques ; les types d’adaptation de contenu qui ont été abordés
sont ainsi principalement focalisés sur la transformation d’image, et ne fournissent pas de
solution générique d’adaptation.
3.
Description de métadonnées
La motivation pour l’adaptation de contenu multimédia est de fournir à l’utilisateur final le
meilleur contenu possible dans un contexte hétérogène, avec des contraintes, des
caractéristiques et des préférences utilisateur fortement personnalisables. La réussite de
l’adaptation de contenu dépend de la qualité et de la quantité de connaissances recueillies sur
le contenu et l’environnement d’utilisation (contexte). Les modèles et systèmes de
métadonnées fournissent un mécanisme de représentation, de stockage et de traitement de
cette connaissance.
Nous considérons trois catégories de métadonnées : les métadonnées de contenu (par
exemple, le format, la taille, la dimension d’une image, etc.), les métadonnées de contexte
(taille de l’écran, contenus pris en charge par le dispositif de connexion, capacité de la bande
passante, préférences linguistiques, etc.), et les métadonnées ou la description des services
d’adaptation (cf. section 4).
Le modèle de métadonnées de contenu que nous avons choisi est le format MPEG-7. Notre
choix (cf. chapitre 4) repose sur le fait que MPEG-7 est indépendant du média, qu’il est
actuellement développé en qualité de standard international, qu’il représente le standard qui
fournit l’ensemble le plus riche et le plus souple de descriptions de propriétés multimédias, et
enfin qu’il couvre une famille de standards comme SMPTE, Dublin Core et d’autres ; il
constitue de fait le standard le plus interopérable.
Des métadonnées de contexte sont utilisées pour décrire l’utilisateur (par exemple : sa langue
préférée), le matériel (résolution d’affichage, contenus supportés, etc.), le réseau (bande
passante disponible…), etc. Un certain nombre d’outils de description ont été développés
pour représenter les métadonnées de contexte ; parmi ces outils figurent CC/PP, MPEG-21,
CSCP, etc. Si CC/PP est décomposable, uniforme et extensible, il manque cependant de
fonctionnalités de structuration. Sa hiérarchie stricte en deux niveaux n’est pas appropriée à
8
la capture de structures de profils complexes. Les outils MPEG-21/DIA garantissent une
adaptation efficace du contenu multimédia ; mais leur restriction aux contenus MPEG-21
limite leur application. CSCP fournit une structure multi-niveaux qui permet une
représentation de tous les types d’information contextuelle. CSCP est basé sur RDF et hérite
ainsi des propriétés de substitution et d’extensibilité. Les noms d’attribut sont interprétés en
fonction du contexte et selon leur position dans la structure de profil. Ainsi un nommage non
ambigu pour les attributs d’un profil n’est pas nécessaire. La description CSCP a été choisie
dans notre travail pour sa simplicité, quoique notre structure d’adaptation demeure ouverte à
l’intégration d’autres modèles de description.
4.
Description des services d’adaptation de contenu multimédia
Un modèle de description de services tel que WSDL ne suffit pas pour automatiser la
découverte, la sélection, la composition et l’invocation des services. En effet, si la syntaxe du
service est importante pour son invocation et sa composition, une information sémantique sur
l’objet et le fonctionnement du service (sémantique des paramètres d’entrée et de sortie, coût
du service, préconditions d’exécution, postconditions, temps d’exécution, qualité du
service…) est essentielle à son utilisation pratique.
Nous proposons dans ce manuscrit (chapitre 5) une ontologie qui formalise la description
sémantique des services d’adaptation multimédia. Cette ontologie facilite la découverte, la
sélection, la composition et l’invocation automatique des services. Nous présentons dans ce
résumé étendu la sous-ontologie qui concerne les données audio. L’ontologie complète est
décrite en Annexe B.
4.1
Hiérarchie de classes
Pour déterminer la structure de la hiérarchie des services d’adaptation, nous avons utilisé la
classification des techniques d’adaptation définie par Lei et al. [Lei01]. Les différents
services d’adaptation sont représentés comme étant des classes hiérarchiquement organisées
dans l’ontologie (Figure 1). Cette hiérarchie de classes et les propriétés des services (cf.
Section 1.2) décrivent l’ontologie complète des services d’adaptation multimédia.
9
Description des services d’adaptation de contenu multimédia
MultimediaAdaptationServices
f
su
bC
las
sO
ImageAdaptationServices
O
la
ss
su
bC
O
f
O
f
las
s
f
la
ss
O
su
bC
O
f
Of
la
ss
su
bC
f
AudioLanguageAdaptation
Services
ss
la
bC
su
AudioFormatAdaptation
Services
O
ss
la
bC
su
subClassOf
su
bC
TextAdaptationServices
UnimodalAudioAdaptationServices
AudioReductionAdaptation
Services
StereoToMonoAdaptation
Services
sO
f
ss
la
bC
su
f
AudioAdaptationServices
MultimodalAudioAdaptationServices
AudioToTextAdaptation
Services
Cla
s
f
VideoAdaptationServices
su
b
sO
la s
bC
su
Of
ss
Cl a
b
su
AudioSamplingRateReduction
AdaptationServices
Figure 1 : Hiérarchie de classes (services d’adaptation de multimédia)
La super-classe dans l’ontologie est la classe MultimediaAdaptationServices. Cette classe
regroupe, pour chaque type de données multimédias, différentes sous-classes de services
d’adaptation. Ces services peuvent être des services d’adaptation audio, des services
d’adaptation d’images, etc. La Figure 2 montre la représentation en OWL de la classe
MultimediaAdaptationServices et ses sous-classes.
<owl:Class rdf: ID= “MultimediaAdaptationServices”>
<owl:Class rdf:ID= “AudioAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
<owl:Class rdf:ID= “TextAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
<owl:Class rdf:ID= “ImageAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
<owl:Class rdf:ID= “VideoAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
Figure 2 : Représentation de la classe MultimediaAdaptationServices en OWL
10
La Figure 3 représente, de manière plus spécifique, la hiérarchie de classes des services
d’adaptation audio.
O
ss
la
bC
su
su
bC
la
ss
O
f
AudioAdaptationServices
f
MultimodalAudioAdaptationServices
O
f
la
ss
O
f
AudioReductionAdaptation
Services
ss
la
su
bC
bC
su
AudioToTextAdaptation
Services
subClassOf
su
bC
la
ss
O
f
UnimodalAudioAdaptationServices
AudioFormatAdaptation
Services
AudioLanguageAdaptation
Services
Of
su
bC
l
ss
la
as
sO
f
bC
su
StereoToMonoAdaptation
Services
AudioSamplingRateReduction
AdaptationServices
Figure 3 : Hiérarchie de classes pour les services d’adaptation d’audio
La
(sous-)classe
AudioAdaptationServices
hérite
des
propriétés
de
la
classe
MultimediaAdaptationServices ; cependant, la valeur de la propriété d’entrée hasInputType est
logiquement
limitée
à
UnimodalAudioAdaptationServices
« audio ».
et
Cette
classe
a
deux
MultiModalAudioAdaptationServices.
sous-classes:
La
classe
UnimodalAudioAdaptationServices impose le type de donnée de sortie (audio) mais aussi le type
de donnée d’entrée (audio). La classe UnimodalAudioAdaptationServices intègre trois sousclasses
:
AudioReductionAdaptationServices,
AudioLanguageAdaptationServices
et
AudioFormatAdaptationServices. La classe AudioReductionAdaptationServices a deux sous-classes :
StereoToMonoAdaptationServices et AudioSamplingRateReductionAdaptationServices. Enfin, la
classe MultiModalAudioAdaptationServices a une sous-classe, AudioTextAdaptationServices.
Description des services d’adaptation de contenu multimédia
11
La Figure 4 décrit un extrait de la représentation de la classe AudioAdaptationServices en OWL.
<owl:Class rdf:about="#AudioAdaptationServices">
<rdfs:subClassOf rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:hasValue rdf:resource="#Audio"/>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasInputType"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Figure 4 : Extrait de la représentation de la classe AudioAdaptationServices en OWL
4.2
Propriétés des services
Les services d’adaptation partagent tous un certain nombre de propriétés générales
(Tableau 1), souvent similaires aux propriétés de la classe OWL-S (cf. Annexe C). Après les
avoir identifiées, nous avons regroupé ces propriétés (attributs) dans la super-classe
MultimediaAdaptationServices.
MultimediaAdaptationServices
Nom de la propriété
hasServiceName
hasServiceTime
hasServiceQuality
hasEffect
Valeur
String
Float
String
Instance de la classe
MultimediaDataTypeFormat
String
Définition
Nom du service
Temps d’exécution du service
Qualité de donnée adaptée
Effets de l’exécution de
service
hasInputType
Nom du type de donnée en
entrée
hasOutputType
String
Nom du type de donnée en
sortie
hasServicePrice
Float
Coût du service
hasPrecondition
Instance de la classe
Condition préalable pour
MultimediaDataTypeFormat
exécuter le service, par
exemple format de l’image
hasServiceProvider
String
Nom et adresse du fournisseur
de service
hasServiceDescription String
Autres descriptions de services
Tableau 1 : Propriétés de MultimediaAdaptationServices
12
Les
types
de
format
de
données
multimédias
sont
décrits
par
la
classe
MultimediaDatatypeFormat. Le tableau 2 décrit les propriétés de cette classe.
MultimediaDatatypeFormat
Nom de la propriété
hasDatatype
hasFormat
Valeur
String
String
Définition
Nom du type de média
Nom du type de format (ex.
MPEG)
Tableau 2 : Propriétés de la classe MultimediaDatatypeFormat
La Figure 5 présente un exemple de description de service d’adaptation (transcodage audio
vers texte) utilisant l'ontologie décrite ci-dessus.
<AtomicProcess rdf:ID="AudioToTextAdapationService ">
<hasInput rdf:ID="#InputAudio">
<parameterType datatype="&xsd;#anyURI">
</hasInput>
<hasOutput rdf:ID="#OutputText">
<parameterType datatype="&xsd;#anyURI">
</hasOutput>
<hasPrecondition>
<hasExpression rdf:ID="InputAudioFormat">
<hasSubject rdf:resource="#InputAudio"/>
<hasProperty rdf:resource="#Audio"/>
<hasFormat rdf:datatype="&xsd; #string">#WAV</hasFormat>
</hasExpression>
</hasPrecondition>
<hasEffect>
<hasExpression rdf:ID="OutputTextFormat">
<hasSubject rdf:ID="#OutputText"/>
<hasProperty rdf:resource="#Text"/>
<hasFormat rdf:datatype="&xsd;#string">#PlainText</hasFormat>
</hasExpression>
</hasEffect>
<hasServicePrice>
<parameterType datatype="&xsd;#float">25
</hasServicePrice>
<hasServiceTime>
<parameterType datatype="&xsd;#float">200
</hasServiceTime>
</AtomicProcess>
Figure 5 : Exemple d’une description de service de transcodage (audio vers texte)
Nous renvoyons le lecteur, pour plus de détails sur l’ontologie de description de services
d’adaptation multimédia, au chapitre 5.
13
Proposition d’une architecture d’adaptation de contenu orientée service
5.
Proposition d’une architecture d’adaptation de contenu
orientée service
Cette section décrit l’architecture générale d’adaptation de contenu proposée dans cette thèse.
Les différents composants de l’architecture et leurs rôles sont tout d’abord analysés avec un
accent plus particulièrement porté sur le module de négociation et d’adaptation de contenu
(Content Negotiation and Adaptation Module - CNAM). Puis nous formalisons la notion de
graphe d’adaptation de contenu et donnons un algorithme de construction de ce graphe.
5.1
L’Architecture DCAF
À la différence des systèmes existants d’adaptation de contenu, lesquels sont restreints à une
application particulière [Lemlouma et al 2003] ou une transformation spécifique [Buchholz et
al 2002], nous visons à fournir une architecture d’adaptation de contenu générique, extensible
et interopérable. L’architecture que nous proposons (Figure 6) est composée de six
composants principaux décrits ci-dessous :
Adaptation Services
Adaptation
Services
Registry
Content Servers
Internet
User Devices
Local Proxies
Content Proxies
Context Profile
Repository
Figure 6: Architecture DCAF
14
Serveurs de contenus : Ce sont des entrepôts standards de données, tels que des sites Web,
des bases de données et des serveurs multimédias.
Proxys de contenus (Content Proxies - CP) : Les proxys de contenus fournissent un accès
aux serveurs de contenus, formulent les requêtes des utilisateurs dans un format adéquat aux
sources, gèrent et livrent (en réponse à des requêtes utilisateur) des descriptions de contenu
(métadonnées).
Gestionnaire de profils utilisateurs (Context Profile Repository - CPR) : ce serveur
stocke les informations du contexte utilisateur, c’est-à-dire les caractéristiques et préférences
de l’utilisateur, les capacités et propriétés du terminal et les propriétés du réseau. Les
utilisateurs peuvent mettre à jour et modifier leur profil à tout moment. Les informations
contextuelles dynamiques telles que la localisation d’un utilisateur ou les paramètres
dynamiques du réseau sont déterminées lors de l’exécution des requêtes de données.
Répertoire des services d’adaptation (Adaptation Service Registry - ASR) : Notre
approche de l’adaptation est basée sur des services d’adaptation tiers. Cependant, la
recherche des services Web d’adaptation disponibles est un problème qui croît de manière
exponentielle avec un nombre croissant de services. Pour faire face à ce problème, nous
avons introduit un annuaire de services d’adaptation. L’ASR est semblable à un annuaire
UDDI (Universal Description, Discovery and Integration). Il stocke les descriptions
fonctionnelles (profils) et non fonctionnelles (ex : coût) des services d’adaptation multimédia
et offre des API de recherche de services.
Services d’adaptation (Adaptation Services - AS) : serveurs hébergeant un ou plusieurs
services d’adaptation. Dans notre approche, les services d’adaptation sont implémentés en
tant que services Web et sont développés de manière indépendante de l’architecture DCAF.
Proxy locaux (Local Proxies - LP) : Ces proxies prennent en charge la récupération et le
traitement des profils de contexte. Ils décident du type et du nombre de traitements adaptatifs,
découvrent les services d’adaptation, planifient l’exécution des services et les invoquent. Un
élément fondamental du proxy local est le module de négociation et d’adaptation de contenu
(CNAM). Ce module détermine un schéma d’adaptation optimal et invoque les services
d’adaptation ad hoc.
Proposition d’une architecture d’adaptation de contenu orientée service
5.2
15
Module de négociation et d’adaptation de contenu (CNAM)
La partie fondamentale du proxy local est le module de négociation et d’adaptation de
contenu (CNAM). Le CNAM a deux principaux composants : le moteur de décision et le
planificateur de l’adaptation. Le moteur de décision identifie les types d’adaptation à
effectuer en utilisant les paramètres de l’environnement : profil de l’utilisateur, profil du
terminal, profil de réseau et métadonnées de contenu. Une fois les types d’adaptation
déterminés, l’étape suivante consiste à identifier les services d’adaptation qui vont les
exécuter. Le planificateur se charge de la sélection et de la composition des services
appropriés. La sélection de services est basée sur des critères de qualité comme le coût du
service et le temps d’exécution. Le planificateur récupère ces informations via les ASR (cf.
plus haut).
5.2.1 Générateur du graphe d’adaptation multimédia (MAGG)
Dans un scénario d’application typique en environnement pervasif, un client demande un
contenu multimédia à un serveur au moyen d’un dispositif présentant des propriétés
spécifiques, connecté au serveur par un réseau donné. L’objectif de l’adaptation de contenu
est de transformer le contenu multimédia, stocké sur le serveur dans un format précisément
défini, en fonction des capacités du terminal, de la connexion réseau et des préférences de
l’utilisateur avant de le transmettre au client. Selon le cas, il peut s’avérer nécessaire
d’appliquer un ensemble de transformations afin de faire correspondre le contenu à
l’environnement d’exploitation. Par exemple, dans le scénario 1 du chapitre 1 (section 1.4),
en considérant que le contenu est rédigé en anglais et que la langue préférée de l’utilisateur
est le français, deux transformations au moins sont nécessaires : une conversion du format
textuel en séquence audio et une traduction de l’anglais au français. Comme chaque
transformation peut être effectuée par un ou plusieurs services d’adaptation, nous sommes
amenés à rechercher un scénario d’adaptation optimal. Pour ce faire, l’ensemble des
compositions de services possibles sont modélisées sous la forme d’un graphe, un scénario
d’adaptation correspondant à un chemin de la racine à l’extrémité du graphe. Ce « graphe
d’adaptation » est construit par le module « Générateur de graphes d’adaptation multimédia »
(Multimedia Adaptation Graph Generator - MAGG) et exécuté par le proxy local.
16
5.2.1.1 Définitions et notations utilisées dans MAGG
Définition 1 : Objet média.
Un objet média est une donnée multimédia qui peut être un texte, une image, un son ou une
vidéo. Il est représenté par
M (m1, m2, …, mn)
où m1, m2, …, mn désignent des propriétés du média ou des métadonnées.
Définition 2 : État d’un objet média.
L’état S d’un objet média M, noté S (M), est décrit par les valeurs courantes des métadonnées
caractérisant l’objet M.
Exemple : Pour un objet-image, l’état comporte les valeurs du format, de la couleur, de la
hauteur, de la largeur, etc. Ex :
S(M) = (bmp, 24 bits, 245 pixels, 300 pixels).
Définition 3 : Tâche d’adaptation.
Une tâche d’adaptation est une expression de la forme t(α1 α2 … αn) où t est une
transformation et α1, α2, …, αn, sont les paramètres de la transformation t.
Exemple : ImageFormatConversion(imageIn, imageOut, oldFormat, newFormat)
avec :
imageIn : fichier-image en entrée,
imageOut : fichier-image en sortie,
oldFormat : ancien format de fichier,
newFormat : nouveau format de fichier.
Proposition d’une architecture d’adaptation de contenu orientée service
17
Définition 4 : Service d’adaptation.
Un service d’adaptation est un service décrit en termes d’entrées, de sorties, de pré-conditions
et d’effets. Il est dénoté par s = (R I O Pre Eff Q)
avec :
R : processus qui effectue une tâche d’adaptation,
I : paramètres d’entrée du processus,
O : paramètres de sortie du processus,
Pre : pré-conditions du processus,
Eff : effets du processus,
Q : critères de qualité du service.
Définition 5 : Opérateur (opérateur de plan d’adaptation).
Un opérateur de plan d’adaptation est une expression de la forme o = (h (a1, a2, …an, b1, b2,
…bm), Pre Eff Q)
avec :
h : tâche d’adaptation réalisée par un service d’adaptation ayant pour paramètres d’entrée a1,
a2, …, an et pour paramètres de sortie b1, b2, …, bm. h est appelé l’entête de l’opérateur.
Pre : pré-conditions de l’opérateur.
Eff : effets de l’exécution de l’opérateur.
Q = {q1, q2,…, qn}: critères de qualité (par exemple : coût, temps, etc.).
Un opérateur représente de manière abstraite un service d’adaptation qui réalise une tâche
d’adaptation. Les opérateurs sont utilisés (cf. paragraphe ci-dessous) pour construire des
graphes d’adaptation.
Soit S un état, t une tâche d’adaptation et M un objet média. Soit o un opérateur d’entête h qui
réalise t tel que Pre de o est satisfait dans S. Alors on dit que o est applicable à t et le nouvel
état est donné par :
S ( M o ) = Executing (o, M , S )
18
Exemple : Pour la tâche d’adaptation mentionnée ci-dessus (cf. déf. 3), on peut rencontrer
une instance d’opérateur comme suit :
Opérateur : ImageFormatConversionOperator (http://mediaadaptation/imagefiles/image1, http:// media-adaptation/imagefiles/image2,
mpeg, bmp)
Entrée : http://media-adaptation/imagefiles/image1, mpeg, bmp
Sortie : http:// media-adaptation/imagefiles/image2
Pré-condition : hasFormat (http://media-adaptation/imagefiles/image1,
mpeg)
Effet : hasFormat (http:// media-adaptation/imagefiles/image2, bmp)
Q (qualité) : (cost=30 units, time=100 ms)
Note :
Une tâche d’adaptation t peut être réalisée par plusieurs opérateurs. Les attributs de qualité Q
sont utilisés pour déterminer un scénario (appelé également plan ou chemin) optimal.
Définition 6 : Graphe d’adaptation.
Un graphe d’adaptation G (V, E) est un graphe orienté acyclique (Directed Acyclic Graph DAG) dans lequel :
V, ensemble des nœuds, représentent des opérateurs d’adaptation ;
E, ensemble des arcs, représentent les compositions possibles entre les opérateurs
d’adaptation.
Le nœud initial A ∈ V est un pseudo-opérateur avec effet (état initial) mais sans précondition.
Le nœud terminal Z ∈ V est un pseudo-opérateur avec pré-condition (état final) mais sans
effet.
Remarque :
Soient oi ∈ V et oj ∈ V. Une liaison ou un arc eij existe de oi vers oj si la condition suivante
est satisfaite :
oj.Pre ⊆ oi.Eff
où :
Proposition d’une architecture d’adaptation de contenu orientée service
19
oj.Pre dénote les pré-conditions de oj ;
oi.Eff dénote les effets de oi.
Définition 7 : Problème de planification d’adaptation.
Un problème de planification d’adaptation est un 4-uplet (SA, SZ, T, D) où SA est l’état initial
de l’objet média, SZ est l’état final de l’objet média, T est une liste (particulière) de tâches
d’adaptation et D est la liste (complète) des opérateurs d’adaptation disponibles. Le résultat
est un graphe G = (V, E).
5.2.1.2 Algorithme
Pour construire le graphe d’adaptation, nous avons d’abord besoin de traduire les descriptions
des services en opérateurs d’adaptation. Dans ce but, nous avons utilisé un analyseur XML
qui prend en entrée le fichier de description d’un service et qui crée l’opérateur d’adaptation
correspondant (cf. chapitre 6).
Disposant des opérateurs d’adaptation, nous avons développé l’algorithme MAGG
(Multimedia Adaptation Graph Generator) qui génère le graphe d’adaptation (cf. ci-dessous).
Algorithm: graph (SA, SZ, T, D)
Input: Initial state SA, final state SZ, adaptation task list T and adaptation operators D
Output: an adaptation graph G (V, E)
// Global constant
// Limit
maximum number of neutral operators allowed in a connection
// Global variables
// V
a set of nodes in a graph
// E
a set of edges in a graph
// ao
start node
// zo
end node
// NO
a set of neutral operators available in the system
// Local variables
// T
a set of adaptation tasks
// t
an adaptation task element of T
20
// O
a set of nodes for adaptation operators realizing an adaptation task
// PO
a set of parent nodes
// Pz
a set containing the end node
var
V, E, T, t, O, PO, ao, zo, Pz, NO
begin
ao= ConstructStartNode(SA) // constructs the start node from the initial state
zo= ConstructEndNode(SZ) // constructs the end node from the goal state
NO= ConstructNeutralOperators( ) // returns the list of the neutral operators available in
//the system
V= {ao} //initialization
E= Ø
//initialization
PO= {ao}//initialization
for each t ∈ T
begin
Construct nodes O from D with operators realizing t
//several operators can realize a task
Connect(O, PO)
//after the process PO holds the value of O
end //T is processed
Pz={zo}
Connect(Pz, PO) // connects the end node
return G (V, E)
end // graph
---------------------------------------------------------------------------------------------------------------// procedure Connect: connects child nodes (O) with parent nodes (PO)
// O a set of nodes-input variable
// PO a set of nodes-input and output variable
---------------------------------------------------------------------------------------------------------------procedure Connect(in O, inout PO)
Proposition d’une architecture d’adaptation de contenu orientée service
//Local variables
// CO a set of nodes-temporal variable used to store child nodes (O)
// TPO a set of nodes-temporal variable used to store parent nodes (PO)
// CPO a set of nodes-temporal variable used to store connected parent nodes
// po a node in PO
// o a node in O
// UNO a set of operators-variable to store already used neutral operators
// Link a Boolean variable to check if a node has a connection
// Connected a Boolean variable, true if a node is connected by neutral operator
// LimitC an integer- number of neutral operators in a connection
//Notations
// po.Pre preconditions of node po
// po.Eff effects of node po
// o.Pre preconditions of node o
// o.Eff effects of node o
var
CO, TPO, CPO, UNO, o, po, LimitC, Link, Connected
begin
CO= Ø
//initialization
CPO= Ø //initialization
Link = false
// connect each o ∈ O with each node of the parent nodes PO
for each o ∈ O
begin
for each po ∈ PO
begin
if (o.Pre ⊆ po. Eff) then // direct connection of node o with node po
begin
if(o∉ V) then
begin
21
22
V= V ∪ {o}
end
E= E ∪ {(po, o)}
Link = true // o is connected in the graph
end
else // for indirect connection of node o with po using neutral operators
begin
LimitC=0
UNO= Ø
Connected=ConnectWithNeutralOperators (o, po, LimitC, UNO)
Link=Link or Connected // Link is true if o has at least one connection
// if po is connected add it to the connected parent nodes list
if (Connected) then
CPO=CPO ∪ {po}
end
end // PO is processed
if (not Link) then // checks if o has at least one direct or indirect connection
begin
if(o=zo) then // it is the end node so the graph construction fails
begin
V= Ø
E= Ø
return
end
else
O=O-{o}// o can not be connected so remove it
end
end // O is processed
// remove parent nodes which have no connection
for each po ∈ PO
begin
if (po ∉ CPO ) then
Proposition d’une architecture d’adaptation de contenu orientée service
23
begin
V=V-{po}
for each (x, po) ∈ E
begin
E=E-{(x, po)}
Remove(x) // removes x with its ancestors
end
end
end
PO= O //child nodes become parent nodes for the next process
end // end connect procedure
---------------------------------------------------------------------------------------------------------------// function ConnectWithNeutralOperators it connects o and op using neutral operators
//recursively
// o a node- input variable
// op a node- input variable
//LimitC an integer- input variable
// UNO a set of nodes- input and output variable
---------------------------------------------------------------------------------------------------------------function Boolean ConnectWithNeutralOperators (in o, in op, in LimitC, inout UNO)
//Local variables
// TNO a set of operators-a temporal variable for neutral operators
// TE a set of edges-a temporal variable to store connectable edges
// TV a set of nodes-a temporal variable to store connectable nodes
// no a node
var
TNO, TE, TV, no
begin
TNO=NeutralOperators(o, UNO)// it returns neutral operators connectable with o
for each no ∈ TNO
begin
if (no.Pre ⊆ op.Eff) then
24
begin
TE= TE ∪ {(op, no)}
TE= TE ∪ {(no, o)}
TV= TV ∪ {no}
TV= TV ∪ {o}
E= E ∪ TE
V= V ∪ TV
return true
end
else
begin
TE= TE ∪ {(no, o)}
TV= TV ∪ {no}
TV= TV ∪ {o}
if (LimitC+ 1=Limit) or (UNO ∪ {no}=NO) then //terminating condition
return false
else
return ConnectWithNeutralOperators(no, op, LimitC+1, UNO ∪ {no})
end
end // TNO is processed
end // ConnectWithNeutralOperators
---------------------------------------------------------------------------------------------------------------// function NeutralOperators returns the set of neutral operators satisfying the preconditions
//of o
// o a node-input variable
// UNO a set of nodes- input variable
---------------------------------------------------------------------------------------------------------------function Operators NeutralOperators(in o,in UNO)
//Local variables
// TNO a set of operators-temporal variable for neutral operators
// no a node
//Notations
Proposition d’une architecture d’adaptation de contenu orientée service
25
// o.Pre preconditions of node o
// no.Eff effects of node no
var
TNO, no
begin
TNO= Ø
for each no ∈ NO
begin
if (o.Pre ⊆ no.Eff) then
if (no ∉ UNO) then
TNO=TNO ∪ {no}
end
return TNO
end // NeutralOperators
---------------------------------------------------------------------------------------------------------------// procedure Remove it removes the node x recursively until it finds a node with a branch
//connection or it reaches the start node
// x a node- input variable
---------------------------------------------------------------------------------------------------------------procedure Remove(in x)
//Local variables
// z a node for which (z, x) is an edge in E
// y a node for which (x, y) is an edge in E
var
z, y
begin
if (x=ao) then // it is the start node make V empty and return
begin
V= Ø
26
return
end
else if ((y ∈ V) and ((x, y) ∈ E)) then // x has a branch connection
begin
return
end
else
begin
for each (z, x) ∈ E
begin
E=E-(z, x)
Remove(z)
end
V=V-{x}
end // each (z, x) is processed
end //Remove
5.3
Recherche d’un chemin /plan d’adaptation optimal
Définition : Plan /chemin d’adaptation.
Un plan (ou chemin) d’adaptation est un chemin dans le graphe d’adaptation G qui relie le
nœud initial au nœud terminal. Il est représenté par une liste de la forme p = (A o1 o2 … on Z)
où
A et Z sont les nœuds initial et terminal et oi est une instance d’opérateur d’adaptation.
Si p = (A o1 o2 … on Z) est un plan et que S est un état, alors S(p) est l’état de l’objet média
produit suite à l’exécution de la suite ordonnée d’opérateurs o1, o2, …, on sur l’objet média en
entrée.
Un plan d’adaptation est caractérisé également par une qualité.
27
Proposition d’une architecture d’adaptation de contenu orientée service
Modèle de qualité de service (QoS)
Comme une tâche d’adaptation peut être accomplie par plus d’un service, le choix d’un
service n’est pas neutre. Une fois que le graphe d’adaptation, qui modélise toutes les
compositions possibles, est généré, le choix de la meilleure alternative, c’est-à-dire du
chemin optimal dans le graphe, est fait sur la base des critères de QoS spécifiés par
l’utilisateur. Le modèle de QoS de base que nous utilisons s’appuie sur deux critères : le
temps de réponse du service et son coût.
Soit p = (A s1 s2 … sN Z) un chemin dans le graphe d’adaptation où N est le nombre de
services. On définit la QoS du chemin, dénotée par Q(p), par :
Q( p) = (QCOST ( p), QTIME ( p ))
(1)
où
QCOST ( p ) désigne le coût total du chemin,
QTIME ( p ) désigne le temps total d’exécution du chemin.
avec
QCOST ( p ) défini par
N
QCOST ( p ) = ∑ QCOST ( s i )
i =1
(2)
où
QCOST ( si ) désigne le coût intégrant l’exécution du service d’adaptation et la
transmission des données.
et
QTIME ( p ) défini par
N
QTIME ( p) = ∑ QTIME ( s i )
i =1
(3)
28
où
QTIME ( si ) désigne la somme du temps d’exécution du service d’adaptation et du
temps de transmission des données.
Pour agréger ces valeurs quantitatives hétérogènes, il est nécessaire de les ramener sur une
échelle unique (scaled values).
QsCOST ( s i ) et QsTIME ( s i ) sont ainsi définies par :
max
⎧ QCOST
− QCOST ( si )
⎪
max
min
QsCOST ( s i ) = ⎨ QCOST
− QCOST
⎪
1
⎩
max
min
if QCOST − QCOST ≠ 0
min
Q max − QCOST
=0
if COST
max
⎧ QTIME
− QTIMe ( s i )
max
min
⎪
if QTIME − QTIME ≠ 0
max
min
QsTIME ( si ) = ⎨ QTIMe − QTIME
max
min
QTIME
− QTIME
=0
⎪
1
if
⎩
(4)
(5)
où
max
min
QCOST
et QCOST sont les valeurs respectives de coûts maximum et minimum et
max
min
QTIME
et QTIME sont les valeurs respectives de temps maximum et minimum.
Note : Les valeurs maximum et minimum sont calculées à partir des services disponibles.
Les utilisateurs peuvent indiquer leurs préférences sur la QoS (ex : choix d’un service rapide
vs choix d’un service peu coûteux) en spécifiant des valeurs de pondération sur chaque
critère. Le score d’un chemin avec des valeurs pondérées s’établit ainsi comme suit :
N
Score( p ) = ∑ (QsCOST ( si ) ∗ wCOST + QsTIME ( si ) ∗ wTIME )
i =1
(6)
où wCOST ∈ [0, 1] et wTIME ∈ [0, 1] représentent les valeurs de poids affectées
respectivement au coût et au temps avec
wCOST + wTIME = 1
(7)
Proposition d’une architecture d’adaptation de contenu orientée service
29
Soit Pset = {p1, p2, …, pK} l’ensemble de tous les chemins possibles dans un graphe
d’adaptation. Alors le chemin optimal est le chemin dont la valeur du score est maximale.
Cette valeur, dénotée scoremax, est définie comme suit :
Scoremax = max {Score( pi )}
iε {1, K }
(8)
Alors que l’algorithme de Dijkstra [Dijkstra59] peut être directement appliqué pour trouver le
chemin optimal, l’algorithme peut être rendu plus efficace pour un graphe orienté acyclique
(ce qui est le cas du graphe d’adaptation) en effectuant un tri topologique du graphe.
Le temps d’exécution pour l’implémentation la plus simple de l’algorithme de Dijkstra est en
O (|V|2). Avec un tas binaire, l’algorithme requiert un temps en O ((|E|+|V|) log (|V|)) ; un tas
de Fibonacci améliore ce temps en O (|E| + |V|log (|V|). Enfin, l’algorithme appliqué à un
graphe trié topologiquement présente un temps d’exécution en O (|E|+|V|). Il est décrit en
Annexe D.
5.4
Evaluation de performances
Deux principaux tests de performance ont été conduits. Le premier visait à étudier l’impact
du ré-ordonnancement des transformations sur le temps total d’exécution. Des services
d’adaptation ont été publiés sur un PC intégrant deux processeurs Pentium 4 à 3.00 GHz,
2.00 Go de mémoire vive et l’édition standard du système d’exploitation Microsoft Windows
Server 2003. Nous avons utilisé des images JPEG de taille 570x760 pixels. Afin de
minimiser l’effet de la variation de la charge du système, l’expérience a été répétée et la
moyenne des résultats a été considérée. Nous avons observé que les différents ordres
d’exécution de services d’adaptation ont produit différents temps d’exécution. Si on met le
service de réduction de couleur en dernier il produit un meilleur résultat comparé aux autres
ordres. Dans la légende R est la redimensionnent de taille, F est la conversion de format et C
est la réduction de couleur. Donc, le meilleur ordre d’exécution est RFC (redimensionnent de
taille, conversion de format, réduction de couleur). La résultat de cette expérience est décrit
Figure 7.
30
Temps d’exécution (100
ms)
Comparaison d’ordre d'exécution des
transformations
50
RFC
40
CFR
30
FRC
20
RCF
CRF
10
FCR
0
32
42
43,3 43,9 45,7 49,4 52,6 56,7 74,4
Taille d’image (Kb)(570*760 pixels)
Figure 7: Comparaison de différents ordres d'exécution
La seconde expérience (Figure 8) étudiait le comportement de l’algorithme de génération du
graphe d’adaptation par rapport à la profondeur du graphe et au nombre de services par
transformation. Elle a été réalisée sur une machine disposant d’un processeur Pentium 4
cadencé à 1.9 GHz, avec 256 Mo de mémoire vive et équipé du système d’exploitation
Microsoft Windows 2000. Alors que la relation entre la construction du graphe et le nombre
de services par transformation est linéaire, comparativement à la profondeur du graphe, le
temps de construction progresse lentement avec le nombre de services par transformation.
Nous avons également observé que la pente pour la profondeur et la largeur (nombre de
services par transformation) était quasiment constante avec une augmentation moyenne de 40
ms pour chaque profondeur et de 10 ms pour chaque tranche additionnelle de 10 services.
Cela signifie que le nombre de services par transformation n’affecte pas significativement le
temps total de construction, tandis que cela permet de choisir le meilleur service parmi les
services candidats. Par exemple, pour 300 services (profondeur de 10 et largeur de 30) dans
un graphe, configuration extrême d’une adaptation réaliste, le temps total de construction
n’est que de 335 ms - résultat en pratique très acceptable.
31
Implémentation du prototype
Temps(ms)
Temps de construction du graphe
400
350
300
250
200
150
100
50
0
10 Services par
transformation
20 Services par
transformation
30 Services par
transformation
2
3
4
5
6
7
8
9
10
Profondeur du graphe (# des
transformations)
Figure 8: Temps de construction du graphe
6.
Implémentation du prototype
Nous avons développé un prototype de l’architecture logicielle DCAF (cf. section 5 Figure 6
ci-dessus) afin de montrer la faisabilité et la validité de nos propositions. Le prototype a été
implémenté avec Borland Jbuilder 9 personal. Nous avons utilisé MySQL-4.0.12 pour les
différentes bases de données mises en œuvre dans le prototype. Le paquetage logiciel
comprend plus de 10 000 lignes de code.
6.1
Composants du prototype
Notre prototype intègre les fonctionnalités principales suivantes :
Moteur de décision d’adaptation : un moteur de décision analysant les contraintes
contextuelles et les préférences utilisateur est chargé de la construction du graphe
d’adaptation et du calcul d’un chemin optimal d’adaptation.
32
Proxys : Trois types de proxys ont été développés. Des proxys de contenu chargés de la
gestion des serveurs de contenus distribués et des métadonnées décrivant les contenus ont été
implémentés. Des bases de données MySQL ont été déployées pour le stockage des contenus
et des métadonnées. Des proxys locaux qui constituent le cœur de l’architecture ont été mis
en place. Le moteur de décision d’adaptation et d’autres fonctionnalités cruciales font partie
intégrante de ces proxys. Enfin, nous avons implémenté des proxys (services) d’adaptation.
Ceux-ci ont été programmés en tant que services Web afin de montrer la faisabilité
d’adaptations complexes à partir de services tiers. C# et ASP.NET ont été utilisés pour
développer ces services.
Annuaires de services d’adaptation : Pour la découverte de services d’adaptation, des
annuaires ont été mis en place afin de stocker les informations relatives aux services
disponibles. Ces annuaires ne s’intéressent qu’aux services d’adaptation. Les fournisseurs de
services d’adaptation peuvent publier la description de leurs services dans ces annuaires que
les proxys locaux viennent consulter en fonction des besoins d’adaptation.
Répertoire de profils client : Ce répertoire stocke les profils client. Un profil client consiste
en les préférences de l’utilisateur, les caractéristiques et capacités des dispositifs et la
connexion au réseau. Alors que, dans le prototype, le profil client est créé lors de la
souscription d’un utilisateur et que ce profil peut être modifié à tout moment, dans une
application réelle, le système récupérerait le profil du terminal à partir de son identifiant dans
les bases de données mises à disposition par le vendeur du dispositif ; le profil réseau est
connu en utilisant les informations de contrôle du réseau. Une base de données MySQL a été
utilisée pour stocker les informations du compte utilisateur ainsi que son profil.
L’élément au cœur du mécanisme d’adaptation est le proxy local.
33
Implémentation du prototype
Interface module
Content Negotiation & Adaptation Module
Context Profile and
Metadata Processor
Adaptation Plan Generator
Communication module
Client Profile agent
Adaptation service agent
Service discovery
Service invocation
Figure 9: Schéma fonctionnel du proxy local
Le schéma fonctionnel de la Figure 9 présente les composants du proxy local, ainsi que les
interactions et les flux d’information entre ces composants. Un proxy local est composé de
cinq éléments principaux : un module de négociation et d’adaptation de contenu, un agent de
profils, un agent de services d’adaptation, un module de communication et un module
d’interface :
Le module d’interface est utilisé pour communiquer avec l’utilisateur. Quatre interfaces
sont définies : une interface de connexion, une interface de saisie de requêtes, une
interface d’affichage des résultats et une interface de saisie/mise à jour du profil
utilisateur. L’interface de connexion sert à la saisie de l’identifiant utilisateur et de
son mot de passe nécessaires pour l’accès au système. L’interface de requêtes permet
de formuler les requêtes de contenu. L’interface de saisie/mise à jour du profil
utilisateur permet l’ajout et la modification du profil client. L’interface d’affichage
des résultats est chargée de la présentation du contenu après adaptation.
Le module de communication est utilisé pour les communications avec les proxys de
contenu. Deux types de données sont échangés entre le proxy local et les proxys de
contenus : des métadonnées et du contenu. Le proxy local envoie au proxy de
34
contenus une requête pour le serveur de contenus ; le proxy de contenus fait parvenir
la réponse du serveur de contenus (des métadonnées) au proxy local. L’utilisateur
choisit un contenu parmi les réponses et en informe le proxy local qui retransmet cette
requête vers le proxy de contenus. Ce dernier demande au serveur de contenus de lui
envoyer les données demandées puis transfère celles-ci au proxy local. L’ensemble
des proxys sont programmés en tant que services Web et SOAP est utilisé comme
protocole de communication.
L’agent de profil est chargé de stocker et récupérer le profil client à partir du répertoire
de profils. Quoique dans notre prototype un seul répertoire de profils client est
déployé, dans une application réelle plusieurs répertoires peuvent exister ; par
exemple, les répertoires de profils matériel des distributeurs. Ceux-ci sont d’ailleurs
susceptibles d’implémenter différents protocoles de communication, ce qui peut
constituer une source de problèmes d’interopérabilité. Nous avons choisi SOAP,
protocole largement répandu, comme protocole de communication entre le proxy
local et les répertoires de profils.
L’agent de service d’adaptation a deux composants : le module de découverte de
services d’adaptation et le module d’invocation de services d’adaptation. Le module
de découverte de services d’adaptation a pour rôle d’identifier tous les services
d’adaptation pertinents enregistrés dans l’annuaire de services. Le module
d’invocation de services d’adaptation est chargé d’invoquer les services distants en
fonction du plan optimal d’adaptation. Dans les deux modules, le protocole de
communication choisi est SOAP.
Le module de négociation et d’adaptation de contenu est la partie centrale du proxy
local. Ces deux principaux composants sont : le processeur de profils et métadonnées
de contexte et le générateur de plan d’adaptation. Le processeur de profils et
métadonnées de contexte est chargé d’analyser et de décider du nombre et des types
de transformation nécessaires pour adapter le contenu en tenant compte des
contraintes et caractéristiques du contexte, des préférences utilisateur et du contenu. Il
établit une règle de transformation (voir chapitre 6, Figure 6.13). Le générateur de
plan d’adaptation prend en entrée cette règle de transformation, construit le graphe
35
Implémentation du prototype
d’adaptation puis génère un plan optimal d’adaptation. Ce plan est alors transmis au
module d’invocation de services d’adaptation.
6.2
Bases de données utilisées dans le prototype
Quatre principales bases de données ont été développées dans le prototype : le répertoire de
profils client, l’annuaire des services d’adaptation, une base de contenus et une base de
métadonnées. Le répertoire des profils stocke les informations relatives aux utilisateurs telles
que le nom, l’identifiant, le mot de passe et un lien vers le fichier du profil contextuel
(CSCP). L’annuaire des services d’adaptation stocke les informations relatives aux services
d’adaptation telles que les identifiants et le lien vers le fichier de description de service
(OWL-S). La base de contenus héberge les données d’application et les contenus
téléchargeables par l’utilisateur. Enfin, la base de métadonnées accueille les informations de
recherche sur le contenu et un lien vers le fichier MPEG-7 associé à chaque contenu Les
bases de données sont déployées sous MySQL-4.0.12.
L’architecture DCAF d’adaptation de contenus multimédias est générique et indépendante du
domaine applicatif et des configurations matérielle et réseau. Cependant, dans le but de
valider concrètement nos concepts et propositions, nous avons développé une implémentation
typée de DCAF pour une application médicale, domaine d’application privilégié de l’équipe.
Notre base de données stocke ainsi des modèles de dossiers médicaux. Le modèle conceptuel
de données utilisé dans le prototype est donné Figure 10. Les tableaux suivants décrivent les
champs des différentes tables.
Hospital
Champ
Description
HCode
Identificateur unique de l’hôpital
Name
Nom de l’hôpital
Address
Adresse de l’hôpital
Section
Liste des services de l’hôpital
36
PatientData
Champ
Description
PatientID
Identificateur unique du patient
FirstName
Prénom
LastName
Nom de famille
DateOfBirth
Date de naissance
Address
Adresse
MedicalRecord
Champ
Description
MedRecId
Identificateur unique
PatientID
Identificateur unique du patient
DocId
Identificateur unique du document
Title
Titre du document
Description
Description du contenu du document
Keywords
Mots-clés décrivant le document
MedicalDoc
Champ
Description
MedDocId
Identificateur unique
DocId
Identificateur du document
MediaObject
Champ
Description
MediaId
Identificateur unique de l’objet média (contenu)
MedDocId
Identificateur unique
MediaType
Type du contenu
Title
Titre du contenu
Description
Description du contenu
Language
Langue du contenu
MetaDataLoc
Adresse URL du fichier de métadonnées
37
Implémentation du prototype
MedicalRecord
Hospital
PK
PK
HospCode
Name
Address
Section
PatientData
MedRecId
PK
1:1
N:1
PatientID
DocID
Title
Description
Keywords
HospCode
N:1
1 :1
PatientID
FirstName
LastName
DataOfBirth
Address
1:1
MediaObject
PK
1:1
MedicalDoc
PK
1:1
N:1
MedDocId
DocId
MediaID
MedDocId
MediaType
Title
Description
Language
MetaDataLoc
Figure 10: Modèle conceptuel des données
6.3
Interfaces visuelles
Plusieurs interfaces visuelles ont été développées pour la communication entre le système et
l’utilisateur : interface de connexion, interface de saisie de profils, interface de saisie de
requêtes et interface de présentation des résultats. Nous présentons ci-dessous les interfaces
de saisie de profil et d’affichage de résultats qui sont les plus significatives.
6.3.1 Interface de saisie du profil client
L’interface de saisie du profil client (Figure 11) est composée de trois panneaux : le panneau
de sélection du type de terminal, le panneau de spécification du réseau et le panneau de saisie
des préférences de l’utilisateur (cf. chapitre 7 pour le détail de chaque panneau).
L’organisation de l’interface de saisie est basée sur la structure de représentation du profil
client (cf. Annexe A). L’interface permet de capturer l’ensemble des informations du profil
client.
38
Figure 11: Capture d’écran de l’interface de sélection du matériel.
6.3.2 Interface d’affichage de données adaptées
Dans un système pervasif, l’adaptation revêt deux principaux aspects : adaptation des
données/du contenu et adaptation de l’interface utilisateur. Notre travail s’est focalisé sur
l’adaptation de contenu. L’adaptation et la gestion de l’interface utilisateur dans un
environnement pervasif constitue un domaine de recherche à part entière qui nécessite un
approfondissement ne faisant pas l’objet de cette thèse. Comme la présentation de
l’information à l’utilisateur requiert à la fois une adaptation de contenu et de l’interface, nous
avons collaboré avec une autre équipe de recherche du laboratoire qui travaille sur un projet
d’adaptation d’interfaces appelé SEFAGI (Simple Environment for Adaptable Graphical
Interfaces) [Chaari05]. Le système SEFAGI fournit un environnement qui permet la
description des interfaces utilisateur spécifiées en utilisant un langage abstrait de description
des fenêtres, un langage de description de plate-forme et des mécanismes de génération
automatique de code.
Notre collaboration avec le projet SEFAGI nous a permis de disposer d’un système complet
d’adaptation qui délivre des informations médicales adaptées au contexte de l’utilisateur en
termes de contenu et d’interface. Comme le système SEFAGI est en phase de développement,
nous avons généré uniquement des interfaces pour les PC et les Smartphones à des fins de
test (voir Figures 12 (a) et (b)). Nous sommes en cours de rédaction d’un article pour une
revue sur les résultats de cette collaboration. Nous espérons poursuivre ce travail commun.
Implémentation du prototype
Figure 12 (a) : Capture d’écran d’une donnée-image sur un PC standard (sans adaptation).
Figure 12 (b) : Capture d’écran d’une donnée-image sur un Smartphone (après adaptation).
39
40
7.
Conclusion et perspectives
S’appuyant sur les progrès récents dans le monde de la communication sans fil et des
technologies mobiles, les environnements pervasifs (ou ubiquitaires) suscitent un intérêt
croissant. Cependant les limitations liées aux ressources des terminaux mobiles et aux
capacités des réseaux sans fil, l’hétérogénéité des terminaux et des données, la variabilité des
conditions réseaux, la multiplicité des demandes et des préférences utilisateurs génèrent des
problèmes que les systèmes multimédias distribués classiques ne traitent qu’imparfaitement.
L’adaptation des contenus (données) transmis(es) aux utilisateurs offre un cadre de solution à
ces problématiques nouvelles.
Dans ce cadre, les principales contributions de cette thèse sont les suivantes :
• Nous avons introduit une nouvelle architecture répartie d’adaptation de contenu
multimédia fondée sur l’utilisation de services tiers (architecture DCAF). Cette
architecture est très facilement extensible en termes fonctionnels (intégration de
nouveaux services d’adaptation) et non-fonctionnels (passage à l’échelle).
L’interopérabilité de cette architecture avec les services d’adaptation est garantie via
l’utilisation de protocoles et de modèles de description standards (e.g. SOAP, XML,
MPEG-7).
• La technologie des services Web est considérée comme étant une solution appropriée
pour l’informatique distribuée, en particulier pour Internet. Son application à
l’informatique pervasive, notamment pour l’adaptation de contenu, a été explorée
dans cette thèse.
• Nous avons proposé une définition et une description formelles du processus
d’adaptation de contenu multimédia (e.g. concepts d’opérateur et de graphe
d’adaptation).
• Nous avons spécifié une ontologie pour la description de services d’adaptation
multimédia. Cette ontologie permet une description sémantique des services, qui
facilite la découverte, la composition et l’exécution automatiques de services
d’adaptation.
• L’approche proposée est fondée sur la composition de services d’adaptation. Une
méthodologie d’optimisation de compositions de services a été proposée.
Conclusion et perspectives
41
• Enfin, un prototype a été réalisé pour évaluer nos propositions. Des expérimentations
ont été menées avec ce prototype qui ont montré la faisabilité et la pertinence de
l’approche proposée.
Nos perspectives se déclinent comme suit :
• Dans cette thèse, des mécanismes distincts de représentation sont utilisés pour décrire
le contexte (utilisateur, matériel, réseau), le contenu et les services d’adaptation.
Cependant, l’interopérabilité du système pourrait être renforcée par la construction
d’une ontologie unifiée et globale. Cette ontologie unifiée admettra des ontologies de
haut et bas niveaux (parente et enfant). L’ontologie parente (de haut niveau) sera
chargée de capturer la connaissance générale sur le monde physique dans les
environnements pervasifs. L’ontologie enfant (de bas niveau) capturera l’information
relative à chaque composant (par exemple : les services d’adaptation).
• Dans l’implémentation actuelle, l’algorithme MAGG prend en considération le format
des données d’entrée et de sortie pour l’analyse de la compatibilité de service. Mais
d’autres paramètres, comme la taille des données et/ou le taux de rafraîchissement
d’une séquence vidéo, sont aussi importants. L’algorithme devrait idéalement tenir
compte de tous les paramètres dans la détermination de la compatibilité des services.
Cela peut être implémenté en modifiant la partie de l’algorithme qui effectue la
correspondance entre les pré-conditions et les effets. Au lieu de ne manipuler qu’un
seul paramètre, l’algorithme vérifiera tous les paramètres.
• À un certain niveau d’abstraction, les systèmes pervasifs et les grilles se rapportent
tous les deux à des unités de traitement distribuées et à grande échelle. La
combinaison des deux aspects, au sein de ce qu’on peut appeler la grille pervasive
[Pierson05], peut favoriser l’essor de la grille de calcul dans le monde réel. Une grille
pervasive est une architecture orientée services. . Notre proposition d’adaptation de
contenu basée sur des services s’inscrit donc parfaitement dans cette orientation. Dans
ce contexte, nous envisageons de déployer les services d’adaptation multimédia
comme des services de grille pour fournir des données multimédias adaptées dans des
environnements de grille pervasive.
Le système de proxy implémenté est, à notre connaissance le premier prototype visant à
étudier l’adaptation de contenu dans un environnement pervasif. Plusieurs axes
42
d’amélioration sont envisageables. La liste suivante expose les limites et les travaux futurs
relatifs au prototype :
• Notre moteur de décision n’utilise pas de « conseils d’adaptation » lors de la décision
des types d’adaptation à implémenter. Par exemple, un fournisseur de contenu peut
vouloir spécifier par le biais des métadonnées liées au contenu la liste restrictive des
adaptations autorisées sur ses données. Les « conseils d’adaptation » peuvent ainsi
limiter ou faciliter la prise de décision.
• Notre prototype implémente une stratégie simple de gestion de cache de contenus
adaptés. Pour leur part, les profils de contexte ne sont pas cachés (ce qui amène le
proxy local à récupérer le profil auprès du répertoire de profils à chaque nouvelle
requête). Il est clair qu’il serait tout à fait pertinent de mettre en place des mécanismes
de gestion de cache (cache de contenus, cache de contextes) plus évolués.
Y. Cardenas, doctorant au sein de l’équipe, s’intéresse aux caches coopératifs dans un
environnement de grille [Carden05]. Son travail s’attache au développement d’un grid
service de cache virtuel (agrégation de multiples caches répartis sur une grille). Nous
comptons rapidement étudier l’intégration de ce service dans notre système.
• Enfin, nous envisagerons le développement de plus nombreuses interfaces à
destination de plusieurs terminaux potentiels en sus de ceux actuellement utilisés dans
le prototype (la collaboration avec le projet SEFAGI).
Chapter
1
Introduction and Motivation
In this chapter, we motivate the need of content adaptation for pervasive computing
environments. In Section 1.1, we present a brief historical of the development of information
technology with a particular emphasis on multimedia information and its major application
areas. In Section 1.2 we give a general definition of pervasive computing and of its major
characteristics. In Section 1.3, we present the need of content adaptation for pervasive
computing environments. Three driving scenarios that illustrate situations in which content
adaptation is desirable are presented in Section 1.4. A Short overview of our proposed content
adaptation approach is presented in Section 1.5. Finally we present the organization of the
thesis in Section 1.6.
1.1 Introduction
Human society has passed through different development ages, defined by the dominant
technology of that particular age, each with profound impacts on the way the society lives,
works and communicates. In the course of technological ascent, society has traversed the
Stone Age, Bronze Age, Iron Age, Agrarian Age, Industrial Age, and most recently - the
Information Age [Aspy93].
Information Age is a term applied to the period where the movement of information became
faster than the physical movement, more narrowly applying to the 1980s onward. One could
argue, though, that it actually began during the latter half of the 19th Century with the
invention of the telephone and telegraphy [Manu04]. Advocates of the concept of the
Information Age maintain that we have embarked on a journey in which information and
2
Chapter 1. Introduction and Motivation
communications will become the dominant forces in defining and shaping human actions,
interactions, activities, and institutions. In contrast to the Industrial Age that proceeded this
era, information is rather than natural resources or capital -- has become the strategic
resource upon which the economy revolves. Information has been defined in innumerable
ways. One definition offered by the American Library Association [List02] is:
"All ideas, facts, and imaginative works of the mind which have been communicated,
recorded, published and/or distributed formally or informally in any format".
Under this broad definition, information is everything that has been created or studied by the
human mind and recorded and communicated in some way. Since the start of civilization,
humans have found ways to record, store, and communicate what they have discovered and
created. In fact, human progress would not have been possible without all of the ingenious
ways humans have recorded, transmitted, stored, retrieved, and used information.
Before the invention of writing, humans depended entirely on the spoken word to record
thoughts and ideas. Known as the oral tradition, this was the process by which "culture,
tradition, and historical accounts were passed from generation to generation in stories,
folklore, songs, and poetry" [Bolner01]. But after writing evolved into the phonetic stage,
completed with symbols and alphabets, it was common for information to be written down.
Scholars believe that humans first wrote their ideas by carving or painting on objects they
found around them: cave walls, bones, and pieces of bark. Clay tablets and large pieces of
stone were used a bit later, and by 500 BC peoples of Egypt, Greece, and Rome were writing
on papyrus2, a substance similar to paper made from a plant that grew along the Nile River
[Wolb02]. Papyrus was gradually replaced by parchment, a substance made from specially
treated animal skins thought to have been invented around 200 BC in what is now modernday Turkey. Parchment was widely used for writing until it was replaced in the 1400's by the
introduction of paper in Europe and the invention of the movable type printing press in 1450.
The invention of the printing press is a milestone in human history because for the first time
books became available to people outside the upper classes. It was in the 17th century that the
first newspapers and journals were published in Europe [List02]. This provided an
2
Papyrus : an Egyptian word which is the base of the English word paper
Introduction
3
opportunity for the average persons to learn about science, politics, and culture. The Industrial
Revolution of the 18th century saw improvements in printing technologies and reductions in
the price of paper, thus initiating the mass marketing of books and journals.
The 19th and 20th centuries saw the development of many new ways to record and store
information other than paper: microfilm, microfiche, phonograph records, audio tape, film
strips, and video tape [List02]. The invention of computers which dated back to 1940’s
[More84] marked the most dramatic advance in recording, storing, and retrieving information.
Although people continue to produce information in handwritten, typewritten, and printed
form, it can now also be generated in electronic format, i.e. recorded as bits and bytes of
computer data and stored on magnetic tape or computer disk. Vast amounts of information are
stored in electronic format and retrievable using computers. The digital electronic computer
made it possible to process information instantly. As the computer developed and matured,
communication and processing technologies were joined into networks that now stretch
around the world, affecting all areas of global society.
The latest advance in recording and distributing information has been the rise of the Internet.
The Internet has its roots in the early 1970’s when the US government was funding research
into a computer network that could survive a nuclear attack [Leiner03]. In 1991 Berners-Lee
[Mosch99] who was working at CERN (“Centre Européen pour la Recherche Nucléaire”European Laboratory for Particle Physics), in Geneva, Switzerland, developed the World
Wide Web (WWW), the hypertext system he had first proposed in 1989. He envisioned the
WWW as a shared information space - a web of hypertext documents - within which people
communicate with each other and with computers. In the early 1990’s, Internet browsers first
appeared, making it easier for the general public to access an astonishing variety and amount
of information.
Further advance in computing and communication technologies devices especially during the
past few years has made possible the creation, storing, processing and dissemination of
multimedia information. Unlike the alphanumeric data which require much less processing,
storage and transmission resources, multimedia data require far more powerful computing and
communication facilities. Multimedia information is a combination of text, graphics, image,
audio and video [Lu99].
4
Chapter 1. Introduction and Motivation
Multimedia provides the possibility for a spectrum of new applications, many of which are in
place today. Multimedia applications differ from traditional software in many ways: up until
recently it has been relatively easy to predict the areas of use of traditional packages but
multimedia applications have the potential to be used in a diverse range of areas from
entertainment, education, and commerce through to communication and art. The following are
some of the application areas:
Multimedia entertainment: the field of entertainment uses multimedia extensively. One of the
earliest applications of multimedia was for games. Multimedia made possible innovative and
interactive games that greatly enhanced the learning experience. Games could come alive with
sounds and animated graphics.
Multimedia training: multimedia presentations are a great way to introduce new concepts or
explain a new technology. In companies, this reduces the training time. Individuals find it
easy to understand and use.
Multimedia in business: even basic office applications like a word processing package or a
spreadsheet tool becomes a powerful tool with the aid of multimedia data. Pictures, animation
and sound can be added to these applications, emphasizing important points in the documents.
Multimedia in healthcare: in the healthcare industry, software developers have implemented
many solutions to deliver the patient management in the following main areas – clinical,
appointments and billing. In clinical section, the healthcare system provides very basic
standard clinical related functionalities. For instance, tools for handling prescription-writing,
managing patient consultation record, requesting pathology tests and importing pathology
results. In order for the doctor to have full and complete patient information, healthcare
systems incorporate multimedia information into the patient records which may include
image, audio or video. This enables to improve the quality and efficiency of the patient
treatment.
Multimedia libraries: different education institutions have developed multimedia or digital
libraries to facilitate the teaching-learning process. Multimedia libraries provide web-based
access to instructional resources such as course note, books, lecture presentations, sample
Introduction
5
exercises and tests. The multimedia library saves time and costs. Many users can have access
to the resources at any time which is not the case in traditional library.
Multimedia museums: the ability to capture and store information in formats other than
structured text provides new opportunities for the documentation and interpretation of works
in museum collections. New kinds of information can be recorded, stored and communicated.
Multimedia databases- which store two or more different types of information enable the
recording of structured text, unstructured text, images, sound and video. All of these data
types can be integrated to form a comprehensive archive which offers a more robust picture of
the context and meaning embodied in artifacts, held in collections. The multimedia data
present the museum visitor with more than formatted data and textual information. It
encompasses interactive multimedia, hypermedia, imaging applications, digital video,
computer graphics, virtual reality, and computer-controlled interactive displays and
participatory exhibitions. The construction of multimedia archives plays a significant role in
the documentation strategies of many museums.
Another multimedia application is videoconferencing. It allows conducting a conference
between two or more participants at different sites by using computer networks to transmit
audio and video data. For example, homecare nurses can use video conferencing to care for
their patients, saving time and costs and helping them cope with increasing workloads.
The rapid advancements in computing and communication technologies combined with the
widespread multimedia applications led to many research topics such as storage, indexing,
searching, delivery and consumption. While the storage, index and searching aspects of
multimedia data have been addressed by several researches during the last decades, the
delivery and consumption of multimedia data have become an interesting research issue with
the emergence of heterogeneous devices and network connections. In this thesis, we present
the important issues related to multimedia content delivery in heterogeneous environment, the
related challenges and the possible solutions.
6
Chapter 1. Introduction and Motivation
1.2 What is Pervasive Computing?
Today, computing is no longer limited to a particular location using some stationary
computing devices, such as Personal Computers (PCs) at home or in office. With the
advances in the computing technologies, computing can now be done on heterogeneous
mobile devices, such as laptop computers and information appliances like Personal Digital
Assistants (PDAs), pagers, smart phones, etc. People can access different multimedia services
using these mobile devices wherever and whenever they want them: at work, at home, in a
meeting, or even when traveling.
The term Pervasive computing [Agoston00] is used to describe the kind of computing that can
be done anytime, anywhere, and on any device. Computing can be done whenever a
computing device is available; e.g. with the PC at home and in office, the PDA you carried
during traveling, the laptop brought into the meeting room, or even the thin client inside a
coffee shop. All these devices help accessing information or services in one seamless,
integrated system. There is no fixed association between a device and a user, meaning that
these devices do not need to be owned, and can be any device that is come across. In
pervasive computing, users are free to move and compute without the need to carry any
device. It is clear that pervasive computing environment is very different from traditional
computing environments.
The essential features and demands, which set the pervasive computing environment apart,
include [Kwan02, Henr01]:
Device heterogeneity: computing is carried out on a wide range of devices, from small
mobile devices, such as smart phones and PDAs, to tablet PCs, laptops, and stationary devices
such as PCs. Each of these devices has a different hardware configuration and capability, and
possibly a different software platform for program execution.
Device resource limitations: miniaturization of devices is one of the propelling factors for
the trend towards mobile computing. Many mobile devices are designed to be small for easy
portability. They are small not only in terms of form factor, but also computing power,
memory, display screen size and battery power. All these limit the type of computing that can
What is Pervasive Computing?
7
be done on these devices. Although the advance in technology will increase the capabilities of
these devices with no doubt, they will still have limited capabilities compare to desktop PC.
In the case where a screen size of a device is less compared to the original media size (e.g.
image), an image resizing adaptation mechanism can be applied to adjust the image size so
that it can fit with the device screen size. Another limitation can be a device without color
capability. In this case, it is possible to stream a variation scaled in the color domain (color-togray conversion, for instance).
Network limitation: the wireless connection used in the mobile devices is usually
bandwidth-limited and unstable when compared with the wired connection. At present, the
wireless technologies standards include Bluetooth, Wi-Fi, General Packet Radio Service
(GPRS), IEEE 802.11a, IEEE 802.11b, IEEE 802.11g and several others under development.
The comparatively slow speed of these technologies compared to wired network is always a
barrier for running large applications and moving large data to/from mobile devices.
High mobility: users in pervasive computing environments are highly mobile. Without the
need to have a fixed association with the computing devices, users can move freely from
place to place with or without any mobile device. For example, a user is carrying out a video
conference on his way home. He may be using the digital display in his car for the
conference. While walking from his car to his home, he switches the conference to his PDA.
Once he is at home, in his room, he continues the video conference on his personal computer.
This high mobility nature results in a continuous change of the computing environment, or
execution context that can affect the execution.
User preferences: while this is not a new phenomen specific to pervasive computing
environment, the increase mobility and the use of several user devices result in dynamic
preferences related to the user device, location, activity, role, knowledge or some other
factors.
The rest of the Chapter is organized as follows. Section 1.3 motivates the thesis by identifying
some scenarios that may benefit from the work in this thesis. Section 1.4 presents a short
overview of the proposed approach. It also lists some advantages and limitations of the
approach. Finally, Section 1.5 provides a road map to the rest of the thesis.
8
Chapter 1. Introduction and Motivation
1.3 The Need for Content Adaptation
There is a huge amount of multimedia information being captured and produced for different
multimedia applications and the speed of generation is constantly increasing. While providing
the right information to a user is already difficult for structured information, it is much harder
in the case of large volume multimedia information. This is further complicated with the
emergence of new computing environments. For example, a user may want to access content
on the network through a handheld device connected by wireless link or from a high-end
desktop machine connected by broadband network. Content that can be presented on one
device might not be necessarily viewable on another device unless some content
transformation operations are applied.
Therefore, a content delivery system must be able to send the appropriate content for every
client in every situation. Efficient content delivery systems must fulfill some requirements to
address the wide range of clients, namely, content adaptation, minimal bandwidth
requirement, and fast real-time delivery [Chi02]. Content delivery is one of the research
topics that attracted a number of multimedia research community. We will limit our
discussion on the issues related to the problem of content adaptation and show how it solves
the problems arisen due to the inherent characteristics of pervasive computing. Content
adaptation is the process of customizing content so that it fits the user and environment
context.
Device heterogeneity: it would be very expensive and time consuming to create different
versions and modalities of the same multimedia content for different device types. This
problem is aggravated by the fact that multimedia contents have different modalities and each
with different formats. However, with a content adaptation facility, the same original content
can be delivered to different devices through a proper adaptation mechanism to convert the
format or modality of the content. For example, having a JPEG image data, we can send it to
a device which supports JPEG directly and after conversion to GIF to a device supporting
GIF.
Device resource limitation: in the case where a screen size of a device is less compared to
the original media size for example image, an image resizing adaptation mechanism can be
The Need for Content Adaptation
9
applied that adjusts the image size so that it can fit with the device screen size. Another
limitation can be a device without color capability: in this case, it is possible to stream a
variation scaled in the color domain (for instance, color-to-gray conversion).
Network limitation: one solution is to scale the network bandwidth to cope up the demand
but this is expensive and difficult; hence we need to minimize the demand for network
bandwidth. This can be achieved by creating a variation that fits the available bandwidth
through different size reduction methods such as color reduction, size reduction, format
conversion etc.
User preferences: for example, a user may be interested to see only the goal scenes of a
football game instead of the whole video. This can be achieved by extracting those particular
scenes and delivering them to the user. Another case scenario is that a user can only read
information in his language; if the pertinent information is written in another language, one
must apply an appropriate language translation to the information before it is delivered.
In summary, the need of content adaptation in pervasive environment is motivated by the
limited availability of resources, the user preferences, and the usage context. Figure 1.1 shows
the tradeoff between the Quality of Service (QoS) with respect to resources in a content
delivery system. As it can be seen from the figure, the goal of content adaptation is to deliver
the content using the available resources.
10
Chapter 1. Introduction and Motivation
Best QoS
Adaptation
Application resource
requirements
Acceptable QoS
Available
resources
Low QoS
Guaranteed
Figure 1.1: Goal of Content Adaptation
1.4 Motivation
Concurrent with the developments in pervasive computing, advances in storage, networking
and authoring tools are driving the production of large amounts of rich multimedia content.
The result is a growing mismatch between the available rich content and the capabilities of
the client devices to access and process it. The mismatch between content requirements and
client capabilities impacts a number of multimedia applications.
Therefore, a solution to the mismatch problems, which is presented in this thesis, is to provide
a context aware content adaptation (or transformation) system which allows clients to access
to a range of media formats and within each media data to convert on the fly if necessary
these multimedia data to more appropriate formats. In this thesis we present a distributed
service-based content adaptation approach. To demonstrate the importance of content
adaptation in pervasive environments, we present three different application scenarios.
Motivation
11
Scenario I: Cooking guide
One of Mrs. Catherine’s hobbies is cooking. She watches her favorite cooking program on
TV. She gets interested in the recipe being explained so she decides to prepare a meal of the
recipe. The program uses a multimedia database system to store video clips on cooking
procedures, image and textual description of recipes and ingredients list. She logs to the
programs web site with her PC to see details of the recipe. Then, she goes to supermarket to
buy the ingredients. She connects to the system with her cell-phone and gets the list of the
ingredients. She comes back home, connects to the system with her cell-phone and prepares
the meal by listening to the recipe description.
Scenario II: Map and route service
Mr. Bob is a tourist who likes visiting museums. He is in Paris for a vacation and wants to
visit “Le Louvre”. Before going to the museum he wants to know the direction and location.
He connects to a location map and routing service system with his PDA. He discovers that the
system provides route guiding service. He activates the route guiding service with his
smartphone and starts driving to the museum. After the visit he likes to walk around the
district. He connects again to the location mapping and routing service with his PDA and
downloads the districts map. He visits the district appreciating architecture of the ancient
building. Since he wants to know history of those ancient buildings, he uses his mobile phone
to connect to a tourism site and walks around while listing a commentary about the sites he
traverses.
Scenario III: Medical Prescription
Consider a situation wherein a physician makes rounds at health center in Paris. The health
center is built with the state-of-art of modern health care system. This center is networked
with other health centers throughout Europe and allows anywhere/anytime patient data access
by doctors, nurses, caretakers and other hospital staffs. The physician is visiting a patient
from one of the European cities. The patient shows signs of a bronchial infection. Before
prescribing any new medication, the doctor wants to check the patient’s medical records
which may consist of media data such as text, image, video or audio on his wireless handheld
device (e.g. PDA). He connects to the system and gets her historical data from centers she has
12
Chapter 1. Introduction and Motivation
previously visited and notes that she is already taking medications for high blood pressure and
heart problems and she is also allergic to penicillin. He then uses the handheld device to
check an online drug database for the most effective treatment compatible with the patient’s
other medications. The doctor fills out a short form on the handheld device screen to authorize
and send the prescription via a wireless network to a pharmacy.
The above three scenarios shows that users are mobile, they have different access devices
with varying processing capacities, display capabilities etc. The information sources are
multimedia, that is, they consist of different media types such as text, image, video, and
audio. On one hand we have limited device and network connections. On the other hand
multimedia requires large resource consumption. Moreover, the user needs may vary with
device and location. To fill the gap between these two requirements, content adaptation or
transformation becomes crucial.
1.5 A Short Overview of Our Approach
One of the architectural issues for content adaptation is the decision where the adaptation
processes resides. Based on the location of the adaptation processes, three approaches have
been proposed: server-based, client-based and proxy-based.
In server-based approaches, the functionality of the content server (provider) is extended so
that it also performs content transformation activities. This approach might produce better
adaptation results as it has more knowledge on the content, however, the processing overhead
of the transformation leads to poor user response experience and server overload.
In client-based approaches, the transformation is done on the client devices after receiving the
content from the server. It is mostly effective in situations where the transmission
characteristics of the end-to-end path are less important than the limitations of the displaying
device. However, this solution performs poorly in situations where the transmission
characteristics of the end-to-end path are also the point of consideration rather than only the
displaying ones and it has poor extensibility (adding an adaptation tool requires modifying all
the clients).
A Short Overview of Our Approach
13
In proxy-based appraoches, an intermediate proxy which is implemented usually at the access
point, intercepts the content coming from the server and applies different transformations
according to the device characteristics and the network connection. By introducing the proxy,
users will experience better performance as the server is relieved from the transformation
tasks. But, this approach has still a limited scalability because of significant computational
costs of adaptation operations such as key-frame extraction from video [Lum02a].
In this thesis we propose a distributed service-based content adaptation approach. This
approach uses adaptation services that perform basic transformation operations and are the
building blocks for processing multimedia media. Through chaining of these services,
complex adaptation scenarios can be achieved. The decision on the number and the type of
transformations is done by a proxy placed between the client and the server and more
appropriately close to the client. Because of their flexibility and distributed nature, web
services are a good choice for the adaptation services. This approach tries to solve
performance problems of content adaptation as the adaptation is done by third party external
services each implementing a particular transformation tool. It also provides a general
solution of content adaptation that can be deployed to any type of application. Moreover, it
addresses the interoperability, extensibility, scalability and flexibility issues of content
adaptation which are important requirements in pervasive application systems by proposing a
general architectural framework.
The major contributions of this thesis are the following:
•
We introduce a novel service-based content adaptation architectural framework for
distributed multimedia systems. Using this architecture, third-party adaptation services
can be easily included into the architecture which makes the framework widely
extensible. Moreover, the framework is scalable and interoperable so that we can use
it for wide application areas.
•
Though in many instances web service technologies are mentioned as good solutions
for distributed computing especially on the Interent, for the best of our knowledge
their application for pervasive computing, particularly for content adaptation is
investigated for the first time in this thesis.
•
We provide a formal definition and description of multimedia content adaptation
process. This formalism enables to understand the different elements involved in
deciding the adaptation process so that different mechanisms can be developed. We
14
Chapter 1. Introduction and Motivation
also define transformation rules that are easily extensible to add new transformation
functionalities and user constraints.
•
The design of the framework allows the composition of adaptation services to provide
optimal service for a given computational context. Therefore, any adaptation need is
achievable.
•
We propose an ontology for multimedia adaptation services description. The ontology
helps to describe services semantically. The semantic description facilitates automatic
discovery, composition and execution of the adaptation services.
•
A planning based algorithm is developed for adaptation service composition.
•
A prototype has been developed that implement the framework. The prototype
demonstrated not only the validity of our proposal but that our solution could be used
for real application systems.
•
Various experiments were conducted on the prototype to measure the overhead of
applying one or more transformations and of the adaptation graph construction
algorithm. The experiments showed that the overhead of the graph construction
algorithm is not significant compared to the total latency time introduced by the
adaptation process.
1.6 Organization of the Thesis
This dissertation is organized as follows:
•
Chapter 2 gives a literature review on content adaptation systems and service oriented
architectures.
•
Chapter 3 gives a brief overview of Service-Oriented Architecture and web services
•
Chapter 4 discusses about content metadata description tools and standards
•
Chapter 5 discusses about context metadata description tools and standards
•
Chapter 6 presents our service-based architecture framework and its key concepts
•
Chapter 7 details the prototype implementation of our architecture
•
Chapter 8 provides a brief discussion on our appraoch
•
Chapter 9 summarizes major contributions of the thesis and describes our future work.
Chapter
2
Related Work on Content
Adaptation
The objective of this chapter is to review the works done on the multimedia content
adaptation for pervasive application systems. More specifically different adaptation
techniques and adaptation approaches proposed in the literature will be discussed. The rest of
the chapter is organized as follows. In section 2.1 we cite main academic and commercial
pervasive computing projects, discuss the difficulties of multimedia access in heterogeneous
environments and the importance of content adaptation to solve these difficulties. Section 2.2
first assesses works in the area of multimedia content adaptation including issues related to
adaptation techniques, adaptation architectures and adaptation systems. Then a short summary
of actually implemented adaptation systems, their functionalities and their drawbacks are
presented. Section 2.3 is devoted to service-oriented architectures and their features. Web
service languages standards and related technologies are presented in Section 2.4. Section 2.5
deals with works related to web service composition particularly workflow techniques and AI
planning approaches. Finally, section 2.6 summarizes the chapter.
2.1 Introduction
Many citations do not distinguish between “pervasive” and “ubiquitous” when it comes to
computing visions. Some citations argue that the difference exists: pervasive computing aims
to make information available everywhere while ubiquitous computing requires information
to be available everywhere [Goff04]. Although the pervasive-computing essentials have
emerged, the ubiquitous-computing age is still yet to come. On the other hand, we have seen
major pervasive/ubiquitous computing projects booming in academia, such as the project
16
Chapter 2. Related Work on Content Adaptation
Aura at Carnegie Mellon University (CMU)3, Endeavour at UC Berkeley4, Oxygen at MIT5,
and Portolano at the University of Washington6. Industry examples include work at AT&T
Research, HP Labs, IBM Research, Intel Research, and many others. Each of these efforts
addresses a different mix of issues and a different blend of near-term and far-term goals. In
this thesis both terms are used synonyms.
Pervasive computing systems try to make life easier for users by deploying various devices
and supporting middlewares. But real difficulties still lie at the application front. Today,
applications are typically developed for specific device classes or system platforms, leading to
separate versions of the same application for handled, desktops, and cluster-based servers. As
heterogeneity increases, developing applications that run across all platforms will become
exceedingly difficult [Saha03]. Firstly, wireless terminals for examples, cell phones, PDAs,
notebook computers etc. are inherently resource-limited. Comparing them to desktop
computers with LAN (Local Area Network) connections, the wireless terminals have smaller
display, limited computation powers and energy consumption, and narrower bandwidths on
their network links. These limited resources can easily be overwhelmed by bulky multimedia
data that are originally intended for wirelined computers.
Secondly, the collection of wireless user terminals is heterogeneous. These terminals run
different operating systems, have different capacity, and may have different installed sets of
applications. Furthermore, they may use some proprietary multimedia formats that other
terminals do not use. As a result, it becomes more and more difficult for the providers of
multimedia contents to decide a priori what file formats are suitable for the terminals of the
target audience.
Thirdly, different users may have different needs. They use different terminals and have their
own preferences as to how multimedia data should be received and presented. Users may have
also different language preferences depending on their background or education.
There are two extreme solutions to these problems, which, however, can be easily
disqualified. The first solution is to have multiple devices and multiple connections, one for
3
Aura project: http://www.cs.cmu.edu/~aura/
Endeavour project http://endeavour.cs.berkeley.edu/
5
Oxygen project: http://oxygen.lcs.mit.edu/
6
Portolano: http://portolano.cs.washington.edu/
4
Content Adaptation
17
each media type. This is far from an optimal solution. Users prefer to operate as few devices
as possible, but they also have specific priorities for some of them (e.g., weight and energy
issues for mobile devices). The other extreme solution would require one device to be capable
of presenting every type of multimedia content. This approach is also disqualified for similar
reasons, in addition to limited resources and cost issues that the production of such a device
would introduce.
The concept of content adaptation has been introduced to bridge the gap between these two
extreme solutions. Instead of having each medium stored in multiple representations, each
matching the characteristics of a probable end-device, the source can provide only one or a
few representations and rely on adaptation functionalities to deliver the content in the
appropriate format at the receiver. In addition, devices with transmission and display
characteristics that prevent them from accessing certain types of media are able to do so by
having the representation of the content adapted to a form suitable for them, with as small an
impact to its perceptual value as possible. Thus, users gain access to a great variety of media,
virtually with any possible combination of connection and device type. In the following
section we will present techniques and approaches of content adaptation and examples of
application systems implementing adaptation functionalities.
2.2 Content Adaptation
Content adaptation or multimedia content adaptation refers to the process of customizing or
tailoring content to suit to the user’s computing environment such as location, device
capability, network bandwidth, user’s preferences and usage context [Lum02b, Hori00].
Content adaptation is considered an effective and attractive solution to the problem of
mismatch in content format, network connectivity, device capability and user’s preferences in
pervasive computing environment [Held02]. Using an adaptation technique, content can be
filtered, transformed, converted or reformed to make it accessible by several devices, to
exploit specific application requirements for customized content and to personalize general
content for different devices and users. By tailoring content, users have become accustomed
to particular interfaces, presentations and preferences. For example, a user is receiving video
broadcast football on his mobile phone while driving to his home. At this time, the system
detects that the user does not have enough network connection to send the video of the match
18
Chapter 2. Related Work on Content Adaptation
so it sends him key-frames showing goals. While arriving in his home the user switches to PC
and continue getting the video but this time the full video since the user has good network
connection. What we can see from this scenario is that the system sends the key-frames by
applying adaptation it provides the user and then sends him the full video when the condition
is possible.
The adaptation process does not only tackle the problem of resource constraints but it also
increases user satisfaction and reachablity. For example, a visual impaired person can not
access visual information unless the system provides him/her in audio form; on the other hand
for hearing impaired person visual form is more appropriate. Another interesting example is
the case where a French speaking person accesses to information sources written in English.
In this case the person does not understand English hence can not understand the content
unless there is a mechanism to produce the content in his/her language that is French. All
these example scenarios show us the importance of content adaptation for universal
information access in the world of pervasive computing.
2.2.1 Content Adaptation Techniques
The introduction of pervasive computing systems in the last decade has made multimedia
content adaptation an important research focus. Since then, several adaptation techniques have
been developed to deliver multimedia data to users in heterogeneous environments. Currently
available techniques apply textual transformation [Nagao01, Hous96, Lilj95], image
transcoding [Wee03, Lee03, Chandra00, Smith98], video and audio processing [Libse04,
Shan00, Vetro02, Bolot98,]. A list of content adaptation technologies that can be applied to
the basic media types: text, image, audio and video have been identified by Lei [Lei01] and
Narendra [Shaha01]. The list is presented in Table 2.1.
Content Adaptation
19
Category
Text
Image
Video
Audio
Transcoding
- format
- data size
- frame rate
- audio stereo-
conversion
- font size
reduction
reduction
- dimension
reduction
- spatial
reduction
resolution
- color-depth
reduction
reduction
resolution
grayscale
reduction
- format
conversion
conversion
- format
conversion
- temporal
- color-to-
transformation
to-mono
- color-depth
reduction
- format
conversion
Transmoding
- text-to-audio
transformation
- image to text
- video-to-image
transformation
- audio-to-text
transformation
- video-to-text
transformation
- video-to-audio
transformation
Summarization - text
summarization
Translation
- language
translation
- key frame
- audio highlight
extraction
- language
translation
- language
translation
Table 2.1: Media Types and Content Adaptation Techniques [Lei01 and Shaha01]
Classifying the adaptation technologies is mandatory for developing a general decision
making strategy for delivering adapted content to users according to their context.
In a more general sense, content adaptation techniques can be broadly classified as semantic
adaptation and physical adaptation. We briefly present each classification as follows:
20
2.2.1.1
Chapter 2. Related Work on Content Adaptation
Semantic adaptation
According to [Lei01], semantic adaptation is a selective process. Based on available and
requested information, multiple pieces of information are combined into a complete
presentation. Semantic adaptation is affected by the semantic structure of a presentation,
which determines the relative data in the final presentation. For example, most current ecommerce web sites contain many images of banners, logos, and advertisements. These data
often consume a good deal of network bandwidth, and are non relevant or not of interest to a
user. We can drop less important data under bandwidth constraints or, we can provide
progressive delivery to send out the more important data first (such as low resolution images)
and then deliver the less important data to enhance the information later (such as
reconstruction of high resolution images). In this way, we can improve the user’s access
experience by efficiently utilizing available network bandwidth. [Ma00] have identified data
prioritization and purpose classification for semantic content adaptation.
Data prioritization: the aim is to distinguish the more important part of the data from the less
important part so that different quality service levels can be provided when delivering the data
through the network [Shaha01]. Data prioritization can be achieved within a single media type
by using special encoding schemes such as layered coding and multi-resolution
comprehension [McCan97, Taub94]. For example, in case of video content, the adaptation
may create a smaller duration variation of the content, usually summary, by selecting the
temporal (and may be also spatial) segments that are more relevant according to some criteria
(e.g. user preferences).
Purpose classification: a typical web page contains a lot of information and media objects
that are redundant or may not be of interest to a user. For example, an e-commerce web site
may have multiple images for linking to the same product site on the top, bottom and side of
the page. Purpose classification [Shaha01, Peak98] deals with classifying the purpose of each
media object in a Web page, to improve the efficiency of information delivery by either
removing redundant objects (assuming the related copyright issues have been properly
addressed) or prioritizing them according to importance.
Data appropriateness is also important for semantic adaptation. A typical application case is
a 10 year old kid who would like to visit a museum. He is really interested in dolphins and
Content Adaptation
21
consequently he proceeds to the ocean section, where he receives on his mobile device the
catalogue. Browsing the catalogue, he selects the chapter related to the dolphins in order to
watch the corresponding video. The original video with a length of 5 minutes consists of
different themes: (1) the search for food, (2) dolphin’s enemies and (3) games. The kid has no
particular interest on specific themes. He just wants to see dolphin’s images. Therefore, he
receives an adapted video, where particularly violent and bloody scenes (e.g., sharks wildly
devouring dolphins) are dropped. Emphasis is instead put on nicer scenes, e.g., dolphins
playing with each other, mother with its little dolphin.
To facilitate semantic adaptation it is important to add semantic information (priority, purpose
and appropriateness) through annotations during the content creation or later. Annotation
refers to the processing of content in order to provide additional information and metainformation, such as summaries, keywords, highlights, etc. Multimedia annotation is time
consuming and requires a large storage space which makes semantic adaptation sometimes
difficult. Consequently most of the adaptation techniques developed so far focus on physical
content adaptation. This thesis is within this context. In the following section we present some
of the physical adaptation technologies.
2.2.1.2
Physical adaptation
Physical adaptation of media is defined as the combination of conversion, scaling and
distillation processes guided by the characteristics of media format and physical QoS [Lei01].
Physical adaptation technologies can further be classified based on target context, time (when
the adaptation is performed), and number of media types involved in the adaptation. The
different classifications are presented in the following section (A-D).
(A)
Based on the target adaptation context, adaptation techniques can be divided into
technical infrastructure (terminal and network), user preferences or user context/location:
•
Terminal and network driven adaptation: The consumption device and the network
capabilities may pose a serious barrier to the content distribution and consumption.
Current pervasive devices vary widely in their features in terms of hardware (screen
size, resolution, color depth, computing power, storage space, …) and software
(applications, codecs, …). They also use a variety of network connections from cable
22
Chapter 2. Related Work on Content Adaptation
to wireless, with different effective bandwidth and network latency. That implies that
the data transmitted must be adapted to fit to the terminal and network connection
capacity. This category of adaptations aims to reduce the content consumption
requirements by adjusting the source content to the device and network capabilities.
For example, in order to display images on devices with a small screen and limited
display capability, reducing the size or resolution for each image will help to fit the
image on the small screens of devices. Techniques such as transcoding, transmoding
and scalable coding are used for terminal and network driven adaptations [Maga04].
Using transcoding content resource can be reduced so that it matches the available
terminal and network capabilities [Lei01b]. Some examples of transcoding are format
conversion, temporal/spatial resolution reduction and color reduction. Transcoding
requires computational power and memory and thus it may be quite expensive to
achieve a large scale adaptation deployment when many on-the-fly adaptations are
required [Maga04, Lum02b].
Transmoding is defined to be the adaptation of a digital media by transformation of its
original modality to another modality [Pere05, Asadi04]. Transmoding (or modality
transformation) is necessary when the usage environment conditions do not allow
consuming the content with its original media types. Some examples of transmoding
are text to speech, video to still image and video to text.
Scalable coding is used to compress video contents in a scalable fashion. Scalable
video usually consists of a series of layered streams. There are three basic scalabilities
on video content [Shen06]: Signal Noise Ratio (SNR) scalability for picture quality,
spatial scalability for frame size, and temporal scalability for frame rate. In many
practical applications, one scalable stream may contain more than one kind of basic
scalability. Each layer can be partially and even completely dropped during
transmission and decoding.
A.Fox et al. [Fox98] developed an architecture that adapts Internet content to network
and client variations. The architecture uses datatype-specific lossy compression to
increase the quality of service for the client and reduce the end-to-end latency
perceived by the client. The Odyssey system [Noble95] supports a form of end-to-end
Content Adaptation
23
bandwidth management by providing a fixed number of representations of data objects
on a server and specifying an Application Program Interface (API) by which clients
track their network characteristics and negotiate for a representation that is appropriate
for their current connectivity. Since the data representations are not exhaustive, that is
they do not represent all possible network connections, a user request which requires a
different representation can not be answered by the server. Moreover, generating
different representations may require large storage space.
•
User characteristics/preferences driven adaptation: Constraints concerning
terminals and networks are technical, yet it exists one more criterion to consider, the
user [Zang00]. It is certain that the user is the one who works with the data, so it is
very important to consider his/her needs, preferences, priorities, role, skills, interests,
characteristics…etc. For a specific multimedia presentation, individual users may have
different requirements on the level of details or some other parameters [Boll01]. For
example, consider a professor on campus who is interested to see in-depth multimedia
material on coronary artery bypass grafting, and an undergraduate student at home
who needs to get only an abstraction of the same material. Users may also have
different language preferences. For example, a user may be more comfortable to
access data in French than English. In this case a language translator can be used to
translate the data from French to English. Content adaptation might also be essential to
facilitate data access for handicapped users [Pere05, Maga04]. For example, a hearing
impaired user may need transformation of speech to text. Conversely a vision impaired
user may need transformation of text to speech.
•
User location/context driven adaptation: Due to the terminal mobility, it is also
important to consider content adaptation based on the user location and/or context.
This is because the natural environment may limit the user capabilities and thus the
user may need a specific adaptation to maximize his/her access conditions. For
instance, if a user is driving, his/her attention (and his/her eyes) is focused on the road,
and thus voice content (text to voice) must be provided. Conversely if a user is in a
meeting he may favor silent content delivery that is transforming voice to text. It is
important to note that the user location/context driven adaptation is not the same as
location aware queries (e.g. where is the nearest gaz station?).
24
Chapter 2. Related Work on Content Adaptation
(B)
Based on the number of media types involved in the adaptation process, adaptation
technologies can be divided into single or cross-media adaptation [Lei01]:
•
Single media adaptation: In single media adaptation, different versions of a media
element are produced with varying features, qualities and resource requirements. Most
of current best-effort adaptation techniques consider switching between different
qualities or formats of single media elements in order to fit the receiving device
capabilities and user interest. For example, most images can be significantly
compressed without an appreciable decrease in quality. Another example is GIF-toJPEG or color-to-grayscale transformations that can be used to reduce the physical
size of an image.
•
Cross-media adaptation: In cross-media adaptation (also called transmoding)
[Boll99], content is transformed from one media type to another so that the content
can be processed by a particular device. For instance, some handheld computers may
not be capable to handle video data due to their hardware and software constraints or
network connections. Thus, transforming video into sets of images and extracting
audio or caption will enable the devices to access to the information contained in the
video. In this case, users will be able to receive useful information in whatever form
their devices can handle. Transmoding also helps disabled people to access data as
mentioned above (section A).
(C)
We can also classify adaptation techniques as structural transformation or media
transformation [Leml03]:
•
Structural transformation: techniques in this category relate to the transformations
applied to the total organization of a document. Some examples of such
transformations are HTML to XHTML BASIC for the mobile terminals, filtering of
HTML documents, transformation of textual contents written in XML to a graphical
representation in SVG, etc. Structural transformation can preserve the media resources
used by the document source as it can filter them.
Content Adaptation
•
25
Media transformation: this category consists of adaptation and encoding of media
objects. For example adaptation of image and video by applying color reduction or
color-to-gray, resizing, changing format encoding etc. Several works have developed
techniques for adaptation of media resources such as image [Wee03, Lee03] and video
[Libse04, Shan00, Vetro02].
(D)
Finally, adaptation techniques can be classified into static or dynamic depending on
the time when the adapted content is created [Lei01, Lum02a, and Chang02]:
•
Static (off-line) adaptation: the content transformation is generated when the
resource (the content) is created or updated. This often involves a human designer to
hand-tailor the content to some specific requirements. The multiple variants of the
same resource are stored in the server and selected to match the client specifications.
For example, the server can store several versions of an original video with different
sizes, formats and resolutions and according to different connection QoS links. The
appropriate version will be selected at runtime depending on the usage context. For
instance, in order to eliminate extra processing overhead at presentation time, most
current web sites create multiple versions of information at authoring time. For
example, a bilingual site is a typical case where an off-line approach may be
convenient. The Odyssey system [Noble97] uses a static adaptation approach. The
Odyssey server has several pre-generated versions of the data with different fidelity
levels, and the appropriate one is chosen at run-time according to the resources, or
even energy, available.
Static adaptation has three main advantages: (1) it is highly customized to specific
classes of client devices (2) it does not require any runtime processing, so no delay is
incurred, and (3) the content creator has the full control on how the content is
formatted and delivered to the client. On the other hand, static adaptation has a number
of disadvantages, mainly related to the management and maintenance of different
variants of the same content [Lum02a, Leml01]: (1) different content formats need to
be created for each sort of device or class of devices, and new content versions should
be created when new devices are introduced, (2) it is unsuitable when the content is
dynamically generated or highly volatile, and (3) it requires large storage space to
keep all variants of the same content.
26
Chapter 2. Related Work on Content Adaptation
•
Dynamic (on-the-fly) adaptation: In dynamic adaptation [Huan04, Sing04, Card03,
Chang02, Mahe02], the desired content is generated on the fly just before delivering to
the client according to the current context of the user and computing environment. The
dynamic approach has the maximum flexibility and generality, and frees the provider
from creating in advance and keeping consistent multiple versions of its resources.
However, as stated by [Lum02b], the adaptation overhead introduces latency in the
delivery.
Classifying adaptation techniques is important as it helps to understand the different
techniques and use them in different application scenarios. It is also useful for developing a
general decision-making strategy to optimize the adapted content delivery.
2.2.2 Content Adaptation Approaches
One major architectural design issue for developing adaptation functionality in pervasive
computing environment is to decide where the decision making and the adaptation operations
reside. There are three basic approaches for locating adaptation functionality on the path of
data delivery from the source to the destination: (i) at the source, (ii) at the destination or
client, and (iii) in between, somewhere in the network, with some special locations having
special properties, e.g., at the boundary between the wireless and the wired parts of the
network. In this section we will examine in detail each design approach with its advantages
and drawbacks.
2.2.2.1
Server-Based (or Source) Adaptation Approach
The first approach puts the adaptation functionality at the source (or server) as shown in
Figure 2.1. In server based approaches such as [Marg01, Mogul01, Mohan99, Bhrag98,
Bolot98], the server is responsible for discovering what the client capabilities are and how
much bandwidth is available. It then decides on the best adaptation strategy.
Content Adaptation
27
Adaptation
Point
Wireless Device Base Station
Application
Server
Figure 2.1: Server-Based or Source Adaptation
The server based approach provides more control since the adaptation can be tied to the
content authoring process, allowing the author to provide hints on the adaptation for different
circumstances. An author can also preview the adaptation outcome under different viewer
preferences and conditions. For secured environment, such as in e-commerce applications,
contents are usually encrypted in which case only the server or client can perform the
adaptation. In addition to technical issues, it is necessary to consider the copyright and
business implications of adaptive content delivery. Modifying content rewritten by someone
else may incur copyright infringement. In a server based apporach, this liability is avoided
since the content provider has control over how the content is to be transformed. Moreover,
server-side solutions allow an additional alternative for content adaptation that is dynamic or
static solutions.
The major drawback to server-based adaptation is its limited scope. Deploying adaptation in
the content server only affects targeted content from that server. It is not appropriate when a
client is viewing content from a range of servers. Performing adaptation on the content server
will also impose an additional load on the resources of the server, and so may require
additional infrastructure enhancements. Furthermore, the main problem of content delivery in
a pervasive environment lies at the last hop, that is, where the wireless connection is, hence
having the transformation process at this point will be more appropriate that is what proxy-
28
Chapter 2. Related Work on Content Adaptation
based approach is. Finally, though the server-based approach allows off-line adaptation,
generation of multiple versions of the content makes content management more cumbersome
and requires more storage. In conclusion, the simplicity of the server-based solution makes it
efficient for simple cases with small variability, but it can not stand as a viable solution under
extremely variable conditions.
2.2.2.2
Client-Based (or Receiver) Adaptation Approach
The second approach in locating the adaptation functionality is to have it reside at the receiver
(or client) as depicted in Figure 2.2. In client-based adaptation [Marr02, Lei01, Björk99,
Yosh97, Fisher97], the required transcoding is performed by the client device taking into
account the device’s capabilities which might not otherwise be available to the server. The
source remains unchanged and continues to transmit the same quality content to the receiver.
The receiver, upon reception of the content, transforms it to suitable form that it is capable of
presenting.
Client-based adaptation can be done in two ways, either by selecting the best representation or
by performing transformation by the client device. Selection of the best representation for a
response is performed by the user agent after receiving an initial response from the server.
The server sends a list of available content variants with their resource requirements, then the
agent selects, based on client information. Some client devices transform the content at the
device, for example, Windows-CE devices (e.g. SmartPhone) change the color-depth (for
example, from 24 bit color to 4 bit gray-level) of images. Opera Software [Opera04] uses
proprietary client-side adaptation technology called Small-Screen Rendering in its mobile
browsers. This technology reformats web sites to fit a smaller screen eliminating the need for
horizontal scrolling. Similarly, Opera’s Medium-Screen Rendering identifies a web page’s
content and adapts its elements to fit on medium-sized screens ranging from PDAs used in
landscape mode to low-resolution TV screens.
Content Adaptation
29
Adaptation
Point
Wireless Device
Base Station
Application
Server
Figure 2.2: Client-Based or Receiver Adaptation
The client-based approach requires minimal changes at the receiver and can be extremely
efficient in customizing the content to meet exactly its capabilities. The user profile which
includes preferences, location and role is an important parameter in determining the
adaptation. In the case of server-based approach, the profile information should be
communicated to the server and this may pose privacy issues. However, in client-based
approach, it is the client who manages the profile and other context-sensitive data so it avoids
the risk. The client-based approach is mostly effective in situations where the transmission
characteristics of the end-to-end path are less of a concern than the limitations of the
displaying device [Nand99].
Indeed, this solution performs poorly in situations where the transmission characteristics of
the end-to-end path are also the point of consideration. Having a desktop connected to the
Internet using a low speed modem, for example, renders the receiver adaptation mechanism
useless, since it resides after the critical part of the end-to-end path; the adaptation mechanism
is applied to the stream after the stream has already congested the low-speed modem link.
Therefore, whatever transformation it applies, it can not prevent the Internet Service
Provider’s (ISP’s) modem from dropping a significant amount of packets of this stream which
overflows the link. Since both the device display and the transmission characteristics are
30
Chapter 2. Related Work on Content Adaptation
important factors to determine content adaptation in pervasive environment, applicability of
this solution as a generic adaptation approach is limited.
Moreover, the complexity of adaptation mechanisms which is usually high also hinders the
wide acceptance of this approach [Perk01]. Since a significant proportion of pervasive devices
have limited CPU power, memory, energy, and storage, implementing such resourcedemanding processes on them might not be feasible or efficient. In particular, the complexity
of algorithms for transformations of text and image are fairly low, but transcoding algorithms
for audio and video are complex and demanding, making their implementation on small and
not powerful devices, such as PDAs and mobile phones, extremely difficult.
2.2.2.3
Proxy-Based Adaptation Approach
The third approach in locating the adaptation mechanism is a compromise between the two
extremes discussed above. It places the mechanism within the end-to-end path, at an
intermediate node identified as the most appropriate for performing effectively the adaptation.
Some examples of proxy-based systems are [Sing04, Wee03, Kim03, Chandra00, Fox98a
Angin98, Bick97, Noble97]. The intermediate node usually denoted as proxy or gateway (See
Figure 2.3), intercepts the reply from the server, decides on and performs the adaptation
according to the user’s preferences, device capabilities and network conditions, and sends the
adapted content to the client.
Content Adaptation
31
Application
Server
Wireless Device Base Station
Adaptation
Point
Proxy
Server
Figure 2.3: Proxy-Based Adaptation
There are several advantages that come with the adoption of the proxy solution. First,
intermediate adaptation shifts computational load from content server to proxy server.
Second, the proxy can be located at the most critical position in the end-to-end path. It is
usually assumed that the bandwidth between the proxy and the server is much higher than
between the client and the proxy [Antonio97], so that the time to download the original
content from the server to the proxy is less compared to the time required from proxy to the
client. For example, let us consider a case that a wireless device accesses to the Internet
through a base station (router) which is connected by wired line. In this case, the last
(wireless) hop is expected to be the bottleneck, which indicates that the proxy will perform
ideally if it resides at the router or as close to it as possible. Putting at the last hop enables the
proxy to have a global picture of the environment resources such as network latency and
bandwidth, content size to be transported before the final delivery, user preferences, any
changes that may occur, etc. Therefore, the flexibility of locating the adaptation mechanism at
the best position in the end-to-end path is an important advantage of the proxy solution over
the other two approaches. The proxy server also plays another important role, that is, it can
cache the results of content adaptation, thus avoiding some roundtrips to the content server
and costly transcoding operations when resources can be served from the cache [Singh04,
Fox97].
32
Chapter 2. Related Work on Content Adaptation
Third, adapting on the proxy means that there is no need to change the existing clients and
servers, and it achieves economy of scale more than a server-based approach since each proxy
can transform content for many servers. One potential problem of this approach is that the
proxy might not have access to context information needed for a satisfactory operation during
transcoding. This problem can be solved by providing context information containing implicit
or explicit guidance to the proxy as in the case of context-aware adaptation [Lei01a, Yau01,
Dey99a]. For example, in server-directed transcoding [Mogul01], the server provides the
context information.
Naturally, the proxy solution also presents some disadvantages. First, it has limited scalability
because of significant computational costs of adaptation operations [Lum02b]. Second,
having an intermediate intercepting the content raises security issues. The (usually) thirdparty operating the proxy must be trusted by the receiver and the source. In the absence of a
trusted third party the proxy approach has no way of adapting the multimedia content. In
addition, the third party may charge for the service it provides and the resources it employs to
perform the adaptation for the receiver. Therefore, accounting mechanisms should be
incorporated in the proxy solution in order to keep track of the amount of resources utilized
and the usage of the data. Third, the list of content adaptation tools is not exhaustive and
might include other in the future so accommodating these new tools may not be possible if
especially the proxy is not extensible. Finally, putting all adaptation functionalities into the
proxy requires powerful CPUs and a lot of memory.
2.2.2.4
Distributed and Agent Based Adaptation Approach
A distributed based approach for content adaptation is quite recent. There are very few works
such as MARCH [Ardon03], Ninja [Gribb01] and DANAE [Hutter05] that propose platforms
based on this approach. The Mobile Aware server aRCHitecture (MARCH) [Ardon03] project
enables the creation of a service-based overlay network, by deploying several proxies at
various points along the data path between the client and the server. MARCH is a servercentric approach in which the decision on the adaptation is done at Mobile Aware Server
(MAS) which is the front end to the content servers. The archicteure has a dynamic proxy
execution environment called Compute Servers (CS) that facilitates uploading of proxies on
session basis and allowing the placement of the required proxies at optimal points along the
data path. The Mobile Aware Server (MAS) is responsible for determining what proxies are
Content Adaptation
33
required to provide the optimum service for a set of operating conditions and deciding where
to execute these proxies. MARCH allows using several proxies to compose the required
service. In the MARCH solution, a client entity needs to be installed in the client device in
order to route applications’ traffic to proxies. This makes MARCH less transparent and also
lacks interoperability and flexibility. Moreover, the decision for the adaptation is done at the
server hence it shares the drawbacks of the server-based approaches.
In the Ninja project [Gribb01], several proxies, each with a specific transcoding capability are
put at different locations in the end-to-end path and the data passes through the path while
being adapted by each proxy according to the need. The project conceives a mechanism to
dynamically establish an adaptation path through several proxies to compose a complex
adaptation service. While this resolves the computational problem, it has its drawbacks. First,
Ninja is intended to provide robust cluster-based services, and it does not consider dynamic
adaptation of data paths or of the paths’ components [Bust01]. Second, it can handle only a
sub-set of adaptation techniques such as image transcoding. Third, it is not easily deployable
as one needs to put the proxies at different points in the delivery path. Finally, no mechanism
is developed to select an optimal adaptation path.
The Dynamic and distributed Adaptation of scalable multimedia coNtent in a context-Aware
Environment (DANAE) [Hutter05] is an IST7 European co-funded project that proposes a
platform for dynamic and distributed adaptation of scalable multimedia content in a contextaware environment. The project covers three major works: the definition of scalable media
formats, the adaptation of multimedia content to session context and the transport and
delivery of multimedia content to the end user. Specific feature of the DANAE platform is
that it provides distributed adaptation by offering adaptation both at the content server and at
intermediate network nodes. This is achieved by implementing the adaptation decision engine
at the different nodes (adaptation nodes). The adaptation nodes collect context information
from the client nodes, merge the context information (by enriching with the adaptation nodespecific descriptors such as supported adaptations) and send the merged context information
to the content server. The content server adapts the content to the quality level requested by
the adaptation node based on the merged context information. The adapted content
corresponds to the highest media quality which satisfies the requests of all terminals
7
IST: Information Society Technology
34
Chapter 2. Related Work on Content Adaptation
connected to the adaptation node. The content server sends the adapted content together with
its content-related metadata to the adaptation node. The adaptation node may further adapt the
content to provide it in optimum way to each terminal.
DANAE is designed based on MPEG-21. This limits its use other than MPEG-21 formats.
While DANAE allows distributed adaptation by using several adaptation nodes, both the
adaptation tool(s) and the adaptation decision engine should be implemented at each node.
Moreover, each node may not have the same type of adaptation tool(s) which further
complicates the implementation of the adaptation nodes.
Angela et al. [Ramos05] developed agent-based framework called PUMAS (Peer Ubiquitous
Multi-Agent Systems) to provide adapted Web content. The framework consists of four
Multi-Agent Systems (MAS) each providing particular function and communicates with other.
The agents are in charge of connection, communication, information transmission and
adaptation. The Connection MAS provides mechanisms for facilitating the connection from
different kinds of devices to the system. The Communication MAS ensures a transparent
communication between the user device and the system. It also adapts information according
to the technical constraints of the user’s device. The Information MAS receives user queries,
redirects them to the right source of information (e.g. the one which is the most likely to
answer the query). This MAS adapts information according to the user’s profile in the system
(preferences) and returns filtered result to the communication MAS. In charge of the
adaptation, the agents of the Adaptation MAS communicate with the agents of the three other
MAS in order to exchange information about user and about the context. The system considers
only one aspect of adaptation which is content filtering while other adaptations are very
important to deliver multimedia content such as transcoding, transmoding etc. Moreover the
system does not have a mechanism to provide a complex adaptation need that can be realized
by chaining of adaptation agents. For example to deliver an MPEG-1 format video with high
frame rate to a device supporting only MPEG-4 video and with less bandwidth connection, we
need to apply at least format conversion (MPEG-1 to MPEG-4) and frame rate reduction. This
type of adaptation scenario can not be realized without chaining adaptation agents but the
system does not have such mechanism.
Content Adaptation
2.2.2.5
35
Ongoing Standardization for Content Adaptation
The IETF8 Working Group has recently proposed the Open Pluggable Edge Services (OPES)
[Barbir02] and the Internet Content Adaptation Protocol (iCAP) [Elson01] defining the basic
functions of future caching proxy. iCAP defined how various caching objects can be
transported from one cache to another. OPES provides some interesting capabilities to
caching proxies. An OPES proxy can be equipped with message parsers, rule modules, and
proxylets library. When messages flow through an OPES proxy, not only it is cached but they
can also be automatically parsed and processed with these rules. The OPES proxylets can
execute the processing in the caching proxies, or optionally can call for remote callout
services via protocols such as iCAP [Lee01]. This approach does not provide enough
flexibility in accommodating various service arrangements that may arise in the real service
deployments, which often restricts where, when and how the service can be performed,
redirected, and who may provide the service specifications. Second, OPES is limited to Web
content and can not be used with any distributed multimedia applications. Finally, OPES is
not developed particularly for content adaptation purpose, it also includes localized
advertisements, virus scanning, personalized data insertion, etc. hence it is not optimized.
The MPEG-21 [Burn03] is a work in progress aiming to enable the use of multimedia
resources across a wide range of network devices by developing an open framework for
delivery and consumption. One part of MPEG-21 is the Digital Item Adaptation, that defines
description tools for usage environment and content format features for the purpose of
transparent access to the multimedia content. These tools enable the adaptation engine to
make better decision in order to provide the best content to the user. The implementation of
the engine that actually performs the required adaptation steps to the multimedia content is
left to tool vendors and is beyond the scope of standardization. The MPEG-21 DIA tools
guarantee an efficient adaptation of multimedia content but its focus on the MPEG-21 content
limits its application [Leml04].
8
Internet Engineering Task Force (IETF), http ://www.ietf.org.
36
Chapter 2. Related Work on Content Adaptation
2.2.3 Content Adaptation Systems
Research towards content adaptation solutions has been the focus of several academic
communities, commercial companies, and standard organizations in order to achieve
ubiquitous access to multimedia content. In the following section, we describe the main
application systems and research prototypes which support content adaptation.
2.2.3.1
Commercial/Open Source Products
Since the importance of adaptation has been recognized by the Internet community, several
commercial products have emerged that try to incorporate the concepts and techniques of
adaptation in order to provide multimedia data access to heterogeneous terminals and users.
The most notable products are presented in the following section.
IBM Transcoding Proxy
The Mobile Networking Group at IBM has developed a transcoding proxy for multimedia
adaptation in order to be displayed in small devices like PDAs and mobile phones [IBM00].
The transcoding proxy was first developed as a research prototype in 1999 for adapting
Internet traffic to PDAs and mobile phones. Later it became a commercial product. For PDAs,
text is summarized, images are transcoded into grayscale equivalents and audio and video is
analyzed and presented as text whenever possible. For mobile phones, text is summarized into
single headline, images are omitted and audio and video are transcoded into speech describing
them. The transcoding proxy is commercially available and one can download for a 90-day
trial from the IBM site (http://www.alphaworks.ibm.com/). One of the problems of the
transcoding proxy is that it is the user that must select what transcoding he/she needs to be
carried on the content by configuring the proxy. This limits the dynamicity of the system as
parameters such as network conditions can vary continuously. Moreover the transcoding
options are limited, for example for html text, there is no language translation, and for images,
there is not format conversion.
Content Adaptation
37
WebSphere Transcoding Publisher
The experience gained from the transcoding proxy developed for the Internet access helped
IBM to develop a product called WebSphere Transcoding Publisher [Rodr01]. The product
was first released in 2000 and went through two additional releases before becoming a
technology embedded in WebSphere Portal and the webSphere EveryPlace Server. It is a
server-based software that dynamically translates Web content and applications into multiple
markup languages and optimizes it for delivery to mobile devices based on user preferences
and device capabilities. Content adaptation for many devices and languages eliminates the
need to maintain multiple versions of a web site. The product can convert images to links to
retrieve images, convert tables to lists, and remove comments and features not supported by
the device. The product comes with a wide variety of standard transcoders including:
- HTML to WML, cHTML, HDML, PalmOS HTML, and VoiceXML
- XML to wide variety of formats through XSLT style sheets
- JPEG/GIF/WBMP image transcoding and rescaling
- Natural language translation
One important feature of WebSphere transcoding is that it provides a pluggable infrastructure
to add transcodings for new data types. However, its plug-and-play architecture is more
tightly-coupled. Specifically, to add a new transcoding capability, a developer has to use the
developer’s toolkit to develop or re-develop a program so as to make the program pluggable
into the system. This limits the interoperability of the system. Moreover, since the transcoidng
is done at the content server it has limited scalability.
Web Clipping
Palm Computing introduced “Web clipping” in 1998 as an HTML transformation process for
its products Palm VII [3Com]. The goal of Web Clipping is to minimize both display
requirements (to fit on the Palm’s screen), and bandwidth usage by optimizing page layouts,
graphics and contents. During an HTML access, the request is redirected to the central server
of the company, which acts as proxy for the PDA. The proxy retrieves the web page, discards
the redundant objects and transforms the content to fit in the PDAs screen. It then starts
transmitting only the objects that will immediately be displayed, while it holds the rest of
them for later transmission upon request. Thus, the power consumption is reduced to
38
Chapter 2. Related Work on Content Adaptation
minimum. Web clipping which was first introduced to adapt Internet content for Palm VII
device which was basically text-based display later extended to other palm devices.
On 2001 Maporama9, the European leader in online cartography and geocentric information,
and Palm, announce their international content partnership for the distribution of Maporama’s
cartographic and geocentric content onto all new Palm products via Palm’s Web clipping
technology. Geographic content is one of the commodities Internet users seek the most
frequently. Since the customers are, by default, mobile users, this service becomes a real need
for them. Palm and Maporama have teamed up to provide users value-added geocentric
services compatible with their hardware. Maporama’s three most essential functionalities maps (both country and street level detail), itineraries (both door-to-door and city-to-city), and
pan-European directories - are accessible from all Palm’s new handheld computers. Locationbased weather forecasts are also available.
Web Clipping does not have transcoding tools so it does not solve the format and modality
mismatches between content and devices. Moreover, it is specifically designed for Palm
handheld devices.
Morphis Wireless Content Transcoder
Morphis10 is an open source java based Web content transcoding, transformation, translation
and aggregation framework. The first version of the product was released in 2001. It was
primarily built for retrieving and translating XML based documents, but it is also capable of
performing any type of translation: binary, plain text, or text markup. Therefore, Morphis is
able to convert XML into HTML or WML, while also being able to scale, crop and convert
images on the fly. Central to the Morphis solution is WAX (Wireless Abstract XML), a set of
tools and an abstract markup language used to author content for wireless applications.
Content is written once in WAX language, and then translated to various wireless languages
via XSL style sheets. The limitations of Morphis are (1) it is server-based so it has limited
scalability (2) WAX is used for content authoring hence it does not support other content
formats (3) the transcoding tools are limited to images.
9
Maporama SA, Paris, develops and markets Maporama.com, an Internet portal dedicated to providing detailed
geographic information (for example town plans) across the world from any Internet enabled device such as a
PC, Palm-Pilot, WAP or WebTV (www.maporama.com).
10
Morphis: http://www.morphis.org/
Content Adaptation
39
Oracle Application Server Wireless
Oracle Application Server Wireless [Oracle03] is the mobile component of the Oracle
Application Server. It includes a multi-channel server which abstracts the underlying
networks, protocols, devices and gateways to one protocol and one language, namely HTTP
and XML. The server enables applications to be accessed through multiple delivery methods
and devices such as 2-way pagers, devices with SMS, MMS, voice, or WAP capabilities, and
handheld computers. The server automatically translates applications written in Oracle
Wireless XML, XHTML Mobile Profile, or XHTML+XForms for any device and network.
For example, an XHTML+XForms application passed through the Multi-Channel Server will
be translated to VoiceXML if a phone is accessing the application through a voice interface or
to WML if a WAP phone issues the request. The system also supports device-specific
adaptation of images, ring tones, voice grammars, audio and video streams. For example,
images can be dynamically adapted to suit the image format, color depth, size and aspect ratio
requested by the device. Ring tone adaptation allows for conversation of ring tone to formats
supported by the most popular phones.
The major limitations of the Oracle Wireless server are: (1) the server is placed on the content
so it has limited scalability; (2) it does not support content formats other than XML; (3) it is
developed for applications developed in oracle.
Sun Java System Portal Server Mobile Access
The Mobile Access pack is an extension to the Sun Java System Portal Server11. It enables
wireless access to the portal and extends the core portal services (session handling,
authentication, logging, e-mail, calendar, address book, discussions etc.) to mobile devices.
Java System Portal Server Mobile Access can dynamically render and deliver personalized
and aggregated content to users with wireless mobile devices, such as cell phones, PDAs, and
smart phones, over any wireless network connection. The server dynamically renders content
into different markups such as XML, HTML or WML and tailors it to make the best use of
the requesting device’s features. The Mobile Access pack uses a templating system based on
JSP technology for accessing applications or XSL style sheets for accessing XML content.
11
http://wwws.sun.com/software/products/portal_ma/index.html
40
Chapter 2. Related Work on Content Adaptation
XSL templates are used to transform the XML data into any markup language including
XHTML, WML and VoiceXML [Sun].
The major limitations of the Sun Mobile Access are: (1) it has no transcoding tools and apply
only structural transformation such as XML to WML; (2) it is server-based approach so it has
limited scalability; (3) it has limited application since it supports only XML content format
Summary on commercial/open products
To conclude, the commercial application systems that have been presented above show the
importance of content adaptation to deliver content in heterogeneous and wireless
environments. The systems are developed mostly for web contents and they are specific, for
example, the Oracle Wireless Server is developed for Oracle applications. The systems are
more interested in structural transformation such XML to WML. These works did not deal
with the problem of content adaptation from the perspective of service that is providing
content adaptation as a service accessible on Internet. Instead, they looked into the
deployment of content adaptation technology at an origin server or a transcoding proxy hence
they have limited scalability. Moreover, they do not consider adaptation paths where we can
have several adaptation chains to be applied on the content and no path optimization is used.
2.2.3.2
Research Prototypes
The emergence of pervasive computing as a result of advance in computing and
communication technologies opens several new research projects in different academic and
research institutions. The focus of these projects is mainly centered on developing adaptation
system platforms for delivering adapted content in heterogeneous access environment. There
are many platforms proposed by the research community. Here, we present the most
important platforms for purpose of comparison.
Content Adaptation
41
TranSend
UC Berkeley’s TranSend Web accelerator proxy [Fox98b] was one of the earliest projects to
explore adaptation proxies aggressively. TranSend intercepts HTTP requests from standard
web clients and applies datatype-specific lossy compression when possible; for example,
images can be scaled down or down sampled in the frequency domain, long HTML pages can
be broken up into series of short pages, …,etc. TranSend supports a wireless vertical handoff
mechanism. When a client equipped switches between wireless networks, the client-side
vertical handoff software (which is completely independent of TranSend) generates a
notification packet containing some essential characteristics (e.g., estimated expected
throughput) of the new network. This packet would be sent to a special UDP port on
TranSend where the notification would be processed and stored in a per-client profile.
TranSend would then process future requests from that client in accordance with the new
network type; for example, very aggressive image downsampling will be performed for
clients connecting with an expected throughput of 15-25 Kb/s, whereas compression will be
much less aggressive (and in some cases disabled) for WaveLAN clients connecting at about
1 Mb/s. Because HTTP is a “stackable” protocol (i.e. it is possible to have several HTTP
“hops” in a request chain), TranSend-based adaptations are naturally composable, allowing a
multilevel system with some “baseline” compression performed far upstream, and additional
compression performed near the clients. Later on, TranSend has been commercialized (mostly
to adapt Web content for display on personal digital assistants (PDAs), for example, for 3Com
PalmPilot) by Proxynet (http://www.proxynet.com).
TranSend adapts contents on-the-fly in a proxy between the client and the Web Server.
Composability support of TranSend enables to apply several adaptations on the content.
Major drawbacks of the system include:
•
The design assumes a single point of adaptation, at the proxy server, this limits its
scalability.
•
The adaptation is primarily limited to image compression and reduction of image size
and color space.
•
It does not provide a mechanism to adapt content to user preferences.
42
Chapter 2. Related Work on Content Adaptation
Odyssey
Odyssey is a system built at CMU to support challenging network applications by adjusting
the quality of accessed data to match the available resources [Noble00]. Odyssey particularly
focuses on resource management for multiple applications running on the same machine.
Odyssey was designed primarily to run in wireless environments characterized by changing
and frequently limited bandwidth, but the model is sufficiently general to handle many other
kinds of challenging resource management issues, such as battery power or cache space. The
goal of the system is to provide all applications on the portable machine with the best quality
of service consistent with available resources and the needs of other applications.
Odyssey is an application-aware approach to adaptation intended primarily to assist
client/server interactions. The Odyssey system consists of a viceroy, an operating system
entity in charge of managing the limited resources for multiple processes; a set of data typespecific wardens that handle the intercommunications between clients and servers; and
applications that negotiate with Odyssey to receive the best level of service available.
Applications request the resources they need from Odyssey, specifying a window of tolerance
required to operate in a desired manner. If resources within that window are currently
available, the request is granted and the client application is connected to its server through
the appropriate warden for the data type to be transmitted. Wardens can handle issues like
caching or pre-fetching in manners specific to their data type to make the best use of the
available resources.
If resources within the requested window are not available, then the application is notified and
can request a lower window of tolerance and corresponding level of service. As conditions
change and previously satisfied requests can no longer be met (or, more happily, conditions
improve dramatically), the viceroy uses upcalls registered by the applications to notify them
that they must operate in a different window of tolerance, possibly causing them to alter their
behavior.
Odyssey became part of the Aura project [Garl02] that was developed by the research
community at Carnegie Mellon University. The drawbacks of the Odyssey system are:
•
The Odyssey system assumes that content in different versions is always pre-created.
But it is difficult to generate all possible versions that match different contexts.
Content Adaptation
•
43
It is specifically designed for adaptation to network characteristics but not to device
capabilities and user preferences.
•
The need to modify the operating system kernel and its specificity to the Odyssey file
system limits its application.
•
It requires the addition of a module on the client.
Conductor
The UCLA Conductor system allows deployment of cooperating adaptive agents at specially
enabled nodes throughout a network [Yarvis01]. Conductor is an application-transparent
adaptation mechanism. Applications can benefit from Conductor without being recoded or
explicitly requesting its services. Instead, the underlying system is configured to indicate what
kinds of data flows Conductor is capable of assisting and the Conductor system automatically
traps and adapts those data flows. Conductor also handles issues of composing adaptations in
support of a single flow at multiple nodes. Conductor determines the characteristics of the
data path from source to destination and estimates if the path will meet the needs of the
applications using it. If not, Conductor automatically deploys adapters at one or several of the
available nodes along the path to adapt the data flow to network conditions, allowing better
application-visible network behavior. Conductor plans the cooperative behavior of the agents
and handles problems of transient or long-term failure of particular adapter nodes.
Conductor is designed to handle both lossy and lossless adaptations. Combining lossy
adaptations and reliability is especially challenging, since a lossy adapter may drop part of the
data or may transform several data packets into fewer packets. If an adapter or its node fails,
some of the adapted packets could be delivered while others were not. Without the lossy
adapter’s state to determine which original packets were dropped or coalesced, the system
may find it difficult to resume transmission without either duplicating already received
information or failing to deliver required information. Unaware applications are generally
unprepared for either problem, so Conductor must hide these problems from such
applications. Conductor attaches numbers to pieces of semantic content that do not vary when
adapted. For example, if every other packet is dropped, the undropped packets are
renumbered to include the dropped packets. The system is thus able to determine which
information has and has not been delivered despite failures.
44
Chapter 2. Related Work on Content Adaptation
Conductor permits the introduction of arbitrary adaptors in the data path between applications
and end services. This solves the incompatibility issues between heterogeneous networks.
However, the system has three major drawbacks: (1) it does not handle device limitation and
user preferences (2) the lack of application input limits its flexibility and (3) a significant
change to existing infrastructure is required for its deployment that is the network nodes must
be
conductor-enabled.
The
software
package
is
available
on
the
net
(http://lasr.cs.ucla.edu/Conductor/).
Digestor
Digestor [Bick99] is a software system that automatically re-authors documents from the Web
to display them appropriately on small screen devices such as PDAs and mobile phones. It
can be run on HTTP proxies so that online documents can be adapted to different client
devices. Re-authoring is the re-structuring of the documents such that they can be presented
on the resource-constrained devices. Techniques for re-authoring includes outlining (e.g.
section headers made into hyperlinks with the contents elided from the document), first
sentence elision (the first sentence of each block made into a hyperlink), and image reduction
and elision (images are scaled down and the reduced images have hyperlinks back to their
originals).
Digestor makes use of an automatic re-authoring system to select the best combination of the
re-authoring techniques for the document/display-size pair. The system uses heuristics to
understand the web documents to enable re-authoring decisions. However, the potentials of
such heuristics are limited [Buch03]. In order to overcome those limitations, other work
considers generic XMLbased representations of documents that are augmented by meta
information to allow smarter adaptation (e.g. [Goeb01]).
The drawbacks associated with the Digestor system are: (1) the concept of re-authoring
requires semantic understanding of the structure of the document which is not always evident
especially to adapt content on-the-fly; (2) the system focuses on different display size rather
than device capabilities or network condition; (3) it applies only structural transformation and
no support for media transcoding; (4) Digestor users are required to specify the size of display
for their device and the size of their default browser font to estimate the screen area
requirements of the text blocks.
Content Adaptation
45
Mowser
Mowser (Mobile Browser) [Joshi00, Bhra98] is a transcoding proxy that modifies the HTTP
stream and changes its content dynamically. It allows users to set their preferences based on
their needs and the capabilities of the devices, such as video resolution, sound and color
capabilities, maximum sizes for each type of files, etc. These preferences are stored in an
Apache server. When the proxy receives a request from the client, it looks up the preferences
that are stored with the IP address of the client, and modifies the HTTP request according to
the preferences before sending to the server. Mowser introduces what is known as content
negotiation. Different variants (or fidelities) of the web contents are stored in the server. The
proxy asks the server for one of the fidelities that is available, and which satisfies the
requirements of the client. If the one that is returned by the server is still too large for the
client, transcoding is applied. The kind of transcoding that is applied depends on the file type.
For example, the size or color depth of an image is reduced, and representative frames of a
video file are selected. The proxy can also parse the HTML stream to remove active contents
and tags that the clients cannot handle. Any contents that cannot be processed by the client are
not returned. Different from other transcoding proxies, Mowser also considers the user
preferences apart from the capabilities of the client devices. The authors claimed that the
proxy is available on the net (http://nirvana.cecs.missouri.edu:8001) but it was not working
during verification.
Since users may have dynamic IP addresses, the use of IP address to store user preferences is
not a good solution. Another limitation of the system is creating content variants require
additional storage.
ADMITS (Adaptation in Distributed Multimedia IT Systems)
ADMITS [Bosz03] [Bosz02] project was initiated at the University of Klagenfurt, Austria,
and is still under development. It realizes a distributed multimedia architecture, which adapts
its behavior to changing resource availabilities. The goal in the ADMITS project is to access
multimedia resources, from different types of terminals and/or over diverse networks and
make this access interoperable and transparent. This distributed multimedia system comprises
several components, such as media servers, meta-databases, adaptive proxy cache, and
adapative routers. The proxy cache stores full videos with their respective metadata
46
Chapter 2. Related Work on Content Adaptation
descriptions in the form of MPEG-7 Variations Descriptors, and it reduces their quality (and
thus their size), before fully deleting them. The essential innovation is that the quality
reduction process is driven by metadata in a standardized format (MPEG-7), which is readily
provided in ADMITS by the meta-database.
The routers can cope up with dynamically varying network load and multicast media stream
along heterogeneouse links clients with different capabilities by applying some adaptation
operations such as dropping of video frames, of certain enhancement layers, or of entire
MPEG-4 Elementary Streams.
The ADMITS project builds an experimental distributed multimedia system for investigations
into adaptation. The MPEG-7 technology is widely used and provides tools, such as the
variation description scheme, which enable the components to communicate adaptation
metadata in a standardized form. The major distinguishing feature of the ADMITS approach
is that (MPEG-conforming) meta-data are used to steer the adaptation processes in
components on the delivery path to the client (e.g., proxies, routers).
Major limitations of ADMITS are (1) the need of processing and storing content variants at
the server (2) the routers must be MPEG-7 compatible to apply some adaptations on the data.
Summary of Content Adaptation Systems
Table 2.2 summarizes the adaptation approach or architecture, transcoding type, and
adaptation target (network, device and user preferences) of the content adaptation systems
discussed above both commercial/open and research.
Content Adaptation
Adaptation
system
IBM
Transcoding
Oracle
Adaptation
approach
Proxy-based
server-based
Sun
Web Clipping
WebSphere
47
Transcoding type
Network
conditions
Yes
Device
capabilities
Yes
User
preferences
Yes
Remark
Images, ring
tones
Yes
Yes
Yes
Server-based
Proxy-based
Server-based
No
No
JPEG/GIF/WBM
P images
Not known
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Uses
proprietary
XML for
authoring
XML to any
MobiXstar
Proxy-based
Yes
Yes
Not known
Morphis
Server-based
Image,
animation, audio
and video
Images
No
Yes
No
TranSend
Proxy-based
Yes
No
No
Odyssey
Middleware
Image and text
compressors
Selection
Yes
No
No
Conductor
Data filtration
and compression
Image reduction
Yes
No
No
Digestor
Multiple
network nodes
Proxy-based
No
Yes
No
MOWSER
Proxy-based
Image and video
No
Yes
Yes
ADMITS
Multiple
network nodes
Video
Yes
Yes
Yes
Image and text
XML to wide
variety
Proprietary
XML used
for authoring
HTML
Uses preadapted
version
considers
only display
size
content
variants
stored at the
server
content
variants
stored at the
server
Table 2.2: Summary of Content Adaptation Systems Features
There are at least four general requirements that a good content adaptation framework should
meet to be effective in a pervasive computing environment. Characteristics of these
requirements are described below:
Extensibility: one major difficulty with content adaptation is that all the adaptation tools can
not be exhaustively determined beforehand. It is difficult to develop a system that can answer
all adaptation demands which are multidimensional. The framework should therefore be
extensible to handle new data object types and content adaptation tools, including those not
yet known. To that end it should comprise of independent, modular and pluggable tools that
48
Chapter 2. Related Work on Content Adaptation
can be easily added, replaced or modified. The tools should perform a single function to
enable reusability and enforce robustness.
Flexibility: pervasive computing is the ability to extending applications and services normally
conducted on office computers to handheld and wireless devices enabling anyway, anytime
with any device access to information systems. This means we can create pervasive systems
from existing applications. Thus, the adaptation framework must be flexible enough to be
easily integrated to existing applications without the need of major alteration on the
applications.
Interoperability: today, application developers use a wide range of programming models,
languages and development environments, and this heterogeneity will continue in the future,
particularly as the range of use for computing technology expands. Thus, the framework must
support diverse types of software components; one of them is the adaptation tools. The
framework must integrate adaptation tools residing in fundamentally different environments,
into compositions that can successfully interact and cooperate to achieve an adaptation need.
This will require interoperability at the component level in addition to interoperability that
overcomes heterogeneity of the environment and components.
Scalability: one of the features of pervasive computing is the increasing availability of
devices and software. Thus, the framework, the interactions between components, and the
software services provided in the pervasive computing environment must all be scalable. Most
importantly, the adaptation framework should perform incremental scalability with an
expanding user base.
Table 2.3 shows a comparison of each of the architecture with respect to the requirements for
good adaptation framework that are presented above.
Summary
Properity
49
Extensibility
Flexibility
Interoperability
Scalability
Server
+
-
+
+
Client
-
-
-
-
Proxy
++
+
++
++
MARCH
++
+
-
+
Ninja
++
+
+
++
DANAE
+
+
-
++
PUMAS
+
+
+
+
Architecture
Table 2.3: Architectural Characteristics of Adaptation Approaches
To summarize, there have been many efforts done to develop different approaches and
techniques of multimedia content adaptation for pervasive environments. A number of
commercial products and research prototypes have been developed that provides different
adaptation techniques to deliver multimedia data in a heterogeneous environment. These
products have contributed a lot to propose different architectures and techniques of adaptation
strategies. However, none of them have addressed well the interoperability, extensibility,
flexibility, and scalability issues of content adaptation which are important requirements in
pervasive computing environment. Moreover, most of the systems are designed only for
narrow needs and do not provide a general adaptation solution. In this thesis, we try to address
these issues.
2.3 Summary
In this chapter we presented the most important and relevant works to the subject of this
thesis. We have discussed major adaptation techniques and their classification. We have also
discussed the different adaptation approaches that have been proposed in the literature their
advantages and drawbacks. Commercial and research adaptation systems and their features
were also presented. Since each of these systems fall in one of the approaches, comparison of
50
Chapter 2. Related Work on Content Adaptation
the different approaches with respect to the requirements of a general adaptation framework
for pervasive computing was done.
Chapter
3
Service-Oriented
Architecture & Web
Services
One of the aims of our research was to develop a generic distributed content adaptation
framework. To achieve this we chose a Service-Oriented Architecture (SOA) based on web
services. In addition to providing a generic framework, the SOA enables to realize different
adaptation scenarios by using externally developed adaptation tools (implemented with web
service technologies). The purpose of this chapter is to present briefly the SOA and its
associated technologies. Section 3.1 presents the major concepts of the SOA. Some features
of the SOA are presented in Section 3.2. Web Service standards and related technologies are
presented in Section 3.3. Discussion on web service composition is presented in Section 3.4
and finally the chapter ends with a short summary in Section 3.5.
3.1 Introduction
In traditional approach to software design and packaging, all the components of a software
system are packaged together, even though most of them are used rarely. Over the last four
decades, software architectures have attempted to deal with increasing levels of software
complexity. But the level of complexity continues to increase, and traditional architectures
seem to be reaching the limit of their ability to deal with the problem. We have gone through
multiple computing architectures designed to allow fully distributed processing, programming
languages designed to run on any platform, greatly reducing implementation schedules, and a
myriad of connectivity products designed to allow better and faster integration of applications.
However, the complete solution continues to elude us. A service-based computing paradigm
52
Chapter 3. Service-Oriented Architecture & Web Services
approach was introduced to handle the ever increasing complexity of modern software
systems.
The service-based paradigm is a more flexible approach in which software components are
loaded on demand, i.e., only when their services are actually requested by the application, and
removed when these services are not needed any more. Such components will be referred to
as service components, in order to distinguish them from the more traditional view of
components as independent entities in their own right [Szyp02].
A SOA [Ort05] is an information technology approach or a strategy in which applications
make use of (perhaps more accurately, rely on) services available in a network such as the
World Wide Web. As shown in Figure 3.1, a SOA has three types of elements: service
provider, service user and service publisher. A service provider develops the services and
publishes them on a directory or registry. The service user also called customer or client
searches for services that provide the task he/she wants to achieve in the directory. The
service registry can also be coupled with a repository component that stores additional
information about each service such as business process information or service use costs.
A service provides a specific function, typically a business function, such as analyzing an
individual's credit history, processing a purchase order or image format conversion (in case of
adaptation services). In this thesis each service implements a particular adaptation tool, for
example, image resizing, language translation, text to speech conversion etc.
Multiple services can be used together in a coordinated way. The aggregated, or composite,
service can be used to satisfy a more complex user requirement. In fact, one way of looking at
a SOA is as an approach to connecting applications (exposed as services) so that they can
communicate with (and take advantage of) each other. In other words, a SOA is a way of
sharing functions (typically business functions) in a widespread and flexible way.
Benefits of Service-Based Development
53
Customers
Client
Service
Business
partners
Service
Directory
Service
Service
Communicate
Publish
Find
Figure 3.1: A service-Oriented Architecture (SOA) [Ort05]
Though the SOA is not a new concept, the emergence of web services made it important tool
to develop distributed application systems [Rao04]. A web service is a service that
communicates with clients through a set of standard protocols and technologies. These web
services standards are implemented in platforms and products from all the major software
vendors, making it possible for clients and services to communicate in a consistent way across
a wide spectrum of platforms and operating environments. This universality has made web
services the most prevalent approach to implementing a SOA.
3.2
Benefits of Service-Based Development
Complexity is a fact of life in information technology (IT). Dealing with the complexity while
building new applications, replacing existing applications, and keeping up with all the
maintenance and enhancement requests represents a major challenge [Lomo04].
Service-based development provides the following benefits which are more appropriate to our
work:
54
Chapter 3. Service-Oriented Architecture & Web Services
Interoperability: the objective of SOA is to enable clients and services to communicate and
understand each other no matter what platform they run on. This objective can be met only if
clients and services have a standard way of communicating with each other - a way that is
consistent across platforms, systems, and languages. In fact, Web services provide exactly
that. Web services comprise a maturing set of protocols and technologies that are widely
accepted and used, and that are platform, system, and language independent.
Scalability: because services in a SOA are loosely coupled, applications that use these
services tend to scale easily, certainly more easily than applications in a more tightly-coupled
environment. That's because there are few dependencies between the requesting application
and the services it uses. On the other hand, in a tightly-coupled environment it is more
complex to make the services accessible by many applications.
Flexibility: loosely-coupled services are typically more flexible than more tightly-coupled
applications. In a tightly-coupled architecture, the different components of an application are
tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it
difficult to evolve the application to keep up with changing technology or business
requirements. The loosely-coupled nature of services in SOA allows applications to be
flexible, and easy to evolve with changing requirements.
3.3
Web Services: Standards and Related Technologies
The term “Web services” has been used very often nowadays. According to IBM [Gard01],
“Web Services are self-contained, modular applications, accessible via the Web through open
standard languages, which provide a set of functionalities to businesses or individuals”. This
definition places the emphasis on two points. The first point is that a Web service is seen as an
application accessible to other applications over the Web. Secondly, Web services are open,
which means that services have published interfaces that can be invoked by message passing
standards. This definition is very simple, but not precise enough. For instance, components in
Common Object Request Broker Architecture (CORBA) are also modular and self-contained
but they are not web services. A step further in refining the definition of Web service is the
one provided by the World Wide Web consortium (W3C) [Aust02]:
Web Services: Standards and Related Technologies
55
“A Web service is a software system identified by a URI, whose public interfaces
and bindings are defined and described using XML. Its definition can be discovered
by other software systems. These systems may then interact with the Web service in
a manner prescribed by its definition, using XML-based messages conveyed by
Internet protocols.”
The W3C definition stresses that web services should be capable of being defined, described,
and discovered [Alonso04]. It should also be emphasized that web services do not merely
provide static information, but allow one to affect some action or change in the world. For
example, in the case of content adaptation, services such as image color reduction, image
format conversion, video frame dropping etc. change the state of the media data.
What makes the web services attractive is the ability to integrate the web services developed
by different organizations together to fulfill the user's requirement. Such integration is based
on the common standards of web service interfaces, regardless of the languages that are used
to implement the web services, and the platforms where the web services are executed. In
general, the web services have the following features that make them better in integration
inside the heterogeneous environments:
Loosely coupled: in software development, coupling typically refers to the degree to which
software components/modules depend upon each other. Comparing with the tightly coupled
components (such as the Distributed Component Object Model (DCOM) or the CORBA)
[OMG02], the web services are autonomous and can operate independently from one another.
The loosely coupled feature enables Web services to locate and communicate with each other
dynamically at runtime.
Universal accessibility: the web services can be defined, described and discovered through
the Web that enables an easy accessibility. Not only the web services users can locate
appropriate services, but services can describe and advertise themselves so that they are
possible to bind and interact with each other.
Standard languages: although the cores of web services may be implemented by different
programming languages, the interfaces of web services are described by uniform standard
XML languages.
56
Chapter 3. Service-Oriented Architecture & Web Services
3.3.1 Web Service Languages
A web service provider offers services on the Web. He may choose to register his service at
an online registry of a service broker. The registry also provides standardized description
facilities, e.g. taxonomies that allow the description of 1) the functionality of a service, 2) the
information about the service provider, and 3) the way to access and interact with the service.
The corresponding information about a particular service is registered by the provider at a
broker.
The service requester searches for a service at the registry. He finds one by browsing or
querying the registry. Then he uses the service description to create a binding for his
application. The last step is to invoke or interact with the web service using standard
communication language. Standards such as XML, UDDI, WSDL and SOAP support the
above procedure.
UDDI [Bell02] provides a registry where service providers can register and publish their
services. The registry consists of three parts: white pages, yellow pages and green pages.
Contact information, human readable information and related information can be registered in
the white pages. Keywords that characterize the service are registered in the yellow pages.
Service rules and descriptions for application invocations are registered in the green pages
(technical). UDDI does not support semantic descriptions of services and no content language
for advertising is provided.
WSDL [Chinnici03] is a proposed W3C standard for describing network services as a set of
end points operating on messages containing either document-oriented or procedure-oriented
information. The operations and messages are described abstractly, and then bound to a
concrete network protocol and message format to define an endpoint. Related concrete
endpoints are combined into abstract endpoints (services). SOAP is typically used to deploy
the operations.
SOAP [Box00] is a proposed W3C standard for exchanging information in a decentralized
and distributed environment. SOAP consists of three parts: envelope, encoding rules and
Remote Procedure Call (RPC) representation. The envelope sets up a framework for what the
Web Services: Standards and Related Technologies
57
message contains and responsibility. The encoding rules provide a serialization mechanism
for exchanging instances of application specific data types. Finally, RPC makes it possible to
encapsulate and represent remote procedure calls and responses.
Both UDDI and WSDL do not include semantic information about the services. Currently
UDDI provides key-word based search. Keywords are not enough to discover the services as
service providers may use different words though they provide the same functionalities.
Moreover, UDDI does not enforce a relationship between the service names and their
functionalities. While WSDL describes the exchange data, it provides no semantic
information such as the service use, input output characteristics, the effect/consequence,
service cost and execution time, etc. However, semantic information is important for
automated adaptation service discovery and composition. Our adaptation services
composition bases on service compatibility which depends on the input, output, and quality
criteria such as service cost and execution time. Hence, UDDI and WSDL fail to provide
enough information about a web service (or an adaptation service in our case) in order to be
discovered and used automatically in real applications. In the following section we present
some of the tools that facilitate semantic service description.
3.3.2 Semantic Web Service Description
In IBM’s proposition, web services have simple rather than rich descriptions, the environment
is closed rather than open, the service requester is human rather than machine and data
exchange are syntactic rather than semantic [Solla02]. However, facilities to put machineunderstandable web service on the web are becoming a high priority for many communities.
To implement reliable and large-scale interoperation of web services, the services should be
computer interpretable. To have computer programs or agents implementing reliable and
large-scale interoperation of web services, the services should be computer interpretable. This
implies to have semantic web of services whose properties, capabilities, interfaces, and effects
are encoded in an unambiguous, machine-understandable form. The Semantic Web language
is a vision: the idea of having semantic service description that can be used by machines for
automation, integration and reuse across various applications. Semantic service description
should enable automatic service discovery, execution, composition and interoperation.
58
Chapter 3. Service-Oriented Architecture & Web Services
Automatic discovery involves automatically locating web services that provide a particular
service and that adhere to requested properties. Currently, a human must perform the
discovery task, first using a search engine to find a service and then either reading the web
page associated with that service or executing the service to see whether it adheres to the
requested properties. With semantic markup of services, we can specify the information
necessary for Web service discovery as computer-interpretable semantic markup at the service
Web sites, and a service registry or (ontology-enhanced) search engine can automatically
locate appropriate services.
Automatic execution involves a computer program or agent automatically executing an
identified web service. To execute a particular service on today’s web a user generally must
go to the web site offering that service, fill out a form, and click a button to execute the
service. Alternately, the user might send an http request directly to the service URL with the
appropriate parameters encoded. Either case requires a human to understand what information
is required to execute the service and to interpret the information the service returns. Semantic
markup of web services provides a declarative, computer-interpretable API for executing
services. The markup tells the agent what input is necessary, what information will be
returned, and how to execute—and potentially interact with—the service automatically.
Automatic composition and interoperation involves the automatic selection, composition,
and interoperation of appropriate web services to perform some task, given a high-level
description of the task’s objective. Currently, if some task requires a composition of web
services that must interoperate, then the user must select the web services, manually specify
the composition, ensure that any software for interoperation is custom-created, and provide
the input at choice points. With semantic markup of web services, the information necessary
to select, compose, and respond to services is encoded at the service web sites. We can write
software to manipulate this markup, together with a specification of the task’s objectives, to
achieve the task automatically.
Nowadays, there are many services accessible on the Internet. It is difficult to identify a
particular service in order to execute a task. This is due to the problem that there is no
common structure or framework in using terms or names to describe services. For example, to
describe a service that provides image resizing function, we may find different names. In
order to facilitate service composition and interoperation it is imperative to have a common
Web Services: Standards and Related Technologies
59
description framework. Ontologies have been introduced to solve these problems. As stated in
[Usch96], ontology is the term used to refer to the shared understanding of some domain of
interest which may be used as a unifying framework. It is also defined as a formal explicit
description of concepts in a domain of discourse (classes sometimes called concepts),
properties of each concept describing various features and attributes of the concept (slots
sometimes called roles or properties), and restrictions on slots (facets sometimes called role
restrictions) [Grub95]. Today there are different ontology specification languages with
varying degree of expressiveness, like RDF (Resource Description Framework), DAML
(DARPA Agent Markup Language), DAML+OIL and OWL (Web Ontology Language).
Here, we present OWL and OWL-S because these are the tools that we have used to develop
our multimedia content adaptation services description.
OWL (Web Ontology Language)
OWL is a W3C general purpose recommendation language for defining web ontologies
[Smith04]. This language incorporates the lessons learned from the design and application of
DAML + OIL. OWL, like DAML + OIL, uses description logic to provide an unambiguous
meaning of terms defined using it. This can be used by applications that require
interoperability. It is also compatible with XML and RDF.
OWL-S (Web Ontology Language for Services)
OWL-S (formerly DAML-S) [Ankol01] is an ontology that provides constructs for describing
web services. With OWL-S the properties of services and their capabilities are less ambiguous
and described in computer-interpretable format. It can be regarded as a semantic-based effort
for service description, service publication and service flow [Solla02]. OWL-S descriptions
enable improved matching of services [Paol02]. The top level of the ontology has a service
construct,
related
to
three
basic
concepts:
ServiceProfile,
ServiceModel
and
ServiceGrounding. The ServiceProfile describes what the service does (what is provided), the
ServiceModel describes how it works (what happens) and the ServiceGrounding describes
how to access it (how to use). In the current version, the ServiceGrounding is defined as the
mapping between the Service- Model and the service's interface description, WSDL. OWL-S
is one of the approaches developed to semantically describe Web services [Cabral]. The other
main similar approaches are IRS (Internet Reasoning Service) [Motta03] and WSMF (Web
60
Chapter 3. Service-Oriented Architecture & Web Services
Service Modeling Framework) [Fensel02]. IRS provides a strong user and application
integration support but it does not have semantic description of composed services. WSMF is
an effort towards developing a comprehensive conceptual architecture, which covers
requirements of e-commerce. Compared to these two, OWL-S has a richer service ontology
which builds on the semantic web stack standards. In addition, the service ontology of OWLS is public.
3.4
Web Service Composition
In service-oriented computing (SOC), developers use services as fundamental elements in
their application-development processes. Services are platform- and network-independent
operations that clients or other services invoke. In SOC, we can identify two distinguished
abstraction levels of proposed services. On one hand, basic services are elementary
functionalities, usually provided by the third parties. On the other hand, composite services
aggregate a set of functionalities into higher level applications, closer to the user’s actual
needs. Thus, service composition enables to fill the abstraction gap between the user’s need
and elementary service levels. Developers and users can solve complex problems by
combining available basic services and ordering them to best suit their problem requirements.
Service composition accelerates rapid application development, service reuse, and complex
service consummation [Milan04].
Web service composition in SOAs has been an active research area lately, as a result of the
increasing impact the web services deployment paradigm on today’s World Wide Web.
Despite of many efforts in developing different languages and standards for service discovery,
description and invocation over the past years, the Web service composition remains highly
complex and beyond the human capability to deal with the whole process manually. Jinghai et
al. [Rao04] have listed three main sources for Web service composition complexity.
•
The number of services available over the web increases dramatically during the
recent years, and one can expect to have a huge web service repository to be searched.
•
Web services can be created and updated on the fly, thus the composition system
needs to detect the updating at runtime and the decision should be made based on the
up to date information.
Web Service Composition
•
61
Web services can be developed by different organizations, which use different
semantic models to describe the services, however, a unique language does not exist to
define and evaluate the web services in an identical means. Many authors have argued
that web service composition will be the dominating paradigm on the web in the years
to come, thus changing its structure from a web of information and manuallyaccessible applications, to that of a web of automatic services [e.g. Casati01].
According to Nikola et al. [Milan04] a web service composition mechanism must satisfy
several requirements such as connectivity, nonfunctional quality-of-service properties,
correctness, and scalability. Every composition approach must guarantee connectivity. With
reliable connectivity, we can determine which services are composed and reason about the
input and output messages. Composition correctness requires verification of the composed
service’s properties, such as security or dependability. Finally, because complicated business
transactions are likely to involve multiple services in a complex invocation chain,
composition frameworks must scale with the number of composed services.
Building composite web services with an automated or semi-automated tool is critical to the
success of the web service applications. To that end, several composition methods have been
proposed recently. Most of them fall into one of the following two categories [Rao04]:
methods based on pre-defined workflow model and methods based on Artificial Intelligence
(AI) planning.
3.4.1 Workflow Technique
In a pre-defined workflow service composition technique, a user should specify the workflow
of the required composite service, including both nodes and the control flow and the data flow
between the nodes. The nodes are regarded as abstract services that contain search recipes.
The concrete services are selected and bound at runtime according to the search recipes. This
approach is widely adopted by members of the Information Systems community [Rao04].
The definition of a composite service includes a set of atomic services together with control
and data flow among the services. Similarly, a workflow has to specify the flow of work
items. In the workflow-based composition methods, we should distinguish the static and
62
Chapter 3. Service-Oriented Architecture & Web Services
dynamic workflow generation. The requestor builds an abstract process model before the
composition planning starts. The abstract process model includes a set of tasks and their data
dependency. Each task contains a query clause that is used to search the real atomic web
service to fulfill the task. In that case, only the selection and binding of atomic web service is
done automatically by the program.
Various web service flow specification standards have been developed in the industry such as
IBM’s Web Service Flow Language (WSFL) [Leym01], BEA Systems’ Web Services
Choreography Interface (WSCI) [Arkin02], and Business Process Execution Language for
Web Services (BPEL4WS, or BPEL for short) [Weer02]. Since the WSFL and WSCI were
incompatible, researchers have developed the BFEL which combines WSFL and WSCI with
Microsoft’s XLANG specification [That01].
The workflow composition systems provide manual and semi-automatic service composition
tools but they present several drawbacks:
•
First, the user is required to specify the workflow which may not be always practical
as in the case of content adaptation services. The type and number of adaptation
services required are determined during request execution.
•
Second, the discovery and selection of services is un-scalable as the number of
services increases.
•
Third, they require the user to have low-level knowledge, e.g. in the case of
BPWS4J12, the user is expected to set up a workflow at the XML level which is not
feasible for a large workflow. Although some systems provide a graphical drag and
drop interface to construct the workflow, it is not feasible for a large workflow.
•
Fourth, if the service is no longer available, the execution will fail.
Because of the above major drawbacks, the manual or semi-automatic workflow composition
is not appropriate for our work. In the following section we present automatic service
composition methods which are basically related to AI planning.
12
BPWS4J is java implementation of BPEL4WS.
Web Service Composition
63
3.4.2 AI planning
The second category includes methods related to AI plainning. The service composition
methods provide dynamic service composition where both the process model and the
selection of atomic services are done automatically. Our composition method proposed in this
work falls in this category. The basic assumption of these methods is that each web service is
an action which alters the state of the world as a result of its execution. Since the services
(actions) are software components, input and output parameters of a service act as
preconditions and effects in the planning context. If the user can specify inputs and outputs
required by the composite service then the service (as a composition of available services) is
generated automatically by AI planners without any knowledge of a predefined workflow.
Since the introduction of Semantic web, several Web service composition methods using AI
planning have been reported in the literature [Rao04, Medj03, McIl02]. In general, a planning
problem can be described as a four-tuple (S, So, G, A), where
- S is the set of all possible states of the world
- So Є S denotes the initial state of the world
- G Є S denotes the goal state of the world
- A is the set of actions that change one state to another state in the world
Given a representation of services as actions, we can exploit AI planning techniques for
service composition by treating service composition as a planning problem. Ideally, given a
user’s objective and a set of web services, a planner would find a collection of web services
requests that achieves the objective. This resemblance demonstrates the relevance of AI
planning to tackle the problem of Web service composition. However, DAML-S (also called
OWL-S in the most recent versions) is the only web language that announces the direct
connection with AI planning [Wu03]. The state change produced by the execution of the
service is specified through the precondition and effect properties of the ServiceProfile in
DAML-S. A precondition presents logical conditions that should be satisfied prior to the
service being requested. Effects are the result of the successful execution of a service. In the
following section, we present some of the web service composition method based on AI
planning. These methods use DAML-S as external Web service description language.
64
Chapter 3. Service-Oriented Architecture & Web Services
Golog
S. McIlraith and T. C. Son [McIl02] proposed a method to compose Web services by applying
logical inferencing techniques on pre-defined plan templates. The service capabilities are
annotated in DAML-S/RDF and then manually translated into Prolog. Now, given a goal
description, the logic programming language of Golog [Leve97] (which is implemented over
Prolog) is used to instantiate the appropriate plan for composing the Web services. Golog is
based on the situation calculus [Gross00] (a logical language for reasoning about action and
change) and it supports the specification and execution of complex actions in dynamical
systems.
PDDL
Jinghai Rao [Rao04] noted that the strong interest to Web service composition from AI
planning community comes from the similarity between DAML-S and Planning Domain
Definition Language (PDDL) representations. Since its release in 1998 by McDermott
[Dermott, 2000], PDDL has become a community standard for the representation and
exchange of planning domain models. Moreover, since DAML-S has been strongly influenced
by PDDL language, mapping from one representation to another is straightforward (as long as
only declarative information is considered). DAML-S descriptions could be translated to
PDDL format and different planners could be exploited to plan service composition.
Rule-based planning
B. Medjahed et. al. [Medj03] presents a technique to generate composite services from highlevel declarative description. The method uses composability rules to determine whether two
services are composable. B. Medjahed et. al. [B. Medjahed et. al.2003] identifies two
composability rules: syntactic and semantic. Syntactic rules include the rules for operation
modes and the rules for binding protocols of interacting services. Semantic rules include (1)
message composability, defines that two Web services are composable only if the output
message of one service is compatible with the input message of another service (2) operation
semantic composability, defines the compatibility between the domain, categories and
purpose of two services (3) qualitative composability, defines the requester’s preferences
regarding the quality of operations for the composite service, and (4) composition soundness
Web Service Composition
65
considers whether a composition of services is reasonable. To this end, the authors introduce
the notion of composition templates that define the dependency between the different kinds of
services. A service composition is considered to be sound if its template is the subset of a
stored template.
The composition approach consists of four phases called specification, matchmaking,
selection and generation. For the specification phase, Medjahed et. al. introduces a high level
language – CSSL (Composite Service Specification Language) – which is a semantic
description language for web service compositions. CSSL extends WSDL and represents the
ontology-based graph. In the matchmaking phase, a special matchmaking algorithm,
integrating the composability rules described above is applied to generate composition plans
that meet the service requester’s specifications. QoS constraints are used in the selection
phase to select the most proper composition plan from the output.
The main contribution of this method is the composability rules, because they define the
possible Web service’s attributes that could be used in service composition. Those rules can
be used as a guideline for other Web service composition methods based on planning.
HTN
Hierarchical Task Network (HTN) [Sirin04a] planning is an AI planning methodology that
creates plan by task decomposition. This is a process in which the planning system
decomposes tasks into smaller and smaller subtasks, until primitive tasks are found that can be
performed directly. HTN includes methods that describe how a complex task can be
decomposed into subtask and operators describing how a primitive task can be achieved.
The appropriateness of HTN planning for the problem of Web service composition is
suggested by the many operational similarities between OWL-S and HTN planning:
- OWL-S atomic processes correspond to primitive actions
- OWL-S composite processes correspond to complex actions or methods
- Both OWL-S and HTN planning use hierarchical decomposition to cope with
complexity. Specifically OWL-S use control constructs to decompose composite
processes to sub processes, and HTN planning use methods to decompose complex
actions to simpler subtask.
66
Chapter 3. Service-Oriented Architecture & Web Services
The similarity between OWL-S and HTN planning leads to mapping of composite processes
to methods and atomic processes to operators. Once this mapping has been performed, given
an objective (goal) and initial state, a HTN planner will find a sequence of web services that
achieves this goal from the initial state. Because of these reasons, a HTN planning approach
was adopted to develop the adaptation service composition algorithm in this thesis.
3.5 Summary
The emergence of web services makes the SOA a standard solution for distributed computing
on the Internet. This chapter presented the SOA and its related technologies with particular
focus on web services. We presented some of the benefits of SOA for distributed computing
such as flexibility, scalability and interoperability. Web services standards and related
technologies such as UDDI, WSDL and SOAP were discussed. We also presented the use of
OWL for semantic web services description. Finally, we presented two major categories web
services composition techniques (work flow and AI) and their comparisons. The HTN which
is one of the AI planning techniques was adopted in this thesis. The similarity between the
HTN and the OWL-S facilitates the representation of the OWL-S in planning operator form
so that a planning algorithm can be used to compose the adaptation services.
Chapter
4
Content Metadata
Description
The purpose of this chapter is to present a brief overview of the most important initiatives for
content metadata standards related to multimedia content adaptations. We start with a formal
definition of the term metadata and its basic characteristics in Section (4.1.). Next we will
present the Dublin Core standard in Section (4.2), the SMPTE Meta-Dictionary in Section
(4.3), the MPEG-7 standard in Section (4.4), and other standards in Section (4.5). We will end
this chapter with a summary in Section (4.6).
4.1 Introduction
Content adaptation enables pervasive access to multimedia resources through the process of
tailoring content. This requires explicit and machine-processable knowledge about the content
and the usage environment (context). Solutions for metadata representation provide a
mechanism for representing and processing this knowledge. Two types of metadata should be
considered: content metadata (e.g. format, size, dimension etc.) and context metadata (e.g.
display size, supported contents, language preference, bandwidth capacity etc.). Content
adaptation can be done without the use of content metadata [Kazai03]. For example, it is
possible to transcode MPEG-2 video to MPEG-4 based on features such as scene changes and
closed captions. However, this requires automatic video analysis which is of course, time
consuming and very difficult to correctly identify meaningful segments. Thus, it is important
that the content metadata should be created before delivering the content and stored with the
content or separately.
68
Chapter 4. Content Metadata Description
Metadata is a term originating from the Greek word ‘meta’ denoting words such as ‘along
with, after, among, between’. Within information technology, the term metadata has been
variously described as 'structured data about data' [Dublin99], or 'information about data',
even 'data about data'. These are technological descriptions. A further definition has been
provided by Lorcan Dempsey [Demp97]: “metadata is data associated with objects which
relieve their potential users having to have full advanced knowledge of their existence or
characteristics”. A user might be a program or a person, and metadata may support a variety
of uses or operations.
The term metadata is used differently in different communities [NISO04]. Some use it to refer
to machine understandable information, while others use it only for records that describe
electronic resources. In the library environment, metadata is commonly used for any formal
scheme of resource description, applying to any type of object, digital or non-digital.
Traditional library cataloging is a form of metadata.
A metadata description characterizes the information or content by a set of attributes. The
attributes may not only describe the actual content in terms of raw data, meaning, and/or key
concepts, but also characterise the content in terms of its author, its quality, its production
time, its format, etc. In short, metadata is information about all relevant aspects of information
objects in terms of the complete content provision chain.
There are three main types of metadata used for multimedia data [NISO04]:
•
Descriptive or Content metadata: information about the object captured in the media
data. It is used for discovery of the media objects. It includes:
o object's name: the name of the object captured in the data (e.g. heart in an
image data)
o title: the title given to the data by the content creator (e.g. heart cancer
treatment)
o materials: form of the media (e.g paper, electronic, film, etc.)
o publication date
o edition or version
o physical characteristics: physical aspects of the object (e.g for a book, its
material, form, color, etc.)
o etc.
Introduction
•
69
Structural or Technical metadata: data about the media data itself (not about the
object in the media). It is used primarily for the storage of objects in a repository and
for presentation. It includes information about:
o digitisation or compression specifications
o encryption
o data format
o file size, etc.
•
Administrative metadata: information related to the management of the media data. It
is used for managing and preserving the media objects in the repository. It includes:
o Location information
o Acquisition information
o Ownership, rights, permission, reproduction information
o Usage information, etc.
Metadata is used for describing resources and thereby improving access to them [Tayl03].
Apart from its application for resource discovery, metadata facilitates a wide range of
purposes. For examples in distributed multimedia systems, metadata can be used for the
following purpose [Kosch03, Adela01]:
•
To search multimedia data by content, e.g., ‘list all video clips from an online video
shop where Roger Moore plays 007’. But, before multimedia data can be searched, the
data have to be indexed; that means content metadata has to be extracted from the
video either automatically or annotated manually.
•
To describe intellectual properties of the multimedia data. These may guarantee a fair
use of the data in commercial applications.
•
To adapt content according to the usage context. For example, if metadata such as
frame rate, spatial resolution and bit rate are easily accessible, decisions about what
media resources to send can be made. The metadata provide media properties so that
appropriate transformation (s) can be applied to match the content with the usage
environment.
70
Chapter 4. Content Metadata Description
Over the years there have been several initiatives to develop standards for content metadata
such as Dublin Core, SMPTE13 Metadata Dictionary, and MPEG-7. These standards are
general, i.e. they do not target a particular industry or application domain, and are supported
by well-recognized organizations [Kosch03]. In the following sections we give a brief
overview of these standards.
4.2 Dublin Core
The Dublin Core14 is a simple content description model for electronic resources. It is a
metadata element set intended to facilitate the discovery of electronic resources. Originally
conceived for author-generated description of web resources, it has attracted the attention of
formal resource description communities such as museums, libraries, government agencies,
and commercial organizations [Adela01]. The Dublin Core Metadata Initiative (DCMI) began
in 1995 with an invitational workshop in Dublin, Ohio, that brought together experts from the
library world, the networking and digital library research communities, and a variety of
content specialties [ISO03]. The DCMI is an organization dedicated to promoting the
widespread adoption of interoperable metadata standards and developing specialized metadata
vocabularies for describing resources that enable more intelligent information discovery
systems. At the end of the workshop, the original Dublin Core metadata elements emerged.
Since the original workshop there has been a steadily growing interest in resource descriptions
that are easy to create and that almost anyone can understand. The interest in cross-domain
discovery fueled growing participation in a series of subsequent DCMI workshops. These
workshops enabled to create a standard Dublin Core metadata consists of fifteen elements (see
Figure 5.1). The Dublin Core metadata elements describe the content of the document,
information about the intellectual property contained in the document and information about
the particular instances of the document [ISO03, Hill03]. The elements in the Dublin Core are
optional, repeatable, modifiable, and can appear in any order.
Advantages associated with Dublin Core are simplicity, interoperability, scalability,
international consensus and flexibility [Hunt98]. The simplicity of the Dublin Core lowers the
cost of creating metadata and promotes interoperability. On the other hand, simplicity does
13
14
SMPTE: Society of Motion Picture and Television Engineers (http://www.smpte.org)
http://purl.org/DC
Dublin Core
71
not accommodate the semantic and functional richness supported by complex metadata
schemes such as MPEG 7 [Libse04].
Dublin Core was designed specifically for generating metadata for textual documents.
Although a number of workshops have been held to discuss the applicability of Dublin Core
to non-textual documents such as images, sound and moving images, they have primarily
focused on extensions to the 15 core elements through the use of subelements and schemes
specific to audiovisual data, to describe bibliographic-type information rather than the actual
content [Hunt98]. For example, metadata about video such as frame rate, resolution, etc. are
important to adapt the video according to the usage context. But Dublin core does not have
elements to specify those metadata. Therefore, Dublin core does not provide all necessary
metadata information for the purpose of content adaptation.
72
Chapter 4. Content Metadata Description
E
Figure 4.1: Dublin Core Metadata Element Set
4.3
SMPTE Meta-Dictionary
The SMPTE Metadata Dictionary is a collection of registered names and data types,
developed mostly for the television and video industry that forms the SMPTE membership. Its
hierarchical structure allows endless expansion and mechanisms for data formatting in TV
and video-signals, and provides a common method of implementation. Most metadata are
media-specific attributes, such as timing information.
MPEG 7
4.4
73
MPEG 7
MPEG-7 [Mart02, Day02, Bekker00] formally named “Multimedia Content Description
Interface” is an ISO/IEC standard developed by MPEG15 that provides a rich set of tools for
completely describing multimedia content so that users can search, browse and retrieve that
content more efficiently and effectively. The effort is being driven by specific requirements
taken from a large number of applications related to image, video and audio databases, media
filtering and interactive media services (radio, TV programs), image libraries and so forth
[Smith00]. MPEG-1, MPEG-2, and MPEG-4 represent the content itself but MPEG-7
represents information about the content. While earlier MPEG versions were focusing on
making multimedia content available, MPEG-7 allows the localization, filtering, managing
and processing of desired media files by tagging them with information regarding their
content and origin [Libse04].
Major guiding principles of MPEG-7 include [Kosch03, Martinez03]:
- It is not specific to any particular application. It is intended to be applicable to content
associated to any application domain. To ensure that the needs of as many applications
as possible are included, MPEG-7 has been developed by experts representing
broadcasters, electronics manufacturers, content creators and managers, publishers,
intellectual property rights managers, telecommunication service providers and
academia.
- For requirements that are not covered by the standard, MPEG-7 is extensible to
address new application domains. It allows the extension of the core set of description
tools in a standard way so that interoperability is guaranteed.
- It addresses a variety of data types (or modalities) such as speech, audio, image, video,
graphics, 3-D models, and synthetic audio.
- It is applicable independently of the medium that carries the content. Media can
include paper, film, tape, CD, hard disk, digital broadcast, Internet streaming, etc.
- It is also applicable independently of the content representation format, whether
analogue or digital, compressed or uncompressed, etc.
15 MPEG (Moving Picture Experts Group) is a working group of the Geneva-based ISO/IEC standards organization (International Standards
Organization/ International Electro-technical Committee) that developed, in particular MPEG-1, MPEG-2 and MPEG-4 standard [Henny
Bekker, 2000].
74
Chapter 4. Content Metadata Description
-
It includes description capabilities with different levels of abstraction, from low-level
features such as color, texture, and motion to high-level features conveying semantic
meaning. Often low-level features are extracted automatically whereas semantic
features need to be extracted manually or semi-automatically.
Using the MPEG-7 description tools one can create different types of descriptions for a
multimedia content. These descriptions contain information related to [Mart02]:
- the content’s creation and production processes (such as director, title, actors, and
location)
- usage of the content (such as broadcast schedules and copyright pointers)
- storage and representation of the content (such as storage format and encoding format)
- the content’s spatial, temporal, or spatio–temporal structure (for example, scene cuts,
segmentation in regions, and region motion tracking)
- the low-level features in the content (for example, colors, textures, sound timbres, and
melody descriptions)
- semantic information of the reality captured by the content (for example, objects,
events, and interactions between objects).
- how objects are related and gathered in collections
- browsing content in an efficient way (such as summaries, variations, and transcoding
information)
- the interaction of the user with the content (such as user preferences and usage
history), etc.
MPEG-7 standardized descriptors for defining the syntax and semantics of each feature
representation and description schemes for specifying relationships between components
(both descriptors and description schemes). Standardizing the multimedia content description
addresses the interoperability issue by allowing content and its descriptions to be exchanged
across different systems [Libse04].
Figure 4.2 [Smith00] below shows the scope of the MPEG-7 standard within the multimedia
content processing chain. The description generation (feature extraction, indexing process,
annotation and authoring, etc.) and the description consumption (search engine, filtering,
retrieval process, browsing etc.) tools are not within the scope of MPEG-7 standard.
MPEG 7
75
This means that only the description format—the minimum needed to ensure interoperability
among applications—is standardized, which is the standard’s goal.
Figure 4.2: Scope of the MPEG Standard
MPEG-7 has four major building blocks [Mart02]:
- Descriptor (D): describes features (multimedia information), attributes, or groups of
attributes of multimedia content. A Descriptor defines the syntax and the semantics of
the feature representation (metadata element). MPEG-7 Descriptors describe for
example the color, the texture, the shape, the motion or the audio features.
- Description Scheme (DS): is the structure and semantics of the relationships between
its components, which may be both Descriptors and Description Schemes. An example
of Video Segment Type Scheme is shown in Figure 3.3.
- Description Definition Language (DDL): is a language that allows the creation of new
DSs and possibly Ds. It also allows the extension and modification of existing DSs.
The W3C's XML schema language is adopted as the MPEG-7 DDL. The DDL adds
extensions to the XML Schema to address specific MPEG-7 requirements such as
support for vectors, matrices and typed references. The adoption of XML Schema as
the basis for MPEG-7 DDL and the resulting XML-compliant instances (which
contains Descriptions in MPEG-7 textual format) eases interoperability by using a
common, generic and powerful presentation format. It also facilities the adoption of
MPEG-7 tools for extending existing XML applications with multimedia content
description functionalities.
-
Systems Tools: are tools to support synchronization of descriptions with content,
delivery mechanisms, and coded representations (both textual and binary format) for
efficient storage and transmission and the management and protection of intellectual
property in MPEG-7 Descriptions. One can represent descriptions in text format also
76
Chapter 4. Content Metadata Description
called TeM (Textual Format for MPEG-7) and binary format called BiM (Binary
Format for MPEG-7) or using a mixture of the two, depending on the usage scenario.
The text format is defined with the DDL and the instances are XML files. It is suitable
for editing, searching and filtering, whereas the binary format is suitable for storage,
transmission, and streaming delivery. The binary descriptions have a more efficient
compression than the textual descriptions and provide flexibility for streaming and
efficient random search and access to description elements without the need of parsing
the complete stream.
<complexType name="VideoSegmentType">
<complexContent>
<extension base="mpeg7:SegmentType">
<sequence>
<choice minOccurs="0">
<element name="MediaTime" type="mpeg7:MediaTimeType" />
<element name="TemporalMask" type="mpeg7:TemporalMaskType" />
</choice>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="VisualDescriptor" type="mpeg7:VisualDType" />
<element name="VisualDescriptionScheme" type="mpeg7:VisualDSType" />
<element name="VisualTimeSeriesDescriptor"
type="mpeg7:VisualTimeSeriesType" />
</choice>
<element name="MultipleView" type="mpeg7:MultipleViewType" minOccurs="0" />
<element name="Mosaic" type="mpeg7:MosaicType" minOccurs="0"
maxOccurs="unbounded" />
<choice minOccurs="0" maxOccurs="unbounded">
<element name="SpatialDecomposition"
type="mpeg7:VideoSegmentSpatialDecompositionType" />
<element name="TemporalDecomposition"
type="mpeg7:VideoSegmentTemporalDecompositionType" />
<element name="SpatioTemporalDecomposition"
type="mpeg7:VideoSegmentSpatioTemporalDecompositionType" />
<element name="MediaSourceDecomposition"
type="mpeg7:VideoSegmentMediaSourceDecompositionType" />
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 4.3 Schema Definition of VideoSegmentType
A Description consists of a Description Scheme (structure) and the set of Descriptor values
(instantiations) that describe the data. A Descriptor value is an instantiation of a Descriptor for
MPEG 7
77
a given data set (or subset). The Description Schemes provide a way to describe in XML the
important concepts related to multimedia data in order to facilitate the searching, indexing and
filtering of multimedia data [Smith00]. The Description Schemes are designed to describe
both the generic aspects of multimedia data management and the specific content features of
the multimedia data. Figure 4.4 shows MPEG-7 document file for video data.
MPEG-7 standard consists of several parts [Manj02]. The different parts of the MPEG-7
standard collectively offer a comprehensive set of multimedia description tools to create
descriptions that can be used by applications that enable fast and efficient access to content.
The multimedia descriptions can also be used for searching, filtering and adapting the content
[Smith00]. For the purpose of content adaptation, MPEG-7 standard contributes at least the
following:
- MPEG-7 standard provides tools (the navigation and access part) for describing
variations of the content such as summaries and abstracts; scaled, compressed and low
resolution versions, and versions with different languages and modalities-audio, video,
image, text, and so forth.
- MPEG-7 standard provides tools (the content management part) for describing media
information such as storage media, coding format, size, quality and transcoding hints
for adapting content to different networks and terminals [Mart02].
78
Chapter 4. Content Metadata Description
Figure 4.4: MPEG-7 Description Example
MPEG-7 is currently used in applications such as video annotation and browsing, Internet
audio/video search and spoken content description. Some industries have already developed
applications using MPEG-7. IBM has developed an MPEG-7 Annotation Tool that assists in
annotating MPEG-1 video sequences with MPEG-7 metadata [Smith00]. The Annotation
Tool is a stand-alone Windows application and it can be freely downloaded from IBM
alphaWorks16. Canon Research Centre Europe Ltd (CRE)17 has developed a spoken content
transcription service that uses MPEG-7 to describe the spoken content. The application uses a
Web interface where the user can upload an audio file in wav format and the service creates
and returns an XML file conforming to the MPEG-7 SpokenContent description scheme. The
audio part of MPEG-7 contains a SpokenContent high-level tool targeted for spoken data
management applications. The MPEG-7 SpokenContent tool provides a standardized
representation of an automatic speech recognition output, i.e. of the semantic information (the
spoken content) extracted by an automatic speech recognition system from a spoken signal. It
consists of a compact representation of multiple word and/or sub-word hypotheses produced
by an automatic speech recognition engine.
16
17
http://www.alphaworks.ibm.com/tech/videoannex
http://www.cre.canon.co.uk/mpeg7asr/
Other standards
79
Thomson has developed a streaming media search engine called Singingfish18. Singingfish is
one of the search engines that currently utilize MPEG-7. It is text-based search engine that
uses MPEG-7 Multimedia Description Schemes to model the metadata characteristics of
Internet streaming media.
A query by humming (QBH) system enables a user to hum a melody into a microphone
connected to a computer in order to retrieve a list of possible song titles that match the query
melody [Batke04]. The system analyzes the melodic and rhythmic information of the input
signal. The extracted data set is used as a database query. The result is presented as a list of
e.g. ten best matching results. A QBH system is a typical application of the MPEG-7
description standard. Different QBH systems are already available on the World Wide Web
(WWW). Musicline19 is a commercial QBH system developed by Fraunhofer. Musicline’s
MPEG-7 powered search engine allows finding music by humming. The search engine
extracts the melody from the user’s singing or from the instrument the user is playing and
compares the result with a database. Currently, the database contains about 3500 melodies of
mainly pop music.
4.5
Other standards
There are also other standardization activities that are focused to more specific applications or
application domains. These standards include TV Anytime Metadata20, SMEF21, and
DICOM22.
The Standard Media Exchange Framework (SMEF) is developed by BBC to support and
enable media asset management ("MAM") as an end-to-end process across its business areas,
from commissioning to delivery to the home. The SMEF Data Model (SMEF-DM) provides a
set of definitions for the information required in production, distribution and management of
media assets, currently expressed as a data dictionary and set of Entity Relationship
Diagrams.
18
http://www.singingfish.com
http://www.musicline.de/de/melodiesuche/input
20
TV-Anytime (http://www.tv-anytime.org/).
21
SMEF: Standard Media Exchange Framework (http://www.bbc.co.uk/guidelines/smef/).
22
DICOM is developed by the American College of Radiology (ACR) and the National Electrical Manufactures
Association (NEMA).
19
80
Chapter 4. Content Metadata Description
TV-Anytime [TV02] is a metadata standard developed by the TV-Anytime Forum23 to define
specifications for programme level content descriptions to allow viewers to find, navigate and
manage contents from a variety of sources, including enhanced broadcast, interactive TV,
Internet and local storage. Such metadata includes attractors (title, synopsis, genre, cast and
awards etc.) that aid the acquisition of available content organised in EPGs (Electronic
Programme Guide).
The Digital Imaging and Communications in Medicine (DICOM) is developed to create an
aid for the distribution, transmission and viewing of medical images such as CT scans, MRIs,
and ultrasound with their associated information [DICOM01]. Unlike other metadata
standards, DICOM stores both the metadata and the content in one file. The metadata
information which contains patient’s name, the type of scan, image dimensions, etc. is stored
in the file header.
4.6 Summary
In this chapter we presented an overview of the most important initiatives to develop
standards for metadata. Our interest in this thesis is to develop an open general architectural
framework for adapting multimedia contents utilizing external adaptation tools developed as
services. One major component of the architecture is the content adaptation module. This
module analysis the context information, the content and the available adaptation services in
order to determine on the number and type of adaptations required to deliver the content. In
view of this context, there is a need for metadata in order to describe the multimedia content.
Reviewing the different standards proposed up to know, the best candidate as a metadata
standard at the moment is MPEG-7: it is media independent, it is currently being developed as
an international standard, it is the standard that provides the richest and most versatile set of
multimedia feature descriptions, and it embraces a family of standards such as SMPTE,
Dublin Core and more, so it is the highest interoperable standard among well-known industry
standard.
23
TV Anytime Forum: association of organizations which seeks to develop specifications to enable audio-visual and other services based on
mass-market high volume digital storage in consumer platforms – simply referred to as local storage.
Chapter
5
Context Metadata
Description
In this chapter we present some of the commonly used context descriptions. We also discuss
the advantages and limitations of each description. First we start by giving a definition of
context in Section 5.1. Then we present the most important context representation developed
for the purpose of content adaptation: CC/PP (Section 5.2), IETF Media Feature Sets (Section
5.3), CSCP (Section 5.4), and MPEG-21 (Section 5.5). We end the chapter with a summary in
Section 4.6.
5.1 Introduction
Not only the availability of content metadata but also context metadata related to user, device,
network, environment, etc. are essential to perform appropriate content adaptations. Although
there are a number of clear benefits for the use of context metadata in other issues of
pervasive computing environments, in this chapter the primary focus is on their use for
content adaptation. To facilitate content adaptation for pervasive computing applications, the
context metadata need to be described, maintained and processed. There are several
description tools that have been developed for context metadata. Before we see these
description tools and their characteristics, we first give a definition of “context”24. It is quite
unlikely that a single definition of context will be accepted by all researchers. From time to
time, from application to application this definition varies. Since it was coined in 1994
[Schi94b], numerous definitions of context have been provided in the literature. Historically
[Wing01], “context” has been adapted from linguistics, referring to the meaning that must be
24
In this work, the use of the notion of “context” is limited to pervasive computing systems and in particular its use for content adaptation
purpose.
82
Chapter 5. Context Metadata Description
inferred from the adjacent text. Here, we are interested with the definition of context with
respect to the computing world. Context definitions are far away from mathematical precision
and a particular definition often strongly depends on an author’s subjectiveness [Reim02].
Most of the definitions are given by list of examples or by choosing synonyms for context
[Dey01].
Schilit and Theimer [Schi94b] define context as location, identities of nearby people and
objects, and changes to those objects. Brown et al. [Brown97] define context in a similar
manner as location, identities of the people around the user, the time of day, season,
temperature, etc. Ryan et al. [Ryan97] define context as the user’s location, environment,
identity and time. Dey [Dey98] enumerates context as the user’s emotional state, focus of
attention, location and orientation, date and time, objects, and people in the user’s
environment. These are definitions by examples. As noted by [Dey01], definitions by
examples are difficult to use since it is difficult to determine whether a type of information
which is not listed in the definition is part of the context or not. It is not clear how the
definition can be used to solve the dilemma.
Synonym definitions of context are provided by Brown [Brown96], Rodden [Rodd98] and
Ward [Ward97]. For these researchers the term context refers to an environment or a
situation. While Brown [Brown96] considers context to be the elements of the user
environment that the user’s computer knows about, Ward et al. [Ward97] view the context as
the state of the application’s surrounds and Rodden et al. [Rodd98] define it to be the
application’s settings. The synonym definitions can provide an indication for the meaning of
the term context but they are at abstract level and it can be extremely difficult to apply them
in a concrete application for instance in the case of content adaptation.
Further refined definitions of context were provided by Schilit et al. [Schi94a], Dey et al.
[Dey99b] and Pascoe [Pascoe98]. According to Schilit et al. context is the execution
environment which changes constantly and consists of computing environment (available
processors, accessible devices, network capacity and connectivity, and computing costs), user
environment (location, collection of nearby people, and social situation), and physical
environment (lighting and noise level). Dey et al. define context to be the user’s physical,
social, emotional or informational state. Pascoe defines context to be the subset of physical
and conceptual states of interest to a particular entity.
Introduction
83
Though Pascoe tried to define context in a more general way, his focus on the need of a single
entity makes it very specific. Context is all about the whole situations relevant to an
application and its set of users. Thus, it is not possible to list which aspects of all situations
are important since it changes from situation to situation. Moreover, an element of context
important in one case may be immaterial for another.
A comprehensive and more general definition of context that can be adapted according to the
particular application scenario was provided by Dey [Dey01]. According to this definition,
context is any information that can be used to characterize the situation of an entity (where an
entity can be a person, place, or physical or computational object) that are considered relevant
to the interaction between a user and an application, including the user and the application
themselves. Context is typically the location, identity, and state of the people, groups and
computational and physical objects.
Based on this definition, application developers can easily enumerate the context for a given
application scenario. A good understanding of the general context concept helps application
designers to determine what context to be considered in their applications. For example, in the
case of context-aware25 content adaptation for pervasive systems, the more relevant context
information consists of the following [Chaari06, Sun03, Held02]:
•
User and environment context: characteristics, preferences, role, activity (e.g meeting,
home, driving, etc.), physical environment (e.g. location, weather, time etc.)
•
Device context: hardware characteristics (e.g. screen resolution, color depth, display
size, etc.) and software characteristics (operating system vender and version, content
type and format capabilities, etc.)
•
Network context: type of connection, available bandwidth, delay, etc.
This context information also called context profiles26 allows adapting content to device
capabilities, user preferences and characteristic, and network conditions. To facilitate the
programming of context-aware content adaptation systems, an infrastructure is necessary to
gather, manage and disseminate context information. This requires that the context-aware
adaptation system should be capable of acquiring and transforming context information and of
25
Context-aware is a term used to refer to systems, devices or applications that have information about the circumstances under which they
operate and can react accordingly.
26
The term context profiles or context metadata refers to the collection of user, environment, device and network context information.
84
Chapter 5. Context Metadata Description
reasoning on the basis of this information, thus showing the need for a uniform and
interchangeable context representation.
Use of context information demands appropriate standards for applications to express and
exchange context information. A representation of context information should be applicable
throughout the process of gathering, transferring, storing and interpreting the context
information. According to Held et al. [Held02], a context representation should be structured,
interchangeable, composable/decomposable, uniform, extensible and standardized. Up to
now, a number of efforts have been done to develop context representation mechanisms such
as UPS [Leml02], CC/PP [Klyne01], IETF [Klyne99], CSCP [Held02], MPEG-21 [Burn03],
etc. In the following sections we will give a brief overview of the most important
representation mechanisms: CC/PP, IETF Media Feature Sets, CSCP and MPEG-21.
5.2
Composite Capabilities/Preference Profiles
The Composite Capabilities/Preference Profiles (CC/PP) is a context description standard for
content negotiation and adaptation proposed by the W3C [Klyne01]. CC/PP offers an XMLbased format for exchanging context descriptions, as well as vocabularies for expressing
context information related to device capabilities and user preferences. The intended use of
such a profile is to allow an origin server to deliver content customized to a device capability
and user’s preferences. CC/PP is based on the Resource Description Framework (RDF)
[Lass99], which was designed by the W3C as a general purpose metadata description
language. The CC/PP specification defines a basic profile structure. A CC/PP profile is
organized as a two-level tree containing components and each component having a number of
attributes (shown in Figure 5.1). The particular components and attributes are not defined by
the CC/PP specification. The CC/PP architecture model uses RDF to define schemas upon
which vocabularies can be independently developed and implemented. This flexible
mechanism ensures CC/PP extensibility but limits the interoperability of the descriptions. In
this model, statements are made about the components (the subject) that have named attribute
(the predicate) and values for those attributes (the object).
Composite Capabilities/Preference Profiles
85
Profile
Attribute
(e.g. displayWidth)
Component
(e.g TerminalHardware)
Attribute
Component
Component
Figure 5.1: CC/PP Context Representation Model
The CC/PP representation more or less fulfils the requirements for context representation that
are listed above; nevertheless it has some disadvantages such as it is a strict two-level
structure [Held02]. For example, if we consider the device profile, it consists of components
such as hardware and software where each component is further composed of different
components. In the case of the software component it is composed of an operating system and
a user agent where a user agent has attributes such as name, version, content types, etc. From
this example, we can understand that the device context naturally has more than two-level.
The CC/PP representation provides extensibility but with limited structure. Furthermore,
CC/PP requires attributes names to be unambiguous even if they are used in different
components. Figure 5.2 shows an example of CC/PP profile in XML form.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description rdf:about="http://www.example.com/profile#MyProfile">
<ccpp:component>
<rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
</rdf:Description>
</ccpp:component>
<ccpp:component>
86
Chapter 5. Context Metadata Description
<rdf:Description rdf:about="http://www.example.com/profile#TerminalSoftware">
<rdf:type rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
<ex:name>EPOC</ex:name>
<ex:version>2.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://www.example.com/profile#TerminalBrowser">
<rdf:type rdf:resource="http://www.example.com/schema#BrowserUA" />
<ex:name>Mozilla</ex:name>
<ex:version>5.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
<ex:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</ex:htmlVersionsSupported>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
Figure 5.2: Example of CC/PP Profile in XML/RDF Format
This sample profile is a collection of the capabilities and preferences associated with either a
user or the hardware platform or a software component. Each collection of capabilities and
preferences are organized within the “ccpp:component”. These description blocks may
contain subordinate description blocks to describe other collections of attributes.
It is also possible to use multiple namespaces. This might be useful to define application
specific capabilities and preferences. In Figure 5.2, there are three namespace declarations.
The first namespace (http://www.w3.org/1999/02/22-rdf-syntax-ns#) declaration is for RDF
usage. The second namespace declaration (http://www.w3.org/2002/11/08-ccpp-schema#) is for
CC/PP core structural vocabulary, which includes "component" and other properties that are
intrinsic
to
the
CC/PP
framework.
The
third
namespace
declaration
(http://www.example.com/schema#) is for CC/PP components properties vocabulary.
CC/PP profiles are intended to provide information necessary to adapt web content to best fit
the device capabilities and user’s preferences. The CC/PP exchange protocol is based on the
HTTP extension framework. During a content request the user agent sends his request with
the URI that references his profile. The URI is included in the HTTP header. When a content
server receives the request, it inquires the CC/PP repositories using the URI.
IETF Media Feature Sets
87
Up to now, the only implementation of CC/PP is UAProf (or User Agent Profile), by the
Open Mobility Alliance (formerly the WAP-Forum) which is targeted to mobile devices
[Vela04]. UAProf has a very specific scope and does not cover the whole spectrum of devices
that can access nowadays Internet services and applications, nor even considers user
characteristics. Figure 5.3 show the structure of the UAProf with its components.
Figure 5.3: UAProf Main Components.
5.3
IETF Media Feature Sets
The IETF27 Content Negotiation Working Group [Klyne99] has developed a standardized
syntax called the Media Feature Sets (MFSs) that allows protocol-independent content
negotiation. The MFSs have been developed to enhance access to internet applications such as
the World Wide Web. The MFSs specifies device capabilities and user preferences by
unstructured attribute/value pairs. In contrary to CC/PP, it specifies the features of the
supported and preferred content representation rather than simply the device capabilities.
The Media Feature Sets description uses Boolean expressions for complex capabilities and
preferences. For example, the following expression describes a data resource that can be
displayed either:
27
IETF (Internet Engineering Task Force): a large open international community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the operation of the Internet. (http:// http://www.ietf.org/overview.html).
88
Chapter 5. Context Metadata Description
(a) as a 750x500 pixel image using 15 colors, or
(b) at 150dpi on an A4 page.
(| (& (pix-x=750) (pix-y=500) (color=15) )
(& (dpi>=150) (papersize=iso-A4) ) )
Note that “|’ is used for “or” and “&” is used for “and”. In the above expression dpi, pix-x,
pix-y, color, papersize are feature tags. One interesting feature of this description is that it is
possible to assign quality values (from 0 to 1) to capabilities and preferences. For example the
expression given above can be written as follows:
(| (& (Pix-x=750) (pix-y=500) (color=15)); q=0.8
(& (dpi>=150) (papersize=iso-A4)) ; q=0.7)
This expression shows that the image with 750x500 pixels using 15 colors is preferred over
the printed form of 150 dpi and A4 size.
This Media Feature Sets has been originally motivated by the requirements from web
browsers to send the browser's display characteristics to the web server to allow the server to
choose an appropriate representation. The media feature sets are included in the request
header like the accept-content header filled by web browsers. Up on receiving the request, the
content server retrieves the feature information from the header and sends a variant that
matches the features.
Drawbacks of the Media Feature Sets are: they have no structure (they use attribute/value
pairs only), there is no formal extension mechanism to add new features, there is no means to
reference external Media Feature Sets, and the Media Feature Tags currently-registered
[MFTR05] cover client capabilities, but not the relevant network properties.
Comprehensive Structured Context Profiles
5.4
89
Comprehensive Structured Context Profiles
To addresse the problems of context profile representation, Held et al. [Held02] have
developed the Comprehensive Structured Context Profiles (CSCP) framework. Just as CC/PP,
CSCP is based on RDF and thus inherits its interoperability and extensibility. Yet CSCP
overcomes the deficits of CC/PP regarding structuring. It does not impose any fixed
hierarchy. It rather supports the full flexibility of RDF to express natural structures of context
information. Attribute names are interpreted context-sensitively according to their position in
the profile structure. Thus, unambiguous attribute naming throughout the profile is not
required.
CSCP profiles are queried by referencing attribute values of entities in the profile. Attribute
values are referenced using CSCP path expressions, for example the expression
ContextProfile.DeviceProfile.Software.UserAgent.ContentTypes refers to content types
accepted by the user agent. A CSCP path expression always starts at a named resource (i.e.
root node) identified by its URI. The attributes of this resource are addressed by simply
appending a query component to the URI containing the attribute name. As the value of the
selected attribute can be a resource itself, attribute names can be chained in a dot-separated
list, thus forming a path traversing a sub-tree of the root node of the CSCP profile. Unlike
plain RDF, CSCP semantics allows for only a single valid attribute value at a time. Hence,
CSCP paths are unambiguous even if there are multiple uses of an attribute (e.g. the attribute
ContentTypes is used both in UserAgent and Preferences elements). The main limitation of
CSCP is that the description has not been standardized so it makes interoperability difficult.
For the device described in Figure 5.2 by CC/CP, the corresponding description in CSCP is
given in Figure 5.3.
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cscp="context-aware.org/CSCP/CSCPProfileSyntax#"
xmlns:dev="context-aware.org/CSCP/DeviceProfileSyntax#"
xmlns:net="context-aware.org/CSCP/NetworkProfileSyntax#"
xmlns="context-aware.org/CSCP/SessionProfileSyntax#"
<SessionProfile rdf:ID="Session">
<cscp:defaults rdf:resource= "http://Context/CSCPProfile/previous#Session"/>
90
Chapter 5. Context Metadata Description
<device>
<dev:DeviceProfile>
<dev:Hardware>
<dev:ScreenWdith>320</dev:ScreenWidth>
<dev:ScreenHeight>200</dev:ScreenHeight>
</dev:Hardware>
<dev:Software>
<dev:OperatingSystem>
<dev:Name>EPOC</dev:Name>
<dev:Version>2.0</dev:Version>
<dev:Vendor>Symbian</dev:Vendor>
</dev:OperatingSystem>
<dev:UserAgent>
<dev:Type>Browser</dev:Type>
<dev:Name>Mozilla</dev:Name>
<dev:Version>5.0</dev:Version>
<dev:Vendor>Symbian</dev:Vendor>
<dev:ContentTypes>
<rdf:Bag>
<rdf:li>text/html</rdf:li>
<rdf:Bag>
</dev:ContentTypes>
</dev:UserAgent>
</dev:Software>
</dev:DeviceProfile>
</device>
</SessionProfile>
</rdf:RDF>
Figure 5.3: CSCP Profile Example
5.5
MPEG 21
MPEG-21 [Burn03], formally known as ISO/IEC 21000-Multimedia Framework is one of a
series of standards being produced by the Moving Picture Experts Group. MPEG has a long
history of producing multimedia standards: MPEG-1 (1993), MPEG-2 (1996), MPEG-4
(1999), and MPEG-7 (2001). The MPEG 21 standard aims to enable a transparent and
augmented use of multimedia resources across a wide range of networks and devices. In order
to realize this goal, MPEG-21 provides a normative open framework for multimedia delivery
and consumption. This framework will be of use for all players in the multimedia delivery and
consumption chain. It will provide content creators, producers, distributors, and service
providers with equal opportunities in the MPEG-21 enabled open market. This will also be to
the benefit of content consumers, providing them access to a large variety of contents in an
interoperable manner. From a content adaptation point of view, content consumers can be
MPEG 21
91
services that perform content transformation, for example, in our approach they are adaptation
services.
The content description has been addressed by MPEG-7 but the description of content format
and usage environments has not been addressed and it has been the target of the MPEG-21
Digital Item Adaptation (DIA) specification.
MPEG-21 is based on two essential concepts: the definition of a fundamental unit of
distribution and transaction (the Digital Item) and the concept of Users interacting with
Digital Items. The Digital Items can be considered as the “what” of the Multimedia
Framework (e.g., a video collection, a music album) and the Users can be considered as the
“who” of the Multimedia Framework. Figure 5.4 shows the MPEG-21 multimeda
frameowork.
In MPEG-21, a User is an entity that interacts within the multimedia framework: it can be a
content creator, a content distributor, or a content consumer (end user). Users include
individuals,
consumers,
communities,
organizations,
corporations,
consortia,
and
governments. Users are identified specifically by their relationships to other users for a certain
interaction. From a purely technical perspective, MPEG-21 makes no distinction between
“content provider”, and “consumer”-both are Users in the MPEG-21 multimedia framework.
MPEG-21 introduced the notion of Digital Item to represent a multimedia content. It is the
fundamental unit of distribution and transaction among Users in the MPEG-21 multimedia
framework. It is a structured digital object with resources (the content), a unique identification
and corresponding metadata (e.g. MPEG-7 description). The structure relates to the
relationships among the parts of the Digital Item, both resources and metadata.
92
Chapter 5. Context Metadata Description
Figure 5.4: A Representation of the MPEG-21 Multimedia Framework [Maga04]
MPEG-21 provides a framework for Users interaction through the Digital Item. Here, the goal
is to develop the necessary technologies that support the access, the exchange, the use and the
manipulation of the Digital item in an effective, transparent and interoperable way. In order to
achieve the goal, the framework defines the elements necessary and the operations applicable
to these elements which at the end guarantee an effective content transmission chain. To
realize these elements, the MPEG-21 standard is organized into several more or less
independent parts primarily to allow various slices of the technology to be useful as standalones [Burn03]. Here, we discuss two of these parts: the Digital Item Declaration (DID) (part
2) and Digital Item Adaptation (DIA-part 7) because they are highly related to our work.
Digital Item Declaration (DID)
The Digital Item Declaration (ISO/IEC 21000-2) [ITMF03] specifies a uniform and flexible
abstraction and interoperable schema for declaring the structure and makeup of Digital Items.
Through the Digital Item Declaration Language (DIDL), a DI can be declared by specifying
its resources (content), metadata, and their interrelationships. The MPEG-21 standard
describes the DID using a model, a representation and a schema. The DID model describes a
set of abstract terms and concepts for defining Digital Item. The representation (in XML)
MPEG 21
93
contains the normative description of the syntax and semantic of each of the DID elements.
The DIDL schema comprises the entire grammar of the DID representation in XML.
Digital Item Adaptation (DIA)
One of the goals of MPEG-21 is to achieve an interoperable transparent access to distributed
multimedia contents by shielding users from network and terminal installation, management,
and implementation issues. Achieving this goal requires the adaptation of Digital Items (see
Figure 5.5). The Digital Item Adaptation (ISO/IEC 21000-7) specifies tools for the adaptation
of Digital Items [MDS03]. Figure 5.5 illustrates a Digital Item that is subject to a resource
adaptation engine and a description adaptation engine, which produces the adapted Digital
Item. For the adaptation, both the description of the content and a description of its format and
the usage environment are essential. The content description has been addressed by MPEG-7
but the description of the content format and the usage environments has not been addressed
and it is the target of the MPEG-21 Digital Item Adaptation (DIA) specification. The major
component of the DIA specification is the usage environment description tool which consists
of [ISO04]:
•
Terminal characteristics: media resource encoding and decoding formats, hardware,
software and communication protocols, etc.
•
Network characteristics: bandwidth, delay and error characteristics
•
Natural environment characteristics: location and time, illumination, altitude,
temperature etc.
•
User preferences: media preferences, presentation preferences, usage history, and
location characteristics.
94
Chapter 5. Context Metadata Description
Digital Item
Adaptation Engine
Digital
Item
Resource Adaptation
Engine
Adapted
Digital
Item
Description
Adaptation Engine
DIA Descriptions
Scope of
standardization
DIA Tools
Figure 5.5: The Adaptation of Digital Items
MPEG-21 is more than a metadata description standard. MPEG-21 standardizes the DIA tools
for adapting multimedia contents according to usage environment descriptors. The adaptation
engines are non-normative tools. The implementation of an engine that actually performs the
required adaptation steps to the multimedia content is left to tool vendors and is beyond the
scope of standardization.
5.6 Summary
This chapter presented the context metadata representation mechanism. We have discussed
different representation mechanisms: CC/PP, IETF Media Feature Sets, CSCP and MPEG-21.
CC/PP is a context description framework proposed by W3C for describing device
capabilities and user preferences based on RDF. CC/PP defines the basic structure of context
profiles and introduces a mechanism for profile decomposability. Whereas CC/PP is
interchangeable, decomposable, uniform and extensible, it lacks sufficient structuring. Its
strict two-level-hierarchy is not appropriate to capture complex profile structures.
Furthermore, CC/PP does not allow for context-sensitive interpretation of attributes requiring
globally unambiguous attribute naming.
Summary
95
The IETF Media Feature Sets specify device capabilities and user preferences by unstructured
attribute/value pairs which is not appropriate. Complex capabilities and preferences are
expressed by Boolean expressions of predicates about single attributes. The Media Feature
Sets are not decomposable and there are no formal, machine readable means for extensions.
The MPEG-21 DIA tools guarantee an efficient adaptation of multimedia content but the
focus only on the MPEG-21 contents limits their application. Exploiting the full potential of
the standard requires MPEG-21 compatibility by all users of the Digital Item which may not
be always the case and also limits its openness. Since there are several formats other than
MPEG-21 in a heterogeneous environment, it is important to have an adaptation strategy for a
broader range of content and conditions.
CSCP is an extension of CC/PP. It provides a multilevel structure that allows representing all
types of context information. CSCP is based on RDF and thus inherits its interchangeability
and extensibility. Attribute names are interpreted context-sensitively according to their
position in the profile structure. Thus, unambiguous attribute naming throughout the profile is
not required. Furthermore, CSCP provides mechanisms to attach conditions and priorities to
attributes. This extends the means to express user preferences. The CSCP description has
been chosen in our work for three reasons (1) the CSCP description is simple as it is used to
describe only the context information unlike the MPEG-21 which is used to describe the
context and the content format (2) the MPEG-21 context description does not have
QoSAdapationService specification such as execution time and prices which are important
components in our work (3) the efficient use of MPEG-21 requires that all the components
participating in the content delivery should be MPEG-21 compatible in other words, not only
the context but the content description should also be in MPEG-21 and this limits openness of
the system.
Chapter
6
Service-Based Content
Adaptation
In this chapter we describe the design and implementation of our proposal of Distributed
Content Adaptation Framework. The chapter starts with an introduction in Section 6.1.
Section 6.2 presents the reasons of service-based content adaptation. Section 6.3 presents a
functional model of a service-based adaptation system. Section 6.4 describes the Distributed
Content Adaptation Framework (DCAF) architecture which is a service-based approach and
its components. Content and context metadata descriptions used by DCAF are given in
section 6.5. The multimedia content adaptation services description is presented in Section
6.6. Section 6.7 describes the Content Adaptation and Negotiation Module (CNAM), the
construction of the adaptation graph, the adaptation graph generator, and its algorithm.
Finally, the chapter ends with a summary in Section 6.8.
6.1 Introduction
As it has been discussed in Chapter 2, context aware content adaptation has been considered
as a fundamental requirement for pervasive computing to meet the dynamic heterogeneous
environment. Up to now, three important approaches have been proposed for content
adaptation namely server-based, client-based and proxy-based (Chapter 2). In this thesis we
present a service-based approach. The main idea behind this proposal is that content
adaptations are developed as services such as web service that will be easily integrated and
reused in our work. In this proposal, a service composition algorithm based on AI (Artificial
Intelligence) planning technique is developed to compose the adaptation services. For this
purpose we have developed a Distributed Content Adaptation Framework (DCAF). Before the
discussion of the concept of our service-based content adaptation, we first briefly present the
98
Chapter 6. Service-Based Content Adaptation
reasons for using services for content adaptation and the general functional model of
adaptation system.
6.2
Why Service-Based Content Adaptation?
In a server or proxy based adaptation approaches, the adaptation systems are developed for
particular or specific application. This (1) limits the usability of the adaptation tool only by
that application (2) does not allow the application to access and use other tools with the same
functionalities that provides better performance and (3) does not permit to change the code of
the tool easily in order to get better performance and better result as it is might affect the
application and (4) lacks scalability and interoperability. By using SOA, adaptation tools can
be developed as services and can be widely accessible through proper communication
interface. Since the services are developed to implement a particular adaptation, they are
efficient. New adaptation tools can be developed by using more powerful algorithm and then
implemented as services. Using the new services does not require modification of the
application system. Moreover, the SOA provides a level of flexibility in deploying and
reusing services not previously attained. Finally, the scalability and interoperability issues can
be solved as the SOA paradigm tends to provide these features. Our proposition of distributed
service-based content adaptation approach bases on these facts.
The use of SOA enables a generic application independent adaptation framework which can
be adapted to different application scenarios. As presented in Chapter 1, there are different
scenarios where we need content adaptations to deliver services to users. For example, an
adaptation framework developed for the medical application can be adapted to tourism or
cooking guide application scenarios with little modifications.
6.3
Functional Model of Adaptation System
The motivation for multimedia content adaptation is to provide with the best possible content
to a user given the heterogeneity of data and device, the limitation of resources, the
characteristics of device and the user’s preferences. A functional overview of our adaptation
system is depicted in Figure 6.1. The usage environment context and the content metadata are
Overview of the DCAF Architecture
99
used to select the adaptation service (s) required to deliver the multimedia content. The
adaptation services description is used to determine the appropriate adaptation services.
Context Metadata
Adaptation service
description
Collects
Collects
Adaptation
system
Processes
Content Metadata &
data
Delivers
Adapted data
Figure 6.1: Functional Model
•
Context Metadata: it consists of the device capabilities, user characteristics and
preferences, and network conditions.
•
Adaptation service description: it consists of the functional and non-functional service
descriptions.
•
Content metadata: it consists of the content description.
•
Content data: the multimedia content to be adapted
6.4
Overview of the DCAF Architecture
The DCAF aims to provide an extensible, scalable, flexible and interoperable adaptation
architecture for pervasive computing applications. The proposed approach is service-based,
i.e. it makes use of Internet accessible adaptation services. Adaptation services provide
adaptation functionalities or tools. An adaptation need or requirement can be broken up into
adaptation steps each fulfilling a certain function. There may be more than one service which
fulfills the same functionality. It is at the adaptation decision time that the appropriate
services are selected, invoked and executed. In our model, in addition to the functional
requirements, non-functional requirements such as service execution time and price are used
100
Chapter 6. Service-Based Content Adaptation
to determine which services would be more suitable to fulfill the required adaptation task(s).
In this section, we present the general architecture of the DCAF architecture, the different
components involved and their roles (see Figure 6.2). The architecture is composed of six
components. We describe these components and their functional relationships as follows:
Content Servers (CSs): they are standard data repositories such as web sites, databases, and
media servers.
Content Proxies (CPs): the content proxies provide access to Content Servers, formulate user
request to source format, manage and provide content description (metadata).
Client Profile Repository (CPR): stores usage environment context information that is, the
user characteristics and preferences, the terminal capabilities and characteristics. Users can
update and modify their profiles at any time. Dynamic context information such as user
location and network conditions are determined at data request execution.
Adaptation Service Registry (ASR): searching the available Web Services space to find
matching services for content adaptation is a problem that with an increasing number of
services displays exponential growth. To cope with this problem, we introduce an adaptation
service registry. The ASR is like a Universal Description, Discovery and Integration (UDDI)
registry specialized for multimedia adaptation services. In additiona to the functional and nonfunctional information of the mulltimedia adaptation services, it also stores semantic
information (e.g. the type of media the service handles) and allows for service look up.
Adaptation Service Proxies (ASPs): the adaptation service proxies are the servers that host
one or more adaptation tools or functionalities. In our framework ASPs are implemented as
Web Services and are developed independently of the DCAF.
Local Proxies (LPs): access point to information delivery systems. They are in charge of
retrieving and processing context profile. They decide the type and number of adaptation
processes, discover adaptation services, plan the execution of the adaptation services and
finally invoke the services. The core part of the local proxy is a content negotiation and
adaptation module (CNAM). This module computes an optimal execution plan of the
Context and Content Descriptions
101
adaptation process and invokes the adaptation services accordingly (see Section 6.6 for
details).
Adaptation Services
Adaptation
Services
Registry
Content Servers
Internet
User Devices
Local Proxies
Content Proxies
Context Profile
Repository
Figure 6.2: General architecture of the Distributed Content Adaptation Framework (DCAF)
6.5
Context and Content Descriptions
As depicted in Figure 6.1, the decision of the adaptation process depends on the extent and
quality of information gathered from various sources. This information consists of usage or
context description, content description or metadata and adaptation services description. The
context description (or context profile) includes the device profile, the network profile, the
user profile and possibly other context information such as environmental information (e.g.
location, sensor information, etc.). The content description (or content metadata) contains
information about the content data or media such as title, description etc., and the media
profile such as format, size, etc. The adaptation service description (or service profile)
contains information about the service such as the name, location, function it provides, etc.
The context and content descriptions are presented in the following sections and the
adaptation services description is presented in Section 6.6.
102
Chapter 6. Service-Based Content Adaptation
6.5.1 Context Description
The context description must give a complete description of the environment and provide an
easy way of processing it. For the reasons discussed in Chapter 5, we have chosen the CSCP
to represent the context information in the DCAF architecture. The context description
(whose partial structure is shown in Figure 6.3) is made of three schemas: the user profile
schema, the device profile schema and the network profile schema. Figure 6.4 shows an
example of partial context profile for a sample device represented in XML. The full context
profile structure and its schema definition can be found in Annex A.
ContextProfile
DeviceProfile
Hardware
DeviceType
ScreenWidth
Software
OperatingSystem
Name
Version
UserAgent
Type
Name
Figure 6.3: Partial Structure of Context Profile Representation
<?xml version="1.0" encoding="UTF-8"?>
<ContextProfile rdf:ID=”Context”>
<device>
<dev:DeviceProfile>
<dev:Hardware>
<dev:ScreenWidth>320</dev:ScreenWidth>
<dev:ScreenHeight>200</dev:ScreenHeight>
</dev:Hardware>
<dev:Software>
<dev:OperatingSystem>
<dev:Name>EPOC </dev:Name>
<dev:Version>2.0</dev:Version>
<dev:Vendor>Symbian</dev:Vendor>
</dev:OperatingSystem>
<dev:UserAgent>
<dev:Type>Browser</dev:Type>
<dev:Name>Mozilla</dev:Name>
<dev:Version>5.0</dev:Version>
<dev:Vendor>Symbian</dev:Vendor>
</dev:UserAgent>
</dev:Software>
Context and Content Descriptions
103
</dev:DeviceProfile>
</device>
</ContextProfile>
Figure 6.4 Partial Example of Context Profile
6.5.2 Content Description (Metadata)
The architecture consists of content servers and content proxies. The content servers store
media objects such as text, image, audio and video. The content proxies manage the content
metadata. Metadata contain both the information about the object(s) captured in the mediathe object’s title, description, language, etc.- and feature data about the media itself (not about
the object(s) in the media). Feature data include the media type, the file format, the file size,
the media dimensions, the color information, the location, etc. For content description the
XML form of MPEG-7 description is used. Figure 6.5 shows an example of the description
for an image data. Content metadata are generated during content creation and stored at
Content Proxies.
<?xml version="1.0" encoding="UTF-8"?>
<ContentDescription>
<MultimediaContent type=“Image”>
<MediaInformation ID=“x_ray_image”>
<MediaUri> http:/localhost/imagefiles/gorge.jpeg </MediaUri>
<MediaTitle>Examen de la gorge</MediaTitle>
<MediaDescription> Patient atteint d’un cancer de la gorge. A ce que nous avons pu
constater, le patient ne peut s’empêcher de fumer un paquet de cigarettes par
jour</MediaDescription>
<MediaLanguage>French</MediaLanguage>
</MediaInformation>
<MediaProfile>
<MediaFormat>JPEG</MediaFormat>
<MediaSize>61.6 </MediaSize>
<MediaWidth>660</MediaWidth>
<MediaHeight>445</MediaHeight>
<MediaColor>24</MediaColor>
</MediaProfile>
</MultimediaContent>
</ContentDescription>
Figure 6.5 Sample Multimedia Content Description in XML Format
104
Chapter 6. Service-Based Content Adaptation
6.6 Multimedia Content Adaptation Services Description
Since the adaptation approach proposed in this thesis uses externally developed adaptation
services, it is important to use or develop appropriate service description mechanism(s). A
service description specifies what a service does, how the service works and how the service
is implemented. The service description enables the following tasks: discovery, i.e. locating
services that provide a particular service (typically through a registry, in our architecture the
adaptation service registry) and that adhere to specified constraints, invocation or activation
and execution of an identified service by an agent or other service, and composition of new
services through automatic selection, composition and interoperation of existing services.
As discussed in Chapter 3, a syntactic service description such as WSDL is not adequate for
automatic service discovery, selection and composition. To enhance the service discovery and
composition, the description should also include semantic information. Semantic description
gives meanings and relationships of the terms and concepts used in describing services. For
example in multimedia adaptation services, the semantic information consists of the meaning
of the input/output, effect of executing the service, cost of the service, service execution time,
etc. Semantic service description can be achieved using ontology.
As part of the thesis work, we propose to build a multimedia adaptation service ontology.
This ontology facilitates describing adaptation services semantically so that they can be
discovered, selected, composed and invoked automatically. To build the ontology, the first
step was to determine the basic multimedia adaptation services and multimedia data entities.
Then, structural hierarchies were determined from the entities. Some entity properties were
adopted from OWL-S profile [Ankol01]. Here for the sake of understanding, we present the
part of the ontology for audio adaptation services as an example. The full ontology can be
found in Annex B.
Multimedia Content Adaptation Services Description
105
6.6.1 Adaptation Service and Multimedia Data Entities
Based on audio adaptation techniques discussed in various papers [Lei01a, Shaha01,
Mohan99], we have identified the following possible audio adaptation services (Table 6.1).
Name
AudioReductionAdaptationServices
Definition
Services that reduce the bit rate of an
audio file
AudioSamplingRateReductionAdaptationServices Services that reduce the rate at which an
audio file is sampled.
StereoToMonoAdaptationServices
Services that convert an audio which has
two channels to single channel
AudioFormatTranscodingAdaptationServices
Services that change the audio file format
(e.g. WAV to MP3)
AudioLanguageTranslationAdaptationServices
Services that translate an audio in one
language to another language (e.g.
French to English).
AudioToTextAdaptationServices
Services that convert an audio file to a
text document.
Table 6.1: Types of Audio Adaptation Services
The above definitions are used to represent the functionalities of audio content adaptation
services. The services have input and output of multimedia data type. Formalizing the
multimedia data types helps to represent the input and output of the services in a standard
way. Table 6.2 shows the multimedia data type entities identified in our prototype (Chapter
7).
Name
Description
MultimediaDatatype
It represents multimedia data types such as audio,
video, image, text, etc.
ImageDatatypeFormat
It represents image data type formats.
AudioDatatypeFormat
It represents audio data type formats.
VideoDatatypeFormat
It represents video data type formats.
TextDatatypeFormat
It represents text data type formats.
GraphicsDatatypeFormat
It represents graphical data type formats.
AnimationDatatypeFormat It represents animation data type formats.
Table 6.2: Multimedia Data Types
106
Chapter 6. Service-Based Content Adaptation
6.6.2 Class Hierarchy
To determine the structural hierarchy of the adaptation service entities, we used the content
adaptation technique classification defined by Lei et al. [Lei01]. According to this definition,
the adaptation techniques are classified based on the different criteria. Here, we are interested
in audio adaptation techniques. We can classify audio adaptation techniques as unimodal or
multimodal. The first class consists of techniques used to create different versions of the
audio element with different qualities, formats and resource requirements. For example,
techniques that are used to convert an audio from one format, e.g. WMA to MP3. The second
class consists of techniques that are used to convert audio to another media type, for example
audio to text conversion.
The different adaptation services are represented as classes in the ontology. These classes can
be arranged in hierarchy that is useful for service discovery. This hierarchy, shown in Figure
6.6, is based on the broad classifications described above. For the sake of simplicity, only the
audio adaptation services are presented in detail the figure. The hierarchical classification
together with the service properties (see section 6.6.3) gives a complete ontology of the
adaptation services.
Multimedia Content Adaptation Services Description
107
MultimediaAdaptationServices
f
su
bC
l as
sO
ImageAdaptationServices
O
la
ss
su
bC
f
O
f
las
s
f
su
bC
O
f
Of
las
s
su
bC
f
AudioLanguageAdaptation
Services
ss
la
bC
su
AudioFormatAdaptation
Services
O
ss
la
bC
su
subClassOf
la
ss
O
TextAdaptationServices
O
su
bC
Of
UnimodalAudioAdaptationServices
AudioReductionAdaptation
Services
StereoToMonoAdaptation
Services
ss
ss
la
bC
su
f
AudioAdaptationServices
MultimodalAudioAdaptationServices
AudioToTextAdaptation
Services
Cla
f
VideoAdaptationServices
su
b
O
ss
la
bC
su
bC
su
f
sO
las
AudioSamplingRateReduction
AdaptationServices
Figure 6.6: Class Hierarchy of Top-level of Multimedia Content Adaptation Services
The super class in the ontology is MultimediaAdaptationServices. This class can have different
sub-classes of adaptation services that are specific to each media element like audio
adaptation services, image adaptation services, etc. Figure 6.7 shows the OWL representation
of the super class (MultimediaAdaptationServices).
<owl:Class rdf: ID= “MultimediaAdaptationServices”>
<owl:Class rdf:ID= “AudioAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
<owl:Class rdf:ID= “TextAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
<owl:Class rdf:ID= “ImageAdaptationServices”>
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
<owl:Class rdf:ID= “VideoAdaptationServices”>
108
Chapter 6. Service-Based Content Adaptation
<rdfs:subClassOf rdf:resource= “MultimediaAdaptationServices”/>
</owl:Class>
Figure 6.7: OWL Representation of MultimediaAdaptationServices Class
Here, we present as an example the audio adaptation services. Therefore, the description of
the sub-classes and properties are restricted to audio adaptation services. Figure 6.8 shows
specifically the class hierarchy of the audio adaptation services.
bC
su
su
bC
f
O
ss
la
la
ss
O
f
AudioAdaptationServices
MultimodalAudioAdaptationServices
bC
su
subClassOf
f
O
ss
la
AudioLanguageAdaptation
Services
bC
su
ss
la
su
bC
AudioFormatAdaptation
Services
f
O
AudioReductionAdaptation
Services
la
ss
O
f
AudioToTextAdaptation
Services
su
bC
su
bC
la
ss
O
f
la
ss
O
f
UnimodalAudioAdaptationServices
StereoToMonoAdaptation
Services
AudioSamplingRateReduction
AdaptationServices
Figure 6.8: Excerpt of Class Hierarchy of Audio Adaptation Service Classes
The AudioAdaptationServices class inherits all properties of MultimediaAdaptationServices, but it
restricts the value of the input property, hasInputType to be Audio. This is because, all audio
adaptation services take an audio file as their input. This class has two sub-classes:
UnimodalAudioAdaptationServices
MultiModalAudioAdaptationServices.
and
The
UnimodalAudioAdaptationServices has an additional restriction on its output data type property
other than the restrictions inherited on its input data type. The instance of this property is
restricted
to
be
Audio.
AudioReductionAdaptationServices,
This
class
has
three
subclasses
AudioLanguageAdaptationServices
under
it:
and
AudioFormatAdaptationServices. The AudioReductionAdaptationServices has two sub-classes:
Multimedia Content Adaptation Services Description
109
StereoToMonoAdaptationServices and AudioSamplingRateReductionAdaptationServices. The other
sub-class of AudioAdaptationServices is the MultimodalAudioAdaptationServices which has one
sub-class, AudioTextAdaptationServices.
The
Figure
6.9
shows
a
small
excerpt
of
the
OWL
representation
of
the
AudioAdaptationServices class. The full description of the ontology can be found in Annex B.
<owl:Class rdf:about="#AudioAdaptationServices">
<rdfs:subClassOf rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:hasValue rdf:resource="#Audio"/>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasInputType"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Figure 6.9: A Small Excerpt of OWL Representation for AudioAdaptationServices Class
6.6.3 Properties of Entities
For audio adaptation services we have identified the following properties, most of which are
similar to those of the OWL-S profile class (See Annex C). These properties are shown in
Table 6.3. These properties are general to all multimedia adaptation services so to make it
extensible to other media elements easier we have put them as properties of the general class
MultimediaAdaptationServices.
110
Chapter 6. Service-Based Content Adaptation
MultimediaAdaptationServices
Property name
Value
Definition
hasServiceName
String
Name of the service
hasServiceTime
Float
Service execution time
hasServiceQuality
String
Quality value for the adapted data
hasEffect
Instance of
Effect of service execution e.g.
MultimediaDataTypeFormat language change or format change
class
hasInputType
String
Name of the input data type
hasOutputType
String
Name of the output data type
hasServicePrice
Float
Service charge
hasPrecondition
Instance of
Conditions to be satisfied to execute
MultimediaDataTypeFormat the service for example, format of an
class
image data, frame rate of a video data,
etc.
hasServiceProvider
String
Name of the service provider that may
include address and other related
information
hasServiceDescription String
Any description about the service
Table 6.3: Properties of MultimediaAdaptationServices
All types of multimedia data type formats have similar properties. Therefore, we put them as
properties of the general class that is MultimediaDatatypeFormat. Table 6.4 shows the properties
with their description.
Multimedia Content Adaptation Services Description
111
MultimediaDatatypeFormat
Property name
Value
Definition
hasDatatype
String
Name of the media type
hasFormat
String
Name of the format type
Table 6.4: Properties of MultimediaDatatypeFormat Class
In Figure 6.10 we present an example of a description of audio to text adaptation service
using the described ontology.
<AtomicProcess rdf:ID="AudioToTextAdapationService ">
<hasInput rdf:ID="#InputAudio">
<parameterType datatype="&xsd;#anyURI">
</hasInput>
<hasOutput rdf:ID="#OutputText">
<parameterType datatype="&xsd;#anyURI">
</hasOutput>
<hasPrecondition>
<hasExpression rdf:ID="InputAudioFormat">
<hasSubject rdf:resource="#InputAudio"/>
<hasProperty rdf:resource="#Audio"/>
<hasFormat rdf:datatype="&xsd; #string">#WAV</hasFormat>
</hasExpression>
</hasPrecondition>
<hasEffect>
<hasExpression rdf:ID="OutputTextFormat">
<hasSubject rdf:ID="#OutputText"/>
<hasProperty rdf:resource="#Text"/>
<hasFormat rdf:datatype="&xsd;#string">#PlainText</hasFormat>
</hasExpression>
</hasEffect>
<hasServicePrice>
<parameterType datatype="&xsd;#float">25
</hasServicePrice>
<hasServiceTime>
<parameterType datatype="&xsd;#float">200
</hasServiceTime>
</AtomicProcess>
Figure 6.10: An Example of Service Description for Audio to Text Adaptation Service
112
6.7
Chapter 6. Service-Based Content Adaptation
Content Negotiation and Adaptation Module
The building block of the local proxy is the Content Negotiation and Adaptation Module
(CNAM). CNAM has two main components: the adaptation decision engine and the
adaptation planner. The decision engine computes the needed adaptation types to run using
the environments parameters: user profile, device profile, network profile, and content
metadata. Once the adaptation types are known, the next step is to determine the adaptation
services to execute them. The adaptation planner is concerned with the selection and the
composition of appropriate adaptation services. The selection of the adaptation services is
based on quality criteria such as service cost and execution time. The adaptation planner finds
these quality criteria from the service description (hasServicePrice, hasServiceTime). Figure
6.11 illustrates the process of content adaptation.
Client
ListDoc
Client
SelDoc
Req
Document filtering
Selected Doc
Doc.Req
ListDoc
Content Proxy
eq
C. R
s
e
C.R
Content Extractor
Content & metadata
Client Profile
Adaptation Decision
Transformation List
Adaptation Planner
Adaptation
Service Profile
Plan of Execution
Proxy Service 1
Plan Executor
Adapted Content
Client
Req
DocReq
ListDoc
SelDoc
C.Req
C.Res
Request
Document Request
List of documents
Selected document
Content Request
Content Response
Figure 6.11: Content Adaptation Process
Proxy Service 2
Proxy Service N
Content Negotiation and Adaptation Module
113
The above figure shows the different steps during the process of content negotiation and
adaptation. The boxes in continues line (e.g. Document Filtering) represent processes. The
boxes in broken line (e.g. Transformation List) represent output and input of the processes.
6.7.1 Constructing Content Adaptation Graph
In a typical pervasive application scenario, a client requests a multimedia content from a
server using a device with specific properties connected to the server through a given
network. In such scenario, the idea of content adaptation is that the multimedia content stored
at the server in exactly one defined format is transformed according to the device capabilities,
the network connections and the user preferences before it is delivered to the client.
Considering the usage context and the multimedia metadata, it may be necessary to apply a
set of transformations28 so that the content matches the usage environment. For example, the
three scenarios presented in Chapter 1 (Section 1.4), demonstrates the need of several
transformations or multi-step adaptations to deliver the response content based on the usage
context, characteristics of the stored multimedia contents, and preferences of the user as
discussed below.
In Scenario I, assuming that the content is written in English language and the user’s
preference is French language we need text to audio and English to French transformations.
In Scenario II, assuming that the map is stored in colored GIF format and the device supports
non color BMP images and in addition, the dimension of the map is greater than the device’s
screen display, we need at least three transformations to display the map on the user’s device.
The needed transformations are: removing the color (changing to black and white), changing
the dimension and changing the format.
In Scenario III, the doctor might prefer to listen rather than read the response on the past
medical history of the patient. In this case, it may be necessary to summarize, translate and
convert the text to audio.
28
In this work the term transformation and adaptation are equivalent
114
Chapter 6. Service-Based Content Adaptation
Transformation mapping rules
As indicated in Figure 6.11, one of the components in the content adaptation process is the
adaptation decision. To facilitate and speed up the computation of the needed transformations
we defined a constraint to the transformation mapping rules. These rules are used to
determine what transformations are required to meet the environment constraints such as the
device capabilities, user preferences and network conditions etc. A description file specifies
each transformation process along with a set of constraints. Table 6.5 shows a sample of these
transformation rules. The transformation rules are interpreted as follows: For example, to
apply image-resizing, the multimedia content type must be image, the device hardware must
be image capable and the image size must be greater than the device size.
For the purpose of simplicity and interoperability XML format is used to describe the rules.
The XML representation of the transformation rules contains Boolean expressions for
aggregating constraints; and, or, and not. It has also a number of conditionals: lessthan,
lessthanequal, greaterthan, greaterthanequal, equal, and contains.
Content Negotiation and Adaptation Module
Transformation
text-languagetranslation
text-to-audio
image-resizing
image-formatconversion
video-to-imageconversion
video-to-text
audio-to-text
115
Context constraint
(MultimediaContent.Type="Text"
^ MultimediaContent.MediaInformation.MediaLanguage
∉UserProfile.Preferences.Languages)
^ ((DeviceProfile.Hardware.TextCapable="Yes" ^
"Text" ∈ DeviceProfile.Software.UserAgent.ContentTypes)
v (DeviceProfile.Hardware.AudioCapable="Yes" ^
"Audio" ∈ DeviceProfile.Software.UserAgent.ContentTypes))
(MultimediaContent.Type="Text"
^ DeviceProfile.Hardware.AudioCapable="Yes"
^ "Audio" ∈ DeviceProfile.Software.UserAgent.ContentTypes)
^ ("Audio" ∈ UserProfile.Preferences.ContentTypes
v DeviceProfile.Hardware.TextCapable="No")
(MultimediaContent.Type="Image"
^ DeviceProfile.Hardware.ImageCapable="Yes"
^ "Image" ∈ DeviceProfile.Software.UserAgent.ContentTypes)
^ ((MultimediaContent.MediaProfile.MediaWidth
> DeviceProfile.Hardware.ScreenWidth)
v (MultimediaContent.MediaProfile.MediaHeight
>DeviceProfile.Hardware.ScreenHeight))
(MultimediaContent.Type="Image"
^ DeviceProfile.Hardware.ImageCapable="Yes"
^ "Image" ∈ DeviceProfile.Software.UserAgent.ContentTypes
^ MultimediaContent.MediaProfile.MediaFormat ∉
DeviceProfile.Software.UserAgent.ContentFormats)
(MultimediaContent.Type="Video"
^ DeviceProfile.Hardware.ImageCapable="Yes"
^ "Image" ∈ DeviceProfile.Software.UserAgent.ContentTypes)
^ (DeviceProfile.Hardware.VideoCapable="No"
v "Image" ∈ UserProfile.Preferences.ContentTypes
v (NetworkProfile.Bandwidth<=UserProfile.QoSNetwork.Medium.L2 ^
NetworkProfile.Bandwidth>=UserProfile.QoSNetwork.Medium.L1))
(MultimediaContent.Type="Video"
^ DeviceProfile.Hardware.TextCapable="Yes"
^ "Text" ∈ DeviceProfile.Software.UserAgent.ContentTypes)
^ (DeviceProfile.Hardware.VideoCapable="No"
v DeviceProfile.Hardware.ImageCapable="No"
v "Text" ∈ UserProfile.Preferences.ContentTypes
v (NetworkProfile.Bandwidth<=UserProfile.QoSNetwork.Low.L2 ^
NetworkProfile.Bandwidth>=UserProfile.QoSNetwork.Low.L1))
(MultimediaContent.Type="Audio"
^ DeviceProfile.Hardware.TextCapable="Yes"
^ "Text" ∈ DeviceProfile.Software.UserAgent.ContentTypes)
^ (DeviceProfile.Hardware.AudioCapable="No"
v "Text" ∈ UserProfile.Preferences.ContentTypes
v (NetworkProfile.Bandwidth<=UserProfile.QoSNetwork.Low.L2 ^
NetworkProfile.Bandwidth>=UserProfile.QoSNetwork.Low.L1))
Table 6.5: Sample Transformation Rules
116
Chapter 6. Service-Based Content Adaptation
Usually transformations that apply transmoding should come at the end, that is, after all the
other transformations are applied on the original data. For example in Scenario III where
summarization, translation and text-to-audio are required, the text-to-audio transformation
should be done at the end while summarization and translation can be done in any order. Of
course applying translation after summarization is more efficient than the other way. In this
case summarization, translation and text to audio, is the more efficient ordering. To capture
such ordering information so that to produce efficient transformation ordering, we defined
two tags: before and after. Optionally each transformation may have before and after tags to
specify its order with respect to other transformations. Taking the same example, Scenario III,
for the translation, the after tag contains summarization. Figure 6.12 gives an example of
transformation rules represented in XML format.
<?xml version="1.0" encoding="UTF-8"?>
<transformations>
<transformation name="text-language-translation">
<constraint>
<and>
<and>
<equal value="Text">MultimediaContent.Type</equal>
<not>
<contains
ref="MultimediaContent.MediaInformation.MediaLanguage">UserProfile.Preferences.Languages</contains>
</not>
</and>
<or>
<and>
<equal value="Yes">DeviceProfile.Hardware.TextCapable</equal>
<contains value="Text ">DeviceProfile.Software.UserAgent.ContentTypes</contains>
</and>
<and>
<equal value="Yes">DeviceProfile.Hardware.AudioCapable</equal>
<contains value="Audio">DeviceProfile.Software.UserAgent.ContentTypes</contains>
</and>
</or>
</and>
</constraint>
<after>
<transformation>text-summary</transformation>
</after>
</transformation>
<transformation name="text-to-audio">
<constraint>
<and>
<equal value="text">MultimediaContent.Type</equal>
<equal value="Yes">DeviceProfile.Hardware.AudioCapable</equal>
<contains value="audio">DeviceProfile.Software.UserAgent.ContentTypes</contains>
<or>
<contains
value="audio">UserProfile.Preferences.ContentTypes</contains>
<equal
value="No">DeviceProfile.Hardware.TextCapable</equal>
</or>
</and>
</constraint>
<after>
Content Negotiation and Adaptation Module
117
<transformation>text-summary</transformation>
<transformation>text-language-translation</transformation>
</after>
</transformation>
<transformation name="image-resizing">
<constraint>
<and>
<equal value="image">MultimediaContent.Type</equal>
<equal value="Yes">DeviceProfile.Hardware.ImageCapable</equal>
<contains value="image">DeviceProfile.Software.UserAgent.ContentTypes</contains>
<or>
<lessthan ref="MultimediaContent.MediaProfile.MediaWidth">DeviceProfile.Hardware.ScreenWidth</lessthan>
<lessthan ref="MultimediaContent.MediaProfile.MediaHeight">DeviceProfile.Hardware.ScreenHeight</lessthan>
</or>
</and>
</constraint>
<before>
<transformation>image-format-conversion</transformation>
<transformation>image-color-reduction</transformation>
</before>
</transformation>
</transformations>
Figure 6.12: Sample Transformation Rules in XML Format
The decision engine produces the transformations needed using the context profile, the
multimedia metadata and the transformation rules. The engine processes the mapping rules as
follows. It parses the file and constructs a post fix description of each set of constraints. It
stores this postfix description in a vector for later evaluation. For example, the text-to-audio
transformation is represented in Table 6.6.
expression
Variables
value
equal
MultimediaContent.Type
"Text"
equal
DeviceProfile.Hardware.AudioCapable
"Yes"
contains
DeviceProfile.Software.UserAgent.ContentTypes "Audio"
contains
UserProfile.Preferences.ContentTypes
"Audio"
equal
DeviceProfile.Hardware.TextCapable
"No"
or
and
Table 6.6: Constraint Processing
The decision engine evaluates the postfix description of a set of constraints by retrieving each
expression, evaluating it and then writing the result back to a result stack. In the case of textto-audio transformation it examines audio capability of the device, user’s content type
preference, content types supported by the device and writes true or false accordingly. The
118
Chapter 6. Service-Based Content Adaptation
engine repeats this process for each transformation and returns a vector containing the names
of transformations necessary to meet the context constraints. As a result of the process, the
engine returns a file (in XML format) that consists of a list of transformations. We call this
file transformation prescript. The transformations are ordered using the information in before
and after tags of the description file, if there exist, otherwise randomly. For the scenario III
described in Chapter 1, the transformation prescript is given in Figure 6.13. We will use this
example in the following to illustrate the adaptation process before formalizing it in Section
6.7.2.
<?xml version="1.0" encoding="UTF-8"?>
<transformationPrescription>
<source>
<MediaContent type="text" identifier="http://localhost/text-data /text-test.txt"
format="text/plain" language="EN"/>
</source>
<transformation name="text-summary">
<input type="text"/>
<output type="text"/>
</transformation>
<transformation name="text-language-translation" language="“FR”">
<input type="text"/>
<output type="text"/>
</transformation>
<transformation name="text-to-audio">
<input type="text"/>
<output type="audio"/>
</transformation>
</transformationPrescription>
Figure 6.13: An XML Encoding of a Transformation Prescript
The transformation prescript provides the list of transformations needed to deliver the data in
the current context. Figure 6.14 is the graphical representation of the transformation prescript
shown in Figure 6.13. It does not specify the actual service executing the transformation. To
generate an adaptation execution plan, we construct graph of services by replacing each
transformation with the appropriate adaptation service(s).
Content Negotiation and Adaptation Module
Summary
Text data
(in English)
A: Start
Where
Data (text)
Language (English)
A
Translation
t1
t1: text-summary
Input: text
Output: text
119
Text to audio
t2
t2: text-languagetranslation
Input: text in English
Output: text in French
t3
t3: text-to-audio
Input: text
Output: audio
Z
Audio data
(in French)
Z: End
Where
Data (Audio)
Language (French)
Figure 6.14: A Graphical Representation for the Transformation Prescript
We can see from Figure 6.11, the transformation prescript and the adaptation services
description are inputs to the planner. Considering the transformation prescript given in Figure
6.13 and 6.14, T= {t1, t2, t3}, where t1, t2, and t3 are the transformation processes or operators,
then we construct the graph as follows:
Step 1:
First, we associate the transformation operators with the available services that can implement
them. This gives us GS, a group of services for each transformation.
GS= {<t1, s11, s12,>, <t2, s21, s22, s23, s33>, <t3, s31, s32>}, where t1 (text summary), t2 (language
translation) and t3 (text to audio) can be realized by the adaptation services {s11, s12}, {s21, s22,
s23} and {s31, s32, s33} respectively.
Step 2:
Then, we connect the services according to the transformation prescript.
We assume that each adaptation service accepts input data with a quality value (Qin) and
generates output data with a quality value (Qout). The quality parameters may include the data
format, the resolution etc. To connect two services, we evaluate the quality compatibility, that
is, the output quality value of one service should match with the input quality value of the
120
Chapter 6. Service-Based Content Adaptation
next service. We find the quality values in the precondition and effect tags of the service
description. Figure 6.15 shows the graph where Fi represents service input/output format.
A
F1
F1
s11
F2
s12
F3
s21
F5
F4
s22
s23
F6
F7
s31
F8
s32
s33
F10
F9
F11
Z
F12
Figure 6.15: An example of Adaptation Graph for Text to Audio Transformation
Step 3:
By looking at the graph in Figure 6.15, we can see that the two services s21 and s33 are
connected only to one service. This is because the output (F5) and the input (F8) formats of
services s21 and s33 respectively do not match with the input and output formats of the next and
predecessor services in the graph. It is necessary to find one or more so called “neutral”
operators so that s21 and s33 will be connected to one of {s31, s32, s33} and {s21, s22, s23}
respectively or alternatively remove them from the graph. Neutral operators are in charge of
transforming the output format of a service into a format compatible with the formats
accepted as input by another service. Removing the unconnected services helps to reduce the
computational time of the algorithm to find the best path. But by doing this, we might exclude
an interesting path through s21 or s33 in terms of global execution time from A to Z.
Content Negotiation and Adaptation Module
121
Assuming that no neutral operator (s) is/are found to connect s33 we remove s33 from the
graph. On the other hand, suppose that the output of s21 is Ms-Word data and the input of s31 is
rtf data. Let us say there exist two services with neutral operators sn1 (Ms-Word to pdf) and
sn2 (pdf to rtf). We can thus connect service s21 to s31 through a chain of the two services (sn1 > sn2). By doing this we add the path {A, s11, s21, sn1, sn2 s31, Z} that can be competitive with
other paths in the graph. The full adaptation graph is depicted in Figure 6.16.
A
F1
F1
s11
F2
s12
F3
F4
s21
s22
F5
F4
s23
F7
F6
sn1
sn2
s31
s32
F9
F10
Z
F12
Figure 6.16: A Fully-Connected Adaptation Graph
Defintion: We say a graph is fully connected when (1) all the services in the graph are
instantiable (2) no input/output quality value mismatches and (3) all paths contain at least the
start node A and the end node Z.
Once the graph is constructed quality criteria such as service execution and price are used to
find an optimal path in the graph. Detailed discussion of the QoS model and the optimal path
selection are presented in Section 6.7.2.3.
122
Chapter 6. Service-Based Content Adaptation
6.7.2 Multimedia Adaptation Graph Generator (MAGG)
As discussed in Chapter 3, there are two approaches for service composition: workflow
technique and AI planning. In this thesis the AI planning approach is used. We developed an
algorithm called Multimedia Adaptation Graph Generator. This algorithm constructs an
adaptation graph. In the following section we present definitions and notations used in the
algorithm.
6.7.2.1
Definitions and Notations Used in MAGG
Definition 1: Media object
A media object is a multimedia data which can be a text, an image, an audio or a video
represented as
M (m1, m2, …,mn)
where m1, m2, …,mn are media features or metadata
Definition 2: State
The state S of a media object M say S (M) is described by the metadata values
Example: for an image object the state holds the values for the format, the color, the height,
the width, etc.
e.g. S(M) =(bmp, 24 bits, 245 pixels, 300 pixels).
Definition 3: Adaptation task
An adaptation task is an expression of the form t (α1 α2 … α n) where t is a transformation and
α1, α2, … α n, are parameters
For example, ImageFormatConversion(imageIn, imageOut, oldFormat, newFormat), where
imageIn: image input file
imageOut: image output file
oldFormat: old file format
Content Negotiation and Adaptation Module
123
newFormat: new file format
Definition 4: Adaptation service
An adaptation service is a service described in terms of inputs, outputs, preconditions and
effects. An adaptation service is represented as s= (R I O Pre Eff Q) where
R: an atomic process that Realizes an adaptation task
I: input parameters of the process
O: output parameters of the process
Pre: preconditions of the process
Eff: effects of the process
Q: quality criteria of the service
Definition 5: Operator (plan operator)
A plan operator is an expression of the form o= (h (a1, a2, …an, b1, b2, …bm), Pre Eff Q) where
h: an adaptation task realized by an adaptation service with input parameters a1, a2, …an and
output parameters b1, b2, …bm. h is called the head or identification of the operator.
Pre: represents the operator’s preconditions.
Eff: represents the effect of executing the operator.
Q= {q1, q2,…,qn}: represents quality attributes (e.g. cost, time, etc.)
Let S be a state, t be an adaptation task and M a media object. Suppose that there is an
operator o with head h that realizes t such that Pre of o is satisfied in S. Then we say that o is
applicable to t and the new state is given by:
M o = S ( M ) = Executing (o, M , S )
Example: for the above given adaptation task, we can have an adaptation operator instance as
follows:
Operator: ImageFormatConversionOperator (http://media-adaptation/imagefiles/image1,
http:// media-adaptation/imagefiles/image2, mpeg, bmp)
Input: http://media-adaptation/imagefiles/image1
Output: http:// media-adaptation/imagefiles/image2
124
Chapter 6. Service-Based Content Adaptation
Precondition: hasFormat (http://media-adaptation/imagefiles/image1, mpeg)
Effect: hasFormat (http:// media-adaptation/imagefiles/image2, bmp)
Quality: (cost=30 units, time=100 ms)
Note:
An adaptation task t can be realized by several adaptation operators hence Q will be used to
compute an optimal plan or path.
Definition 6: Adaptation graph
An adaptation graph G (V, E) is a Directed Acyclic Graph (DAG) where
-
V is the set of nodes that represent the adaptation operators
-
E is the set of edges that represent the possible connections between the adaptation
operators.
The start node A ∈ V is a pseudo operator with effect (initial state) but no precondition
The end node Z ∈ V is a pseudo operator with precondition (goal state) but no effect
Remark
Let oi ∈ V and oj ∈ V, a link or an edge eij exist from oi to oj if the following condition is
satisfied:
oj.Pre ⊆ oi.Eff
Where
-
oj.Pre denotes preconditions of oj
-
oi.Eff denotes effects of oi
Definition 7: Adaptation planning problem
An adaptation planning problem is a four-tuple (SA, SZ, T, D) where SA is the initial state of the
media object, SZ is the goal state of the media object, T is an adaptation task list and D is the
adaptation operators. The result is a graph G= (V, E).
Content Negotiation and Adaptation Module
6.7.2.2
125
Algorithm to Construct Adaptation Graph
To construct the adaptation graph, first we need to translate the service description to
adaptation operator representation. For this purpose, we used an XML parser that accepts the
service description file and then creates an object for the adaptation operator. The algorithm
that generates the adaptation graph is represented in Figure 6.17.
Algorithm: graph (SA, SZ, T, D)
Input: Initial state SA, final state SZ, adaptation task list T and adaptation operators D
Output: an adaptation graph G (V, E)
// Global constant
// Limit
maximum number of neutral operators allowed in a connection
// Global variables
// V
a set of nodes in a graph
a set of edges in a graph
// E
start node
// ao
end node
// zo
a set of neutral operators available in the system
// NO
// Local variables
// T
a set of adaptation tasks
an adaptation task element of T
// t
a set of nodes for adaptation operators realizing an adaptation task
// O
a set of parent nodes
// PO
a set containing the end node
// Pz
var
V, E, T, t, O, PO, ao, zo, Pz, NO
begin
ao= ConstructStartNode(SA) // constructs the start node from the initial state
zo= ConstructEndNode(SZ) // constructs the end node from the goal state
NO= ConstructNeutralOperators( ) // returns the list of the neutral operators available in
//the system
V= {ao} //initialization
E= Ø
//initialization
PO= {ao}//initialization
for each t ∈ T
begin
Construct nodes O from D with operators realizing t
//several operators can realize a task
Connect(O, PO)
//after the process PO holds the value of O
end //T is processed
Pz={zo}
Connect(Pz, PO) // connects the end node
return G (V, E)
end // graph
126
Chapter 6. Service-Based Content Adaptation
----------------------------------------------------------------------------------------------------------------// procedure Connect: connects child nodes (O) with parent nodes (PO)
// O a set of nodes-input variable
// PO a set of nodes-input and output variable
----------------------------------------------------------------------------------------------------------------procedure Connect(in O, inout PO)
//Local variables
// CO a set of nodes-temporal variable used to store child nodes (O)
// TPO a set of nodes-temporal variable used to store parent nodes (PO)
// CPO a set of nodes-temporal variable used to store connected parent nodes
// po a node in PO
// o a node in O
// UNO a set of operators-variable to store already used neutral operators
// Link a Boolean variable to check if a node has a connection
// Connected a Boolean variable, true if a node is connected by neutral operator
// LimitC an integer- number of neutral operators in a connection
//Notations
// po.Pre preconditions of node po
// po.Eff effects of node po
// o.Pre preconditions of node o
// o.Eff effects of node o
var
CO, TPO, CPO, UNO, o, po, LimitC, Link, Connected
begin
CO= Ø //initialization
CPO= Ø //initialization
Link = false
// connect each o ∈ O with each node of the parent nodes PO
for each o ∈ O
begin
for each po ∈ PO
begin
if (o.Pre ⊆ po. Eff) then // direct connection of node o with node po
begin
if(o∉ V) then
begin
V= V ∪ {o}
end
E= E ∪ {(po, o)}
Link = true // o is connected in the graph
end
else // for indirect connection of node o with po using neutral operators
begin
LimitC=0
UNO= Ø
Connected=ConnectWithNeutralOperators (o, po, LimitC, UNO)
Link=Link or Connected // Link is true if o has at least one connection
Content Negotiation and Adaptation Module
127
end
// if po is connected add it to the connected parent nodes list
if (Link) then
CPO=CPO ∪ {po}
end // PO is processed
if (not Link) then // checks if o has at least one direct or indirect connection
begin
if(o=zo) then // it is the end node so the graph construction fails
begin
V= Ø
E= Ø
return
end
else
O=O-{o}// o can not be connected so remove it
end
end // O is processed
// remove parent nodes which have no connection
for each po ∈ PO
begin
if (po ∉ CPO ) then
begin
V=V-{po}
for each (x, po) ∈ E
begin
E=E-{(x, po)}
Remove(x) // removes x with its ancestors
end
end
end
PO= O //child nodes become parent nodes for the next process
end // end connect procedure
----------------------------------------------------------------------------------------------------------------// function ConnectWithNeutralOperators it connects o and po using neutral operators
//recursively
// o a node- input variable
// po a node- input variable
//LimitC an integer- input variable
// UNO a set of nodes- input and output variable
----------------------------------------------------------------------------------------------------------------function Boolean ConnectWithNeutralOperators (in o, in po, in LimitC, inout UNO)
//Local variables
// TNO a set of operators-a temporal variable for neutral operators
// TE a set of edges-a temporal variable to store connectable edges
// TV a set of nodes-a temporal variable to store connectable nodes
// no a node
var
TNO, TE, TV, no
128
Chapter 6. Service-Based Content Adaptation
begin
TNO=NeutralOperators(o, UNO)// it returns neutral operators connectable with o
for each no ∈ TNO
begin
if (no.Pre ⊆ po.Eff) then
begin
TE= TE ∪ {(po, no)}
TE= TE ∪ {(no, o)}
TV= TV ∪ {no}
TV= TV ∪ {o}
E= E ∪ TE
V= V ∪ TV
return true
end
else
begin
TE= TE ∪ {(no, o)}
TV= TV ∪ {no}
TV= TV ∪ {o}
if (LimitC+ 1=Limit) or (UNO ∪ {no}=NO) then //terminating condition
return false
else
return ConnectWithNeutralOperators(no, po, LimitC+1, UNO ∪ {no})
end
end // TNO is processed
end // ConnectWithNeutralOperators
----------------------------------------------------------------------------------------------------------------// function NeutralOperators returns the set of neutral operators satisfying the preconditions
//of o
// o a node-input variable
// UNO a set of nodes- input variable
----------------------------------------------------------------------------------------------------------------function Operators NeutralOperators(in o,in UNO)
//Local variables
// TNO a set of operators-temporal variable for neutral operators
// no a node
//Notations
// o.Pre preconditions of node o
// no.Eff effects of node no
var
TNO, no
begin
TNO= Ø
for each no ∈ NO
begin
if (o.Pre ⊆ no.Eff) then
if (no ∉ UNO) then
TNO=TNO ∪ {no}
end
Content Negotiation and Adaptation Module
129
return TNO
end // NeutralOperators
----------------------------------------------------------------------------------------------------------------// procedure Remove it removes the node x recursively until it finds a node with a branch
//connection or it reaches the start node
// x a node- input variable
----------------------------------------------------------------------------------------------------------------procedure Remove(in x)
//Local variables
// z a node for which (z, x) is an edge in E
// y a node for which (x, y) is an edge in E
var
z, y
begin
if (x=ao) then // it is the start node make V empty and return
begin
V= Ø
return
end
else if ((y ∈ V) and ((x, y) ∈ E)) then // x has a branch connection
begin
return
end
else
begin
for each (z, x) ∈ E
begin
E=E-(z, x)
Remove(z)
end
V=V-{x}
end // each (z, x) is processed
end //Remove
Figure 6.17: Algorithm for Adaptation Graph Construction (AGC)
130
Chapter 6. Service-Based Content Adaptation
6.7.3 Searching an Optimal Adaptation Path/Plan
Definition: Adaptation plan/path
An adaptation plan/path is a path in the adaptation graph G that connects the start node to the
end node. It is represented as a list of the form p= (A o1 o2 … on Z)
Where
A and Z are the start and the end nodes and oi is an adaptation operator instance.
If p= (A o1 o2 … on Z) is a plan and S is a state, then S(p) is the state of the media object
produced by executing o1, o2, …, on in the given order on the input media object. Q(p) is the
aggregate quality value of the path computed according to equation (6).
QoS model
Since an adaptation task can be achieved by more than one service29, choosing an appropriate
service is an obvious requirement. Once the adaptation graph that consists of all possible
compositions is generated, then the choice of the best alternative i.e. the optimal path in the
graph is done based on user specified QoS criteria. The QoS model used contains two
features: the response time of the service and its cost (charge). This model can be extended to
include other features such as reliability, availability and security. The response time is
composed of the execution time and the transmission time. The execution time represents the
necessary time to execute a service. The transmission time corresponds to the communication
of data between two services. Since the services are provided by third parties there is a cost
associated with each service. This cost consists of service execution charge and transmission
charge.
Let p= (A s1 s2 … sN Z) be a path in an adaptation graph where N is the number of services.
We define the QoS of the path, denoted as Q(p), as follows:
Q( p) = (QCOST ( p), QTIME ( p))
Where
29
The services are represented by operators in the graph
(1)
Content Negotiation and Adaptation Module
131
QCOST ( p ) : the total cost of the path
QTIME ( p ) : the total execution time of the path
N
QCOST ( p ) is defined as QCOST ( p) = ∑ QCOST ( si )
(2)
i =1
Where
QCOST ( si ) : the adaptation service execution cost and the data transmission cost
N
QTIME ( p ) is defined as QTIME ( p) = ∑ QTIME ( si )
(3)
i =1
Where
QTIME ( si ) : the adaptation service execution time and the data transmission time
To aggregate the quality values we define scaled qualities QsCOST ( s i ) and QsTIME ( s i ) as
follows:
max
⎧ QCOST
− QCOST ( si )
⎪
max
min
QsCOST ( s i ) = ⎨ QCOST − QCOST
⎪
1
⎩
max
min
if QCOST − QCOST ≠ 0
min
Q max − QCOST
=0
if COST
max
⎧ QTIME
− QTIMe ( s i )
max
min
⎪
if QTIME − QTIME ≠ 0
max
min
QsTIME ( si ) = ⎨ QTIMe
− QTIME
min
Q max − QTIME
=0
⎪
1
if TIME
⎩
(4)
(5)
Where
max
min
QCOST
and QCOST
are the maximum and the minimum cost values respectively and
max
min
QTIME
and QTIME
are the maximum and the minimum time values respectively
Note: the maximum and the minimum values are calculated from the services currently
available.
132
Chapter 6. Service-Based Content Adaptation
Users can give their preference on QoS (i.e by balancing the impact of the different criteria)
such as fastest or cheapest by specifying weight values for each criteria. The score of a path
with weighted values is calculated as follows:
N
Score( p ) = ∑ (QsCOST ( si ) ∗ wCOST + QsTIME ( si ) ∗ wTIME )
(6)
i =1
Where wCOST ∈ [0, 1] and wTIME ∈ [0, 1] represent the weight value assigned to the cost and
the weight value assigned to the time respectively and
wCOST + wTIME = 1
(7)
Let Pset= {p1, p2, …, pK} be the set of all possible paths in an adaptation graph, then the
optimal path is the path with the maximum score value scoremax where scoremax is defined as
follows:
Scoremax = max {Score( pi )}
iε {1, K }
(8)
To find the optimal path one possible solution is to perform an exhaustive search that is,
computing all possible adaptation paths and selecting the optimal path. Obviously, such an
approach is of combinatorial complexity (in dependency of the number of adaptation
operators n in the adaptation graph) and only feasible for a small number of n.
The Dijkstra’s algorithm [Dijkstra59] can be used to find the optimal path. We can express
the running time of Dijkstra's algorithm on a graph with E edges and V nodes as a function of
|E| and |V| using the Big-O notation. The running time for the simplest implementation of the
Dijkstra’s algorithm is O (|V|2). With a binary heap, the algorithm requires O ((|E|+|V|)log
(|V|)) time, and the Fibonacci heap improves this to O (|E| + |V|log(|V|). The algorithm can be
made more efficient in the special case when the directed graph is acyclic. This can be
achieved by modifying the algorithm to include a step for sorting the graph topologically.
Since the adaptation graph is a DAG, the modified algorithm was used. The algorithm with a
topologically sorted graph has a running time of O (|E|+|V|). The algorithm can be found in
Annex D.
Content Negotiation and Adaptation Module
133
6.7.4 Performance Evaluation
6.7.4.1
Adaptation services execution time
In this section we present the experiments we made to measure the execution time of image
adaptation services. The goal of the test was to examine feasibility of the adaptation services.
This was done by measuring the execution time required by the service with respect to the
size of the images. It was also to observe the impact of ordering the transformation services
on the total execution time. The adaptation services have been implanted in the DCAF
prototype. The adaptation services were published on double 3.00 GHZ Pentium 4 with 2.00
GB RAM running Microsoft Windows Server 2003 standard edition service pack 1. For the
purpose of testing we have used JPEG images with 570*760 pixels. To minimize the effect of
varying system load during the adaptation execution we made repeated experiments and took
the average execution time.
Our experiment demonstrated that the execution time of the adaptation services increases with
the size of the images which is logical. One interesting observation of the experiment was that
the format conversion and the image resizing services took less time compared to the color
reduction services. Moreover, we observed that varying order of the adaptation services
produced different execution times. Putting the color reduction services at the end produced
better result compared to the other orderings. In the legend R is Resizing, F is Format
conversion and C is Color reduction. The best ordering was Resizing-Format conversionColor reduction (RFC). The experimental result is shown in Figure 6.18.
134
Chapter 6. Service-Based Content Adaptation
Execution Time (in 100 ms)
Comparison of Transformation Execution Order
50
RFC
40
CFR
30
FRC
20
RCF
CRF
10
FCR
0
32
42
43,3 43,9 45,7 49,4 52,6 56,7 74,4
Image Size(Kb)(570*760 pixels)
Figure 6.18: Comparison of Different Execution Orders
6.7.4.2
Graph construction time
Definition 1: Link Ratio
A link ratio ri of a node ni is defined as the number of links divided by the number of child
nodes.
Remark
-link ratio of the end node is zero
-link ratio of the start node is 1
For Figure 6.20, the link ratio values are:
3
2
1
1
r1 = , r2 = , r3 = , r4 = , etc.
3
4
4
4
Content Negotiation and Adaptation Module
135
A
n1
n4
n2
n3
n5
n6
n8
n7
n9
Z
Figure 6.20 Example of an adaptation graph
Definition 2: Average Link Ratio (ALR)
Average link ratio ALR of a graph G is defined as follows:
k
ALR =
∑r
i
i =1
k
with ri ≠ 0 .
, Where ri is the link ratio of node ni and k is the number of nodes in the graph
For Figure 6.20, the average link ratio is
10
ALR =
∑r
i =1
10
i
=
1
2
The first analysis of the algorithm shows that there is no significant difference in the graph
construction time for the different average link ratios. This is due to the fact that the algorithm
performs the checking condition for each child and parent node whether there is a link or not.
Here, we present the experimental result on the performance of the algorithm with respect to
the depth of the graph and the number of services per transformation. Our aim in this
experiment was to see the progress of the graph construction time with respect to the graph
depth and the number of services per transformation. As cited by Libse [Libse04] and our
136
Chapter 6. Service-Based Content Adaptation
experience with different adaptation scenarios (see Table 2.1) show that in practice the path
length is not more than ten levels. Therefore, we did the experiment with maximum graph
depth of 10 levels. We varied the number of services per transformation from ten to thirty.
The experiment was performed on a 1.9 GHZ Pentium 4 with 256 MB RAM running
Microsoft Windows 2000.
Time(ms)
Graph Construction Time
360
340
320
300
280
260
240
220
200
180
160
140
120
100
80
60
40
20
0
10 Services per
transformation
20 Services per
transformation
30 Services per
transformation
2
3
4
5
6
7
8
9
10
Graph Depth (# of Transformations)
Figure 6.19: Graph Construction Time
As can be seen in the Figure 6.19, the graph construction time increases linearly with the
graph depth (# transformations in the path). It also shows that the relationship between graph
construction and the number of services per transformation is linear, as the gap between each
curve remains constant. Compare to the graph depth, the construction time progress slowly
with number of services per transformation. Of course, it was observed that the progress both
for the depth and width (number of services per transformation) was almost constant with
average increase of 40 ms when we increased the depth by one and average increase of 10 ms
when we increased the width by 10 services. This implies that having several services per
transformation does not affect much on the total construction time, while it provides the
possibility to select the best service among the candidates. For example, for 300 (depth of 10
and width of 30) services in a graph which are large enough to realize an adaptation need, the
total construction time is only 335 ms which is really acceptable.
Summary
137
Optimal path search algorithm
Our measurement on the performance of the optimal path search algorithm showed that the
average link ratio has not significant impact on the execution time. For a graph with depth of
10 and 10 services per transformation, the algorithm’s execution time was 18 ms.
6.8 Summary
By enabling people to access information and services independent of time and location
pervasive computing promises to facilitate work, play, and every day activities. The pervasive
computing environment is characterized, however, by devices with widely varying
capabilities (e.g., display size, network connectivity), and a variety of data formats and
supported services. Given this extreme diversity, providing effortless access to data and
services anywhere and anytime requires the seamless customization of content and
applications to the user's context. Context-aware content adaptation is a key concept to meet
the varying requirements of different clients in a dynamic heterogeneous environment, such
as pervasive computing. On one hand, content adaptations are resource intensive processes
and the tools required to implement them are diversified. On the other hand, the emergence of
web services brought the advantages of publishing Internet accessible functionalities which
includes content adaptation tools. In this chapter we proposed several concepts for a novel
content adaptation approach-the distributed service-based framework of multimedia content
adaptation for pervasive computing applications. We particularly:
•
described the architectural framework and its components
•
defined content and context metadata description mechanisms
•
developed an ontology for multimedia content adaptation services description
•
described the process and components of a content adaptation and negotiation module
•
described the construction of the content adaptation graph
•
described a Qos model for content adaptation services
•
presented a formalism for multimedia adaptation graph generator and its algorithm
•
presented a performance evaluation of some of the adaptation services and the MAGG
algorithm to demonstrate the feasibility of the approach
Chapter
7
Prototype Implementation
Based on the concepts mentioned in the last few chapters, we have implemented a prototype
of content adaptation system as a proof-of-concept. The system demonstrates the idea of
multimedia content adaptation by selecting Internet accessible content adaptation service(s)
that provide(s) the desired functionality satisfying the execution context. This chapter
describes a prototype implementation of our framework and reports our initial experience.
Section 7.1 describes major functionalities of the prototype system, the components of the
local proxy and their description. Sample databases used in the prototype are presented in
Section 7.2. Discussion on the visual interface of the prototype is given in Section 7.3. Finally
the chapter ends with a short summary in Section 7.4.
7.1
Components of the Prototype
We developed a prototype implementation of the DCAF to show the feasibility, validity and
practicability of our proposals. The prototype was built using Borland Jbuilder 9 personal. For
the different databases developed in the prototype we used MySQL-4.0.12. The software
package consists of more than 10,000 lines of code. Our prototype system is based on the
architecture described in Chapter 6 (Section 6.3). The architectural framework consists of
local Content Servers, Content Proxies, Client Profile Repository, Adaptation Service
Registry, Adaptation Service Proxies, and Local Proxies. Figure 7.1 represents an overview of
a DCAF session which is described as follows:
Step 1
Client login information: the client enters his login information
Step 2
Client profile request: profile request from the local proxy to the client profile repository
140
Chapter 7. Prototype Implementation
Step 3
Client profile response: profile response from the client profile repository
Step 4
User interface: the local proxy provides a user interface for the user to enter his content
request
Step 5
User request: content request from the user
Step 6
Local proxy request: the request can not be served from the cache and the local proxy
contacts the content proxy
Step 7
Content proxy response: metadata response from the content proxy
Step 8
Local proxy response: the response from the cache/the content proxy is sent back to the user
Step 9
User request for selected data: the user selects from the list and sends to the local proxy
Step 10 Local proxy request for selected data: the selected data request is sent to the content proxy
Step 11 Content request: the content proxy contacts the content server
Step 12 Content server response: the content server sends the content to local proxy
Step 13 Content response: the response from the content server is sent back to the local proxy.
Step 14 Adaptation service description request: a description request from the local proxy is sent to
the adaptation service registry
Step 15 Adaptation service registry response: description response from the registry to the local
proxy
Step 16 Adaptation request: adaptation request sent from local proxy to the adaptation service proxy
Step 17 Adaptation service proxy response: the adapted content from the adaptation service proxy is
sent to the local proxy
Step 18 Local proxy response: the adapted content received from the adaptation service proxy
finally sent to the user by the local proxy
Note: While the adaptation service registry response (Step 15) may be cached to avoid the next request
(Step 14) so that to improve performance of the system, it would be useful to execute Step 14 each
time to get the newly added services in the registry.
Components of the Prototype
141
2
3
Client Profile
1
Local Proxy
Content Proxy
10
11
12
Content Server
Adaptation
Service Registery
*
16
*
7
1
15
13
14
User Agent
6
7
4
5
8
9
18
Adaptation
Service Proxy
* this communication can occur several times , if several
adaptations are required
Figure 7.1: Components and Interaction of DCAF Architecture
Our prototype offers the following major functionalities:
Adaptation decision engine: The aim of our system is to have the intelligence of making
suitable decisions on the adaptation services that are needed for adapting a content so that this
latter matches the execution environment constraints. The decision engine uses a planning
algorithm to find suitable adaptation services to construct the adaptation graph and finally
produce an optimal adaptation path from the graph. It uses the framework described in
Chapter 6.
Proxies modules: three categories of proxies were developed as parts of the prototype
implementation. One group represents content proxies which were developed to manage
distributed content servers and their content metadata. MySQL was used for storing the
content and metadata databases. The second group represents local proxies that are the core
parts of the architecture. The adaptation decision engine and other important functionalities
are parts of these proxies.
The third group represents proxies that provide specific content adaptation functionalities.
These were implemented as Web service to show the feasibility of providing complex
adaptations using third party adaptation services. C# and ASP.NET were used to develop the
adaptation services. The following adaptation services were used/developed in the prototype:
142
•
Chapter 7. Prototype Implementation
A language translation service which translates a text written in one language to
another language (e.g. French to English). A widely used language translator
(BabelFish)30 was used to perform the actual translation. No specific coding was
needed in using the service. We only developed the equivalent description of the
service. This shows the framework is easy to extend.
•
A Text-to-audio transcoding service which transcodes a text document to audio
format.
•
An Image resizing service which changes the size of an image
•
A Color to greyscale conversion service
•
An Image format conversion service which converts the format of an image to png,
gif, etc.
Adaptation Service registries: for adaptation service discovery, registries were used to store
the information about available adaptation services. The registries are specialized in the sense
that they store only adaptation services. Service providers publish their service description in
the registries and local proxies consult the registries when matching for particular adaptation
service(s) is required. For a given adaptation service, the identifier of the service and its
description are stored. The description contains both functional and non-functional properties
(see Table 6.3 in Chapter 6).
Client profile repositories: they are used to store client profile. The client profile consists of
user’s preferences, device characteristics and capabilities and network connection. While in
the propotype, the client profile is created during user subscription and it can be modified any
time, in real application, the system captures the device profile from device vendors databases
using the device’s identification and the network profile is captured using network
monitoring. MySQL database was used to hold user login information and its associated
profile.
The block diagram in Figure 7.2 shows the components of the local proxy and the interaction
and information flow between them. It has five major components: a Content Negotiation and
Adaptation Module, a Profile Agent, an Adaptation Service Agent, a Communication Module,
30
Babelfish: http://www.babelfish.org/
Components of the Prototype
143
and an Interface Module. In the following section, we describe the components and their
roles:
•
The Interface Module is used to communicate with the user. There are four interfaces
defined in this module: user login interface, user request input interface, result display
interface and user profile entry/modification interface. The user login interface is used
to enter user id and password information to access the system. The user request
interface is used to enter user content requests. The user profile entry/modification
interface is used to enter/modify the client profile. And finally the result display
interface is used to display the adapted content.
•
The Communication Module is used to communicate with content proxies. There are
two types of data exchanged between the local proxy and content proxies: metadata
and content. The content proxy first sends local proxy request to content server and
then sends back the response (metadata) to the local proxy. The user selects a
particular data from the response and sends to the local proxy. The local proxy sends
the selected data request to the content proxy. The content proxy requests the content
server for the data and sends back to the local proxy. We used web services and SOAP
as a communication protocol.
•
The Profile Agent is used to store and get client profile to/from the profile repository.
SOAP is used as communication protocol between the Local Proxy and the profile
repository. Though in our prototype, one client profile repository is used, in real
applications, there may be several repositories for example, vendors’ device profile
repositories. Vendors may use different protocols and this creates the problem of
interoperability. We use SOAP as a solution to this problem.
•
The Adaptation Service Agent has two components: the adaptation service discovery
module and the adaptation service invocation module. The Adaptation Service
Discovery is used to find all the possible adaptation services from the adaptation
service registry. The Adaptation Service Invocation is used to invoke remote
services according to the optimal adaptation plan. SOAP is used as a communication
144
Chapter 7. Prototype Implementation
protocol for both Adaptation Service Discovery and Adaptation Service Invocation
modules.
•
The Content Negotiation and Adaptation Module is the central part of the local
proxy. It has two main components: the Adaptation Decision and the Adaptation
Planner. The Adaptation Decision is responsible to analyse and decide the number
and types of transformations required to send the content providing the constraints and
characteristics of the context and the content. It finally creates a transformation
prescript as described in Chapter 6 (see Figure 6.13). The Adaptation Planner uses
the output of the Adaptation Decision as input (the transformation prescript),
constructs the adaptation graph and finally generates an optimal adaptation plan. The
optimal plan is communicated to the Adaptation Service Invocation.
Figure 7.2: Block Diagram of the Local Proxy
Several classes and data structures have been developed to implement the different
components of the Local Proxy (as Shown in Figure 7.3). Two important data structures have
been created: the OperatorLayer and LinkLayer. The OperatorLayer stores the operators
Components of the Prototype
145
corresponding to the transformations or the adaptation tasks. The LinkLayer stores the links
of the operators. The adaptation graph discussed in Chapter was implemented using these data
structures. While the OperatorLayer was used for the nodes of the graph, the LinkLayer
was used for the edges of the graph. Detailed description of the classes with their purpose,
instance variables and methods can be found in Annex E.
Classes
MediaObject
PlanElement
PlanHandler
MediaState
ContextProfile
OWLHandler
Predicate
ProfileHandler
Operator
MediaHandler
MappingHandler
Vector*
AdaptationTasks
OperatorsList
OperatorLayer
LinkLayer
OpInput
OpOutput
OpPrecondition
OpEffect
Plan
OptimalPlan
Plans
Figure 7.3: Classes of Local Proxy Implementation.
* Vector is a built-in Java class used for representing list of values
146
7.2
Chapter 7. Prototype Implementation
Sample Database Used in the Prototype
Four major databases were developed in the prototype: profile database, adaptation service
registry, content and metadata. The profile database is used to store user related information
such as the user name, identification, password and a link to the context profile (CSCP) file.
The adaptation service registry database is used to store adaptation service related information
such as the identification and a link to the service description file (OWL-S). The content
database was used to store the application data or content to be provided to the user. Finally
the metadata database was used to store content search information and a link to the MPEG-7
file. All the databases used in the prototype were developed with MYSQL-4.0.12.
Our proposal for distributed service-based multimedia content adaptation is very generic so
that it can be used for any multimedia content delivery application domain in heterogeneous
environments such as pervasive systems. However, for the purpose of testing our concepts
and proposals we developed a sample database for medical application. Our choice for the
medical application comes from the fact that these are multimedia data and we have already
sample data because some members of the laboratory work on them (e.g. Flory06, Vedier06).
Our sample database stores medical records of patients. The conceptual data model is shown
in Figure 7.4. The following tables describe the fields of the various tables.
Hospital
Field
Description
HCode
Unique identification code of the hospital
Name
Name of the hospital
Address
Full address of the hospital
Section
List of services (departments) of the hospital
Sample Database Used in the Prototype
PatientData
Field
Description
PatientID
Unique identification of the patient
FirstName
First name
LastName
Last name
DateOfBirth
Birth date
Address
Full address
MedicalRecord
Field
Description
MedRecId
Unique identification for the record
PatientID
Patient identification
DocId
Document identification
Title
Title of the document
Description
Description of document content
Keywords
Key words used to search the document
MedicalDoc
Field
Description
MedDocId
Unique identification of the document
DocId
Document identification
MediaObject
Field
Description
MediaId
Unique identification of the media object
MedDocId
Unique identification of the document
MediaType
Type of media
Title
Title for the content of the media
Description
Description for the content of the media
Language
Language of the media content
MetaDataLoc
URL address of the metadata location
147
148
Chapter 7. Prototype Implementation
MedicalRecord
Hospital
PK
PK
HospCode
Name
Address
Section
PatientData
MedRecId
PK
1:1
N:1
PatientID
DocID
Title
Description
Keywords
HospCode
N:1
1 :1
PatientID
FirstName
LastName
DataOfBirth
Address
1:1
MediaObject
PK
1:1
MedicalDoc
PK
1:1
MedDocId
DocId
N:1
MediaID
MedDocId
MediaType
Title
Description
Language
MetaDataLoc
Figure 7.4: Conceptual data model.
7.3
Visual Interfaces
We developed various visual interfaces for the communication between the system and the
user. These interfaces include a user login interface, a profile entry/modification interface, a
user request entry interface and an adaptation data display interface. Here we present the
profile entry/modification and the adapted data display interfaces since they are most
important ones.
7.3.1 Client Profile Entry Interface
The client profile entry interface is composed of three panels: Device Type selection panel,
Network Specification panel and User Preferences entry panel. The organization of the entry
interface is based on the client profile representation structure (See Annex A). The interface
enables to capture client profile information. Each of these panels is described below.
Device Type Selection Panel
The device type selection panel allows selecting the type of device the user wants to use to
access the data from an existing list for which the profile already exists (See Figure 7.5).
Visual Interfaces
149
Figure 7.5: Screenshot of the Device Selection Interface
The Device Characteristics Entry Panel
The device characteristics entry panel allows entering characteristics of the device the user
uses to access data if the profile of this device has not yet described. Using this panel the user
enters the hardware and software characteristics of the device (See Figure 7.6).
Figure 7.6: Screenshot of the New Device Entry Interface
150
Chapter 7. Prototype Implementation
Network characteristics Entry Panel
The network specification panel allows the specification of the network connection the user is
connected to (See Figure 7.7). Using this panel the user enters the network type, bandwidth
and delay of the network connection.
Figure 7.7: Screenshot of the Network Characteristics Entry Interface
User Preferences Panel
The user preferences entry panel allows specifying user preference information so that data
will be sent to accordingly (See Figure 7.8). Using this panel the user provides his language
preference and the QoS value in terms of time and cost.
Figure 7.8: Screenshot of User Preferences Entry Interface
Visual Interfaces
151
7.3.2 Patient Record Search Interface
The patient record search interface permits patient record search using key words (See Figure
7.9). The user enters patient identification and key words related to a type of disease, a
treatment or a medical examination. The result of the search provides the list of associated
documents for that patient. Then the user selects the interest document for detail information.
Figure 7.9: Screenshot of Patient Record Search Interface
7.3.3 Adapted Data Display Interface
In pervasive systems, adaptation consists of at least two things: the data/content and the user
interface. Our work deals with the adaptation of content. The user interface adaptation and
management in pervasive environment by itself is another important research domain that
needs further investigation which is not investigated in this thesis. Since presenting
information to users requires both content and interface adaptation, we collaborated with
another research group in the laboratory. This group works on an interface adaptation project
called SEFAGI (Simple Environment for Adaptable Graphical Interfaces).
The SEFAGI project [Chaari05] aims to design and build a platform that allows using the
same application services with different terminal types. The system provides an environment
that permits the description of expected user interfaces using an abstract window description
language, the description of target platforms using a platform description language and the
automatic generation of user interface code based on the previous descriptions.
152
Chapter 7. Prototype Implementation
The SEFAGI system developed an interface server that provides tools (a) to create a new
Abstract Windows Descriptions (AWD) (b) modify or reuse abstract windows descriptions
and (c) to generate the code corresponding to the abstract windows descriptions for each kind
of terminal. The system provides a graphical interface to help making the first two activities
(a and b) and a code generator.
Figure 7.10: Graphical Assistant: AWD graphical representation
The XML AWD which is the output of the graphical interface serves as an input for the code
generator. The graphical interface offers (See Figure 7.10) an interactive design process and
hides the language syntax. This avoids the writing of the abstract description by the users. To
design a window, the end user chooses in one click a group of graphical components (a
standard SEFAGI panels) in a library. Then, he links the component to a service by
navigating in the service repository. In SEFAGI the services are implemented to manage and
display different information parts, for example, in a medical application, the patients list, the
medical records (textual information), the medical records (images), etc. are considered as
different services. The platform descriptions are provided by computer scientists. Such
descriptions are made using the XML grammar provided by the system. Generated interfaces
Visual Interfaces
153
are deployed on terminals as dedicated runtime environment. Each type of platform requires a
different runtime environment code, as it depends on the available platform API. Platforms
descriptions are used to build automatically the code of the runtime environments.
Our collaboration enabled us to have a complete adaptation system that provides medical
information adapted to the user context. The system provides adapted information both for the
content and the interface. Since the SEFAGI system is still a project in development, we
generated only interfaces for standard PC and smart phone for the purpose of testing (see
Figure 7.11 (a) and Figure 7.11 (b)). We are in the process of writing an article on the result
of this collaboration work to be sent for a publication in a journal. We also hope to continue
working with the group in the future. This will finally enable us to have a fully complete
adaptation system that allows medical information access with any type of terminal.
For the case of scenario III (Chapter 1), where a medical doctor requests the medical history
of a patient on his PDA or Smartphone and the system has medical records written in a
language for example French but the doctor’s language preference is English, the system uses
a language translation service and returns the adapted data (in English). Figure 7.12 (a) and
Figure 7.12 (b) are screenshots of the data in French and English respectively.
Figure 7.11 (a): Screenshot of an Image data on a Standard PC (without adaptation)
154
Chapter 7. Prototype Implementation
Figure 7.11 (b): Screenshot of an Image data on a Smartphone (after adaptation)
Figure 7.12 Screenshot of text data (a) original in French (b) the translated data in English
Summary
155
7.4 Summary
In this chapter, we presented a prototype that implements the DCAF framework to evaluate
the validity and practicability of our proposals. We first described the different components of
the architecture and their interaction. We then presented the major functionalities of the
prototype and their implementations. We also presented the implementation of the local proxy
and its sample class hierarchy. While our proposal for distributed service-based multimedia
content adaptation is very generic so that it can be used for any multimedia content delivery
application domain, a sample database for medical application was developed for the purpose
of testing our concepts. Two computer science students at the laboratory (Yann Gripay and
Christope Litzinger) were involved in the development of the prototype and the integration of
the SEFAGI system to the prototype. Our framework is based on Internet accessible
adaptation services. We connected our prototype to language translation services and
multimedia adaptation services which were implemented by our means.
The different visual interfaces developed in the prototype facilitate the communication
between the system and the user. The visual interfaces include Client Profile Entry, Patient
Record Search, and Adapted Data Display interfaces. The client profile entry interface is used
to capture client profile information. The patient record search interface is used to search
patient records using patient identification and keywords. The medical data adapted by the
system is sent to the SEFAGI interface server [Chaari05] which provides an adapted data
display interface so that the data will be presented according to the terminal characteristics.
Chapter
8
Discussion
In this thesis, we proposed a novel distributed service based content adaptation system for
pervasive environments. The important issues addressed in this thesis are: the design of
distributed adaptation architectural framework, the development of an ontology for semantic
content adaptation service description, and the development of an algorithm for content
adaptation service composition. Moreover, we developed a prototype that demonstrates the
practicality of our proposals and concepts. The purpose of this chapter is to briefly present the
advantages and limitations of the framework, the service description, the composition
algorithm and the prototype. We also try to give ideas how these limitations can be solved.
8.1
DCAF Architecture
The type of content adaptation to be performed depends on the context information gathered
and the characteristics of the content to be adapted. In this thesis we proposed an architectural
framework to deliver adapted content in pervasive environments. The architecture takes into
consideration the characteristics of the client device, the user’s preferences, the client
network, the content description (also called content metadata), and the properties of available
adaptation services to determine the number and type of adaptations to be performed on the
content. The principal strengths of our architecture are extensibility, scalability, flexibility and
interoperability.
Extensibility: three fundamental design principles of our architecture aid its extensibility.
First, the DCAF architecture uses externally developed adaptation services. Adaptation
services needed to process new data types and/or satisifiying new client requirements can be
158
Chapter 8. Discussion
easily added to the adaptation service registry just by publishing their description. New
adaptation services implementing more effective algorithms can be added easily to the
system. Second, the structure of the architecture is modular. Therefore, adding or removing
components to the system is made easy, for example, device profile databases provided by
device vendors can be added to the system and used by the system to retrieve device
characteristics. New content servers can be added to the system by creating the corresponding
metadata databases containing the content search information and link of the MPEG-7 files.
Third, our design utilizes XML as a standard means of information exchange between
different components of the architecture and different stages of the adaptation process. The
XML technology facilitates the extensibility. For example, the transformation rules are
encoded in XML that enables to add and modify rules to incorporate new client constraints.
Finally, the system can use several adaptation service registries. New content servers can be
added to the system by just creating the corresponding metadata databases containing the
content search information and link of the MPEG-7 files. Third, our design utilizes XML as a
standard means of information exchange between different components of the architecture
and different stages of the adaptation process. The XML technology facilitates the
extensibility. For example, the transformation rules are encoded in XML that enables to add
and modify the rules to incorporate new client constraints. Finally, the system can use several
adaptation service registries.
Scalability: as discussed in Chapter 2, in the proxy-based approach, the proxy is responsible
for adaptation decision and execution of the adaptation functions. However, such an approach
is not scalable and impedes performance under several conditions. Externalizing the
adaptation process minimizes the load of the local proxy so the local proxy can handle several
requests and several clients. Moreover, adapted contents can be cached so that requests for the
same content with the same contextual situation can be served from the cache.
Interoperability: one of the bases for architectural interoperability is to implement a standard
way of communication between the components of the architecture. Web services technology
is used to implement the different components of our architecture (e.g. Client profile
repository, adaptation service registry, etc.) and SOAP as communication protocol. The third
party adaptation services are developed with web services (e.g. [Babelfish]). Web services
have a mature set of protocols and technologies that are widely accepted and used. They are
platform, system and language independent. Hence, they provide interoperability.
Semantic Adaptation Services Description
159
Flexibility: our architecture is flexible in two ways. First, it is generic and content independent
so it can be adapted easily to different content delivery application environments. For
example, the architecture can be used for patient record access in medical application as
demonstrated in our application or it can be used to access recipes from a cooking guide
information system. Second, it permits components of the architecture to evolve easily with
changing requirements. The different components of the architecture are developed
independently and loosely- coupled, hence they can be updated without affecting the other
components. For example, the separation of content adaptation and presentation (user
interface) adaptation enabled to easily integrate the SEFAGI’s [Chaari05] adaptable graphical
interface to the prototype.
Since the architecture relays on third party adaptation services, its application may be limited
as many of the adaptation services have not yet been developed. For example, in developing
our prototype we found only the language translator services and we implemented other
services by ourselves. However, the increase popularity of Web Service and the need of an
open and interoperable content adaptation system will open the venue for developing more
external adaptation services.
8.2
Semantic Adaptation Services Description
Fully automatic adaptation decision process and adaptation service composition require a
formal and semantic description of the adaptation services. The significant advantages of
semantic descriptions is that they enable to identify the appropriate adaptation services for the
needed adaptation functionalities, facilitate the use of planning techniques for adaptation
service composition and finally invoking the selected adaptation services. However the
commonly used service description such as WSDL lacks the semantic information which
makes automatic service composition difficult.
To solve these problems, we developed semantic adaptation services description ontology.
This ontology defines the different multimedia data types and their associated adaptation
techniques. Moreover, it formalizes the input/output, precondition and effects of the
adaptation services. This formalization enables to automatically verify the compatibility of
160
Chapter 8. Discussion
two adaptation services for composition. It increases the robustness of the system by
providing global view of the adaptation functionalities of the system. This is also good for
maintenance. The ontology provides specification for developers for implementing adaptation
services at the same time wrappers can be easily developed for other service descriptions.
Classifying the adaptation services into different category based on the media type simplifies
the difficulty in describing services by the service developers.
Our semantic service description is not complete (e.g. no description for video adaptation
services). However, the extensibility of the ontology enables addition of new adaptation
techniques and new data types easily in the future. While the system can not use services
described in other form, an automatic wrapper can be developed to transform other
descriptions into the system’s semantic description platform.
8.3
Adaptation Service Composition
Our service composition algorithm implements automatic service composition by using
planning methodology. We first developed a formal representation of multimedia adaptation
service composition. This formalism enabled us to define the algorithm as a planning problem
with four-tuple (SA, SZ, T, D) input where SA is the initial state of the media object, SZ is the
goal state of the media object, T is an adaptation task list and D is the adaptation operators.
We developed a parser that translates the service description to operator representation (D)
which is the input for the algorithm. The algorithm produces an adaptation graph with all
possible adaptation paths as a result of the composition. The experiments conducted to see the
performance of the algorithm demonstrated that the algorithm performs well even when there
are several transformations and several services per transformation. For example, for a graph
with the depth level (no of transformations) of 10 and width (services per transformation) of
30 (a total of 300 services) which is enough to realize any type of adaptation scenario, the
construction time was only 335 ms which is acceptable. One of the strong features of the
algorithm is that its execution time progress very slowly with the depth and width of the
graph. For example, for each increases of 10 services it only has 10 ms additional time.
The algorithm generates a DAG and the Dijkstar’s algorithm [Dijkstra59] with a topological
sort step is used to find the optimal adaptation path in the graph. This algorithm is based on
Adaptation Service Composition
161
QoS criteria to find the optimal path based on the user’s preference on service time and
charge. The QoS criteria are indication of user’s interest on the time and/or the charge. The
user indicates his/her interest by giving more weight on the specific criteria. For example, if
the user gives 0.7 for time and 0.3 for charge 0.3, it means that the user is interested in the
response time of the service than the cost of the service.
The MAGG algorithm considers only compatibility of the input format and the output format
of the adaptation services in the composition. But in reality there can be other parameters that
should be compatible such as the size of the input/output data, the frame rate of the
input/output data, etc. therefore; we need a composition algorithm that considers several
compatibility parameters in addition to the format of the input/output data. Moreover, the
algorithm does not consider different ordering possibilities of the transformations. In the
prototype implementation one ordering is used. While all ordering might not be efficient (e.g.
applying text language translation before text summary is less efficient than the other way
order) or not possible, some ordering constraints may be added during the time of registry of
the adaptation services. The ordering constraints of a transformation can be provided by the
administrator who is responsible in registering the services or the service provider.
One of the problems with the optimal path search algorithm is that it assumes that the services
available during composition will be available during the execution. But a service which was
active during the composition might not be available later on when the graph was generated.
In this case the path execution fails because of this service. The algorithm does not consider
such situation and leads to system failure. Since the composition algorithm generates all
possible paths, the problem can be fixed by taking another optimal path or replacing the
service by another service with similar function and cost. This recovery mechanism is not
implemented in the algorithm.
The path cost which consists of the service execution time and the service charge is assumed
to be static. But in the case where the cost varies with network condition or other parameters,
the optimal path might not be the same. The algorithm does not consider such issues. One
possible solution could be to include some possible variation value in calculating the path cost
or check the cost after the optimal path is found to verify if the cost is the same. Such
contingency mechanism is not implemented in the algorithm.
162
Chapter 8. Discussion
To select the optimal path only service time and charge are considered. However, other
parameters such as reliability, security, etc can also be essential from the user’s point of view.
In such case we need to develop a metrics to combing them with the existing ones. One
possible solution can be to store some history information of the services with respect to these
QoS. This historic information will finally enables us to represent these parameters
numerically so that they can be combined with the time and the charge to calculate overall
QoS of a service.
It was not implemented in the prototype but the construction time can be minimized using
caches. Since the same path might be used for other request, the path can be cached for further
use. If there is a request with similar contextual settings (e.g. context profile and content
metadata), then the path can be applied without the need of constructing the graph.
8.4
Prototype Implementation
In developing the prototype, we used a modular approach. Each components of the system are
developed independently and communicate through proper interface. The modularity of the
system enables to add or evolve the components without difficulty and without affecting other
components of the system. Its modularity helps us to integrate easily adaptable user interface
systems such as SEFAGI [Chaari05].
The modularity of the system also facilitates to use the prototype in other application
scenarios but it requires creating the metadata databases, the content servers, and modifying
the search and the presentation interfaces. The SEFAGI system provides the necessary tools
to generate automatically the search and the presentation interfaces. Therefore, by using
SEFAGI we can create the interfaces for the new application.
To make the prototype fully functional, the ontology is required to be completed and we need
more externally available adaptation services. It will also be necessary to include interface for
other terminals other than PC and smart phone. This hopefully will be achieved by future
collaboration with the SEFAGI project.
Chapter
9
Conclusion and Future
Work
9.1 Conclusion and Contributions
Due to recent communication and technological advances such as wireless and mobile
devices, computing has moved towards pervasive or ubiquitous environment enabling
anywhere and anytime data access in distributed multimedia systems. However, resource
limitation of mobile device and limited capacity of wireless networks have created many
issues that have not been adequately addressed in traditional distributed multimedia systems.
One of these issues is content delivery to applications and users with varying terminal and
network characteristics, preferences and requirements. Delivering content in such
heterogeneous and dynamic environments requires understanding the different elements
involved such as the user, the terminal, the network and send data accordingly. In order to
solve the heterogeneity of the client devices used in pervasive computing, content should be
adapted to the clients such that it would be usable. Content adaptation is, therefore, of great
significance in pervasive computing environments.
Content adaptation attracted much attention in the pervasive community and several
approaches have been proposed by research groups which can be generally classified as
client-based, server-based and proxy-based. Client based content adaptation is sometimes
impossible due to the resource requirement of the adaptation processing on one hand and the
inherent resource limitation of client devices on the other hand. Server-based content
adaptation is good in terms of producing acceptable adapted content as it is close to the
content and has knowledge about the content but the adaptation process results in an overload
of the server which in turn diminishes its performance. Proxy-based is the most employed
164
Chapter 9. Conclusion and Future Work
approach for content adaptation because it relives the server load and its implementation
simplicity. However, putting all adaptation operations for which some of them may be
computationally expensive requires a proxy with powerful CPUs and a lot of memory. To
summarize, all the three approaches do not provide a complete and general content adaptation
solution that can be usable in a wide distributed heterogeneous environment.
In this thesis, we presented a service-based distributed content adaptation framework called
DCAF for adapting multimedia content in pervasive computing environments. The
framework addressed the problem of content adaptation in a complete and more general way.
We have also showed the validity of the concepts proposed by implementing and evaluating a
simple prototype for content adaptation.
The major contributions of this thesis are the following:
•
We introduced a new service-based content adaptation architectural framework for
distributed multimedia systems. Using this architecture third-party adaptation services
can be easily included into the architecture what makes the framework widely
extensible. Moreover, the framework is scalable and interoperable so that we can use
it for wide application areas.
•
Web Service technologies are considered to be good solutions for distributed
computing especially on the Internet. Their application for pervasive computing,
particularly for content adaptation has been investigated in this thesis.
•
We provided a formal definition and description of multimedia content adaptation
process. This formalism enables to understand the different elements involved in the
adaptation process so that different mechanisms can be developed (e.g. new
mechanisms can be added to the transformation rules). We have also defined
transformation rules that are easily extensible to add new transformation
functionalities and user constraints.
•
The design of the framework allows the composition of adaptation services to provide
an optimal service for a given computational context. Therefore, any adaptation need
is achievable.
•
We developed an ontology for multimedia adaptation services description. The
ontology helps to describe services semantically. The semantic description facilitates
Future Work
165
the discovery, the composition and the execution of the adaptation services
automatically.
•
An algorithm was developed for the optimization of the adaptation service
composition.
•
A prototype was developed to implement the framework. Various experiments were
conducted on the prototype. The prototype demonstrated not only the validity of our
proposal but our solution could be used for real application systems.
9.2 Future Work
Some of the future works include:
•
In this thesis separate representation mechanisms are used to describe context (e.g.
user, device and network), content, and adaptation services. However, the
interoperability of the system could be enhanced by building a unified and
comprehensive ontology that can be used to describe each of these components. This
unified ontology will have upper and lower ontologies. The upper ontology captures
the general knowledge about the physical world in pervasive computing environments.
The lower ontologies capture information about each component (e.g. the adaptation
services).
•
While CSCP overcomes the shortcomings of other representations (e.g. CC/PP), it
can’t
represent
complex
relationships
and
constraints.
Moreover,
the
component/attribute model becomes clumsy if there are many layers. On the other
hand, future’s full fledged pervasive systems will require much more sophisticated
context models in order to support seamless adaptation to changes in the
computational environment. The context models will need to specify a range of
characteristics/quality of context information including temporal characteristics as
well as various types of dependencies among the different context information. One
possible solution for context modelling could be an ontology based modeling, but
more investigation is required in this direction. D. Ejigu, a PhD student in the group is
currently working on context modelling for pervasive systems [Chaari06]. Therefore,
one of our future works will be to integrate his work in our prototype.
166
•
Chapter 9. Conclusion and Future Work
In the current implementation the MAGG algorithm considers the format of the input
and the output data for service compatibility. But other parameters for example, the
size of data and/or frame rate (for video) are also important. Therefore, the algorithm
should use all the parameter in determining the compatibility of the services. This can
be implemented by modifying the part of the algorithm that performs the precondition
and effect matching. Instead of checking only one parameter, it will check all the
parameters.
•
Pervasive computing is about distributed computing devices in the physical world,
such as personal devices, wearable computers, devices embedded in everyday objects
and sensors in the environment - it is about both the devices and the infrastructures
needed to support pervasive computing applications. Grid computing is about large
scale distributed computation, large scale data and large scale collaborations - applied
to solving large scale problems [Foster99]. Sometimes the Grid application demands
the pervasive computing, for example, in the grid-enabled devices in a laboratory-the
pieces of scientific equipment connected directly to the gird-and handheld devices
with which users gather information and access results [Roure03]. On the other hand,
in pervasive computing where we have arrays of sensors we acquire data with higher
temporal or spatial resolution, and this increasing bulk of (often real-time) data
demands the computational power of the Grid. At an appropriate layer of abstraction
both Pervasive and Grid are about large scale distributed processing elements. By
combining the two aspects together, that is, Pervasive Grid [Pierson05], we can bring
Grid computing to the physical world. Pervasive Grid is a service-oriented architecture
which involves research challenges including: service description, discovery and
composition, and security, authentication and trust. Our proposition of service-based
content adaptation maps well into this realm. In this context, we envisage that,
multimedia adaptation services can be deployed as Grid services31 for delivering
adapted multimedia data in pervasive grid environments. Hence, one of our future
works will be investigating the deployment of our framework into Pervasive Grid
systems.
The proxy system that has been implemented is first prototype to demonstrate content
adaptation in pervasive computing environments and there are still rooms for improvements.
31
A Grid service is a Web Service that conforms to a set of conventions (interfaces and behaviours) that define how a client interacts with
the Grid service [Geldof04]
167
We have identified the following list of limitations and future works concerning the
prototype:
•
Our decision engine does not utilize adaptation hints in deciding the adaptation types.
For example, a content provider can specify in the content metadata some allowed
adaptations on the data. The adaptation hints facilitate informed decision. Therefore,
we will investigate the incorporation of the adaptation hints.
•
Our prototype implements a simple cache strategy for adapted content. However, it
would be important to use caching strategy that guarantees high performance. Since
caching was not used for context profile, each time a user request a content, the local
proxy demands the profile from the repository. However, using cache for context
profile enables to increase the performance of the system. Therefore, further
investigation would be important to implant appropriate cache strategy for both the
adapted content and context profile. Y.Cardenas, a PhD student in the group is
working on cooperative caches in Grid environment [Carden05]. His work deals with
developing cache service for Grid computing. Our framework is developed in such a
way that enables easily integration of components/services to the system. Therefore,
we will study, how his cache service can be integrated and used by our system.
•
To develop interfaces for several possible terminals other than those used in the
prototype through collaboration with SEFAGI project.
169
Annexes
170
Annexes.
Annex A: Context Profile
171
Annex A: Context Profile
I Structure of the Context Profile
ContextProfile
DeviceProfile
Hardware
DeviceType
DeviceName
ScreenWidth
ScreenHeight
ScreenCharSize
ColorDepth
Memory
Processor
Storage
TextCapable
ImageCapable
VideoCapable
AudioCapable
Software
OperatingSystem
Name
Version
Vendor
Type
Name
UserAgent
Version
Vendor
ContentTypes
ContentFormats
UserProfile
Preferences
ContentTypes
Languages
QoSAdaptationService
Time
Price
QoSNetwork
Medium
L1
L2
Low
NetworkProfile
Type
Bandwidth
Delay
L1
L2
172
II XML Representation of the Context Profile
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#"
xmlns="http://Perse.insa-lyon.fr/DCAF/Schema/ContextProfile#">
xmlns:dev="http://Perse.insa-lyon.fr/DCAF/Schema/DeviceProfile#">
xmlns:use="http://Perse.insa-lyon.fr/DCAF/Schema/UserProfile#">
xmlns:net="http://Perse.insa-lyon.fr/DCAF/Schema/NetworkProfile#">
<ContextProfile rdf:ID="Context">
<device>
<dev:DeviceProfile>
<dev:Hardware>
<dev:DeviceType></dev:DeviceType>
<dev:DeviceName></dev:DeviceName>
<dev:ScreenWidth></dev:ScreenWidth>
<dev:ScreenHeight></dev:ScreenHeight>
<dev:ScreenCharSize></dev:ScreenCharSize>
<dev:ColorDepth></dev:ColorDepth>
<dev:Memory></dev:Memory>
<dev:Processor></dev:Processor>
<dev:Storage></dev:Storage>
<dev:TextCapable></dev:TextCapable>
<dev:ImageCapable></dev:ImageCapable>
<dev:AudioCapable></dev:AudioCapable>
<dev:VideoCapable></dev:VideoCapable>
</dev:Hardware>
<dev:Software>
<dev:OperatingSystem>
<dev:Name></dev:Name>
<dev:Version></dev:Version>
<dev:Vendor></dev:Vendor>
</dev:OperatingSystem>
<dev:UserAgent>
<dev:Type> </dev:Type>
<dev:Name></dev:Name>
<dev:Version></dev:Version>
<dev:Vendor></dev:Vendor>
<dev:ContentTypes>
<rdf:Bag>
<rdf:li></rdf:li>
</rdf:Bag>
</dev:ContentTypes>
<dev:ContentFormats>
<rdf:Bag>
<rdf:li></rdf:li>
</rdf:Bag>
</dev:ContentFormats>
</dev:UserAgent>
</dev:Software>
Annexes.
173
</dev:DeviceProfile>
</device>
<user>
<use:UserProfile>
<use:Preferences>
<use:ContentTypes>
<rdf:Bag>
<rdf:li></rdf:li>
</rdf:Bag>
</use:ContentTypes>
<use:Languages>
<rdf:Bag>
<rdf:li></rdf:li>
</rdf:Bag>
</use:Languages>
</use:Preferences>
<use:QoSAdaptationService>
<use:Time></use:Time>
<use:Price></use:Price>
</use:QoSAdaptationService>
<use:QoSNetwork>
<use:Medium>
<use:L1></use:L1>
<use:L2></use:L2>
</use:Medium>
<use:Low>
<use:L1></use:L1>
<use:L2></use:L2>
</use:Low>
</use:QoSNetwork>
</use:UserProfile>
</user>
<network>
<net:NetworkProfile>
<net:Type></net:Type>
<net:Bandwidth></net:Bandwidth>
<net:Delay></net:Delay>
</net:NetworkProfile>
</network>
</ContextProfile>
</rdf:RDF>
174
III Schema Definition of the Context Profile
<?xml version="1.0" encoding="UTF-8"?>
<rdf :RDF xmlns :rdf="http ://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns :rdfs="http ://www.w3.org/2000/01/rdf-schema#"
xmlns="http://Perse.insa-lyon.fr/DCAF/Schema/ContextProfile">
<! Context Profile Schema>
<rdf :Description rdf :ID="ContextProfile">
<rdf :type rdf :resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs :subClassOf rdf :resource="http ://www.w3.org/2000/01/rdfschema#Resource"/>
<rdfs :comment>
Device, user and network profile descriptions
</rdfs :comment>
</rdf :Description>
<rdf :Description rdf :ID="device">
<rdf :type rdf :resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs :subClassOf rdf :resource="#ContextProfile"/>
<rdfs :comment>
Device characteristics
</rdfs :comment>
</rdf :Description>
<rdf :Description rdf :ID="user">
<rdf :type rdf :resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs :subClassOf rdf :resource="#ContextProfile"/>
<rdfs :comment>
User profile and preferences
</rdfs :comment>
</rdf :Description>
<rdf :Description rdf :ID="network">
<rdf :type rdf :resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs :subClassOf rdf :resource="#ContextProfile"/>
<rdfs :comment>
Network charactertsics
</rdfs :comment>
</rdf :Description>
</rdf :RDF>
Annexes.
175
IV Schema Definition of the Device Profile
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http ://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http ://www.w3.org/2000/01/rdf-schema#"
xmlns="http://Perse.insa-lyon.fr/DCAF/Schema/DeviceProfile">
<rdf:Description rdf:ID="DeviceProfile">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http ://www.w3.org/2000/01/rdfschema#Resource"/>
<rdfs:comment>
Contains device, user and network descriptions
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Hardware">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#DeviceProfile"/>
<rdfs:comment>
Hardware characteristics of the user device
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Software">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#DeviceProfile"/>
<rdfs:comment>
Software characteristics of the user device
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="DeviceType">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
The type of user device: PC, Laptop, Phone, PDA etc.
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="DeviceName">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
The name of user device: Qtek 9100, Nokia E61, HP iPAQ hx2790, etc.
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ScreenWidth">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Width of the screen
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ScreenHeight">
176
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Height of the screen
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ScreenCharSize">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Character lines supported by the device"
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ColorDepth">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Number of colors supported by the screen
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Memory">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Memory capacity of the device in MB
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Processor">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Processor speed in MGHZ
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Storage">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Hard disk capacity of the device in GB
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="TextCapable">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Text capability of the device “Yes” or “No”
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ImageCapable ">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
Annexes.
177
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Image capability of the device “Yes” or “No”
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="VideoCapable">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Video capability of the device “Yes” or “No”
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="AudioCapable">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Hardware"/>
<rdfs:comment>
Audio capability of the device “Yes” or “No”
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="OperatingSystem">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Software"/>
<rdfs:comment>
Describe operating system name, version and vendor
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Name">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#OperatingSystem"/>
<rdfs:comment>
Name of the operating system
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Version">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#OperatingSystem"/>
<rdfs:comment>
Version of the operating system
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Vendor">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#OperatingSystem"/>
<rdfs:comment>
Vendor of the operating system
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="UserAgent">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Software"/>
178
<rdfs:comment>
Describe the user agent used
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Type">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#UserAgent"/>
<rdfs:comment>
Type of the user agent
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Name">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#UserAgent"/>
<rdfs:comment>
Name of the user agent
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Version">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#OperatingSystem"/>
<rdfs:comment>
Version of the user agent
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Vendor">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#OperatingSystem"/>
<rdfs:comment>
Vendor of the user agent
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ContentTypes">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Bag"/>
<rdfs:domain rdf:resource="#UserAgent"/>
<rdfs:comment>
Content types supported by the user agent
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ContentFormats">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Bag"/>
<rdfs:domain rdf:resource="#UserAgent"/>
<rdfs:comment>
Content formats supported by the user agent
</rdfs:comment>
</rdf:Description>
</rdf:RDF>
Annexes.
179
V Schema Definition of the User Profile
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http ://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http ://www.w3.org/2000/01/rdf-schema#">
xmlns="http://Perse.insa-lyon.fr/DCAF/Schema/UserProfile"
<rdf:Description rdf:ID="UserProfile">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http ://www.w3.org/2000/01/rdfschema#Resource"/>
<rdfs:comment>
Describe user profile and preferences
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Preferences">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#UserProfile"/>
<rdfs:comment>
Describe user preferences
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="ContentTypes">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Bag"/>
<rdfs:domain rdf:resource="#Preferences"/>
<rdfs:comment>
User content preference
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Languages">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Bag"/>
<rdfs:domain rdf:resource="#Preferences"/>
<rdfs:comment>
Describe user language preference
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="QoSAdaptationService">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#UserProfile"/>
<rdfs:comment>
Describe user Qos for adaptation services in terms of time and price
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Time">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#QoSAdaptationService"/>
<rdfs:comment>
Describe user preference for service delay (waiting time) in terms of weight values
between 0 and 1
180
Annexes.
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Price">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#QosAdaptationService"/>
<rdfs:comment>
Describe user preference for service charge in terms of weight values between 0 and 1
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="QosNetwork">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#UserProfile"/>
<rdfs:comment>
Describe network Qos specification in terms of bandwidth values
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Medium">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#QoSNetwork"/>
<rdfs:comment>
Describe medium network bandwidth range
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="L1">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Medium"/>
<rdfs:comment>
The lower bound value for medium network bandwidth
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="L2">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Medium"/>
<rdfs:comment>
The upper bound value for medium network bandwidth
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Low">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#QoSNetwork"/>
<rdfs:comment>
Describe low network bandwidth range
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="L1">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Low"/>
<rdfs:comment>
The lower bound value for low network bandwidth
</rdfs:comment>
181
</rdf:Description>
<rdf:Description rdf:ID="L2">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#Low"/>
<rdfs:comment>
The upper bound value for low network bandwidth
</rdfs:comment>
</rdf:Description>
</rdf:RDF>
VI Schema Definition of the Network Profile
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http ://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http ://www.w3.org/2000/01/rdf-schema#"
xmlns="http://Perse.insa-lyon.fr/DCAF/Schema/NetworkProfile">
<rdf:Description rdf:ID="NetworkProfile">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http ://www.w3.org/2000/01/rdfschema#Resource"/>
<rdfs:comment>
Describe network characterstics
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Type">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#NetworkProfile"/>
<rdfs:comment>
Describe the network type
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Bandwidth">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#NetworkProfile"/>
<rdfs:comment>
Describe the network bandwidth in KB per second
</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Delay">
<rdf:type rdf:resource="http ://www.w3.org/2000/01/rdf-schema#Property"/>
<rdfs:domain rdf:resource="#NetworkProfile"/>
<rdfs:comment>
Describe the network delay
</rdfs:comment>
</rdf:Description>
</rdf:RDF>
Annex B: Proposed Services Description Ontology
183
Annex B: Proposed Services Description Ontology
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="http://perse.insa-lyon.fr/DCAF/Ontology/MMASO.owl#"
xml:base="http://perse.insa-lyon.fr/DCAF/Ontology/MMASO.owl">
<owl:Ontology rdf:about=""/>
<!---Multimedia Adaptation Services -->
<owl:Class rdf:ID="MultimediaAdaptationServices">
<rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:allValuesFrom>
<owl:DataRange>
<owl:oneOf rdf:parseType="Resource">
<rdf:rest rdf:parseType="Resource">
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Good</rdf:first>
<rdf:rest rdf:parseType="Resource">
<rdf:rest rdf:parseType="Resource">
<rdf:rest rdf:parseType="Resource">
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Bad</rdf:first>
<rdf:rest
rdf:resource="http://www.w3.org/1999/02/22-rdfsyntax-ns#nil"/>
</rdf:rest>
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Poor</rdf:first>
</rdf:rest>
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Fair</rdf:first>
</rdf:rest>
</rdf:rest>
<rdf:first
rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Excellent</rdf:first>
</owl:oneOf>
</owl:DataRange>
</owl:allValuesFrom>
<owl:onProperty>
<owl:DatatypeProperty rdf:ID="hasServiceQuality"/>
</owl:onProperty>
</owl:Restriction>
184
Annexes.
</rdfs:subClassOf>
</owl:Class>
<owl:DatatypeProperty rdf:ID="hasServiceName">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="hasServiceTime">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:about="#hasServiceQuality">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:about="#hasEffect">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#hasInputType">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="#MultimediaDatatype"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#hasOutputType">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="#MultimediaDatatype"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasServicePrice">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#hasPrecondition">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasServiceProvider">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID="hasServiceDescription">
<rdfs:domain rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<!---Audio Adaptation Services -->
<owl:Class rdf:about="#AudioAdaptationServices">
<rdfs:subClassOf rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasInputType"/>
Annex B: Proposed Services Description Ontology
</owl:onProperty>
<owl:hasValue rdf:resource="#Audio"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#UnimodalAudioAdaptationServices">
<rdfs:subClassOf>
<owl:Class rdf:ID="AudioAdaptationServices"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasOutputType"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Audio"/>
</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="MultimodalAudioAdaptationServices"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#AudioAdaptationServices"/>
</owl:Class>
<owl:Class rdf:about="#MultimodalAudioAdaptationServices">
<rdfs:subClassOf rdf:resource="#AudioAdaptationServices"/>
<owl:disjointWith rdf:resource="#UnimodalAudioAdapationServices"/>
</owl:Class>
<owl:Class rdf:ID="AudioLanguageAdaptationServices">
<owl:disjointWith>
<owl:Class rdf:ID="AudioFormatAdaptationServices"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="AudioReductionAdaptationServices"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="UnimodalAudioAdaptationServices"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="AudioToTextAdaptationServices">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#hasOutputType"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Text"/>
</owl:hasValue>
</owl:Restriction>
185
186
Annexes.
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:ID="MultimodalAudioAdaptationServices"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#AudioReductionAdaptationServices">
<rdfs:subClassOf rdf:resource="#UnimodalAudioAdapationServices"/>
<owl:disjointWith>
<owl:Class rdf:about="#AudioFormatAdaptationServices"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#AudioLanguageAdaptationServices"/>
</owl:Class>
<owl:Class rdf:ID="StereoToMonoAdaptationServices">
<rdfs:subClassOf>
<owl:Class rdf:about="#AudioReductionAdaptationServices"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="AudioSamplingRateReductionAdaptationServices"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#AudioSamplingRateReductionAdaptationServices">
<rdfs:subClassOf rdf:resource="#AudioReductionAdaptationServices"/>
<owl:disjointWith rdf:resource="#StereoToMonoAdaptationServices"/>
</owl:Class>
<owl:Class rdf:about="#AudioFormatAdaptationServices">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasPrecondition"/>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:ID="AudioDatatypeFormat"/>
</owl:allValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#AudioLanguageAdaptationServices"/>
<owl:disjointWith rdf:resource="#AudioReductionAdaptationServices"/>
<rdfs:subClassOf rdf:resource="#UnimodalAudioAdapationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasEffect"/>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:about="#AudioDatatypeFormat"/>
</owl:allValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Annex B: Proposed Services Description Ontology
<!---Image Adaptation Services -->
<owl:Class rdf:about="#ImageAdaptationServices">
<rdfs:subClassOf rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasInputType"/>
</owl:onProperty>
<owl:hasValue rdf:resource="#Image"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#UnimodalImageAdaptationServices">
<rdfs:subClassOf>
<owl:Class rdf:ID="ImageAdaptationServices"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasOutputType"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Image"/>
</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="MultimodalImageAdaptationServices"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#ImageAdaptationServices"/>
</owl:Class>
<owl:Class rdf:about="#MultimodalImageAdaptationServices">
<rdfs:subClassOf rdf:resource="#ImageAdaptationServices"/>
<owl:disjointWith rdf:resource="#UnimodalImageAdapationServices"/>
</owl:Class>
<owl:Class rdf:ID="ImageResizingAdaptationServices">
<owl:disjointWith>
<owl:Class rdf:ID="ImageColorReductionAdaptationServices"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="ImageColorToGrayAdaptationServices"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="ImageFormatAdaptationServices"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="UnimodalImageAdaptationServices"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="ImageToTextAdaptationServices">
187
188
Annexes.
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#hasOutputType"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Text"/>
</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:ID="MultimodalImageAdaptationServices"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#ImageResizingAdaptationServices">
<rdfs:subClassOf rdf:resource="#UnimodalImageAdapationServices"/>
<owl:disjointWith rdf:resource="#ImageColorReductionAdaptationServices"/>
<owl:disjointWith rdf:resource="#ImageColorToGrayAdaptationServices"/>
<owl:disjointWith>
<owl:Class rdf:about="#ImageFormatAdaptationServices"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#ImageFormatAdaptationServices">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasPrecondition"/>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:ID="ImageDatatypeFormat"/>
</owl:allValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#ImageResizingAdaptationServices"/>
<owl:disjointWith rdf:resource="#ImageColorReductionAdaptationServices"/>
<owl:disjointWith rdf:resource="#ImageColorToGrayAdaptationServices"/>
<rdfs:subClassOf rdf:resource="#UnimodalImageAdapationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasEffect"/>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:about="#ImageDatatypeFormat"/>
</owl:allValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!---Text Adaptation Services -->
Annex B: Proposed Services Description Ontology
<owl:Class rdf:about="#TextAdaptationServices">
<rdfs:subClassOf rdf:resource="#MultimediaAdaptationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasInputType"/>
</owl:onProperty>
<owl:hasValue rdf:resource="#Text "/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#UnimodalTextAdaptationServices">
<rdfs:subClassOf>
<owl:Class rdf:ID="TextAdaptationServices"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasOutputType"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Text"/>
</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="MultimodalTextAdaptationServices"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#TextAdaptationServices"/>
</owl:Class>
<owl:Class rdf:about="#MultimodalTextAdaptationServices">
<rdfs:subClassOf rdf:resource="#TextAdaptationServices"/>
<owl:disjointWith rdf:resource="#UnimodalTextAdapationServices"/>
</owl:Class>
<owl:Class rdf:ID="TextLanguageAdaptationServices">
<owl:disjointWith>
<owl:Class rdf:ID="TextFormatAdaptationServices"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="TextSummaryAdaptationServices"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="UnimodalTextAdaptationServices"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="TextToAudioAdaptationServices">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
189
190
Annexes.
<owl:ObjectProperty rdf:about="#hasOutputType"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Audio"/>
</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:ID="MultimodalTextAdaptationServices"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#TextSummaryAdaptationServices">
<rdfs:subClassOf rdf:resource="#UnimodalTextAdapationServices"/>
<owl:disjointWith>
<owl:Class rdf:about="#TextFormatAdaptationServices"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#TextFormatAdaptationServices">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasPrecondition"/>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:ID="TextDatatypeFormat"/>
</owl:allValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#TextLanguageAdaptationServices"/>
<owl:disjointWith rdf:resource="#TextSummaryAdaptationServices"/>
<rdfs:subClassOf rdf:resource="#UnimodalImageAdapationServices"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasEffect"/>
</owl:onProperty>
<owl:allValuesFrom>
<owl:Class rdf:about="#TextDatatypeFormat"/>
</owl:allValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="MultimediaDatatype">
<owl:equivalentClass>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Audio"/>
<owl:Thing rdf:about="#Image"/>
<owl:Thing rdf:about="#Text"/>
Annex B: Proposed Services Description Ontology
<owl:Thing rdf:ID="Video"/>
<owl:Thing rdf:ID="Graphics"/>
<owl:Thing rdf:ID="Animation"/>
</owl:oneOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
<!---Multimedia Data Type Format -->
<owl:Class rdf:ID="#MultimediaDatatypeFormat">
<rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
</owl:Class>
<owl:ObjectProperty rdf:about="#hasDatatype">
<rdfs:domain rdf:resource="#MultimediaDatatypeFormat"/>
<rdfs:range rdf:resource="#MultimediaDatatype"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID="hasFormat">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain rdf:resource="#MultimediaDatatypeFormat"/>
</owl:DatatypeProperty>
<!---Audio Data Type Format -->
<owl:Class rdf:about="#AudioDatatypeFormat">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#hasDatatype"/>
</owl:onProperty>
<owl:hasValue rdf:resource="#Audio"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#MultimediaDatatypeFormat"/>
</owl:Class>
<!---Image Data Type Format -->
<owl:Class rdf:ID="ImageDatatypeFormat">
<rdfs:subClassOf>
<owl:Class rdf:ID="MultimediaDatatypeFormat"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="hasDatatype"/>
</owl:onProperty>
<owl:hasValue>
<owl:Thing rdf:ID="Image"/>
</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
191
192
Annexes.
<owl:Class rdf:ID="AnimationDatatypeFormat">
<rdfs:subClassOf rdf:resource="#ImageDatatypeFormat"/>
</owl:Class>
<owl:Class rdf:ID="GraphicsDatatypeFormat">
<rdfs:subClassOf rdf:resource="#ImageDatatypeFormat"/>
</owl:Class>
<!---Text Data Type Format -->
<owl:Class rdf:ID="TextDatatypeFormat">
<rdfs:subClassOf rdf:resource="#MultimediaDatatypeFormat"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#hasDatatype"/>
</owl:onProperty>
<owl:hasValue rdf:resource="#Text"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!---Video Data Type Format -->
<owl:Class rdf:ID="VideoDatatypeFormat">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#hasDatatype"/>
</owl:onProperty>
<owl:hasValue rdf:resource="#Video"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#MultimediaDatatypeFormat"/>
</owl:Class>
</rdf:RDF>
Annex C: OWL-S Profile Schema
193
Annex C: OWL-S Profile Schema
<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE uridef [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema">
<!ENTITY owl "http://www.w3.org/2002/07/owl">
<!ENTITY expr "http://www.daml.org/services/owl-s/1.1/generic/Expression.owl">
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema">
<!ENTITY service "http://www.daml.org/services/owl-s/1.1/Service.owl">
<!ENTITY process "http://www.daml.org/services/owl-s/1.1/Process.owl">
<!ENTITY DEFAULT "http://www.daml.org/services/owl-s/1.1/Profile.owl">
]>
<!-This document uses entity types as a shorthand for URIs.
For a version with unexpanded entities, try loading this source into Internet Explorer.
-->
<rdf:RDF
xmlns:rdf=
"&rdf;#"
xmlns:rdfs=
"&rdfs;#"
xmlns:owl=
"&owl;#"
xmlns:service="&service;#"
xmlns:process="&process;#"
xmlns= "&DEFAULT;#"
xml:base=
"&DEFAULT;">
<owl:Ontology rdf:about="">
<owl:versionInfo>
$Id: Profile.owl,v 1.51 2004/11/03 03:27:20 martin Exp $
</owl:versionInfo>
<rdfs:comment>
OWL ontology for Advertisements (i.e. Profiles).
This file belongs to the OWL-S Release.
Initial version created by Terry Payne ([email protected]).
Modified by Massimo Paolucci ([email protected])
Modified by David Martin and other members of the OWL-S Coalition.
</rdfs:comment>
<rdfs:seeAlso
rdf:resource="http://www.daml.org/services/owls/1.1/ProfileAdditionalParameters.owl" />
<rdfs:seeAlso
rdf:resource="http://www.daml.org/services/owls/1.1/ProfileDeprecatedElements.owl" />
<rdfs:seeAlso rdf:resource="http://www.daml.org/services/owl-s/1.1/ActorDefault.owl"
/>
<!--->
<owl:imports>
194
Annexes.
<owl:Ontology rdf:about="&service;" />
</owl:imports>
<owl:imports>
<owl:Ontology rdf:about="&process;" />
</owl:imports>
</owl:Ontology>
<!-- ############
PROFILE
########### -->
<!-Profile is a subclass of ServiceProfile. It is used to acknowledge that there may be
different ways to profile services that are different from the way we expressed it so far.
-->
<owl:Class rdf:ID="Profile">
<rdfs:label>Profile</rdfs:label>
<rdfs:subClassOf rdf:resource="&service;#ServiceProfile" />
<rdfs:comment>
Definition of Profile
</rdfs:comment>
</owl:Class>
<!-- ############
<!-- ############
PROFILE
########### -->
NON FUNCTIONAL PROPERTIES
########### -->
<!-The Service Name refers to the name of the service that is being offered.
-->
<owl:DatatypeProperty rdf:ID="serviceName">
<rdfs:domain rdf:resource="#Profile"/>
</owl:DatatypeProperty>
<!-- there is only one name per profile -->
<owl:Class rdf:about="#Profile">
<rdfs:comment>
A profile can have only one name
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#serviceName"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-The TextDescription provides a brief description of the service.
It summarisese what the service offers, or to describe what
service is requested.
-->
Annex C: OWL-S Profile Schema
195
<owl:DatatypeProperty rdf:ID="textDescription">
<rdfs:domain rdf:resource="#Profile"/>
</owl:DatatypeProperty>
<!-- there is only one text description per profile -->
<owl:Class rdf:about="#Profile">
<rdfs:comment>
A profile can have only one text description
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#textDescription"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-Contact information is used to record contact information about the entity that issued
the Profile. It once refered to Actor, that records address and other info that allows a
receiver of the profile to contact directly the issuer. However, this class has migrated to a
separate ActorDefault.daml ontology.
-->
<owl:ObjectProperty rdf:ID="contactInformation">
<rdfs:domain rdf:resource="#Profile"/>
</owl:ObjectProperty>
<!-has_process is a pointer the process that is associated with the service.
-->
<owl:ObjectProperty rdf:ID="has_process">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="&process;#Process"/>
</owl:ObjectProperty>
<owl:FunctionalProperty rdf:about="#has_process"/>
<owl:ObjectProperty rdf:ID="serviceCategory">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="#ServiceCategory"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="serviceParameter">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="#ServiceParameter"/>
196
Annexes.
</owl:ObjectProperty>
<!-- ####### SERVICE PROFILE FUNCTIONALITY DESCRIPTION ###### -->
<owl:ObjectProperty rdf:ID="hasParameter">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="&process;#Parameter"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasInput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:range rdf:resource="&process;#Input"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasOutput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:range rdf:resource="&process;#Output"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasPrecondition">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasResult">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="&process;#Result"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="ServiceCategory"/>
<!-- categoryName is the name of the actual category, which could be just a literal, or
perhaps the uri of the process parameter (a property)
-->
<owl:DatatypeProperty rdf:ID="categoryName">
<rdfs:domain rdf:resource="#ServiceCategory"/>
</owl:DatatypeProperty>
<!-- each serviceCategory can refer to only one categoryName -->
<owl:Class rdf:about="#ServiceCategory">
<rdfs:comment>
a ServiceCategory is restricted to refer to only onename
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
Annex C: OWL-S Profile Schema
197
<owl:onProperty rdf:resource="#categoryName"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-- taxonomy stores a reference to the taxonomy scheme. It can be either the URL of
the taxonomy, or the name of the taxonomy or anything else. -->
<owl:DatatypeProperty rdf:ID="taxonomy">
<rdfs:domain rdf:resource="#ServiceCategory"/>
</owl:DatatypeProperty>
<!-- each serviceCategory can refer to only one taxonomy, to limit the possibility of
confusion. -->
<owl:Class rdf:about="#ServiceCategory">
<rdfs:comment>
a ServiceCategory is restricted to refer to only one taxonomy
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#taxonomy"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-- value points to the value in a specific taxonomy. There may be more than one value
for each taxonomy, so no restriction is added here.
-->
<owl:DatatypeProperty rdf:ID="value">
<rdfs:domain rdf:resource="#ServiceCategory"/>
</owl:DatatypeProperty>
<!-- each serviceCategory can refer to only one value, if more then one value applies,
then they have to be added as a string with space separators -->
<owl:Class rdf:about="#ServiceCategory">
<rdfs:comment>
a ServiceCategory is restricted to refer to only one taxonomy
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#value"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
198
Annexes.
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-- Often taxonomies associate a code to each type of service. The following property
stores the code -->
<owl:DatatypeProperty rdf:ID="code">
<rdfs:domain rdf:resource="#ServiceCategory"/>
</owl:DatatypeProperty>
<!-- each serviceCategory can refer to only one code, if more then one value applies,
then they have to be added as a string with space separators
There may be of course a problem of synchronization with the value -->
<owl:Class rdf:about="#ServiceCategory">
<rdfs:comment>
a ServiceCategory is restricted to refer to only one taxonomy
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#code"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-ServiceParameter describes service parameters.
In general we can think this class as the root of an ontology of
Service Parameters of different types. Other types of
ServiceParameters may expand this definition by adding other
properties.
-->
<owl:Class rdf:ID="ServiceParameter"/>
<!-- serviceParameterName is the name of the actual parameter, which could be just a
literal,
or perhaps the uri of the process parameter (a property)
-->
<owl:DatatypeProperty rdf:ID="serviceParameterName">
<rdfs:domain rdf:resource="#ServiceParameter"/>
</owl:DatatypeProperty>
<owl:Class rdf:about="#ServiceParameter">
<rdfs:comment>
A ServiceParameter should have at most 1 name (more precisely only
Annex C: OWL-S Profile Schema
one serviceParameterName)
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#serviceParameterName"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-- sParameter points to the value of the parameter within some OWL ontology -->
<owl:ObjectProperty rdf:ID="sParameter">
<rdfs:domain rdf:resource="#ServiceParameter"/>
<rdfs:range rdf:resource="&owl;#Thing"/>
</owl:ObjectProperty>
<owl:Class rdf:about="#ServiceParameter">
<rdfs:comment>
a Parameter is restricted to refer to only one concept in some
ontology
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#sParameter"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<!-- Map the Profile to a Service Type -->
<owl:DatatypeProperty rdf:ID="serviceClassification">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="&xsd;#anyURI"/>
</owl:DatatypeProperty>
<!-- Map the Profile to a product Type -->
<owl:DatatypeProperty rdf:ID="serviceProduct">
<rdfs:domain rdf:resource="#Profile"/>
<rdfs:range rdf:resource="&xsd;#anyURI"/>
</owl:DatatypeProperty>
</rdf:RDF>
199
200
Annexes.
Annex D: Modified Dijkstra’s Algorithm
201
Annex D: Modified Dijkstra’s Algorithm
function: Dijkstra (G)
Input: Adaptation Graph G= (V, E) and W
Output: Optimal path OPath
V
E
os
oe
v
u
D[v]
W ( v)
Pred
SV
A set of nodes representing operators
A set of edges representing connection between operators
A start node
An end node
A node
A node
Stores total quality value (price and execution time) of the path from
start node os to node v
stores quality value of v
A set of nodes to store predecessor nodes, e.g. Pred[v] stores
predecessor of v
A set of nodes-stores topologically sorted nodes
begin
SV=SortTopologiocally(V, E) // sort V topologically
for each v ∈ V
begin
D[v] = negative infinity
Pred[v] =NIL//parent of v in the optimal path
end
D[os] =0
for each u ∈ SV
begin
for each v ∈ SV
begin
if ((u, v) ∈ E) then
begin
if (D[v] < D[u]+W(v) then
begin
D[v] =D[u]+W(v)
Pred[v] =u
end
end
end
end
//reading the optimal path by iteration
Opath =Ø //contains list of nodes on the optimal path from os to oe
u =oe //e is the end node
for each Pred[u] ≠ NIL
begin
Opath ={u} ∪ Opath //Insert u in the beginning of Opath
end
202
Annexes.
return Opath
end //Optimal-path search
// this procedure sorts a graph topologically and returns a set of sorted nodes
// in a topologically sorted graph, if there is a path from node x to node y, the node x comes
// before the node y in the node set.
// V a set of nodes-input
// E a set of edges-input
function Vector SortTopologically(in V, in E)
// TE a set of edges- temporal variable
// TV a set of nodes-temporal variable
// TSV a set of nodes- stores topologically sorted nodes
// v a node- temporal variable
begin
TE =E
TV =V
TSV =Ø
while (TV ≠ Ø)
begin
for each v ∈ TV
begin
if (Not Predecessor(v, TV, TE)) then // v does not have predecessor
begin
TSV =TSV ∪ {v}
Delete(v, TV, TE)
end
end
end
return TSV
end //SortTopologically
//this function returns true if a node has a predecessor otherwise false
// v a node-input
// TV a set of nodes-input
//TE a set of edges-input
function Boolean Predecessor(in v, in TV, in TE)
//y a node
var
y
begin
for each y ∈ TV
begin
if ((y, v) ∈ TE) then // the node has predecessor
return true
end
return false
end //Predecessor
Annex D: Modified Dijkstra’s Algorithm
//this procedure deletes a node
//v a node to be deleted-input
//TV a set of nodes-input/output
//TE a set of edges-input/output
procedure Delete(in v, inout TV, inout TE)
// y a node
var
y
begin
for each y ∈ TV
begin
if ((v,y) ∈ TE) then
TE=TE-{(v, y)}
end
TV=TV-{v}
end //Delete
203
Annex E: Classes Hierarchy of Local Proxy
205
Annex E: Classes Hierarchy of Local Proxy
Class::MediaObject
This class represents a media object such as text, image, video or audio data.
MediaObject: instance variables
Vector mediaInfo
Vector mediaProfile
MediaObject: Methods
public void setMediaInformation(vector mediaInfo)
sets the media information of the media object
public void setMediaProfile(vector mediaProfile)
sets the media profile of the media object
public vector getMediaInformation()
returns the media information of the media object
public vector getMediaProfile()
returns the media profile of the media object
Note: Hashtable was used to implement the media object
Class: AdaptationTasks
This class extends the Vector class. It stores the transformation tasks.
Class: Operator
This class stands for an operator that corresponds to an adaptation service. It has a constructor
to initialize the instance variables.
Operator: Instance variables
protected String OpName; the name of the operator
206
Annexes.
protected int OpId; the identification of the operator
protected Vector Input; the input list of the operator
protected Vector Output; the output list of the operator
protected Vector Precondition; the preconditions of the operator
protected Vector Effect; the effect of the operator
protected double Cost; cost of the operator
protected double Time; execution time of the operator
Operator: Methods
public void SetOpId(int id)
public void SetOpName(String op)
public void AddInput(Vector in)
public void AddOutput(Vector out)
public void SetPrecond(Vector pre)
public void SetEffect(Vector effect)
public void SetCost(double c)
public void SetTime(double t)
public int GetOpId()
public String GetOpName()
public Vector GetPrecond()
public Vector GetEffect()
public double GetCost()
public double GetTime()
Class: Predicate
This class stores the predicate information to define precondition and effect of an operator
Predicate: Instance variables
protected String PredName; the name of the predicate
protected String PredValue; the value of the predicate
Predicate: Methods
public void SetPred(String preName, String preValue)
Annex E: Classes Hierarchy of Local Proxy
207
public String GetPredName()
public String GetPredValue()
Class: PlanElement
This is a data structure that has two main variables of type list (Vector) of Operator and list
(Vector) of String. The first list stores the operators that realize an adaptation task and the
second list stores the links of each operator with next operators. It has a constructor to
initialize the instance variables.
PlanElement: Instance variables
protected Vector opLayer; the list of operators
protected Vector linkLayer; the link or connection of each operator in the opLayer with the
next operators
PlanElement: Methods
public void setOpLayer(Vector ops)
public void setLinkLayer(Vector link)
public Vector GetOpLayer()
public Vector GetLinkLayer()
Class: Plans:
This is a data structure that has a list (Vector) of PlanElement objects. Its purpose is to hold
all possible adaptation plans (also called adaptation graph).
Class: OptimalPlan (also called optimal path)
This class extends the Vector class. Its purpose is to hold the operators of the optimal plan or
path.
Class: Predicate
This class stores the predicate information to define precondition and effect of an operator
Predicate: Instance variables
protected String PredName; the name of the predicate
208
Annexes.
protected String PredValue; the value of the predicate
Predicate: Methods
public void SetPred(String preName, String preValue)
public String GetPredName()
public String GetPredValue()
Class: ContextProfile
This class stores the context profile/metadata which includes user profile, device profile and
network profile.
ContextProfile:Methods
public Void setUserProfile()
public Void setDeviceProfile()
public Void setNetworkProfile()
public Vector getUserProfile()
public Vector getDeviceProfile()
public Vector getNetworkProfile()
Note: Hashtable was used to implement ContextProfile
Class: ContextProfileHandler
This class extends the DefaultHandler class. It parses the XML description of context profile
and stores the data in the ContextProfile object.
Class: MediaHandler
This class extends the DefaultHandler class. It parses the Multimedia content description (in
XML format) and stores the data in the MediaObject object.
Class: OperatorMappingHandler
Annex E: Classes Hierarchy of Local Proxy
209
This class extends the DefaultHandler class. It takes ContextProfile object, MediaObject
object and transformation rules (in XML format) and returns the transformations prescript in
XML format.
Class: OWLHandler
This class extends the DefaultHandler class. It parses an OWL description of an adaptation
service and returns its corresponding Operator object.
Class: AdaptationProcessor
This class is responsible for constructing the adaptation graph and the finding the optimal path
of the graph. It has a constructor that takes ContextProfile, MediaObject and a file containing
the transformation rules and returns the transformation tasks.
AdaptationProcessor: Instance variables
AdaptationTasks tasks;
MediaState iState;
MediaState fSate;
AdaptationProcessor: Methods
public
Void
AdaptationGraphConstructor
(MediaState
iState,
MediaState
AdaptationTasks tasks)
public Vector SearchOptimalPath (Vector plans)
this method returns the optimal adaptation plan if there is one otherwise empty.
fState,
Annex F: Glossary
211
Annex F: Glossary
API
Application Program Interface
CC/PP
Composite Capabilities/Preference Profiles
CSS
Cascading Style Sheets
cHTML
Compact HTML
GPRS
General Packet Radio Service
GIF
Graphics Interchange Formats
HDML
Handheld Device Markup Language
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
ISP
Internet Service Provider
JPEG
Joint Photographic Experts Group, a lossy compression technique for color
images
MMS
Multimedia Messaging Service, a method of transmitting multimedia and short
text messages over wireless networks using WAP protocol
MPEG
Moving Picture Experts Group, also refers to family of digital video
compression standards and file formats developed by the group
PDA
Personal Digital Assistant
PDF
Portable Document Format
PNG
Portable Network Graphics
SMIL
Synchronized Multimedia Integration Language
SOAP
Simple Object Access Protocol
RIM
Remote Invocation Method
RPC
Remote Procedure Call
Smartphone
A combination of mobile phone and PDA
SMS
Short Message Service
SVG
Scalable Vector Graphics
TIFF
Tagged Image File Format
UAProf
User Agent Profile
W3C
World Wide Consortium
WAP
Wireless Application Protocol
212
WAX
Annexes.
Wireless Abstract XML a set of tools and an abstract markup language used to
author content for wireless applications.
WBMP
Wireless Bitmap, a graphic format optimized for mobile devices
WML
Wireless Markup Language, an XML language used to specify content and
user interface for WAP devices
XHTML
eXtensible HyperText Markup Language
XML
eXtensible Markup Language
XSL
eXtensible Style Language
XSLT
eXtensible Style Language Transformations, the language used in XSL style
sheets to transform XML documents into other XML documents
Windows CE (sometimes abbreviated WinCE) is a variation of Microsoft's Windows
operating system for minimalistic computers and embedded systems.
Bibliography
Bibliography
215
Bibliography
[3Com00]
3Com
Inc.
Palm
VII
[On
line].
Available
on:
<http://www.palm.com/products/palmvii> (Accessed on 11 December 2003).
[Adela01]
T. Adelaar, F. Aldershoff, E. Goedvolk, et al. Engineering Content for a
New Competitive Era: The GigaPort Content Engineering Periodical 2000. TI/RS/2000/164
[on
line].
Netherlands:
GigaCE,
2001.
Available
on:
<http://extranet.telin.nl/docuserver/dscgi/ds.py/ViewProps/File-12331> (Accessed on 14
December 2003).
[Agoston00]
T.C. Agoston, T.Ueda, Y.Nishimura. Pervasive Computing in a Networked
World. In Global Distributed Intelligence for Everyone, INET2000: 10th Annual Internet
Society Conference, 18-21 July 2000, Yokohama, Japan [on line]. Available on:
<http://www.isoc.org/inet2000/cdproceedings/3a/3a_1.htm> (Accessed on 11 December
2003).
[Alonso04]
G. Alonso, F. Casati, H. Kuno et al. Web Services: Concepts, Architectures
and Applications. New York: Springer-Verlag, 2004, 480 p. ISBN 3540440089.
[Angin98]
O. Angin, AT. Campbell, ME. Kounavis et al. The mobiware Toolkit:
Programmable Support for Adaptive Mobile Networking. IEEE Personal Communication,
1998, Vol.5, No.4, pp. 32-43.
[Ankol01]
A. Ankolekar, M. Burstein, JR. Hobbs et al. DAML-S: Semantic Markup
for Web services. In proceedings of the International Semantic Web Working Symposium,
July 30-August 1, 2001, Stanford, CA, pp. 411-430.
[Apache]
The Apache Software Foundation. The Apache Cocoon Project [on line].
Available on: <http://cocoon.apache.org/> (Accessed on 10 April 2004).
[Ardon03]
S. Ardon, P. Gunningberg, B. LandFeldt et al. MARCH: A distributed
content adaptation architecture. International Journal of Communication Systems, Special
Issue: Wireless Access to the Global Internet: Mobile Radio Networks and Satellite Systems,
2003, Vol 16, No. 1, pp. 97-115.
[Arkin02]
A. Arkin .Business Process Modeling Language. Working Draft June 24,
2002 [on line]. Available on: <http://xml.coverpages.org/BPML-WD-200206.pdf> (Accessed
on 13 April 2004).
[Arkin02b]
A. Arkin, S. Askary, S. Fordin et al. Web Service Choreography Interface
(WSCI) 1.0. World Wide Web Consortium, 2002, Boston, USA.
216
Bibliography.
[Asadi04]
M. K. Asadi and J-C. Dufourd. Multimedia Adaptation by Transmoding in
MPEG-21. In 5th International Workshop on Image Analysis for Multimedia Interactive
Services (WIAMIS), April 21-23, 2004, Lisbon, Portugal.
[Aspy93]
C. B. Aspy D. N. Aspy. The Human Age in Education. Journal of
Invitational Theory and Practice, 1993, Vol. 2, No. 1, pp.5-12.
[Aura]
Aura (CMU) [on line]. Available on: <http://www-2.cs.cmu.edu/aura/>
(Accessed on 10 September 2004).
[Aust02]
D. Austin. Web Services Architecture Requirements [on line]. W3C
Working Draft 14 November 2002. Available on: <http://www.w3.org/TR/wsa-reqs>
(Accessed on 13 October 2003).
[BabelFish]
BabelFish [on line]. Available on: <http://babelfish.altavista.com/>
(Accessed on 25 October 2003).
[Bane02]
Language
A. Banerji, C. Bartolini, D. Beringer et al. Web Services Conversation
(WSCL)
1.0,
W3C
Note,
Mar.
2002
[on
line].
Available
on:
<http://www.w3.org/TR/2002/NOTE-wscl10-20020314/> (Accessed on 19 March 2003).
[Barbir0202]
A. Barbir02, R. Chen, M. Hofmann et al. An Architecture for Open
Pluggable Edge Services (OPES), Internet Draft, IETF Network Working Group, December
11, 2002 [on line]. Available on: <http://www.ietf.org/internet-drafts/draft-ietf-opesarchitecture-04.txt> (Accessed on 9 December 2003).
[Batke04]
J-M. Batke, G. Eisenberg, P. Weishaupt et al. A QBH system using
MPEG-7 Descriptor. In Proceedings of the 116th Audio Engineering Society Convention, May
8–11 2004, Berlin, Germany.
[Bekker00]
H. Bekker, I. Belgers, P. Valkenburg. Inventory of Metadata for
Multimedia
[on
line].
September
2000.
Available
on:
http://www.surfnet.nl/innovatie/surfworks/doc/mmmetadata/. (Accessed on 24 May 2003).
[Bell02]
T. Bellwood, L. Clément, D. Ehnebuske et al. Universal Description,
Discovery and Integration specification (UDDI) 3.0. UDDI Spec Technical Committee
Specification [on line], 19 July 2002. Available on: <http://uddi.org/pubs/uddi-v3.00published-20020719.htm> (accessed on 10 June 2003).
[Bhra98]
H. Bharadvaj, A. Joshi, and S. Auephanwiriyakul. An active transcoding
proxy to support mobile web access. In Proceedings of 17th IEEE Symposium on Reliable
Distributed System, 1998, West Lafayette, IN, USA, pp. 118--123.
Bibliography
[Bhrag97]
217
V. Bharghavan, V. Gupta. A Framework for Application Adaptation in
Mobile Computing Environments. In Proceedings of the IEEE Compsoc’97, 11-15 Aug 1997,
Washington, D.C., USA.
[Bick97]
T. Bickmore and B. Schilit. Digestor: Device-independent Access to the
World Wide Web. In Proceedings of the 6th World Wide Web Conference (WWW6), April
7-11, 1997, Santa Clara, California USA, pp. 655–663.
[Bick99]
T. Bickmore, A. Girgensohn, J.W. Sullivan. Web Page Filtering and Re-
Authoring for Mobile Users. In The Computer Journal, 199, vol. 42, no. 6, pp. 534—546.
[Björk99]
S. Björk, L.E. Holmquist, J. Redström et al. WEST: a Web browser for
small terminals. In Proceedings of the 12th annual ACM symposium on User interface
software and technology, 07-10 November 1999, Asheville, North Carolina, USA, pp.187196.
[Boll01]
S. Boll and W. Klas. ZYX - A Multimedia Document Model for Reuse and
Adaptation. In IEEE Transactions on Knowledge and Data Engineering, May/June 2001,
Vol.13, No. 3, pp. 361-382.
[Boll99]
S.Boll, W.Klas, J.Wandel. A cross-media adaptation strategy for
multimedia presentation. In Proceedings of the 7th ACM International Conference on
Multimedia, Oct. 1999, Orlando, Florida, USA, pp. 37-46. ISBN: 1-58113-151-8.
[Bolner01]
M. S. Bolner and G. A. Poirier. The Research Process: Books and Beyond.
2nd Ed. Dubuque, IA: Kendall/Hunt, 2001, 450 p. ISBN: 0787294489.
[Bolot98]
J.C. Bolot, T. Turletti. Experience with rate control mechanisms for packet
video in the Internet, Computer Communication Review, ACM, January 1998, Vol. 28, No. 1;
pp.4-15.
[Bosz02]
L. Böszörményi, M. Döller, H. Hellwagner, H. Kosch et al. Comprehensive
treatment of adaptation in distributed multimedia systems in the ADMITS project. In
Proceedings of the 10th ACM international conference on Multimedia, December 1-6, 2002,
Juan Les pins, France, pp. 429-430. ISBN: 1-58113-620-X.
[Bosz03]
L. Böszörményi, H. Hellwagner, H. Kosch et al. Metadata Driven
Adaptation in the ADMITS Project. EURASIP Signal Processing: Image Communication
Journal (Special Issue on Multimedia Adaptation), Sept. 2003, Vol. 18, No. 8 pp. 749-766.
[Box00]
D. Box, D. Ehnebuske, G. Kakivaya et al. Simple Object Access Protocol
(SOAP) 1.1. Tech. rep., W3C Note, 08 May 2000.
218
[Brown96]
Bibliography.
J.P. Brown. The Stick-e Document: a Framework for Creating Context-
Aware Applications. In Proceedings of Electronic Publishing (EP’96), 1996, Palo Alto, pp.
259-272.
[Brown97]
P.J Brown, J.D. Bovey, X. Chen. Context-Aware Applications: From the
Laboratory to the Marketplace. IEEE Personal Communications, Oct. 1997, Vol. 4, No. 5,
pp.58-64.
[Buch03]
S. Buchholz, A. Schill. Adaptation-Aware Web Caching: Caching in the
Future Pervasive Web. In 13th GI/ITG Conference Kommunikation in verteilten Systemen
(KiVS), Feb. 25.-28, 2003, Leipzig, Germany, pp. 55-66.
[Burn03]
I. Burnett, R. Van de Walle, K. Hill et al. MPEG-21: Goals and
Achievements. IEEE Multimedia, October-December 2003, Vol.10, No.4, pp.60-70.
[Bust01]
F. E. Bustamante. The Active Streams Approach to Adaptive Distributed
Applications and Services. Ph.D. Thesis. Atlanta, GA: Georgia Institute of Technology,
November 2001, 112 p.
[Cabral04]
L. Cabral, J. Domingue, E. Motta et al. Approaches to Semantic Web
Services: An Overview and Comparisons. In Lecture Notes in Computer Science Volume
3053: Proceedings of the First European Semantic Web Symposium (ESWS2004); 10-12
May 2004, Heraklion, Crete, Greece, Berlin / Heidelberg: Springer, pp. 225-239. ISBN:
978-
3-540-21999-6.
[Carde03]
V. Cardellini, M. Colajanni, R. Lancellotti et al. A distributed architecture
of edge proxy servers for cooperative transcoding. In Proc. of 3rd IEEE Workshop on Internet
Applications, June 2003, San Jose, CA, pp. 66–70.
[Carden05]
Y. Cardenas, J. Pierson, L. Brunie. Uniform Distributed Cache Service for
Grid Computing. In Sixteenth International Workshop on Database and Expert Systems
Applications (DEXA 2005), IEEE ed. Copenhagen, Denmark. pp. 351-355.
[Casati00]
F. Casati, S. Ilnicki, and L. Jin. Adaptive and dynamic service composition
in EFlow. In Lecture Notes in Computer Science, Vol. 1789: Proceedings of the 12th
International Conference on Advanced Information Systems Engineering (CAiSE), June
2000, Stockholm, Sweden, London (UK): Springer Verlag pp. 13-31. ISBN: 3-540-67630-9.
[Casati01]
F.Casati, M.Sayal, and M.-C.Shan. Developing e-services for composing e-
services. In Proceedings of the 13th International Conference on Advanced Information
Systems Engineering (CAiSE), June 2001, Interlaken, Switzerland, pp.171-186.
[Chaari05]
T Chaari, F. Laforest. SEFAGI: Simple Environment For Adaptable
Graphical Interfaces -Generating user interfaces for different kinds of terminals. In
Bibliography
219
Proceedings of the Seventh International Conference on Enterprise Information Systems
(ICEIS), 25-28 May 2005, Miami, USA, pp. 232-237. ISBN 972-8865-19-8.
[Chaari06]
T. Chaari, D. Ejigu, F. Laforest et al. Modeling and using context in
adapting applications to pervasive enviroments. In Proceedings of the IEEE International
Conference on Pervasive Services (ICPS’06), 26-29 June 2006, Lyon, France, pp.111-120.
[Chandra00]
S. Chandra, C.S. Ellis, A. Vahdat. Differentiated Multimedia Web Services
Using Quality Aware Transcoding. 19th Annual Joint Conference of the IEEE Computer and
Communication Societies (INFOCOM 2000), Mar. 2000, Tel Aviv, Israel, pp. 961–969.
[Chandra99]
S. Chandra and C.S. Ellis. JPEG Compression Metric as a Quality Aware
Image Transcoding. In 2nd Usenix Symposium on Internet Technologies and Systems
(USITS ’99), Oct. 1999, Berkeley, CA, USA, pp.81-92.
[Chang02]
C.-Y. Chang and M.-S. Chen. Exploring Aggregate effect with weighted
transcoding graphs for efficient cache replacement in transcoding proxies. In Proceedings of
the 18th IEEE International Conference on Data Engineering (ICDE-02), February 26 - March
1 2002, San Jose, CA, USA, pp. 383-392.
[Cheng02]
S.-W. Cheng, D. Garlan, B. R. Schmerl et al. Software architecture-based
adaptation for pervasive systems. In Lecture Notes In Computer Science, Vol. 2299:
Proceedings of the International Conference on Architecture of Computing Systems: Trends
in Network and Pervasive Computing, London, UK: Springer-Verlag, 2002, pp. 67-82. ISBN:
3-540-43409-7.
[Chi02]
C.-H. Chi, Y. Cao, and T. Luo. Scalable Multimedia Content Delivery on
Internet. In Proceedings 2002 IEEE International Conference on Multimedia and Expo
(ICME’02), August 2002, Lusanne, Switzerland, Vol. 1, pp. 1-4. ISBN: 0-7803-7304-9.
[Chinnici03]
R. Chinnici, M. Gudin, J. Moreau et al. Web Services Description
Language (WSDL) [on line], Version 1.2. W3C Working Draft 24 January 2003. Available
on: <http://www.w3.org/TR/wsdl/> (accessed on June 2003).
[Chris99]
L. Christianson and K. Brown. Rate Adaptation for Improved Audio
Quality in Wireless Networks, 1999 IEEE International Workshop on Mobile Multimedia
Communications (MoMuC’99), November 15-17, 1999, San Diego, CA, pp. 363-367.
[Cooltown]
Cooltown (HP) [on line]. Available on: <http://www.cooltown.hp.com>.
(Accessed on 21 May 2003).
[Cowan95]
C. Cowan, S. Cen, J. Walpole et al. Adaptive methods for distributed video
presentation. In ACM Computing Surveys, Special Issue on Multimedia Systems Symposium on Multimedia, December 1995, Vol. 27, No. 4, pp. 580-583.
220
Bibliography.
[Day02]
N. Day and J. M. Martinez. Introduction to MPEG-7 (v4.0). ISO/IEC
JTC1/SC29/WG11 N4675. MPEG Requirements Group, Jeju, March 2002.
[Dean02]
M. Dean, D. Connoly, F. Harmelen et al. Web Ontology Language (OWL)
Reference Version 1.0 Recent Trends and Developments [on line]. W3C Working Draft 12
November 2002. Available on: <http://www.w3.org/TR/2002/WD-owl-ref-20021112/>
(Accessed on 15 October 2003).
[Demp97]
L. Dempsey, R. Russell and R. Heery. In at the shallow end: metadata and
cross-domain resource discovery, In Discovering online resources across the humanities: a
practical implementation of the Dublin Core, Paul Miller and Daniel Greenstein, eds. Bath:
UKOLN on behalf of the Arts and Humanities Data Service, 1997, pp. 63-71. ISBN 09516856-4-3.
[Dey01]
A. K. Dey. Understanding and Using Context. Personal and Ubiquitous
Computing Journal, 2001, Vol. 5, No. 1, pp. 4-7.
[Dey98]
A.K Dey. Context-Aware Computing: The CyberDesk Project. AAAI 1998
Spring Symposium on Intelligent Environments, Technical Report SS-98-02, 1998, pp. 51-54.
A.K. Dey, G.D. Abowd and P. J. Brown. Towards a Better Understanding
[Dey99a]
of Context and Context-Awareness. In Lecture Notes in Computer Science Vol. 1707: In
Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing
(HUC’99), 27-29 Sept. 1999, Karlsruhe, Germany, pp. 304-307.
[Dey99b]
A.K. Dey, G.D Abowd, A. Wood. CyberDesk: A Framework for Providing
Self-Integrating Context-Aware Services. Knowledge-Based Systems, 1999, Vol. 11, pp. 313.
[DICOM01]
The Digital Imaging and Communications in Medicine (DICOM) Standard
Part 1-16 [on line]. Published by National Electrical Manufactures Association, 1300 N. 17th
Street,
Rosslyn,
Virginia
22209
USA,
2001.
Avaialble
on:
<http://medical.nema.org/dicom/2001.html>. (Accessed on 16 May 2004).
[Dijkstra59]
E. W. Dijkstra. A note on two problems in connection with graphs. Journal
of NumerMath, 1959, Vol. 1, pp. 269-271.
[Dogan04]
S. Dogan, S. Eminsoy, A. H. Sadka et al. Video Content Adaptation Using
Transcoding for Enabling UMA over UMTS. 5th Workshop on Image Analysis for
Multimedia Interactive Services, April 21-23, 2004, Instituto Superior Técnico, Lisboa,
Portugal.
Bibliography
[Dublin99]
221
Dublin Core. The Dublin Core: A Simple Content Description Model for
Electronic Resources [on line]. 1999. Available on: <http://purl.oclc.org/dc/>. (Accessed on
13 October 2004).
[EasyLiving]
EasyLiving
(Microsoft)
[on
line].
Available
on:
<http://www.research.microsoft.com/easyliving>. (Accessed on 21 May 2003).
[Elson01]
J. Elson, A. Cerpa. ICAP the Internet Content Adaptation Protocol [on
line]. Internet Draft, The ICAP Protocol Group, Jun 2001. Available on: <http://www.icap.
org/spec/icap_specification.txt>. (Accessed on 20 February 2003).
[Esler99]
M. Esler, J. Hightower, T. Anderson et al. Next Century Challenges: Data-
Centric Networking for Invisible Computing: The Portolano Project at the University of
Washington. In Proceedings of the 5th annual ACM/IEEE international conference on Mobile
computing and networking (MOBICOM'99), August 1999, Seattle, Washington, pp.256-262.
ISBN: 1-58113-142-9.
[Fensel02]
D. Fensel and C. Bussler. The Web Service Mode ling Framework WSMF.
In Proceeding of the NSF-EU Workshop on Database and Information Systems Research for
Semantic Web and Enterprises, April 2002, Georgia, USA, pp. 15-20.
[Fisher97]
B. Fisher, G. Agelidis, J. Dill et al. CZWeb: Fish-Eye Views for
Visualizing the World-Wide Web. Proc. of the 7th Int. Conf. on Human-Computer Interaction
(HCI International '97), 1997, Elsevier, Amsterdam, pp. 719-722.
[Flory06]
A. Flory, C. Verdier, S SASSI. Nouvelles Interfaces pour la représentation
de l'information médicale. In INFORSID 2006 (Systèmes d’information et services web), june
2006, Hammamet Tunisia.
[Foster99]
Foster and C. Kesselman (editors). The Grid Blueprint for a New
Computing Infrastructure. San Francisco, CA: Morgan Kaufmann Publishers Inc., 1999, 701
p. ISBN: 1558604758.
[Fox97]
A. Fox, S. D. Gribble, Y. Chawathe et al. Cluster-Based Scalable Network
Services. In Proc. of the 16th ACM Symposium on Operating System Principles, October
1997, Saint Malo, France, pp. 78–91.
[Fox96]
A. Fox, S. Gribble, E. Brewer, E. Amir. Adapting to Network and Client
Variation via On-Demand, Dynamic Distillation. In Proceedings ASPLOS-VII, October 1996,
Cambridge, MA, USA, pp. 160-170.
[Fox98a]
A. Fox, I. Goldberg, S. Gribble et al. Experience with TopGun Wingman:
A Proxy-Based Web Browser for the 3Com PalmPilot. In Proceedings of the IFIP
222
Bibliography.
International Conference on Distributed Systems Platforms and Open Distributed Processing
(Middleware ’98), Sept. 1998, Lake District, England, pp.407-426.
[Fox98b]
A. Fox, S. Gribble, Y. Chawathe et al. Adapting to Network and Client
Variation Using Infrastructural Proxies: Lessons and Perspectives. IEEE Personal
Communications, Special Issue on Adaptation, 1998, Vol.5, No. 4, pp. 10-19.
[Gaia]
Gaia (UIUC). [on line] Available on: <http://gaia.cs.uiuc.edu/>. (Accessed
on 21 May 2003).
[Gard01]
T. Gardner. An Introduction to Web Services [on line]. 02-October-2001.
Available on <http://www.ariadne.ac.uk/issue29/gardner/intro.html> (accessed on June 2004).
[Garl02]
D. Garlan, D. Siewiorek, A. Smailagic et al. Project Aura: Toward
Distraction-Free Pervasive Computing. IEEE Pervasive Computing, special Issue on
Integrated Computing Environments, April-June 2002, Vol.1, No.2, pp. 22-31. ISSN 15361268.
[Geld04]
M. Geldof. The Semantic Grid: will Semantic Web and Grid go hand in
hand? European Commission DG Information Society Unit “Grid technologies”, June 2004.
[Goeb01]
S. Goebel, S. Buchholz, T. Ziegert et al. Device Independent
Representation of Web-based Dialogs and Contents. In: Proceedings of the IEEE Youth
Forum in Computer Science and Engineering (YUFORIC'01), 2001, Valencia, Spain.
[Goff04]
M. K. Goff. The Scope of Network Distributed Computing [on line].
Chapter 3. In: Network Distributed Computing: Fitscapes and Fallacies, 27 February 2004.
Available
on:
<http://www.informit.com/content/images/0131001523/samplechapter/0131001523_ch03.pdf
>. (Accessed on December 7, 2005).
[Gribb01]
S. D. Gribble, M. Welsh, R. Behren et al. The Ninja architecture for robust
Internet-scale systems and services. Journal of Computer Networks, March 2001, Vol. 35, No.
4, pp. 473-497.
[Gross00]
H. Grosskreutz, G. Lakemeyer: cc-Golog: Towards More Realistic Logic-
Based Robot Controllers. In Proc. of the Seventeenth National Conference on Artificial
Intelligence and Twelfth Conference on Innovative Applications of Artificial Intelligence,
July 30 - August 3, 2000, Austin, Texas, USA. AAAI Press / The MIT Press, 2000, pp. p.476482. ISBN 0-262-51112-6.
[Grub95]
T. R. Gruber. Toward principles for the design of ontologies used for
knowledge sharing. International Journal of Human-Computer Studies, 1995, vol. 43, pp. 907928.
Bibliography
[Han98]
223
R. Han, P. Bhagwat, R. LaMaire et al. Dynamic adaptation in an image
transcoding proxy for mobile Web browsing. IEEE Personal communications, Dec. 1998,
Vol. 5, No. 6, pp. 8–17.
[Held02]
A. Held, S. Buchholz, A. Schill. Modeling of Context Information for
Pervasive Computing Applications. In Proceedings of the 6th World Multiconference on
Systemics, Cybernetics and Informatics (SCI), July 2002, Orlando, FL, USA.
[Hill03]
D. Hillmann. Using Dublin Core [on line]. 2003. available on
http://dublincore.org/documents/usageguide/ (Accessed on Dec. 7, 2004).
[Hori00]
M. Hori, G. Kondoh, and K. Ono. Annotation-based web content
transcoding. In Proceedings of the Ninth International World Wide Web Conference, May 1519 2000, Netherlands, Amsterdam, pp. 197—211.
[Horr02]
I. Horrocks. DAML+OIL: a reason-able web ontology language. Proc.
Intern. Conf. on Advances in Database Technology (EDBT), March 2002, Prague, Czech
Republic, pp. 2-13.
[Henr01]
K. Henricksen K, J. Indulska J, A. Rakotonirainy. Infrastructure for
Pervasive computing: Challenges. In Proceedings of Workshop on Pervasive Computing
INFORMATIK 01, Viena, September 2001.
[Hous96]
B. C. Housel and D. B. Lindquist. WebExpress: A System for Optimizing
Web Browsing in a Wireless Environment. In Proceedings of ACM/IEEE of the Second
Annual International Conference on Mobile Computing and Networking (MobiCom '96),
November 1996, Rye, New York, pp. 108—116.
[Huan04]
J.L. Huang, M.S. Chen and H.P. Hung. A QoS- Aware Transcoding Proxy
Using On-demand Data Broadcasting. In Proceedings IEEE INFOCOM 2004, The 23rd
Annual Joint Conference of the IEEE Computer and Communications Societies, 7-11 March
2004, Hong Kong, China.
[Hunt98]
J. Hunter, R. Iannella. The Application of Metadata Standards to Video
Indexing. In Proceedings of Second European Conference on Research and Advanced
Technology for Digital Libraries ECDL'98, 19 - 23 September, 1998, Crete, Greece.
[Hutter05]
A. Hutter, P. Amon, G. Panis et al. Automatic Adaptation of Streaming
Multimedia Content in A Dynamic and Distributed Environment. Proceedings of the IEEE
Int’l Conference on Image Processing (ICIP 2005 2005), 11-14 Sept. 2005, Genova, Italy, pp.
716-719.
[IBM00]
2000.
IBM Inc. Internet Transcoding for Universall Access [on line]. September
Available
on:
224
Bibliography.
<http://www.research.ibm.com/networked_data_systems/transcoding/index.html>. (Accessed
on 10 January 2004).
[IBMPC]
IBM Pervasive Computing [on line]. Available on: <http://www-
3.ibm.com/pvc/pervasive.shtml> (Accessed on 11 October 2003).
[IBMTR]
IBM Think Research: Pervasive Computing [on line]. Available on:
<http://www.research.ibm.com/thinkresearch/pervasive.shtml>. (Accessed on 10 October
2003).
[IBMWS]
IBM Web services tutorial [on line]. Available on: <http://www-
106.ibm.com/developerworks/webservices/> (Accessed on 10 October 2003).
[Ihde01]
S.C. Ihde, P.P. Maglio, J. Meyer et al. Intermediary-based transcoding
framework. IBM Systems Journal 2001, Vol. 40, No. 1, pp. 179-192.
[Inou97]
J. Inouye., S. Cen, C. Pu et al. System Support for mobile multimedia
Applications. In Proc. 7th Intl. Workshop on Network and Operating Systems Support for
Digital Audio and Video (NOSSDAV '97), May 1997, St. Louis, Missouri, USA, pp. 143154.
[Intel]
Intel
QuickWeb
[on
line].
Available
on:
<http://www.intel.com/quickweb>. (Accessed on 22 May 2003).
[Ipiqa01]
Diego Lspez de Ipiqa, Sai-Lai Lo. Sentient Computing for Everyone. In
Proceedings of the The Third IFIP WG 6.1 International Working Conference on Distributed
Applications and Interoperable Systems (DAIS'2001), 17-19 September, 2001, Krakow,
Poland, pp. 41-54.
[ISO03]
ISO 2003. Information and documentation — The Dublin Core metadata
element set. ISO 15836:2003 (E) [on line]. 23 February 2003. Available on:
<http://www.niso.org/international/SC4/n515.pdf>. (Accessed on 17 October 2004).
[ISO04]
ISO/IEC 21000-7:2004. Information technology — Multimedia framework
(MPEG-21) — Part 7: Digital Item Adaptation, First Edition, October 2004.
[ITMF03]
ISO/IEC 21000-2:2003. Information Technology-Multimedia Framework
(MPEG-21)-Part 2: Digital Item Declaration, March, 2003.
[Jaco97]
S.Jacobs and A.Eleftheriadis. Real-time dynamic rate shaping and control
for internet video applications. In Proceedings of Workshop on Multimedia Signal Processing,
June 23-25 1997, Princeton, NJ, pp. 23-25.
[Jaza02]
M. Jazayeri. On the way to pervasive computing. In Proceedings of XVI
Brazilian Symposium on Software Engineering (SBES'2002), 16-18 October, 2002, Rio
Grande do Sul – Brazil.
Bibliography
[Joshi00]
225
A. Joshi. On proxy agents, mobility and web access. ACM/Baltzer Journal
of Mobile Networks and Applications, 2000, Vol. 5, No. 4, pp. 233-241.
[Kazai03]
G. Kazai, M. Lalmas, M-L. Bourguet et al. Using Metadata to Provide
Scalable Broadcast and Internet Content and Services. Proceedings of the 4th European
Workshop on Image Analysis for Multimedia Interactive Services (WIAMIS 2003), April
2003, London, pp. 487-492.
[Kim03]
J.-G. Kim, Y. Wang, and S.-F. Chang. Content-adaptive utility-based video
adaptation. In Proc. of IEEE Int'l Conference on Multimedia & Expo (ICME), July 6-9, 2003,
Baltimore, MD, pp. 281-284.
[Kist92]
J. Kistler and M.Satyanarayanan. Disconnected Operation in the Coda File
System. ACM Transcations on Computers, Vol.10, No.1, Feb. 1992, pp. 3-25.
[Klyne01]
G.
Klyne,
F.
Reynolds,
C.
Woodrow
et
al.
Composite
Capability/Preference Profiles (CC/PP): Structure and Vocabularies. W3C Working Draft [on
line]. Mar 15, 2001. Available on: <http://www.w3.org/TR/2001/ WD-CCPP-struct-vocab20010315/>. (Accessed on 18 October 2003).
[Klyne99]
G. Klyne. A Syntax for Describing Media Feature Sets. RFC 2533 [on
line]. Mar 1999. Available on <: http://www.faqs.org/rfcs/rfc2533.html>. (Accessed on 19
octobre 2003).
[Kosch03]
H. Kosch. Distributed Multimedia Database Technologies supported by
MPEG-7 and MPEG-21. CRC Press LLC, November 2003, 248 p. ISBN: 0849318548.
[Kumar93]
P. Kumar and M.Satyanarayanan. Supporting Application-Specific
Resolution in an Optimistically Replicated File System. In Proceedings of the 4th Workshop
on Workstation Operating systems, October 1993, Napa, CA, pp. 66-70.
[Kumar95]
P. Kumar and M.Satyanarayanan. Flexible and Safe Resolution of File
Conflicts. In Proceedings of the 1995 Winter Usenix Conference, January 1995, New Orleans,
LA, pp. 95-106.
[Kwan02]
W. M. Kwan. A Distributed Proxy System for Functionality Adaptation in
Pervasive Computing Environments. Master’s Thesis, Department of Computer Science and
Information Systems, The University of Hong Kong, August 2002.
[Lass99]
O. Lassila, R. Swick. Resource Description Framework (RDF) Model and
Syntax Specification. W3C Recommendation [on mine]. Feb 22, 1999. Available on:
<http://www.w3.org/TR/1999/REC-rdf-syntax- 19990222/>. (Accessed on 20 October 2003).
[Lee01]
S. J. Lee, W. Y. Ma, and B. Shen. Interactive video caching and delivery
using video abstraction and summarization. Proc. International Workshop on Web Caching
226
Bibliography.
and Content Distribution (WCW’01), 20-22 June 2001, Boston University, Boston,
Massachusetts, USA.
[Lee03]
D. G. Lee, D. Panigrahi, and S. Dey. Network-Aware Image Data Shaping
for Low-Latency and Energy-Efficient Data Services over the Palm Wireless Network. In
Proc. of World Wireless Congress (3G Wireless Conference), 27-30 May 2003, San Francisco
/ Silicon Valley, U.S.A.
[Lei01a]
Z. Lei and N.D. Georganas. Context-based Media Adaptation in Pervasive
Computing. In Proc. of Canadian Conference on Electrical and Computer Engineering
(CCECE), Toronto, May 2001.
[Lei01b]
Z. Lei. Media transcoding for pervasive computing. ACM Press: Vol. 9. In
Proceedings of the ninth ACM international conference on Multimedia, 2001, Ottawa,
Canada, pp. 459-460. ISBN: 1-58113-394-4.
[Lein04]
B.M.Leiner, V.G.Cerf, D.D.Clark, et al. A Brief History of the Internet, 10
Dec 2003 [on line]. Available on <http://www.isoc.org/internet/history/brief.shtml>
(Accessed on January 2004)
[Leml01]
T. Lemlouma and N. Layaïda. A Framework for Media Resource
Manipulation in an Adaptation and Negotiation Architecture. Research Report, Opéra Project,
INRIA Rhône Alpes, August 2001.
[Leml02]
T. Lemlouma, N. Layaïda. Universal Profiling for Content Negotiation and
Adaptation in Heterogeneous Environments. W3C Workshop on Delivery Context, 4-5 March
2002, W3C/INRIA Sophia-Antipolis, France.
[Leml03]
T. Lemlouma and N. Layaïda. SMIL Content Adaptation for Embedded
Devices. SMIL Europe 2003, Paris, February 12-14, 2003.
[Leml04]
T. Lemlouma. Architecture de Négociation et d'Adaptation de Services
MultiMedia dans des Environnements Hétérogènes. PhD Thesis defended on June 9, 2004,
INPG, Grenoble, France.
[Leve97]
H.J Levesque, R. Reiter, Y. Lesperance et al. GOLOG: A logic
programming language for dynamic domains. Journal of Logic Programming, 1997, Vol. 31,
No.1-3, pp. 59-83.
[Leym01]
F. Leymann. Web Services Flow Language (WSFL 1.0) [on line].
Technical report, 2001. Available on: <http://www.ibm.com/software/solutions/webservices/
pdf/WSFL.pdf> (Accessed on 11 June 2004).
[Libsie04]
M. Libsie. Metadata Supported Content Adaptation in Distributed
Multimedia Systems. PhD thesis, defended on June 2004, University Klagenfurt Austria.
Bibliography
[Lilj95]
227
M. Liljeberg, T. Alanko, M. Kojo et al. Optimizing World-Wide Web for
Weakly Connected Mobile Workstations: An Indirect Approach. In Proc. 2nd International
Workshop on Services in Distributed and Networked Environments (SDNE'95) 5-6 June
1995, Whistler, Canada, pp. 132-139. ISBN: 0-8186-7092-4.
[List02]
C.List. Information Research. 2nd edition, Dubuque, IA: Kendall/Hunt
Publishing Co.2002. Located in the Reserve Room at Moon Library - Call Number Reserve Z
711.2 .L57 2002.
[Lomo04]
G. Lomow and E. Newcomer. Introduction to SOA with Web Services. In:
E. Newcomer and G. Lomow. Understanding SOA with Web Services (Independent
Technology Guides). Addison-Wesley Professional Sample Chapter is provided courtesy of
Addison Wesley Professional, 2004, 480 p. ISBN: 0321180860.
[Lu99]
G. Lu. Multimedia Database Management Systems. Boston/London:
Artech House Publishers, 1999, 373 p. ISBN: 0-89006-342-7.
[Lum02a]
W.-Y. Lum and F.C.M. Lau. A context-aware decision engine for content
adaptation. IEEE Pervasive Computing, July-September 2002, Vol.1 No. 3, pp. 41-49.
[Lum02b]
W.-Y. Lum and F.C.M. Lau. On balancing between transcoding overhead
and spatial consumption in content adaptation. Proc. of ACM Mobicom 2002, Sept. 2002,
Atlanta, USA, pp. 239-250.
[Ma00]
W.-Y. Ma, I. Bedner, G. Chang et al. A Framework for Adaptive Content
Delivery in Heterogeneous Network Environments. In Proceedings of Multimedia Computing
and Networking (MMCN'00), 2000, San Jose, California, USA, pp.86-100.
[Maga04]
J. Magalhães, F. Pereira. Using MPEG standards for multimedia
customization. Signal Processing: Image Communication, 2004, Vol. 19, No. 5, pp. 437-456.
ISSN 0923-5965.
[Mahe02]
A. Maheshwari, A. Sharma, K. Ramamritham et al. TranSquid:
Transcoding and Caching Proxy for Heterogeneous E-Commerce Environments. In
Proceedings of the 12th IEEE Workshop on Research Issues in Data Engineering (RIDE ’02),
Feb. 2002, San Jose, CA. pp. 50-59.
[Manj02]
B. Manjunath, P. Salembier, and T. Sikora. Introduction to MPEG 7:
Multimedia Content Description Language. Ed. John Wiley and Sons, Ltd, 2002, West
Sussex, England, p. 352. ISBN: 0471486787.
[Manu04]
K. Manuel. Information Literacy Textbook [on line]. Printed 12/13/2004.
On
line
Textbook.
Available
on:
228
Bibliography.
<http://lib.nmsu.edu/instruction/lsc311/textbook/information.pdf>
(Accessed
on
10
September 2005).
[Marg01]
M. Margaritidis and G.C. Polyzos. Adaptation Techniques for Ubiquitous
Internet Multimedia. Wireless Communications and Mobile Computing, 2001, John Wiley &
Sons, Vol. 1, No. 2, pp. 141-164.
[Marr02]
K. Marriott, B. Meyer, and L. Tardif. Fast and Efficient client-Side
Adaptivity for SVG. ACM Press, 2002: In Proc. of WWW 2002, May 2002, Honolulu,
Hawaii, USA, pp. 496–507.
[Mart02]
J. M. Martínez, R. Koenen and F. Pereira. MPEG-7: the generic
multimedia content description standard. (part 1) IEEE Multimedia, 9 (2), April-June 2002,
pp. 78-87.
[Mart03]
J. M. Martínez. MPEG-7 Overview. ISO/IEC JTC1/SC29/WG11 N5525,
March 2003.
[McCan97]
S.McCanne, M. Vetterli, and V. Jacobson. Low-complexity video coding
for receiver-driven layered multicast. IEEE JSAC, August 1997, Vol.16, No.6, pp. 983-1001.
[McDe00a]
D.McDermott. The 1998 AI planning systems competition. AI Magazine,
2000, Vol. 21, No.2, pp. 35-55.
[McDe00b]
D. McDermott. Estimated-Regression Planning for Interactions with Web
Services. Proceedings of the AI Planning Systems Conference (AIPS'02), June 2002.
[McIl02]
S. McIlraith and T. C. Son. Adapting Golog for composition of Semantic
Web services. In Proceedings of the 8th International Conference on Knowledge
Representation and Reasoning (KR2002), April 2002, Toulouse, France, pp. 482-493.
[MDS03]
MPEG MDS Group, MPEG-21 Multimedia Framework-Part 7: Digital
Item Adaptation (final Committee Draft) ISO/MPEG N5845, July 2003.
[Medj03]
B. Medjahed, A. Bouguettaya, and A. K. Elmagarmid. Composing Web
services on the Semantic Web. The VLDB, November 2003, Journal Vol. 12, No.4, pp. 333351.
[MFTR05]
Media Feature Tags Registry (last updated November 2005) [on line].
Available on: http://www.iana.org/assignments/media-feature-tags (Accessed on 14 October
2004).
[Milan04]
N. Milanovic, M. Malek. Current Solutions for Web Service Composition.
IEEE Internet Computing, November 2004, Vol.8, No.6, pp.51-59.
Bibliography
[Mobi02]
229
MobiXtar Rich Media Service Center. [on line]. April 5, 2002. Available
on: <http://products.datamation.com/wireless/dt/1017134171.html>. (Accessed on 23 October
2003).
[Mogul01]
J.C. Mogul. Server-Directed Transcoding. Computer Communications,
Feb. 2001, Vol. 24, No.2, pp.155-162.
[Mohan99]
R. Mohan, J.R. Smith and C.S. Li. Adapting Multimedia Internet Content
for Universal Access. IEEE Trans. on Multimedia, 1999, Vol. 1, No. 1, pp.104–114.
[More84]
R. Moreau. The Computer Comes of Age: The People, the Hardware, and
the Software, translated by J. Howlett (Cambridge: MIT Press, 1984).
[Morphis]
Morphis Open Source Java Wireless Content Transcoder [on line].
Available on: <http://www.morphis.org/>. (Accessed on 26 October 2003).
[Mosch99]
C.J.P. Moschovitis, H. Poole, T.Schuyler et al. History of the Internet: A
Chronology, 1843 to the Present. ABC-Clio 1999. ISBN 1576071189.
[Motta03]
E. Motta, J. Domingue, L. Cabral, and M. Gaspari. IRS-II: A Framework
and Infrastructure for Semantic Web Services. In Lecture Notes in Computer Science: Vol
2870: In Proceedings of the International Semantic Web Conference, October 2003, Sanibel
Island, FL, USA, Springer Verlag, pp. 306-318.
[Mumm95]
L.
Mummert,
M.
Ebling,
M.Satyanarayanan.
Exploiting
Weak
Connectivity for Mobile File Access. Symposium on Operating System Principles, December
1995, Copper Mountain, Colorado, pp. 143-155.
[Nagao01]
K. Nagao, Y. Shirai, and K. Squire. Semantic annotation and transcoding:
Making web content more accessible. IEEE Multimedia, April-June 2001, pp. 69--81.
[Nand99]
T. Nandagopal, TE. Kim, P Sinha. Et al. Service Differentiation Through
End-to-End Rate Control in Low Bandwidth Wirless Packet Networks. Proceedings of the 6th
International Workshop on Mobile Multimedia Communications; November 1999, San
Diego, CA, USA.
[Nau99]
D. S. Nau, Y. Cao, A. Lotem et al. SHOP: Simple hierarchical ordered
planner. In Thomas Dean, editor, Proceedings of the International Joint Conference on
Artificial Intelligence (IJCAI). Morgan Kaufmann Publishers, July 31–August 6 1999, pp.
968–973.
[NISO04]
National Information Standards Organization (NISO). Understanding
Metadata. NISO Press 2004, Bethesda, MD, USA, p.1.
[Noble00]
B. Noble. System Support for Mobile, Adaptive Applications. IEEE
Personal Communications, February 2000.
230
Bibliography.
[Noble95]
B.D. Noble, M. Price, and M. Satyanarayanan. A programming Interface
for Application Aware adaptation in mobile computing. Proceedings of the Second USENIX
Symposium on Mobile and Location-Independent Computing, Apr 1995, Ann Arbor, MI,
USA.
[Noble97]
B.D. Noble, M. Satyanarayanan, D. Narayanana et al. Agile application-
aware adaptation for mobility. In Proceedings of the 16th ACM Symposium on Operating
Systems Principles, December 1997, Vol. 31, No. 5, pp. 276-287.
[Norm98]
D.A. Norman. The invisible computing. Cambrideg, MA, MIT Press, 1998.
[OMG02]
Object Management Group. The Common Object Request Broker
Architecture (CORBA): Core Specification. Revision 3.0.2. OMG Document Technical
Report formal/2002-12-02, Object Management Group, Dec. 2002, Framingham, MA, USA.
[OnLine]
OnLineAnywhere
[on
line].
Available
on:
<http://www.onlineanywhere.com>. (Accessed on 28 May 2003).
[Ooi01]
W. T. Ooi, R. v. Renesse. Distributing Media Transformation Over
Multiple Media Gateways. In Proceedings of the 9th ACM International Multimedia
Conference, September 2001, Ottawa, Canada, pp. 159-168.
[Opera04]
Opera press release. The Web adapted to every screen size: Opera solves
the problem of rendering Web content on medium-sized screens [on line]. Jan. 20, 2004.
Available on: <http://www.opera.com/pressreleases/en/2004/01/20/> (Accessed on 9 July
2004).
[Oracle03]
White
Oracle Application Server Wireless: Complete Mobile Platform. Technical
Paper
[on
line].
August
2003.
Available
on:
<http://www.otn.oracle.com/products/iaswe/OracleAS_Wireless_Enterprises_TWP.pdf>
(Accessed on 27 July 2004).
[Ort05]
E. Ort. Service-Oriented Architecture and Web Services: Concepts,
Technologies, and Tools. Sun Microsystems, April 2005.
[Orte97]
A. Ortega, F. Carignano, S. Ayer, et al. Soft Caching: Web cache
management techniques for image. In IEEE Signal Processing Society Workshop on
Multimedia Signal Processing, June 23-25, 1997, Princeton, New Jersey, USA, pp. 475-480.
[Oxygen]
Oxygen (MIT) [on line]. Available on: <http://oxygen.lcs.mit.edu>
(Accessed on 23 May 2003).
[Paol02]
M. Paolucci, T. Kawamura, T. R. Payne et al. Semantic matching of web
services capabilities. In First International Semantic Web Conference, June 2002, Sardinia,
Italy, pp. 333-347.
Bibliography
[Pascoe98]
231
J. Pascoe. Adding Generic Contextual Capabilities to Wearable Computers.
2nd International Symposium on Wearable Computers, 1998, Pittsburgh, PA, USA, pp. 9299. ISBN 0-8186-9074-7.
[Peak98]
S. Peak and J. R. Smith. Detecting Image Purpose in World-Wide Web
Documents. Symposium on Electronic Imaging: Science and Technology - Document
Recognition, IS&T/SPIE, 1998, p. 151-158.
[Pere05]
F. Pereira. Content and Context: Two worlds to bridge. In Int. Workshop
on Content-Based Multimedia Indexing, CBMI'2005, June 2005, Riga.
[Perk01]
A. Perkis, Y. Abdeljaoued, C. Christopoulos, et al. Universal multimedia
access from wired and wireless systems. Transactions on Circuits, Systems and Signal
Processing, Birkhauser Boston, 2001, Vol. 10, No. 3, pp. 387-402.
[Portolano]
Portolano
(University
of
Washington)
[on
line].
Available
on:
<http://www.cs.washington.edu/research/portolano> (Accessed on 27 May 2003).
[ProxiNet]
ProxiNet [on line]. Available on: <http://www.proxinet.com>. (Accessed
on 27 July 2004).
[Ramos05]
A. Carrillo Ramos, J. Gensel, M. Villanova-Oliver, H. Martin. PUMAS: a
Framework based on Ubiquitous Agents for Accessing Web Information Systems through
Mobile Devices. 20th Annual ACM Symposium on Applied Computing - Handheld
Computing (SAC2005), March 13 -17, 2005, Santa Fe, New Mexico. ACM Press, New York,
NY, 2005, Vol. 2, pp 1003-1008.
[Rao04]
Jinghai Rao, Xiaomeng Su: A Survey of Automated Web Service
Composition Methods. Semantic Web Services and Web Process Composition (SWSWPC),
First International Workshop, July 6, 2004, San Diego, CA, USA, pp. 43-54.
[Reim02]
M. Reimer. Design and Implementation of a mobile Personal Health
Monitor. Master thesis. Technische Universität Darmstadt, Dept of Computer Science, 2002.
[Rodd98]
T. Rodden, K. Cheverst, K. Davies et al. Exploiting Context in HCI Design
for Mobile Systems. In Proceedings of the First Workshop on Human Computer Interaction
for Mobile Devices, May 21-23, 1998, Staffordshire University, UK, pp.12-17.
[Rodr01]
J. Rodriguez, B. Dakar, F. L. Marras, et al. Transcoding in WebSphere
Everyplace Suite. Chapter 11. In: New Capabilities in IBM WebSphere Transcoding
Publisher Version 3.5 Extending Web Applications to the Pervasive World. IBM Redbooks
[on
line],
30
May
2001,
446
p.
Available
on:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246233.pdf (Accessed on 16 May 2003).
ISBN 0738421545.
232
[Roure03]
Bibliography.
D. De Roure. Semantic Grid and Pervasive Computing. First GGF
Semantic Grid Workshop at 9th Global Grid Forum (GGF9), October 2003, Chicago, USA.
[Ryan97]
N. Ryan, J. Pascoe, D. Morse. Enhanced Reality Fieldwork: the Context-
Aware Archaeological Assistant. In Gaffney,V., van Leusen, M., Exxon, S. (eds.) Computer
Applications in Archaeology, 1997.
[Saha03]
D. Saha, A. Mukherjee. Pervasive Computing: A Paradigm for the 21st
Century, IEEE Computer, IEEE Computer Society Press, March 2003, pp. 25-31.
[Satya02]
M. Satyanarayanan. Evolution of the Coda File System. To appear in ACM
Trans. Computer Systems, ACM Press, New York, 2002.
[Satya96]
M. Satyanarayanan. Mobile Information Access. IEEE Personal Comm.,
Feb. 1996, Vol. 3, No. 1, pp. 26–33.
[Schi94a]
B. Schilit, M. Theimer. Disseminating Active Map Information to Mobile
Hosts. IEEE Network, 1994, Vol.8 No.5 pp.42-47.
[Schi94b]
B. Schilit, N. Adams, and R. Want. Context-aware computing applications.
In Proceedings of the 1st International Workshop on Mobile Computing Systems and
Applications, 1994.
[Schu00]
H. Schuster, D. Georgakopoulos, A. Cichocki, and D. Baker. Modeling and
composing service-based and reference process-based multi-enterprise processes. In
Proceeding of 12th International Conference on Advanced Information Systems Engineering
(CAiSE), Stockholm, Sweden, June 2000. Springer Verlag.
[Sentient]
Sentient
Computing
[on
line].
Available
on:
http://www.uk.research.att.com/spirit (Accessed on 19 March 2003).
[Shafer98]
Steve Shafer et al. The New EasyLiving Project at Microsoft Research:
Joint DARPA/NIST Smart Spaces Workshop, July 30-31, 1998, Gaithersburg, Marymand.
[Shaha01]
N. Shaha, A. Desai, M. Parashar. Multimedia Content Adaptation for QoS
Management over Heterogeneous Networks. In Proc of International Conference on Internet
Computing 2001, 2001, Nevada, USA, pp. 642-648.
[Shan00]
T. Shanableh and M. Ghanbari. Heterogeneous video transcoding to lower
spatio-temporal resolutions and different encoding formats. IEEE Trans. Multimedia, June
2000, Vol. 2, pp. 101-110.
[Shapiro01]
May 2001.
R. Shapiro. A comparison of XPDL, BPML and BPEL4WS, Cape Visions,
Bibliography
233
[Shen06]
H. Shen, X. Sun, F. Wu et al. Scalable Video Adaptation for IPTV. Internet
Protocol TeleVision (IPTV) workshop in conjunction with WWW '06, May 2006, Edinburgh,
Scotland, United Kingdom.
[Singh04]
A. Singh, A. Trivedi, K. Ramamritham et al. PTC: Proxies that Transcode
and Cache in Heterogeneous Web Client Environments. World Wide Web Journal, 2004, Vol.
7, No. 1, pp. 7-28.
[Sirin04a]
E. Sirin and B. Parsia. Planning for semantic web services. In Semantic
Web Services Workshop at 3rd International Semantic Web Conference (ISWC2004), 2004.
[Sirin04b]
E. Sirin, B. Parsia, D.Wu et al.. HTN planning for web service composition
using SHOP2. Journal of Web Semantics, 2004, Vol. 1, No. 4, pp.377-396.
[Smith00]
J. R. Smith. Interoperable Content-based Access of Multimedia in Digital
Libraries.In Proceedings of the First DELOS Network of Excellence Workshop on
Information Seeking, Searching and Querying in Digital Libraries, 11-12 December 2000
Zurich, Switzerland.
[Smith00]
J. R. Smith and B. Lugeon. A Visual Annotation Tool for Multimedia
Content Description. Proc. SPIE Photonics East, Internet Multimedia Management Systems,
November 2000, Boston, MA, USA, pp. 49-59.
[Smith04]
Language
M. K. Smith, C. Welty and D. L. McGuinness. OWL Web Ontology
Guide.
W3C
Recommendation,
2004
[on
line].
Available
on:
<http://www.w3.org/TR/2004/REC-owl-guide-20040210/> (Accessed on 20 September
2005).
[Smith98a]
J. R. Smith, R. Mohan, C.-S. Li. Content-based Transcoding of Images in
the Internet. In Proceedings of the 1998 IEEE International Conference on Image Processing
(ICIP-98), 4-7 October 1998, Chicago, Illinois. IEEE Computer Society, 1998, Vol. 3, pp. 711. ISBN 0-8186-8821-1.
[Smith98b]
J.R Smith, R.Mohan, C.S. Li. Transcoding Internet Content for
Heterogenouse Client Devices. Proceeedings IEEE International Symposium on Circuits and
Systems (ISCAS), June 1998, Monterey, California, Vol.3, pp. 599-602.
[Smith99]
J.R. Smith, R.Mohan, and C.S. Li. Scalable Multimedia Delivery for
Pervasive Computing. In Proceedings of ACM Multimedia Conference (Multimedia 99), Oct.
-Nov., 1999, Orlando, Fl, USA, pp. 131-140.
[Solla02]
T. Sollazzo, S. Handschuh, S. Staab et al. Semantic Web service
architecture-evolving Web service standards toward the Semantic Web. In Proceedings of the
234
Bibliography.
15th International FLAIRS Conference, 16-18 May 2002, Pensacola, Florida, USA, pp. 425429.
[Sow01]
D. M. Sow, G. Banavar, J. S. Davis II et al. Preparing the Edge of the
Network for Pervasive Content Delivery. Workshop on Middleware for Mobile Computing
(in association with IFIP/ACM Middleware 2001 Conference), 16 November 2001,
Heidelberg, Germany.
[Spgyglass]
Spgyglass-Prism [on line]. Available on: <http://www.sphyglass.com>
(Accessed on 21 July 2003).
[Stemm98]
M. Stemm and R.H. Katz. Verical handoffs in wireless overlay networks.
ACM mobile Networking (MONET), Special issue on Mobile Networking in the Internet,
1998, Vol. 3, No.4, pp. 335–350.
[Sun]
Sun Java System Portal Server Mobile Access [on line]. Available on:
<http://wwws.sun.com/software/products/portal_ma/index.html> (Accessed 19 June 2004).
[Sun03]
H. Sun, A. Vetro, K. Asai. Resource Adaptation Based on MPEG-21
Usage Environment Descriptions. IEEE International Symposium on Circuits and Systems
(ISCAS), 25-28 May 2003, Bangkok, Thailand, Vol. 2, pp. 536-539.
[Szyp02]
C.
Szyperski.
Component
Software:
Beyond
Object-Oriented
Programming. 2nd Edition. Harlow, UK: Addison-Wesley/ ACM Press, 2002, p. 589. ISBN 0201-74572-0.
[Taub94]
D.Taubman, A. Zakhor. Multi-rate 3D sub-band coding of video. IEEE
Trans. on Image Processing, Sept. 1994, Vol.3, No.5, pp.572-588.
[Tayl03]
C. Taylor. An Introduction to Metadata. University of Queensland Library,
July 2003 [on line]. Available on: <http://www.library.uq.edu.au/iad/ctmeta4.html>
(Accessed on 19 October 2004).
[That01]
Corporation,
S. Thatte. XLANG, Web services for business process design. Microsoft
2001
[on
line].
Available
on:
<http://www.gotdotnet.com/team/xmlwsspecs/xlang-c/default.htm> (Accessed on 14 June
2004).
[Turn03]
M. Turner, D. Budgen, and P. Brereton. Turning software into a service.
New York: IEEE Computer Society, October 2003, Vol. 36, No. 10, pp. 38-44. ISSN 00189162.
[TV02]
TV-Anytime Provisional Specification 1.3 (Sept 2002) [on line]. Available
on: <http://www.tv-anytime.org> (Accessed on 18 May 2003).
Bibliography
[Usch96]
235
M. Uschold and M. Gruninger. Ontologies: Principles, Methods and
Applications. Knowledge Engineering Review, February 1996, Vol. 11, No. 2, pp. 93-155.
[Vela04]
C.A. Velasco, Y. Mohamad, A.S. Gilman et al. Universal Access to
Information Services - the Need for User Information and its Relationship to Device Profiles.
In: Gulliksen J, Harker S, Vanderheiden G (eds), Special issue on guidelines, methods and
processes for software accessibility. Universal Access in the Information Society, 2004, Vol.
3, No. 1, pp. 88-95. ISSN: 1615-5289
[Verd06]
C. Verdier. Health information systems: from local to pervasive medical
data. Santé et Systèmique, Hermès ed. 2006.
[Vetro02]
A. Vetro, Y. Wang, and H. Sun. Rate-distortion optimized video coding
considering frameskip. In Proc. IEEE ICIP, Oct. 2002, Rochester, NY.
[Ward97]
A. Ward, A. Jones, A. Hopper. A New Location Technique for the Active
Office. IEEE Personal Communications, 1997, Vol. 4, No. 5, pp. 42-47.
[Wee03]
S. Wee and J. Apostolopoulos. Secure scalable streaming and secure
transcoding with JPEG-2000. IEEE International Conference on Image Processing (ICIP), 1417 Sept. 2003, Barcelona, Spain, Vol.1, pp. 205-212. ISBN: 0-7803-7750-8.
[Weer02]
BPEL4WS,
S.Weerawarana,
Part
1,
Aug
C.
2002.
Francisco.
[on
Business
line].
Processes:
Availabile
on
Understanding
:
http://www-
128.ibm.com/developerworks/webservices/library/ws-bpelcol1/(Accessed on 16 October
2003)
[Weiser91]
M. Weiser. The Computer for the 21st Century. Scientific American,
September, 1991, Vol. 265, No. 3, pp.94-104.
[Wing01]
T. Winograd. Architecture for Context. Human Computer Interaction
Journal, 2001, Vol. 16, pp. 401-419.
[Wolb02]
D. Wolbers. Information Society: From Cave Walls to the Internet. Course
Material
2002
[on
line].
Available
on:
<http://smccd.net/accounts/skylib/lsci100/lesson1_2.htm> (Accessed on September 12, 2005).
[Wu03]
D. Wu, E. Sirin, B. Parsia et al. Automatic web services composition using
SHOP2. In Proceedings of Planning for Web Services Workshop in ICAPS 2003, 10 June
2003, Trento, Italy.
[Yarvis01]
M. Yarvis. Conductor: Distributed Adaptation for Heterogeneous
Networks. Ph.D. Dissertation, UCLA Department of Computer Science, November 2001.
[Yau01]
S.S. Yau and F. Karim. Context-Sensitive Distributed Software
Development for Ubiquitous Computing Environments. Proc. 25th IEEE International
236
Bibliography.
Computer Software and Applications Conference (COMPSAC 2001), 8-12 Oct. 2001,
Chicago, USA, pp. 263-268. ISBN: 0-7695-1372-7.
[Yosh97]
C. Yoshikawa, B. Chun, P. Eastham et al. Using smart clients to build
scalable services. In Proc. Winter 1997 USENIX Technical Conf., 6-10 January 1997,
Anaheim, California, USA, pp. 105-117.
[Zang00]
H. Zang. Adaptive content delivery: A new research area in media
computing. Proceedings of the 2000 International Workshop on Multimedia Data Storage,
Retrieval, Integration and Applications, 13-15 January 2000, Hong Kong, China
[Zenel97]
B. Zenel, D. Duchamp. A general purpose proxy filtering mechanism
applied to the mobile environment. Proceedings of MOBICOM’97, September 1997,
Budapest, Hungary, pp. 248-259.
Curriculum Vitae
Nom
Prénom
Date et lieu de naissance
Etat civil
Nationalité
Adresse
Girma
Berhe
le 06 Janvier 1974 à Adigrat (Ethiopie)
Célibataire
Ethiopienne
INSA de Lyon, LIRIS Bat.501 (Bat. Blaise Pascal)
20 Avenue Albert Einstein, 69621 Villeurbanne, France
Tel. +33 (0)4 72 43 63 48
Fax: +33 (0)4 72 43 87 13
Formation
• Doctorant en informatique au LIRIS, INSA de Lyon (Oct.2002-présent).
• Master en informatique, School of Information Study for Africa, Université d’AddisAbeba, Addis-Abeba, Ethiopie: (Sept. 1999- Juillet 2001).
• ‘Bachelor of Science (BSc)’ en informatique, Département de mathématiques, Faculté
des Sciences, Université d’Addis-Abeba, Addis-Abeba, Ethiopie : (Sept.1992-Juillet
1996).
• E.S.L.C.E (Diplôme de fin d’études secondaires), Addis-Abeba, Ethiopie: (Juin 1992).
Expérience professionnelle
• Enseignement de cours en informatique, Département de mathématiques et
Informatique, Université d’Addis-Abeba: (Sept. 1996- Juin 2002).
Expérience administrative
• Directeur adjoint des études, Faculté des Sciences Université d’Addis-Abeba:
(Sept.1999- Août 2000).
• Intervenant et responsable pour les cours de Bureautique et logiciels d’Application,
formation continue, Département de mathématiques et Informatique, Université d’
Addis-Abeba: (Sept. 2001-Juin 2002).
Connaissances linguistiques
• Anglais
• Français
• Amharique et Tigrigna (langues d’Ethiopie)
Liste des publications
I.
Revues nationales/internationales
•
•
Girma Berhe, Lionel Brunie, “Adaptation de contenus multimédias pour les systèmes
d’information pervasifs”, Journal d’Ingénierie des Systèmes d’Information, Revue des
Sciences et Technologies de l'Information (RSTI) série ISI, Volume 9, no 2/2004
pp.61-85.
Girma Berhe, Lionel Brunie, Jean-Marc Pierson, “Content adaptation in distributed
multimedia systems”, Journal of Digital Information Management, Special Issue on
Distributed Data Management, Volume 3, No 2, June 2005, pp.95-100.
II. Conférences Internationales
•
•
•
•
•
Surafel Lemma, Dawit Bekele, Girma Berhe. “Semantic Description of Multimedia
Content Adaptation Web services”, International Joint Conferences on Computer,
Information, and Systems Sciences, and Engineering (CIS2E 05), University of
Bridgeport, USA, December 10-20, 2005.
Girma Berhe, Lionel Brunie and Jean-Marc Pierson, “Composing Multimedia
Content Adaptation Services”, Workshop on Distributed Multimedia Databases and
Multimedia
Adaptation,
WDMDMA'05
(held
in
conjunction
with
EUROMEDIA'2005), Toulouse, France, 11-13 April 2005 pp.199-203. Proceedings
published in 11th Annual EUROMEDIA'05 Conference.
Girma Berhe, Lionel Brunie, Jean-Marc Pierson, “Distributed Content Adaptation for
Pervasive Systems”, In proceedings of IEEE International Conference on Information
Technology, ITCC 2005, April 4-6, 2005, Las Vegas, Nevada, USA, Vol.2 pp.234241.
Girma Berhe, Lionel Brunie, Jean-Marc Pierson, “Modeling Service-Based
Multimedia Content Adaptation in Pervasive Computing”, ACM Proceedings of the
first conference on computing frontiers (CF’04), Ischia , Italy, April 14 - 16, 2004 pp.
60 – 69
Girma Berhe, Lionel Brunie, Jean-Marc Pierson, “Service-Based Architectural
Framework of Multimedia Content Adaptation for Pervasive Computing
Environment”, 2004 Communication Networks and Distributed Systems Modeling
and Simulation Conference (CNDS'04), January 18-21, 2004.
FOLIO ADMINISTRATIF
THESE SOUTENUE DEVANT L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON
NOM : GIRMA
DATE de SOUTENANCE : 25 septembre, 2006
(avec précision du nom de jeune fille, le cas échéant)
Prénoms : BERHE
TITRE : Accès
et adaptation de contenus multimédia pour les systèmes pervasifs
NATURE : Doctorat
Numéro d'ordre : 06 ISAL 0056
Ecole doctorale : Informatique et Information pour la société (EDIIS)
Spécialité : Documents Multimédia, Images et D’Information Communicants (DISIC)
Cote B.I.U. - Lyon : T 50/210/19
/
et
bis
CLASSE :
RESUME :
La gestion des données en représente clairement l’une des composantes-clefs, recouvrant de nombreux aspects: extensibilité du système,
accès et intégration des données (en termes d’indexation et d’exécution de requêtes dans un environnement distribué fortement hétérogène),
optimisation de l’utilisation des ressources et de la qualité de service (bande passante réduite, discontinuité du service), cohérence de
l’information (l’utilisateur pouvant se trouver en mode déconnecté, comment assurer la cohérence et la pérennité des données qu'il manipule
?). Enfin, l'adaptation de contenus multimédias constitue certainement l'un des mécanismes centraux dans la mise en œuvre effective des
systèmes d'information pervasifs. La très grande hétérogénéité des moyens de connexion et des conditions de communication (bande
passante notamment), la très grande variabilité des préférences utilisateur imposent en effet de fournir des outils d'adaptation des contenus
transmis aux utilisateurs.
Dans ce contexte, beaucoup de travaux de recherche ont été effectués que l’on peut classer en trois approches principales selon le site
d’exécution des mécanismes d'adaptation : l’approche orientée client, l’approche orientée serveur et l’approche orientée proxy
Dans cette thèse, nous présentons une architecture logicielle d'adaptation de contenus multimédia (nommée DCAF: Distributed Content
Adaptation Framework). Cette architecture est fondée sur l’utilisation de services d'adaptation accessibles sur l'Internet. A l’inverse des
approches précédentes où le client, le serveur de contenu ou un proxy est responsable du processus d'adaptation, ce sont ici des services
développés extérieurement qui effectuent la transformation des contenus. DCAF fournit ainsi une solution générique d'adaptation de
contenus offrant flexibilité, extensibilité et interopérabilité.
La principale problématique introduite est la détermination du scénario optimal d’adaptation (également appelé chemin optimal
d'adaptation), plusieurs services d'adaptation pouvant fournir les mêmes fonctionnalités. Cette thèse propose d’adopter une technique issue
de l’intelligence artificielle pour optimiser la planification, la composition et l’exécution des services impliqués dans l’adaptation d’un
contenu. L’algorithme proposé prend en compte le profil des utilisateurs, les caractéristiques des dispositifs, la connectivité du réseau, le
format des contenus échangés et les spécifications (coût, qualité) des services d'adaptation disponibles pour construire un graphe d'adaptation
modélisant le scénario d’adaptation choisi.
Parallèlement, nous avons développé une ontologie dédiée à la description des services d'adaptation. Cette ontologie permet de décrire la
sémantique des services d’adaptation enfin de faciliter la découverte et la composition des services. Elle permet également de passer
facilement de la description d’un service à la représentation de l’opérateur d’adaptation.
Pour démontrer la faisabilité de l’architecture DCAF, un prototype a été développé et évalué. Les expériences conduites montrent que le
temps de construction du graphe d'adaptation et la durée moyenne d'adaptation sont compatibles avec les contraints des environnements
pervasifs.
MOTS-CLES : Systèmes Pervasifs, Adaptation de Contenu Multimédia, Composition de Services, Planification, Contexte
Laboratoire (s) de recherche : LIRIS (Laboratoire d’Informatique en Image et Systèmes d’Information)
Directeur de thèse:
Prof. Lionel Brunie
Co-directeur:
Prof. Jean-Marc Pierson
Président de jury :
Composition du jury :
Rapporteur:
Examinateur:
Directeur de thèse:
Co-directeur de thèse:
Harald Kosch, Professeur, Université de Passau, Allemagne
Hervé Martin, Professeur, LSR, Université Joseph Fourier
Günter Haring, Professeur, Université de Vienne, Autriche
Ahmed Mostefaoui, Maître de conférences, (LIFC) UFR-STGI, Montbéliard
Lionel Brunie, Professeur, INSA de Lyon
Jean-Marc, Pierson, Professeur, IRIT, Toulouse