Capabilities, Metadata and Adaptation Architectures T-110.456 Next - - PowerPoint PPT Presentation

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

S e l e c t i

• n

T r a n s f

• r

m a t i

• n

G e n e r a t i

• n

Delivery Context URI Delivery Unit

Application Content Adaptation Rules

DU PU PU PU AU AU AU 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_SDPng0406131704.pdf

• CC/PP
• http://www.w3.org/Mobile/CCPP/
• DPF
• http://www.w3.org/TR/DPF/