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
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 3rd 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, …)