Core Vocabulary

Description

Within the "DDWG Charter 2" the group is expected to produce, among the other documents, a Note defining a list of properties needed to produce a basic presentation for mobile devices browsing the Web.

The document will be composed of a limited number of properties that are considered needed for the presentation of a web page also suited for mobile devices. Advanced features or the exploitation of very specific device functionalities will be left for a later time. The document is not intended to be a fully comprehensive list of all possible features and functionalities of mobile devices or a fully complete list of possible user-agent features, bugs or behaviours.

Existing Vocabularies

WURFL

WURFL is an open-source project aimed at collecting device descriptions. Originally started as a project to collect information about WAP 1 browsers, it later included much more data about mobile devices in general. The database is a monolithic XML file will the public data.

Vocabulary entries, defined as capabilities, can be found on the WURFL site under "WURFL Devices and WURFL Capabilities".

The vocabulary currently does not define data types.

Unit measures are not defined if not only in the online documentation.

The project does not enforce any specific process for the definition of new capabilities. Capabilities are added by request. The community decides based on the interest and support. Requests should be made on the public mailing list called wmlprogramming. Developers are free to extend the list of capabilities at their will through the "patch program".

The repository is widely used among mobile site developers, content providers. For these reasons, markup, image formats and downloadable content format are the most well detailed.

UAProf

UAProf is a standard defined by the OMA and is based on "CC/PP". UAProf is meant to be used to develop WAP 1 and WAP 2 sites based on WML and XHTML-MP. Device features defined in UAProfiles are first of all about browsing such as supported MIME Types. Based on the RDF structure and extensibility some UAProfiles may also include other information such as MMS (which could be considered a very specific type of browsing), J2ME version, Bluetooth profiles and other device features. When requesting a page a user-agent complying with the OMA standards is required to provide an ad-hoc HTTP header with the URL where the UAProf can be retrived. Manufacturers or browser vendors are generally the maintainers of these files. UAProfiles are thus distributed on many different websites around the world.

Vocabulary entries are defined by the OMA. Requests for new entries are open to the public, but an internal commission decides which one will eventually be included. It is possible to see a list of "UAProf requests" on the OMA site and track the status.

The OMA also provides a public list of "Validated UAProfiles". Anyone is allowed to upload and get its profile validated. Profiles are only validated against the schema definition. Data is not currently validated.

"UAProf (PDF)" has now reached version 2.0.

UAProf has strong data typing. An example of the data types is available for UAProf 2.0 in the "CC/PP Schema".

Unit measures are not defined.

DDWG Charter 1 work on vocabulary

In late 2005, at the request of the Best Practices Working Group, the DDWG polled its members for their opinion of the five most important Device Characteristics for development of Web sites accessed by mobile devices. Answers were collected anonymously, aggregated and circulated to the members of the group [members only].

The Top 5 list is obviously longer than just 5 entries, however there was strong agreement among almost all the respondents as to the Top 3 entries. The final outcome was:

1. Screen dimension in pixels. Emphasis on viewport or usable size, and width.
2. Supported/preferred markup. May be implied by context.
3. Supported/preferred image formats.
4. Maximum sizes. Per mime-type and total page weight.
5. Colour. Supported or not supported. Actual colour depth seems not important.
6. Ringtone capable.
7. Specific browser issues. Bugs, limits, table support etc.
8. Image size (bytes)
9. Video support
10. MIME multipart support
11. Specific features: J2ME, DRM etc

This Top 5 list is taken as the starting point for defining the core vocabulary.

In December 2005, during a face-to-face meeting in Boston, the group concluded its first charter by producing a mind-map collecting many more opinions, based on the original work on the Top 5. The TopFiveMindMap is now available for public viewing.

The Top 5 list was sent to the OMA for comments and their public reply will be used as a contribution to the definition of the core vocabulary. A formal response to the OMA's reply was sent on the DDWG public mailing list.

Definition of Properties

History

The initial draft of the process was sent to the mailing list on Feb, 26 2007 by Andrea Trasatti. The thread can be followed on the web archive of the public list. Initial e-mail is available, "Vocabulary process kick-start"

The intention to launch the process was announced in May 2007.

