1 / 27

Capabilities, Metadata and Adaptation Architectures

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.

sef
Download Presentation

Capabilities, Metadata and Adaptation Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Capabilities, Metadata and Adaptation Architectures T-110.456 Next Generation Cellular Networks Immo Heino

  2. Content • Adaptation and delivery context • Methods for describing capabilities and preferences • Adaptation architectures • Summary

  3. 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

  4. General adaptation model • Picture source: W3C DIWG

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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) ) ) )

  16. 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 (?)

  17. 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

  18. 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

  19. 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”)

  20. Client side adaptation • Picture source: W3C DIWG

  21. 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 !)

  22. Intermediate (proxy) adaptation • Picture source : W3C DIWG

  23. 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)

  24. Server side adaptation • Picture source: W3C DIWG

  25. 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)

  26. 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

  27. 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/

More Related