Capabilities, Metadata and Adaptation Architectures
T-110.456 Next Generation Cellular Networks
Immo Heino
Content
• Adaptation and delivery context• Methods for describing capabilities and
preferences• Adaptation architectures• Summary
Adaptation and delivery context• Goals of content negotiation/adaptation – best efforts to
provide: Device independence Personalization
• Elements needed for content negotiation /adaptation: A way to describe attributes of the data source A way to describe capabilities & preferences of data requester Naming & registration schemes for labeling the attribute sets Frameworks (protocols & algorithms) to exchange and
process attributes
• Delivery context: A attribute set that characterizes the capabilities of the access
mechanism, the preferences of the user and other aspects of the context into which the content is to be delivered
General adaptation model
Web
Adaptation
Se
lec
tio
n
Tra
ns
form
ati
on
Ge
ne
rati
on
DeliveryContextURI
DeliveryUnit
Application
Content
Adaptation Rules
DU
PU
PU
PU
AUAUAU
DU
DU
DU
• Picture source: W3C DIWG
Some characteristics of delivery context
• User interaction methods Presentation and capturing modalities
• User agent capabilities Scripting, MIME types capabilities
• Connections Networks, protocols, bandwidth, latency
• Location and localization Geographic location, proximity, languages, time
• Use environment Noise, light
• Level of discourse Verbosity, content detail
• Trust Privacy and security
Approaches to describe delivery context
• WWW Consortium (W3C) HTTP headers & negotiation CSS Media Queries CC/PP DPF SMIL
• Open Mobile Alliance (OMA) Wap UAProf
• IETF Conneg Media Feature Sets SIP
• ISO/IEC MPEG21
• Open source WURFL
HTTP headers & negotiation• Accept headers:
Accept : text/html (MIME types) Accept-Charset: iso-8859-5 (charset accepted) Accept-Encoding: gzip (preferred reply encoding) Accept-Language: en, fr=0.5 (preferred by user)
• User agent string: User-Agent: Nokia6630/1.0 (2.3.129) SymbianOS/8.0
Series60/2.6 Profile/MIDP-2.0 Configuration/CLDC-1.1• Server driven negotiation vs. HTTP 1.1 agent driven
negotiation Server determines which alternate to send to a user agent as
a result of examining the user agent’s request header fields Server gives a list of available presentations, User Agent is
responsible for selecting most appropriate content
HTTP headers & negotiation (cont.)
• Pros: Already used in practice
• Cons: User agent string format not standardized User agent strings are not officially available or maintained ( a
list of mobile UA agents strings: http://www.zytrax.com/tech/web/mobile_ids.html)
Limited capability to describe user preferences (no support for dynamic attributes/properties)
Agent driven negotiation delay (multiple request-response round trips)
Numerous proprietary HTTP headers are already used for content negotiation
CSS2/CSS3 Media Queries• HTML4 + CSS2 supports media-dependent style sheets
tailored for different media types <link rel="stylesheet" type="text/css" media="screen"
href="sans-serif.css"> <link rel="stylesheet" type="text/css" media="print" href="serif.css">
@media screen { * { font-family: sans-serif } } • CSS3 Media Queries = media type + media feature
expressions to limit the scope of the style sheets E.g. declares what kind of media types a style sheet is suitable
for <link rel="stylesheet" media="screen and (color)"
href="http://www.example.com/color" /> Several media queries can be combined
Comma = Logical Or, and = logical AND, only, not Associated style sheets applied (by User Agent) when
matching is true, otherwise ignored
CSS2/CSS3 Media Queries• Pros
Compatibility with current XML syntaxes Style sheets already supported (?) Proposed Media Features (CSS3) extends the control of
content presentation (related to IETF Conneg’s work) Width,height,color,resolution,scan, grid etc..
• Cons Coarse CSS2 media types (“aural”, “braille”, “handheld”,
“print”,”projection”, “screen”, “tty”, “tv”) CSS3 not supported yet with current browsers (limited support
with Opera 7, Mozilla 1.7, “IE Exploder” ?) Support for user preferences / non static attributes? Work in progress since 2002
CC/PP• W3C's Composite Capability/Preference Profiles is a framework:
for defining delivery contexts ( vocabularies e.g. attribute sets) by using the Resource Description Framework (RDF) [CCPPStruct]
allows devices to pass a description of these characteristics to Web servers for use in content selection/adaptation (CCPPex)
• CC/PPStruct standardize the structure of profile information In practice CC/PP vocabulary is a structured set (components) of (unique)
attribute names and valid attribute data types (RDF /XML Schema) Each vocabularies are uniquely identified by a URI Additional specification of meaning of attributes and attribute values is needed
• CC/PPEx standardize the exchange protocol Exchange of CC/PP refence profiles (as a URI) or profile diffs (inline XML ) HTTP extension framework (RFC2274) use was recommended but not
actually used (nor functionally equivalent W-HTTP) WSP used instead
WAP UAProf• The Open Mobile Alliance’s (formerly known as the WAP
Forum) CC/PP based vocabulary (CC/PP application) for describing static characteristics of mobile phones:
Hardware Platform: e.g., screen size, type of IO methods etc. Software Platform: operating system, supported markup
languages, supported media codecs etc. Network characteristics: bearer information Browser User Agent WAP characteristics: WML browsers WAP capability Push characteristics
• Virtually all CC/PP capable devices use UAProf • UAProf defines how to include profile information in WSP or
HTTP requets
Dynamic Properties Framework (DPF)
• Device configuration, user preferences and environmental conditions can vary dynamically
• W3C Multimodal Interaction Framework (abstract framework) Interaction manager —the logical component that coordinates data and manages
execution flow from various input and output modality component interface objects System & Environment - component enables the interaction manager to find out about
and respond to changes in device capabilities, user preferences and environmental conditions
Dynamic Properties Framework (cont.)
• Dynamic Properties Framework provides: the dynamic access (an DOM based interface) to a
hierarchy (a tree) of properties representing the current device capabilities, device configuration, user preferences and environmental conditions (related to MIF system & environment)
a mechanism to both query and update persistent (static) and transient (dynamic) properties
Properties raise events to notify changes to property values
• Complementary to CC/PP• Work has just started in 4Q/2004
IETF Conneg – MFS,BCP• Media Feature Tags (MFS), RFC 2506, 2533
allows complex descriptions of capabilities and preferences by allowing individual predicates to be combined using Boolean expressions in MIME-type definitions
An algorithm and a basic implementation of feature set matching is also presented
• Media Feature Tag Registration Procedure (BCP), RFC 2506 Handling of tag namespaces
IETF General Tree, Global tree (g.org-X.xxx) URI tree enables the sharing of media feature tags without registration (u.org.xxx)
• Example : Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="break" Content-features: (& (pix-x<=800) (pix-y<=600) (| (& (type=”text/html”) (charset=iso-8859-1) (color=limited) ) (& (type=”text/plain”) (charset=US-ASCII) ) (& (type=”image/gif”) (color=mapped) ) (& (type=”image/jpeg”) (color=full) ) ) )
IETF Conneg – MSF,BCP (cont.)
• Pros: Based on solid principles (predicate calculus) Extendable Protocol independent Non-verbose (vs. XML-style tagging)
• Cons: Sender oriented approach (provides content media
information that augments basic MIME content type information)
Not actually used in practice (?)
MPEG21, SMIL, SIP etc..• MPEG-21 Multimedia Framework Digital Item Adaptation (DIA):
Descriptions of the environment (terminal, networks, user) focus on video, audio and image (requantization, wavelet and spatial size
reduction etc..)• SMIL (Synchronous Multimedia Integration Language) content control module
for runtime content choices and optimized content delivery priorities for different media objects Predefined Test Attributes & additional test-attributes (system-bitrate,
system-screen-size, system-screen-depth) media objects to be preloaded (as bandwidth allows) to improve presentation
quality.
• SIP (Session Initiation Protocol) provides a mechanism for user agents to negotiate the media types they can accept in message bodies
a user agent can announce the MIME media types it supports to another user agent.
SDPng (Session Description Protocol) for content negotiation (proposed IETF RFC in 2001)- related to work of IETF Multiparty Multimedia Session Control
Wireless Universal Resource File (WURFL)
• Standard like UAProf is endorsed by many in theory, but not enough in practice, which makes it hard to rely on:
infrastructure to set up UAProf profiles ? There is no guarantee that the info in UAProf are accurate
• the WURFL file contains information regarding wireless devices' configurations, capabilities and features
Open-source project and intended for developers working with the WAP environment.
Hundreds of possible properties to describe static properties (over 300)
contains over 1,500 devices XML based (human readable, machine interpretable)- Current size 2.5 MB The WURFL framework includes tools, utilities, and libraries to parse
and query the XML data• http://wurfl.sourceforge.net
Adaptation architecture models
• Architecture alternatives at the destination (client side) at the intermediary (proxy) at the source (server side)
• Dynamic vs. static adaptation Adaptation based on predefined profiles (static
versioning of the content) Adaptation on demand (“on the fly”)
Client side adaptation
• Picture source: W3C DIWG
Client side adaptation (cont.)
• Benefits Has full information on own capabilities, user preferences and
usage context Always has up-to-date information Can use information that could not be revealed to server (due
to privacy issues) Is not limited to what has been standardized
• Drawbacks Requires terminal processing resources (CPU, battery life) If dummy origin server, needless traffic (especially in mobile
networks !)
Intermediate (proxy) adaptation
• Picture source : W3C DIWG
Intermediate (proxy) adaptation
• Benefits: Moves computation from the client site to the proxy Complex transformations possible (image & video transcoding
etc..) Dedicated services possible (versatility)
Reduces the volume of data transferred to the client • Drawbacks:
Possible bottleneck No control for origin data (legal issues ?) nor terminal behavior Infrastructure maintenance (profile databases)
Server side adaptation
• Picture source: W3C DIWG
Server side adaptation (cont.)
• Benefits: Full control to the content (content modularization) Pre calculated content representations possible
(static adaptation) as well as dynamic adaptation
• Drawbacks: Infrastructure maintenance (profile databases) Storing content locally usually “locks it down” to a
specific adapted form (static adaptation)
Summary
• Adaptation/content negotiation is a very complex issue Moving target: terminal devices and the network infrastructure Variation of media types Changing (dynamic) properties of delivery context
• No single capability/metadata standard will be adequate or dominant
Due to diversity of standardization bodies ? Several overlapping work with metadata in progress or ended Standards will be only partially supported, manufacturer
specific extensions etc..?• Suitable adaptation architecture depends on application,
media content and required level of adaptation
References• Device Independence
http://www.w3.org/2001/di/
• SMIL Content control http://www.w3.org/TR/1999/WD-smil-boston-19991115/content.html
• Media Queries http://www.w3.org/TR/css3-mediaqueries/
• IETF Conneg http://www.imc.org/ietf-medfree/index.html
• MPEG21 DIA http://www-vs.informatik.uni-ulm.de/proj/qos/drafts/m10996_SDPng04
06131704.pdf• CC/PP
http://www.w3.org/Mobile/CCPP/• DPF
http://www.w3.org/TR/DPF/