Nowadays, mobile devices have implemented several transmission technologies which enable access to the Internet and increase the bit rate for data exchange. Despite modern mobile processors and high-resolution displays, mobile devices will never reach the stage of a powerful notebook or desktop system (for example, due to the fact of battery powered CPUs or just concerning the small-sized displays). Due to these limitations, the deliverable content for these devices should be adapted based on their capabilities including a variety of aspects (e.g., from terminal to network characteristics). These capabilities should be described in an interoperable way. In practice, however, there are many standards available and a common mapping model between these standards is not in place. Therefore, in this paper we describe such a mapping model and its implementation aspects. In particular, we focus on the whole delivery context (i.e., terminal capabilities, network characteristics, user preferences, etc.) and investigated the two most prominent state-of-the-art description schemes, namely User Agent Profile (UAProf) and Usage Environment Description (UED).
Boost Fertility New Invention Ups Success Rates.pdf
Delivery Context Descriptions Comparison and Mapping Model
1. Delivery Context Descrip1ons
A Comparison and Mapping Model
Chris&an Timmerer
Klagenfurt University (UNIKLU) Faculty of Technical Sciences (TEWI)
Department of Informa&on Technology (ITEC) Mul&media Communica&on (MMC)
h9p://research.1mmerer.com h9p://blog.1mmerer.com mailto:chris1an.1mmerer@itec.uni‐klu.ac.at
Co‐authors: Chris1an Timmerer, Johannes Jabornig, and Hermann Hellwagner
(UNIKLU)
3. Introduc1on
• Access to Internet is
ubiquitous
• Device types: sta1onary +
mobile
• Characteris1cs manifold
• Calls for a descrip1on of the
usage environment context
– Different formats available
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 3
4. Mo1va1on
• Use case: mul1media content Terminal Devices
adapta1on Server / Proxy /
Live Content Access Point /Client
Mul&media Content
Adapta&on
Characteris&cs
Stored Content Adapta&on Capabili&es
Decision‐Taking Condi&ons
. . .
… does not want to change/update SW each &me a
new format appears
… keep mapping effort minimal
… want to have a generic approach
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 4
5. Available Descrip1on Formats
RDF
Composite Capabili1es / Preference Profiles (CC/PP) – W3C
•
– Components + a9ributes (simple|complex={bag,seq})
– Does not define a vocabulary of terms
User Agent Profile (UAProf) – Open Mobile Alliance (OMA)
•
HW/SW Placorm: display/audio output, interac1on, media types, codecs, OS, …
– CC/PP
BrowserUA: (X)HTML features, JavaScript, …
–
NetworkCharacteris1cs: bearer, security op1ons, Bluetooth support, …
–
Wap/PushCharacteris1cs
–
Usage Environment Descrip1on (UED) – MPEG‐21 Digital Item Adapta1on (DIA)
•
– User characteris1cs: user informa1on, preferences, accessibility, … XML Schema
– Terminal capabili1es: display/audio output, codecs, power/storage, CPU, …
– Network characteris1cs: capabili1es/condi1ons, bandwidth, error, …
– Natural environment characteris1cs: illumina1on, noise, loca1on, 1me, …
Delivery Context Ontology (DCO) – W3C
•
OWL
Environment: loca1on, network, …
–
Hardware: display, input, memory, camera, Bluetooth, CPU, …
–
Soiware: supported APIs, data formats, OS, protocols, Java/Web browser specifics, …
–
Measure: units wrt physical electrical charges, length, unit conversion, …
–
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 5
6. Analysis / Comparison
• All standards make use of XML
– MPEG‐21 UED: XML Schema
– OMA UAProf: RDF (as it is based on CC/PP)
– W3C DCO: OWL
• Only a few but essen1al characteris1cs/capabili1es are
common across all usage environment context descrip1on
formats
– Display capabili1es, file/coding formats, …
– Difference in syntax, e.g., horizontal=1024, ver1cal=768 vs.
1024×768
• CC/PP defines only a basic structure without a vocabulary
of terms
describe rela1onship between commonali1es (how? which
technology?)
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 6
7. Mapping Model
• Direct mapping model: explicit func1ons from one
standard/format to another
• Integra1on model: common interface + func1on for
conver1ng to/from this model
• Technology
– XML Schema: data type and value range incompa1bili1es
cannot be described (e.g., UED: colorCapable={true,false},
UAProf: ColorCapable={Yes,No})
– OWL: describes rela1onship between classes and proper1es
uaprof2dco
ued2dco
dco integra1on model
dco2uaprof
dco2ued im2ued
. . .
ued2im
ued2uaprof
ued uaprof dco
ued uaprof
uaprof2ued
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 7
8. Approach: Mapping Levels
• Component: mapping of predefined group of elements/a9ributes
to similar group of the other descrip1on format
• Elements: mapping of a9ributes/elements with equal seman1cs but
possibly different syntax, i.e., different tag names
• Datatype: mapping of datatypes with equal domains but different
syntax
• Value: mapping of datatypes with different domains but equal
seman1cs
Level UAProf Example UED Example
Component prf:NetworkCharacteristics dia:NetworkType
Element prf:InputCharSet dia:CharacterSetCode
Datatype prf-dt:Boolean xsd:Boolean
Value Yes true
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 8
11. Mapping Classes
• Direct: equal seman1cs and compa1ble datatypes with equal domains but
may differ in their syntax (i.e., tag name)
– E.g., dia:bitsPerPixel (xsd:integer) and prf:BitsPerPixel (prf‐dt:Number)
• Advance: same concept (i.e., equal seman1cs) but with different, non‐
compa1ble datatypes and/or domains
– E.g., dia:Resolu1on (horizontal/ver1cal a9ributes) and prf:SreenSize (480x320)
• Derive: element values can be derived from one or more elements of the
respec1ve other descrip1on format
– E.g., prf:SoundOutputCapable derived from presence of
dia:AudioOutputCapability
• Extend: require proprietary extensions of the respec1ve other descrip1on
format
– E.g., UAProf WapCharacteristcs not present in UED
• UAProf: 77 elements with direct (4), advance (7), derive (4), and extend
(62)
• Direct (4), advance (7), and derive (4) cover most mul1media content
adapta1on scenarios
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 11
14. Conclusions
• Mapping of context delivery descrip1ons between different formats
• Mapping model based on levels => four classes: direct, advance,
derive, extend
• Defined integra1on model + formulated templates (SPARQL/OWL)
to query informa1on from this model to generate the target context
delivery format
• Findings
– Overlap between different formats not that huge as expected
• Clustered around those proper1es which are considered by the majority of
applica1ons areas (e.g., screen size, coding formats, etc.)
– Direct, advance, derive are sufficient
– Rela1onship described manually with respect to an integra1on model
• Requires a thorough analysis of these formats which is some1mes
cumbersome
• Mapping func1ons need to be defined only once
– We have demonstrated that it is feasible but requires the integra1on
of many XML‐based technologies (XML Schema, RDF, OWL, SPARQL,
XSLT, …)
2009/03/19 Chris1an Timmerer, Klagenfurt University, Austria 14