Warning:
This wiki has been archived and is now read-only.

DeviceDescriptionEcosystemCompetition

From Device Description Working Group Wiki
Jump to: navigation, search

This is the Competition section of the Device Description Ecosystem document. See the DeviceDescriptionEcosystem overview.

Competition

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 judgment 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

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 repositories 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.

Accuracy

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:

  • Are there errors in the data?
  • Are errors corrected? If so, how fast?
  • Has the data been approximated or normalized? Will this have consequences for the consumer?
  • Is the data based on samples? How representative are these samples?

Price

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.

Relevance

Do the descriptions relate specifically to my business? There is no point in offering descriptions that have no relevance.

Specialized information providers may offer device descriptions that are filtered according to their relevance to a specific purpose. For example, a specialized repository may offer details on the color gamut of mobile displays. This niche information may be relevant to creators of mobile images.

* In time, it is expected that basic device information will become more widely available, but there will still be a demand in specialized areas for specific device information. There is an expectation that the general and the specific repositories will be compatible (in the way data is accessed and the way information is represented). In this way, the specific repositories can be seen as compatible extensions of the general repositories, with all the benefits this evolutionary path provides.

Scope

Are the data restricted in any manner? Sample restrictions in scope include:

  • Geographic regions
  • Device classification (size, feature, price etc.)
  • User type (fashion, teen, executive etc.)
  • Service type (news, messaging etc.)
  • Temporal (e.g. only the devices manufactured since YYYY)
  • Operator partnership

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.

Depth/detail

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. * In a generic authoring environment, where the author can influence the adaptation of content based on any available contextual data, having a broad range of data in the repository may be beneficial (or at least perceived to be so). In pre-configured adaptation solutions where the necessary contextual data is known in advance, a repository that only holds that particular data may be advantageous (i.e. less overheads, less maintenance and potentially better performance).

Availability

X Is the data available now? Do I have to wait for delivery? How quickly to I get updates? Is it available non-stop (if it is hosted somewhere else)?

* Providers may compete on the availability of their repository data. In some cases, the data is immediately available, especially if it is hosted on a public server. Alternatively it may be available from a server following a short registration and/or payment step. These are high-availability scenarios and may be more attractive to repository users than other sources of data that involve greater delay. For example, an instance of a repository may be delivered physically on various storage media for installation by the recipient.

* Users of repositories may also be concerned about the frequencies of updates. Updates are necessary when a new device becomes available, or corrections are made to existing data, or when new categories of data are introduced. The time between updates becoming necessary and the data user having access to the updated data may have a bearing on the decision to use a particular source of data.

Timeliness (removed)

X When new devices appear, or new information (including corrections to errors), how soon will the data be updated to reflect the changes? {i} This is now covered in the previous section on Availability.