The process was activated in June, with submissions coming initially from OMA. The public announcement of the process was made on 11 June 2007 via this wiki and the public mailing list.

How to contribute

This is the lightweight process by which the DDR Core Vocabulary will evolve.

• a) SUBMIT A public Online Submission Form is provided to suggested vocabulary entries.
  1. the submission should provide at minimum the description of what entry is being requested:
     • A description of the property, with as much precision as possible.
     • The units with which one measures the property (or range of values, or whatever is appropriate).
     • The data type to use (e.g. non-zero integer).
     • Justification for the property being in the core vocabulary.
• b) the submission could include the ontology definition (using Protege Ontology Editor), but as this may be seen as particularly technical, it will be left to the DDWG members to transform the informal submission into a formal submission in RDF/OWL.
• c) EVALUATE The group will receive the request, evaluate it, discuss it
  1. the group may contact the individual or company that requested the entry for more explanations
  2. a public mailing list public-ddr-vocab@w3.org is used to discuss submissions with the wider community
• d) DECIDE The group will consider if and how the entry should be created
• e) EDIT The group will create a new entry in the vocabulary using a tool such as ProtÈgÈ to edit the ontology
• f) PUBLISH The group will add the entry to the Core Vocabulary and publish this update via the W3C Web site.

---

Comments

The group referred to here is the W3C Device Descriptions Working Group (DDWG) under its second charter. The process defined here may outlive the lifetime of the group and the group may make arrangements to hand over operation of the process to some other group.

The submission process should accommodate verification of the submission. The results of the group's evaluation of the request will be notified to the originator.

SUBMIT: The group will most likely receive a lot of requests during its charter. There should be a period, around the end of life of the group in which the group might review the entire vocabulary and drop entries that are not considered core, too similar to others or try to merge, group or review entries requested in the past.

EDIT: what happens here is simply the creation of the entry using a tool such as the Protege Ontology Editor. This will provide the strong data typing that is required for this vocabulary and will also provide the ease of a visual tool to produce the human-unreadable, but machine-friendly RDF ontology definition of the entry.

PUBLISH: Once all this is done, using ProtÈgÈ anyone will be able to download the full vocabulary, browse it, check it and fit it into a database or application and use a DDR that will be defined in the other group Note and Recommendations.

Submissions Collected

All the submissions received by the group have been collected in a Wiki page called CoreVocabularyAllSubmissions .

Out of all the submission a more consistent list has been created called CoreVocabularySubmissions .

Core Vocabulary

These are all the properties that have been approved by the DDWG and that are officially part of the W3C MWI DDWG Core Vocabulary.

Device Name

Device Vendor

Description: The maker (OEM) of a device

Measurement: <none>

Type: String

Justification: Knowing the Vendor and Model is very important when designing and application and building reports and analytics about your application. While it is not a required information when performing adaptation it is a very important piece when designing it or analyzing logs and usage data

Property Name: deviceVendor

Related properties: <none>

Ontology Name: <none>

Approved on 29 Oct 2007

Device Model

Description: The model name of the device

Measurement: <none>

Type: String

Justification: Knowing the Vendor and Model is very important when designing and application and building reports and analytics about your application. While it is not a required information when performing adaptation it is a very important piece when designing it or analyzing logs and usage data

Property Name: deviceModel

Related properties: deviceVendor

Ontology Name: <none>

Approved on 29 Oct 2007

Hardware

Screen Width

Description: The total number of addressable pixels in the horizontal direction of a rectangular display when held in its default orientation. The property does not apply to screen shapes that are not rectangular or square.

Measurement: The pixels are counted from the top left corner to the top right corner, and the result expressed as an integer whose units are 'pixels'.

Type: Non-negative integer.

Justification: Needed to fit/crop images, text or other width-adaptable content to the screen. Especially useful for LTR and RTL content, where vertical scrolling would be the norm but horizontal scrolling is not desirable. Identified as an important property by the DDWG in its Top N finding. Present in UAProf. Present (and used) in existing adaptation solutions.

Property Name: screenWidth

Related properties: screenHeight

Ontology Name: <none>

Approved on 15 Oct 2007

Screen Height

