Benefits of Metadata for Content Adaptation

Oskari Koskimies

Nokia Research Center

oskari.koskimies@nokia.com

Opinions and views expressed in this presentation belong to the author and do not necessarily represent the views of Nokia

Introduction

• Server-side content adaptation has not worked too well in practice

• Client-side content adaptation has significant advantages and has become feasible with the increase in terminal capabilities

• With the help of metadata client can decide what content to download

• Note 1: This presentation covers only part of the picture; server-side content adaptation is also needed e.g. to handle low-end and legacy devices, and server-side transcoding can support client-side content adaptation
• Note 2: This presentation is not focused on today, but the situation 5+ years from now

Disadvantages of Server-side CA

• Need for infrastructure stifles development of mobile-suitable content
• Organizational problems are at least as important as technical
• An organization can provide mobile content only if the whole organization commits to the necessary infrastructure
• Infrastructure maintenance (esp. profile database)
• Client capabilities change due to SW updates
• Device features are constantly in flux, but can only be understood if supported by the concepts of the profile vocabulary, which updates slowly
• Too complex client-server dependency. F content features, R client rendering engines, S server engines => F * R * S failure possibilities => “Who’s fault is it?”
• Storing content locally “locks it down” to a specific adapted form

Why Client-Side CA?

• Resource limitations no longer mandate placing adaptation on server side
• Client Knows Best:
• Has full information on own capabilities, user preferences, and usage context
• Always has up-to-date information
• Can use information that could not be disclosed to server due to privacy issues
• Is not limited to what has been standardized
• Fallback for missing metadata exists: You can analyze the data
• Not possible for server-side CA: you can’t analyze a device!
• Concentrates bug-fixing responsibility at the terminal manufacturer, who anyway is highly motivated to provide good usability and gets immediate feedback
• Content can of course still be faulty, but that can be mitigated and/or detected by client, just like “street” HTML today.
• Non-mainstream terminal concepts become easier since terminal can adapt content to suit the new features of the terminal
• Server-side content adaptation would likely ignore such terminals

Example: 3D Terminals and Content

• Content is a 3D image
• Metadata would be something like “3D-display = true”
• “3D-display = <Boolean>” needs to be added to standardized vocabulary!
• Alternative 2D-images are provided by content author
• Server-Side failure cases:
• Vocabulary missing (slow standardization process) -> cannot handle selection, either 3D always or 2D always
• Don’t understand new vocabulary (slow software update) -> cannot handle selection, either 3D always or 2D always
• Profile not available (slow profile update) -> treated as “default”, 2D version used
• Client-Side failure cases
• Vocabulary missing -> can still download and analyze content
• Don’t understand new vocabulary -> in all likelihood cannot handle the content either (could use directives like “Must-Understand”), so no problem really
• Profile not available – cannot happen

What Does This Mean for Metadata?

• Metadata should be:
• Easy
• Simple to do the simple thing
• KISS is usually the most important thing for adoption
• Efficient
• Easier to process than it would be to analyze the data
• Avoid extra roundtrips – should be downloaded at same time as CSS
• Compact
• Keep overhead to a manageable level even when metadata is ubiquitous and abundant
• Sufficient
• Enough for all common applications
• Extendable
• For special applications

Interesting Questions

• Should metadata describe the content itself (“ImageResolution=128x100”), context requirements for the content (“DisplayResolution>=640x480”), or both?
• Describing context makes content selection easy and allows author control, but is vulnerable to changes in the set of context properties and to author mistakes due to the complexity of catering to all possible contexts
• Describing only content itself makes clients very complicated and presentation can vary considerably depending on client implementation
• Authored context metadata and automatically generated content metadata?

• How far existing standard (e.g. CSS Media Queries, XHTML2 Object tag) will take us?

• How authoring for device independence can be made as painless as possible?

• How to support voice and multimodality?

Summary

• Metadata enables moving adaptation decision from server to client
• Still possible to do transcoding at origin or 3^rd party server
• But even then adaptation is directed by client
• E.g. by including transcoding instructions in URL

• Client-side content adaptation has significant advantages

• Design of metadata should take into account client-side content adaptation by mobile devices – metadata should be compact and efficient to process

• A lot can already be accomplished with current / in-progress W3C specs (XHTML2 object element, CSS3 Media Queries, …)