Transcript Feature-based Device Description and Content Annotation Alamgir Farouk © NOKIA 2000 FeatureBased Device Description and Content Annotation.

Feature-based Device Description and
Content Annotation
Alamgir Farouk
1
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Defining our scope
Generalizing
X-Independent content
X-specific content
Where X = device, network (2G, 3G), context (time, location,
transaction) etc.
The transformation or specialization can be done
 at server
during content generation, developer fully responsible
 en-route
automatically or with hints from developer
 at client
automatically, or using hints or embedded scripts, which
are again responsibility of the developer
There are many aspects of this problem !
We address one small part !
2
© NOKIA 2000 FeatureBased Device Description and Content Annotation
'Evolution' and Features
•
The issue:
•
Key to our proposal: Acknowledging and accommodating this
evolution
•
Evolution occurs by (simplified view)
Devices (hand-held and others) are evolving!
1. Existing characteristics or features (variables) vary
2. New characteristics or 'features' show up
3. Old characteristics or features stop varying or disappear
•
3
Identifying a 'feature-set' is then very important, -it makes the system
evolution-tolerant yet evolution-compatible.
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Features-based Device Description
• Define features so they form a comprehensive 'set'
• Define features which are still varying
• Discretize the possible values these features can take (developerfriendly)
• Describe device in terms of values of these features.
• Use this feature-set to create Device-independent Content
4
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Defining Features
5
© NOKIA 2000 FeatureBased Device Description and Content Annotation
‘Values’ of Features
6
© NOKIA 2000 FeatureBased Device Description and Content Annotation
"Space"
7
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Only some points are ‘real’
PC
ABCD
AB CD
A BCD
A B CD
8
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Current phone set is subset of P
9
© NOKIA 2000 FeatureBased Device Description and Content Annotation
‘NEW’ Feature is added
New Features extend the
‘space’ . Until we extend
our ‘alphabet’ we do not
recognize this space.
10
© NOKIA 2000 FeatureBased Device Description and Content Annotation
   
E A BC
E A B C
E A BC C
E A B C
E A B C
E A B C

D
D
D
D
D
D
Extending the ‘SPACE’
P
E
C
ABCD
AB CD
A BCD
A B CD
11
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Features become obsolete
Old features may converge
to a single value, and hence
no longer be of interest.
12
© NOKIA 2000 FeatureBased Device Description and Content Annotation
   
E A BC
E A B C
E A BC C
E A B C
E A B C
E A B C

D
D
D
D
D
D
'Members' of the Phone' SPACE
13
© NOKIA 2000 FeatureBased Device Description and Content Annotation
'Features' describing phones
Device Features are mutually independent
characteristics of the device. Together, they
should completely describe the device.
Example
Name: Aspect Ratio of display
Values: Landscape or Portrait
(DISPLAY_LANDSCAPE, DISPLAY_PORTRAIT)
(Full set of features not shown here)
14
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Difference between UAProf, CC/PP and
'Feature' s
Let us compare how the display screen is described by the two methods.
UA Prof
Feature
Variables are X and Y
Variables: Aspect-Ratio and Density
XxY
Landscape and High
(60x100, etc)
X and Y are continuous variables.
Aspect-Ratio and Density are NOT
continuous variables.
Developer must deal with infinite
Developer deals with finite possibilities.
possibilities.
Some variables are going to be identical or similar, but otherwise they are not the
same system of describing a phone (or device)
15
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Phones with different aspect-ratios
DISPLAY_PORTRAIT
DISPLAY_LANDSCAPE
…
16
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Developer participation
• Not ALL features require developer help or hints. For example, pixel
aspect ratio, which can distort circles into ellipses, can be taken
accommodated automatically.
• Some features are irrelevant, for example screen-brightness, battery-life.
• The rest require hints from the developer for the system to
accommodate.
• We develop a system to 'annotate' content based on the 'feature-set'
chosen.
• We close the loop using a 'Processor' which can match devices to
feature-values and make content device-specific using this mapping.
17
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Annotating content
Motivation in choosing implementation method:
 Use existing markup language if possible
 Meta-data being added should be backward compatible
 Simple 'english-language' words.
 Practical, should not be difficult to implement.
Result : Use 'class' attribute of WML, which is ignored by the browser,
but supported by EVERY element.
So far we have not been surprised!
18
© NOKIA 2000 FeatureBased Device Description and Content Annotation
WML Content Sample with meta-data
<wml>
<card>
<table class="DISPLAY_LANDSCAPE" >
(….landscape table…)
</table>
<table class="DISPLAY_PORTRAIT">
(….portrait table…….)
</table>
</card>
<wml>
19
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Feature value and annotation match-making
• On one side:
 Content in standard WML with embedded feature specific meta-data.
• On the other-side:
 Devices with different physical characteristics.
We act as the match-maker, -mapping device characteristics to
features, and modifying content based on annotation.
Feature Value example: If the feature Aspect-ratio is termed 
Nokia7110  = DISPLAY_PORTRAIT
R380
20
( = A )
 = DISPlAY_LANDSCAPE ( = A )
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Content Modification
We have to modify or filter the content based on 'current' feature list of
'client' device.
Our Approach:
• Parse serial content into Document Object Model (DOM),
• Manipulate the DOM based on Meta-Data and Feature (filter or modify),
• Serialize the DOM back to output stream.
Sdfasdf asfdasfdasf
Asdfasfdasdf
asf asdf asdf
Asdfasfd asdfasdfasfd asdf
Asdfasdf asdfdasd asdfasdf
Asdfasff asdfasdf asdfasfd
Asdfadsf asdfasddf a
a
21
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Sdfasdf asfdasfdasf
Asdfe ewewewe flakjlkfi
Asflfaldsklk oioweewfe jklaasdas
jfkajlkf faefa lkf
Flkajwlekfjlakjlekjflawkejflaw
lakwelaskdfasdfasd
Af fw wlkelkkjflklajlkjj
Advantages and Limitations
LIMITATIONS
ADVANTAGES
22
• Decouples devices and
developers, allowing each to
innovate independently
•
Applications will need to be updated,
and will need a minimal filtering to
work.
• Allows for advance release of
features by device manufacturers
•
Significant involvment of application
developers (i.e. not automatic)
• Allows application developers to
incorporate features in advance of
device releases
•
Mappings must be updated when new
devices are released or features are
defined
• A practical compromise as
opposed to an absolute yet
unattainable ideal
•
Agreement or standard required.
© NOKIA 2000 FeatureBased Device Description and Content Annotation
Conclusion
• We proposed a method to describe devices in terms of 'features'
• They are 'evolution' compatible.
• Their values are 'developer-friendly'.
• It is a compromise,
 We sacrifice 'fine-grained' device specialization
 We gain 'simplicity' and 'longevity'.
• We achieve device-independent content generation by requiring
developer to be 'aware' of device features, but not actual device.
• It will only work, however, if 'features' are chosen judiciously and
everyone agrees on a standard.
23
© NOKIA 2000 FeatureBased Device Description and Content Annotation