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).
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
Delivery Context Descriptions - A 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