Quantum Data - the heart of DetectRight

DetectRight's core technology is the Quantum Data Tree (for on/off properties) and the Quantum Data Collection (for numbers and other descriptive data).

It lies at the heart of DetectRight's ability to be compatible with anything it likes, which in turn lies at the heart of our ability to deliver customer-life-enhancing products and tools.

Trees are the only way

Traditional databases (not only device detection ones) use "fields" or "properties", and values.

resolution_width=240
resolution_height=320

This appears straightforward until you realise that the actual item of data you're referring to is massively ambiguous without outside information.

  1. The resolution of what? (in this case: the primary display screen)

  2. In what context? (in this case, measuring physical pixel size)

  3. What units are being used? (in this case: pixels)

  4. What format should the value be in? Is this a string, integer or what? (in this case: positive integer)

The information you need (the ontology of the datapoint) would generally be a schema definition or development document, if you're lucky. But generally the most attention is paid to syntax - the format of the field itself.

In many cases, any description of what the field represents, its context, and its units, are either assumed to be obvious, or are included in a text description: or are worded so vaguely that it's difficult to know what it stands for. In some cases, I get the impression that even the authors didn't quite know.

Let's consider the problem in more detail.

Screensize again:

screenx=240
screeny=320

This is, quite obviously the same data as the previous case. But how do we know that this is referring to the same thing as the previous data?

This is not just an academic issue: it goes to the heart of making sense of the data about mobile devices from different sources: manufacturer data, search results, UAProfiles, Header information, DOM interrogation.... and more.

What our technology does is to regard each "key" or "property" as a shortcut or pointer to a path and a payload in a data tree representing the combined data about the entity.

For instance, we might represent physical screen size in pixels as:

Display//dimension=size{value:240x320;units:pixels}

DetectRight knows that screenx, screeny, resolution_width, resolution_height correspond to the various bits in the path above, so it automatically import data into the right place in the tree, and can retrieve it later using a different shortcut name pointing to the right place.

Quantum data?

Device databases always have to cope behind the scenes with conflicting data: arguments between data sources about whether something is on/off, or arguments about sizes or other features. This is always handled behind the scenes, and results in an "approved" set of static data, which is then shipped.

Implicitly or explicitly, this generally depends on a "trust" level of the incoming data source: and there is always a tension between high-trust data sources that might make a drastic error, combined with lower quality data sources who are agreeing with each other, and who happen to be right.

DetectRight's Quantum Data Tree does this resolution in real-time while it's creating a profile: which is the key to producing truly dynamic profiles which reflect the device being seen, not an ideal example.

But why Quantum?

In Quantum Mechanics, the state of something is, essentially, a probability, which is resolved when it's observed.

In DetectRight, every item of data or node in a tree has a number of possible states, which is a combination of:

  • Importance of this datapoint. Importance and trust are linked, but importance takes into account the context of the datapoint: for instance, a datapoint for a browser the phone was shipped with, but isn't using, is zero, even if the trust level is huge.

  • The status of this datapoint? (negative information, or positive information? on or off?)

  • Was this datapoint a "direct hit", or has it been implied from something else such as its position in the tree?

DetectRight collects these states, and resolves them at query time, using statistical methods where necessary to balance high-trust lone datapoints against collections of lower quality ones.

Why trees?

A mobile phone is a collection of components, combined together out of technological necessity or marketing/customer requirements.

This immediately leads to a one:many relationship between a phone, and the components in it: such as Browser, OS, JVM, Chipset, CPU, etc.

All device databases except DetectRight are tied to a broken, outdated assumption: that the collection of components will never change.

Attempts to handle this in device databases such as DeviceAtlas or WURFL are sticking plasters or hacks on an essentially broken model dependent on static predictable heirarchies.

The ecosystem and its fragmentation are chaotic and unpredictable. The only way to properly deal with it is to build a system which can model (and make sense of) any arbitrary collection of components combined together.

Any Quantum Data Tree can be merged with any other Quantum Data Tree, to produce a composite tree. This is hugely powerful (and has potential uses outside of the mobile sphere: for instance, customer preference modelling): and it means that property trees for different components can be merged and then queried.

