Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This W3C Note describes the business models surrounding the creation, maintenance and use of device descriptions. It identifies the main actors in the current model, explores their motivations for participating, identifies the costs associated with participation and the benefits that accrue to participants.
It is shown in this Note that the current model is incomplete, partly because of the absence of a common repository that can address the needs of the various actors. A complete model is postulated, on the assumption of the existence of a common repository, from which is derived some key requirements upon such a repository to ensure the success of the model.
This Note should be read in conjuntion with the DDWG Landscape document, which provides details of the particular technologies and actors currently engaged in work related to device descriptions. This Note, together with the Landscape document, provides input to the DDWG Requirements document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document is a First Public Working Draft of a future Working Group Note. It has been produced as part of the W3C Mobile Web Initiative Device Description Working Group [DDWG], following the procedures set out for the W3C Process. This Working Group is part of the Mobile Web Initiative. The authors of this document are members of the W3C Mobile Web Initiative, Device Description Working Group (members only). Feedback can be directed to the DDWG Public Mailing List, which is also archived.
1 Introduction
2 Actors in the Device Description market
2.1 Device Manufacturers
2.1.1 Motivation
2.1.1.1 Unique Selling
Point
2.1.1.2 Seem less content
delivery
2.1.2 Current situation
2.1.2.1 Absence of
regulatory imperative to produce profiles
2.1.2.2 Absence of a
standards imperative to produce profiles
2.1.2.3 Commercial
regulation
2.1.3 Component
manufacturers
2.2 Browser Vendors
2.2.1 Motivation
2.2.2 Current situation
2.3 Device Validators
2.3.1 Motivation
2.3.2 Current situation
2.4 Accessibility Groups
2.4.1 Motivation
2.4.2 Current situation
2.5 Content Adaptors
2.5.1 Motivation
2.5.2 Current situation
2.6 Content Annotators
2.6.1 Motivation
2.6.2 Current situation
2.7 Content Ratings
2.7.1 Motivation
2.7.2 Current situation
2.8 Content Authors
2.8.1 Motivation
2.8.2 Current situation
2.9 Application Developers
2.9.1 Motivation
2.9.2 Current situation
2.10 Operators
2.10.1 Motivation
2.10.2 Current situation
2.11 End-Users
2.11.1 Motivation
2.11.2 Current situation
2.12 Repository Providers
2.12.1 Motivation
2.12.2 Current situation
2.13 Standards Organisations
2.13.1 Motivation
2.13.2 Current situation
2.14 Content Providers
2.14.1 Motivation
2.14.2 Current Situation
3 Costs
3.1 Manufacturers
3.1.1 Compiling profiles
3.1.2 Validating profiles
3.1.3 Advertising profiles
3.1.4 Cost reduction
3.2 Authors
3.2.1 Awareness
3.2.2 Tooling
3.2.3 Barrier to entry in absence
of descriptions
3.2.4 Cost reduction
3.3 Repository costs
4 Benefits
4.1 Better quality presentations
4.2 More efficient use of bandwidth
4.3 Enables easier movement to new
devices
5 Competition
5.1 Trust
5.2 Accuracy
5.3 Price
5.4 Relevance
5.5 Scope
5.6 Depth/detail
5.7 Availability
5.8 Timeliness
6 Trust
6.1 Trust the source of information
6.1.1 Missing information
6.1.2 Multiple sources
6.1.3 Errors in original
information
6.1.4 Objective vs Subjective
information
6.2 Trust how information is used
6.2.1 User preferences
6.2.2 Implied user
properties
6.2.3 Legal restrictions
6.2.4 Jurisdiction issues
6.3 Trust the fidelity of forwarded
information
7 Business Model
7.1 Value Chain
7.1.1 Source of Attributes
7.1.1.1 Device
manufacturers
7.1.1.2 Browser
creators
7.1.2 Storage
7.1.2.1 Validation
7.1.2.2 Discovery
7.1.3 Authoring tool vendors
7.1.4 Content creators
7.1.5 End user
7.2 Issues
7.2.1 Effort does not produce
reward
8 Architecture and Deployment
9 References
9.1 CC/PP and UAProf, comment by Mark Butler
In the context of this Note, Device Descriptions are pieces of information relating to Web-enabled devices that may be used to categorise or distinguish these devices. In particular, this Note is concerned with descriptions of Web- enabled mobile devices and the characteristics detailed in such descriptions that may influence the delivery of content (resource representations) to them.
As an example, a description of a device may provide information about the type of markup supported by the browser, the size and resolution of the screen and the presence of various input features. A separate description of the same device might contain an evaluation of the usability of its keyboard, the usable area of the screen and the appropriate layout of the access keys. A third description might detail the most effective navigation strategies for the device, the best colour schemes and the most readable fonts in order of preference. There may be many such descriptions. The information in these descriptions may overlap, may even conflict.
These descriptions can have various sources. Each source, such as a manufacturer or a usability group, will have different motivations for providing the information. The information could be in the public domain, or only available for a fee. The descriptions can be used in various ways. In particular, the descriptions of a device can influence the content delivered to the device. The descriptions could be used by content authors, and by the users (or potential users) of these devices.
In this environment there is a community of actors (stakeholders) who collaborate or compete within a web of relationships. The actors are motivated to benefit from these relationships, and over time these relationships will evolve. This is a social, commercial and technological ecosystem based on the exchange and management of device descriptions.
At the time of writing, the ecosystem is still in its early days. Models of exchange and management have yet to evolve and mature. Many actors are unsure of the roles they will play in the ecosystem, but there is general agreement that the availability of device descriptions will bring benefits to all of the stakeholders, in particular the participants in the Mobile Web.
This Note explores the current and evolving Device Descriptions ecosystem, and suggests a potential model for exchange and management.
| Editorial note | |
This list is neither final nor exhaustive. It also contains descriptions of the current situation of each actor at the time of writing. This information is provided at this point in the draft to establish context. It is expected that this information will ultimately be presented in this Note's companion "Landscape" document. |
|
In this section we summarise the actors that currently play a role in the device description market, and those who are likely to play a role in the future. Each of these have different motivations for participating in the device description ecosystem. These are highlighted in each case.
The manufacturers provide the key physical capabilities of the mobile device. Their manufacturing processes determine the size of the screen, the amount of memory, the speed of the processor, the networking features and more.
By providing accurate descriptions of their devices, manufacturers can ensure that the features of their devices will be known to content authors and adaptation solutions, so that these features can be exploited. This should produce improved user experiences, raising the approval ratings of their devices, and thus leading to enhanced sales.
Question: what is the current motivation for manufacturers to create device descriptions, such as instances of UAProf?
Device manufacturers are not required to provide device descriptions. For mobile devices, such descriptions would normally be represented using the OMA's User Agent Profile technology, which is based on the W3C's CC/PP. If these profiles are created by a manufacturer, there is no requirement to store them in any particular place for public access, or even to advertise that they have been created. In some cases, the stored profiles have been found to be invalid according to the specifications of UAProf, or have contained inaccurate data, possibly because the device characteristics were altered during the design/manufacturing process without updating the profile before publication. Errors are not always corrected. Some useful device information has been contained within the profiles in the form of comments, which are inaccessible to automated processes.
The OMA is making efforts to provide better access to validation tools, and to provide a repository of validated profiles. This will provide manufacturers with a common management framework in which to facilitate their device descriptions. Facilities for augmenting or correcting the OMA repository are not provided, though the public access to the repository means that such facilities could be provided through third parties.
Manufacturers are not required to provide profiles of their devices. There is therefore no penalty for those who do not provide profiles. The availability of profiles therefore depends on other factors.
A regulatory imperative to provide profiles would guarantee their availability, but such regulations could only be imposed if their necessity could be clearly demonstrated. There is also the issue of identifying the appropriate regulatory body to enforce the regulations.
There are no standards, necessary for the manufacture of devices, that demand the provision of device profiles. In fact, the only popular standard used by Web enabled devices that demands some communication of device capabilities is HTTP itself, in the form of the "accept" header. It is unfortunate that very few Web servers actually make use of the accept header. With this poor track record, it is not surprising to find that there is scepticism about the future of device description technology.
Browser vendors provide content presentation software that may be installed at the time of manufacture, or at a later stage by the end- user via an installation process. The browser determines the presentation capabilities, including the type of markup, the type of image, sound or other media formats, and the modes of interaction.
Obviously, interaction may be limited by the capabilities of the device.
Like device manufacturers, browser vendors are motivated by economic factors. By making the characteristics of their browsers known to the authors and adaptation solution providers they ensure that content can be presented to maximum effect. Good user experience should encourage more manufacturers or operators to adopt the browsers, and end users to install them.
There are also providers of browsers who are not motivated by economics, the open source community being a particular example. For these the motivation is typically a desire to demonstrate quality and professionalism while contributing something useful to their user community. Providing descriptions of their products is a simple way to advertise the features they are providing, and of ensuring that these features are used.
Browser vendors are not required to provide descriptions of their browsers. Unlike manufacturers, there is no common technology with which they can provide descriptions. The UAProf vocabulary does not extend to include the specific features associated with the browser, although some vital information is supported. Only the content adaptors maintain descriptions related to browsers, and with the exception of the open source solutions, these descriptions are treated as commercial property. This is because of the effort involved in gathering and verifying information about the browsers, particularly as their characteristics can be affected by the device into which they are installed.
The handset validation sector is both a provider and a customer of device descriptions: they are gatekeepers of new handsets coming into the network. Although a lot of their knowledge of handsets is at lower radio levels, there is increasing service/application/content-level expertise.
The focus of the accessibility and usability groups is typically on software and services, rather than on the characteristics of the device. Nevertheless, there are certain device features that can be described by these groups, including:
To illustrate how an accessibility/usability group might augment the descriptions provided by the manufacturer, consider the first item on the list: "font-magnifier". An accessibility group may determine that the built-in magnifier works best with sans serif fonts, which is information that might not be indicated by the manufacturer. This assessment would be made by specialists available to the accessibility group that would not necessarily be available to the manufacturer.
Because of the wide diversity of Web-enabled devices, a single representation of a resource will not be suitable for all devices in all delivery contexts. This has been well documented by the DIWG. Content adaptation solution providers use device descriptions as part of their content adaptation processes. Better device descriptions lead to better adaptations.
Content adaptors are typically motivated by economic factors to maintain large and detailed repositories of device descriptions. The quality of their adaptations is directly influenced by the quality of the information in their repositories. Adaptation quality is a key selling factor.
Content adaptors maintain large and complex repositories of device descriptions. They do this by gathering information from a number of sources, including:
Direct assessment is the primary source for some content adaptation providers, as it is the most reliable. This requires that their evaluation laboratories have physical access to new devices. In many cases, descriptions of new devices appear some time after the devices are released to the market, so there can be a lag between new devices appearing and optimum content being available.
An annotator adds content to existing content, possibly via a metadata-based technology. This might be for translation, for summaries, for interpretation. Not sure if there is an actual company or organisation I can use as an illustration, nor if such people would be interested in using or creating device descriptions. Needs more thought...
Examples: adding keywords, adding company references to cause tickers to appear etc.
People who provide information to enable you to decide what is suitable (to your device, to your age, to your interests, etc.) We might find in the future that these people will provide a service for rating if a site is MobileOK, MobileBetter or MobilePerfect. Needs more thought.
Content author use device information to determine the amount, type and variations of content to provide. For example, it is common for branding purposes that a corporate logo will be available in a number of different formats and sizes. The variation in these images results from knowing the variation in device characteristics.
Network operators provide the means for conveying content to devices, and in many cases also provide the content.
Would like some comments from operators before I write anything here.
End users can influence device descriptions. They can enable or disable features, and in some cases can combine multiple devices into a composite (e.g. by adding a camera to a cellphone). End users are a source of preference information, which is another influencing factor in content selection or adaptation. This is why capabilities and preferences are handled by the same representation within CC/PP. End-user preferences, choices and combinations of features should complement the device description technologies.
A repository provider offers a set of descriptions for sale or license. Need to say something about who consumes this data. This is a very new type of business.
Standards organisations determine the interoperable means by which their participant members achieve mutually beneficial goals. The goals (e.g. efficiency) are generally perceived by the user community as positive objectives.
The attainment of standards by the organisation's membership can establish a defensible perception of quality that is attractive to consumers and acceptable to regulatory authorities (where appropriate). This enables products (that verifiably meet such standards) to operate in a consumer market and with a reasonable expectation that adherence to standards will attract customers.
Standards organisations capitalise on their members desires to benefit from standardisation, and their members desires (pre- standardisation) to ensure that the results of a standardisation process will be in line with their current/planned products and services.
Since device descriptions are to be shared and used by many actors, interoperability becomes a key requirement, for which a standards organisation is the natural facilitator.
Although several standards already exist that have a significant bearing on device descriptions (e.g. RDF, CC/PP, etc.), the benefits to the participants in the standardisation process have not been made obvious. Consequently it has been a struggle to achieve any standards, with barely enough done to demonstrate interoperability. The quality one normally associates with the use of standards is not evident in the case of device descriptions, and this is probably because of two reasons:
There are costs associated with the provision, maintenance and use of information. This section summarises the following:
As the prime determinants of the device features, the manufacturer is an authoritative source of device descriptions.
| Editorial note | |
There are several ways in which suppliers of device descriptions can compete. This section will show several dimensions of competition, but will be far from complete. No judgement will be made regarding which of the competing aspects is superior. For example, in the case of commercial and open source price competition, it is not the intention to show that open source offers a better price but rather to show that there are different prices and that these form part of the competition parameters. |
|
This section examines how device description suppliers compete with each other. The presence of choice and competition in an ecosystem is considered to be beneficial.
Trust is a subjective concept related to the integrity or ability of something or someone. It is difficult to measure, compare or define values for trust. For the purpose of this Note, a device repository that is perceived by users to be more reliable, stable and accurate shall be said to be trusted, and the stronger this perception the greater the trust.
It is inevitable that repositories will contain errors, of varying severity. Those responsible for the respositories will have varying responses to reported errors. Some will permit users to make corrections themselves via a system to check and update data, possibly acting on a local instance of the repository. Other providers will require a more formal process to be followed, especially where the repository is managed centrally. A good mechanism for addressing repository errors will improve trust in the repository.
Repository providers can distinguish their products on the basis of trust. For some users, the ability to contribute corrections where necessary will be seen as trust enhancing. Additionally, the presence of a formal process for validating contributed corrections will increase perceived trust, even for those who are not the contributors of corrections.
Support for repository users also improves trust. This can come in the form of a provider/vendor offering support for a fee, or a community of users offering mutual support.
Errors occur in many places. In the case of device descriptions, the following need to be addressed by the suppliers in order to maintain a sense of accuracy, which increases trust:
There are two main business models to consider. In the commercial model, there are vendors of data repositories that generate revenue by offering quality-assured information and providing support for these products. In the open source model, the community offers data repositories in return for further contributions to the repository.
In the case of a commercial product, the price is expected to be commensurate with the quality of key features (accuracy, scope, depth, etc.). Vendors can compete by varying the prices. The commercial value of the repositories is measured by the revenue generated through sales.
In the open source model, the monetary price is zero. However, there is a reasonable expectation that those who benefit from open source repositories would respond by making contributions in kind. This could be in the form of additional device data, validation of existing data, the provision of documentation, translation of documentation, implementation of interfaces etc. All of these contributions have a commercial value, and the commercial value of the repositories (although unmeasured) is - at least - the sum of the values of the contributions.
Customers of commercial repositories generally expect that the price paid will ensure that the responsibility for maintenance of the repository (e.g. correction of errors) will rest with the vendor. Users of open source solutions, while benefiting from a significantly lower price, form part of a community that collectively bears responsibility for maintenance.
Do the descriptions relate specifically to my business? There is no point in offering descriptions that have no relevance.
Specialised information providers may offer device descriptions that are filtered according to their relevance to a specific purpose. For example, a specialised repository may offer details on the colour gamut of mobile displays. This niche information may be relevant to creators of mobile images.
Are the data restricted in any manner? Sample restrictions in scope include:
The supplier may have other arbitrary restrictions that reduce the size of the collection of data, typically accompanied by a lower price. If this data is specifically relevant to the data user's market, then this becomes an attractive idea.
Is the data limited to a few pieces of essential information per device, or are there hundreds of different data? In some cases (e.g. the download of mobile software) the minute details of the device can be important. In other cases, such detail is irrelevant.
Trust is a value we place on data. When offered two or more sources of data that offer the same information, we choose the source with the highest trust to increase the chance of getting good information from the data.
The issues to be resolved include:
Consider the following scenario:
Manufacturer M provides a highly portable device with a built-in keyboard. Service provider S wants to deliver an interactive form to M and will choose a menu-based solution or a text-entry solution based on the keyboard usability. User U has indicated no particular preference for stylus, buttons or keyboard. Accessibility group A has rated M's keyboard as poor, while M has rated the keyboard as excellent. How should S proceed?
In the above scenario, S may decide that M has a reputation for good usability testing and is honest in its descriptions, whereas A has a tendency to be over- critical. Thus S trusts M's description more that A's, and sends a form to the device requiring the user to enter some text into a field.
Alternatively, S may have no opinion about the trustworthiness of M's descriptions, but knows that the government has suggested A's usability assessments be used whenever possible. In this case, S will choose A's judgement and deliver a sequence of simple menus to the device to avoid the user having to type text.
The scenario above highlights a problem with subjective descriptions (such as the usability of certain device features) since any such descriptions can only be the opinion of the people who created the description. However, a similar problem can occur with data that appears to be objective. The size of a screen would appear to be an objectively measurable value. Yet, to the manufacturer it means the number of pixels present in the screen, while to the content author it means the subset of those pixels that can actually be used to render content. The two values are often different. One could attempt to derive "usable size" from "physical size" but now you have introduced a processing step in the acquisition of information and you will need to consider the trustworthiness of this processing. Thus, any variability in the interpretation of the data can lead to discrepancies and loss of trust.
User preference is not part of device description. May be part of extended repository.
The implication of some device properties is that the end-user may be categorised. For example, the presence of a screen reader would be seen as implying that the user was visually impaired, and this information could influence the content/service provider (e.g. a health insurance provider offering a service via the Web).
What happens to cached information? Will it go stale? Will forwarded information be delivered verbatim, or will an intermediary be permitted to summarise/aggregate?
Many of these issues are addressed by established information security technologies. However, their implementation raises some overheads (e.g. the calculation of digital signatures), which will impact both the cost and the efficiency of the DD respository.
In a working ecosystem, those demanding trust must place a value on this trust and therefore accept the associated overheads.
Content creators are typically authors or aggregators who provide content for direct consumption by end users, or who provide raw material to content adaptors.
The content creators need to be aware of the needs of the different devices, and create content to suit these devices, such as a range of versions of a logo image.
Generally, the more end-users are capable of accessing the created content, the greater the potential revenue that can be created from such content.
| Editorial note | |
This section describes the potential architecture and physical locations of the mechanism behind a working Device Description solution. The DDWG has repeatedly discussed the DNS (Domain Name System) architecture in which a combination of delegation and redirection enables the system to be distributed globally. Each entry in the DNS is labeled as authoratitive (for a zone under its control) or non-authorative, in which case it is caching information that originated from an authorative source. The DNS merely demonstrates that a resiliant distributed database is feasible. Unfortunately the DNS lacks many features that would make it a candidate model for the DD Repository, including:
In a successful DD ecosystem, the cost of deploying the repository would need to be met, most likely by those who derive benefit from its existence. This continues to be a matter for discussion by DDWG. |
|