Description: The total number of addressable pixels in the vertical direction of a rectangular display when held in its default orientation. The property does not apply to screen shapes that are not rectangular or square.

Measurement: The pixels are counted from the top left corner to the bottom left corner, and the result expressed as an integer whose units are 'pixels'.

Type: Non-negative integer.

Justification: Needed to fit/crop images, text or other height-adaptable content to the screen. Especially useful for vertical content. Suggested that it may be an important property by the DDWG in its Top N finding. Present in UAProf. Present (and used) in existing adaptation solutions. Needed if the screen orientation is rotated 90 degrees, in which case this property would represent the width of the rotated screen.

Property Name: screenHeight

Related properties: screenWidth

Ontology Name: <none>

Approved on 15 Oct 2007

Screen Color Depth

Description: Screen color depth

Measurement: The value should be defined based on the bits usable for color definition.

Type: Integer positive number

Justification: If you are making any image or video transcoding it is important to know the maximum colors addressable by the screen. Measuring in bits should make it easier for programmatic conversions.

Property Name: screenColorDepth

Related properties: <none>

Ontology Name: <none>

Approved on 15 Oct 2007

Input Devices

Description: This property described which input devices are available to the user. Normally most mobile devices such as mobile phones will have a keypad, it is common, though, to have a rocker, a stylus and a touch screen in PDA's, tablets and so on.

Measurement: Hardware specifications

Type: Enumeration, returned as an unordered Array of the available devices

Justification: From an application perspective knowing that a device features a stylus or a touch screen can open many possibilities to greatly enhance the user interaction.

Property Name: inputDevices

Related properties: <none>

Ontology Name: <none>

Approved on 29 Oct 2007

possible values

Name	Description	Measurement	Justification	Related properties	Ontology Name	status
keypad	classic 12 buttons mobile phone keypad	Hardware specifications	<none>	<none>	<none>	Approved
touch screen	touch screen that allows to point exact regions of the screen	Hardware specifications	<none>	<none>	<none>	Approved
stylus	a stylus normally works in combination with a touch screen, the stylus provides higher precision	Hardware specifications	<none>	<none>	<none>	Approved
trackball	a little sphere that acts like a trackball mouse	Hardware specifications	<none>	<none>	<none>	Approved
click-wheel	a wheel that is normally placed either below the screen or on the side of the device that lets the user quickly move up and down and click on link or items on the screen	Hardware specifications	<none>	<none>	<none>	Approved

Web Browser

Mark-up

Description: Set of values of mark-ups the browser can render. Each value will represent one markup language representing a Web page (or fragment thereof) that can be rendered by the device Web browser(s)

Measurement: See individual values, normally conformance to the minimum compliance requirements. More detail may appear in other specific properties such as tableSupport.

Type: Enumeration, returned as an unordered Array of the supported mark-up names.

Justification: In order to provide the appropriate mark-up when serving a web page, it is required that the server knows the supported mark-ups. Accept headers are often not accurate enough and can be modified by proxies in-between.

Property Name: markup

Related properties: <none>

Ontology Name: <none>

Approved on 15 Oct 2007

possible values

Name	Description	Measurement	Justification	Related properties	Ontology Name	status
xhtmlBasic10	XHTML Basic 1.0	conformance to the requirements	often the Accept headers are not enough detailed to go down to a specific mark-up version, XHTML Basic is the basis for many more complex mark-ups	<none>	<none>	<#32CD32 > Approved
xhtmlMp10	XHTML-MP 1.0	conformance to the requirements	many mobile browsers are based on WAP standards, XHTML-MP is part of WAP 2	<none>	<none>	<#32CD32 > Approved
xhtmlBasic11	XHTML Basic 1.1	conformance to the requirements	XHTML 1.1 is the evolution of 1.0, many browsers already support it. Next versions of WAP 2 are based on this too	markup.xhtmlBasic10	<none>	<#32CD32 > Approved

Style Sheets

Description: Set of values of Style sheet recommendations the browser can render. Each value will represent one style sheet recommendation

Measurement: See individual values, normally conformance to the minimum compliance requirements. More detail may appear in other specific properties such as tableSupport.

Type: Enumeration, returned as an unordered Array of the supported style sheet names.