Nested Properties

The other advantage of the Quantum Data Tree is that you can nest things together and assign properties to them. This is very useful in the field of AV, which has an explicit container/codec/profile relationship to model: something which is impossibly unwieldy to do properly in a flat key/value device profile.

For instance:

Media//Player//Codec:Video:H263:Profile 0:Level 30//capacity=rate{max:10;units:kbps}
Which in a static database would be something like: "videoPlaybackCodecH263Level0Profile30MaxBitrate" (no database has this information, to our knowledge, but DetectRight can represent it).

For instance:

Media//Player//File Format:Video:3GP//Codec:Video:H263:Profile 0:Level 30//capacity=rate{max:10;units:kbps}

DetectRight can comfortably represent this statement: "In a 3GP file using the H263 codec at Profile 0, level 30, the max bitrate is 10kbps". In another database, this would be videoPlaybackAVIH263MaxBitrate. Considering the number of codecs, file formats, profiles, and contexts, you can see that the traditional key=value system simply breaks down. There are too many possible items of data to have shortcuts for.

DetectRight allows direct querying of a tree structure using a rich but understandable API to get at information you know is there, but which you don't have a name for.

Implied Properties

If you're maintaining a database, consistency is all important. And part of consistency is maintaining the relationship between linked fields.

For example:

playback_mp3 = true
ringtone_mp3 = true
These two fields are linked: playback_mp3 is a more general question ("Can this device play back MP3 in any context?") than ringtone_mp3 (can MP3s be assigned as ringtones?). However, the workflow of maintaining these fields is manual: it's entirely possible for them to drift out of sync, resulsing in, for example:
playback_mp3 = false
ringtone_mp3 = true
Considering how many devices are in a database and how many linked fields there are, it becomes a consistency nightmare.

Quantum Data Trees can link these two fields painlessly

Searching and querying

Let's consider the "import" paths of playback_mp3 and ringtone_mp3 when both are true:

playback_mp3 = Media//Player//File Format:Audio:MP3//status=1
ringtone_mp3 = Profiles//Ringtones//File Format:Audio:MP3//status=1
However, if you were querying the tree to ask the question: "does this device support MP3 in any context at all", you would do this:
result = *//File Format:Audio:MP3//status=1
Which literally says "anything in this tree is MP3: find it". So, if you have ringtone_mp3 populated, playback_mp3 will pick it up structurally.

More cleverly, if we ask this question:

*//File Format:Audio//description
We can extract a list of all of the audio file formats supported in the tree, ever. Which,in this case would be "MP3".

But there's more...

Consider this path:

Media//Player//File Format:Audio:MP3//status=1
This is telling us that the device plays back MP3 files. But its position in the tree is also telling us other information:
  • It can play back at least one type of audio file format

  • It has audio output capabilities

  • It has some form of general media support

For a tree with only one datapoint going in, there can be more than one coming out. The implied capabilities are "indirect hits", and the one that generated the datapoint is a "direct hit".

But what about negative data?

Just as important as knowing that something can do something, it's important to know when they can't:

Media//Player//File Format:Audio:MP3//status=0
But unlike with a status=1, the position in the tree cannot be allowed to imply anything: or you get a device that doesn't support MP3, but is claimed as supporting audio. In a Quantum Data Tree, this situation is handled.

Thanks

Once again, thanks for reading. Hopefully now you'll understand why the field of device data really needed a good shaking up because the knowledge management (inherited from relational databases and legacy systems) just isn't up to the task of representing device information properly.

 
DetectRight Quick Links
Products and Services

 Device Detection Software
 Research Tools
 Device Data and Metadata
 
Downloads
 
Documents
  FAQ
  White Papers
  Legal and Privacy
Why Choose DetectRight?
DetectRight is trusted by:
DetectRight users say:

DetectRight has been a great advantage for our products. Its unparalleled accuracy gives our customers the best possible experience, and the best compatible content. Great support allowed a customized solution that met our needs exactly

- Alan L, Mansef
DetectRight Fact:

DetectRight servers have been responsible for over 100 billion detections since 2009!