Justification: Style sheets are needed to define how the page should be layed out, positions and colors.

Property Name: styleSheet

Related properties: markup

Ontology Name: <none>

Approved on 15 Oct 2007

possible values

Name	Description	Measurement	Justification	Related properties	Ontology Name	status
css10	CSS 1.0	conformance to the requirements	often the Accept headers are not enough detailed to go down to a specific mark-up version, CSS 1.0 is the first defined and most widely supported	markup.xhtmlBasic10	<none>	<#32CD32 > Approved
wcss10	WCSS 1.0	conformance to the requirements	part WAP 2 specification	markup.xhtmlMp10	<none>	<#32CD32 > Approved
css21	CSS 2.1	The BPWG knows that full and exact support is rarely achieved and believes that DDWG should consider what is meant by support, if and when it should be possible to assert that a markup is supported even if not all the elements and attributes are completely supported. DDWG should also consider make these findings available to the public in association with the property definitions.	CSS 2.1 support is important to know if and how it can be used to define the page layout	styleSheet.css10	<none>	<#32CD32 > Approved

Image Formats

Description: Set of values of image formats the browser can render in-line. Each value will represent one image format.

Measurement: See individual values, normally conformance to the minimum compliance requirements. More detail may appear in other specific properties such as transparency, animation, etc.

Type: Enumeration, returned as an unordered Array of the supported image format names.

Justification: Images are the first step to make content more compelling. Accept headers are often not accurate enough and can be modified by proxies in-between.

Property Name: imageFormat

Related properties: <none>

Ontology Name: <none>

Approved on 15 Oct 2007

possible values

Name	Description	Measurement	Justification	Related properties	Ontology Name	status
gif87	display a GIF87 image in a mobile web page	correctly load and display a GIF87 image	GIF is the most widely used image format	<none>	<none>	Approved
gif89a	display a GIF89a image in a mobile web page	The browser shows the image appropriately in a web page	GIF89a adds animation and other evolutions to the basic GIF specification	imageFormat.gif87	<none>	Approved
jpg	display an image created following the JPEG standard in a web page	The browser shows the image appropriately in a web page	JPEG is one of the most common formats	<none>	<none>	Approved
png	display an image created following the PNG standard in a web page	The browser shows the image appropriately in a web page	PNG is one of the most common formats and is an open standard	<none>	<none>	Approved

Form Text Input Mode

Description: This property indicates the preferred way of supporting specific formats for input type="text" fields. This can be done with the 'format' attribute, as a W-CSS property or using the 'inputmode' attribute

Measurement: Test the browser with <input type="text" controls specifying the format with the mechanisms cited above

Type: Enumeration {format_as_attribute, format_as_css, format_using_inputmode}

Justification: Needed to adapt to different delivery contexts in order to respect user intentions with respect to format restrictions and at the same time improving text user input

Property Name: formTextInputMode

Related properties: <none>

Ontology Name: <none>

Approved on 29 Oct 2007

Cookie

Description: The ability of a web browser to store cookies and send them to the remote server when appropriate

Measurement: A web server sets a cookie in an HTTP Response. The mobile web browser makes a subsequent HTTP request. If the browser supports cookies the HTTP request should contain the cookie previously set by the web server

Type: Boolean

Justification: It is very important to know if a browser support cookies, among other things, to support the concept of user session. An adaptation solution that knows that a device does not support cookies should fallback to a URI rewriting mechanism

Property Name: cookie

Related properties: <none>

Ontology Name: <none>

Approved on 29 Oct 2007

Other Vocabularies

This group is chartered to define a vocabulary that will cover only properties that are required for the development and adaptation of content for mobile devices.

It is understood that other groups or companies will be interested in properties that are specific to their interests or that are seen as very important, but did not make it into this Core Vocabulary. The group welcomes the work of other individuals and the creation and development of other vocabularies that will be complementary to the Core Vocabulary. Web browsers are often used as vehicles to deliver media, applications and other contents, information should be collected in complementary vocabularies. Specific optimizations such as advanced adaptation should also be developed as part of complementary Vocabularies.

Third parties are welcome to use the process that this group has identified and refined over time or use it as a model and improve according to the group's needs.

Tools

• Protege Ontology Editor