How it Works

You don’t need a data model

Data is just facts, and people communicate facts easily by saying things like “the height of the Chrysler building’s antenna is 71 feet“.

Truenumbers represents data using statements like that. but in a very simple language. This language is human readable but far more limited than natural language. Because it is structured, Truenumbers statements support storage, computation and search as well or better than relational or object based data can. Without restrictions on nouns or adjectives, Truenumbers can express facts about anything. No data model required. Let’s see exactly how Truenumbers represents facts.

Building truenumber facts

The heart of the fact language is the Structured Resource Descriptor (SRD), which is our way to encode noun phrases that in turn, are used to write sentences called truenumbers. Truenumbers sentences are our data. An SRD is a path-like string of words separated by colon ( : ) and forward-slash ( / ) operators. The colon operator denotes an adjective-noun pair, basically an “IS-A” relationship. For example, building:Chrysler is the SRD for the phrase “Chrysler building”. Note that the noun is first in the SRD – the reverse of the English phrase.

The slash operator acts like the preposition “of” used in English to denote belonging to, or a “HAS-A” relationship. The phrase “antenna of Chrysler building” is therefore equivalent to SRD building:Chrysler/antenna and represents the subject of the fact we started with: “nominal height of antenna of Chrysler building is 71 feet”. That description begins with “nominal height of” telling us that height:nominal is the property of the antenna this fact specifies. We represent properties as SRDs too, so now we have the pieces to construct the fact as a truenumber in sentence form:

antenna of Chrysler building has nominal height = 71 ft

It’s OK to use SRD’s in sentences if you want, instead of equivalent phrases, so this fact could also be written:

building:Chrysler/antenna has height:nominal = 71 ft

So, a truenumber consists of the subject the fact is about, a property of that subject, and the value of that property. Truenumber sentences are convenient for people to read and write, and they correspond to a data structure in the computer. This structure can have different implementations for storing in different databases, but the most portable representation is JSON, the format used by the Truenumbers APIs. In simplified form, a JSON truenumber looks like the following (the actual format for the API is a bit more complex):


{
  subject: "building:Chrysler",
  property: "height:nominal",
  value: {
    type: "numeric",
    magnitude: "1046",
    units: "ft",
    dimension: "length"
  },
  tags: [
    "location:USA/city:New_York",
    "project:demo:truenumber"
  ]
}


In the JSON above, we notice an array of SRDs labeled “tags”. A truenumber can be decorated with any number tags to enrich, qualify or classify it The tags shown tell us that the Chrysler building is located in New York, and is associated with a truenumber demo project. Tags allow us to aggregate facts or create relationships among them. Talking about reality In the absence of a governing data model, it’s the SRD subjects, tags and properties that shape the knowledge in truenumbers. Given a bag of truenumbers, the SRDs tell us what subjects being talked about, what sort of properties are of interest, and so forth. SRDs read left to right, from the general to the specific, so they also make excellent keys for indexing or wildcard searches, and they naturally form trees, for example: These are useful tools for visualizing the vocabulary of a domain. As we gather more facts about New York, for example, we might find that the building tree has hundreds of branches if we’re talking about many buildings. But an SRD is computationally very light-weight, being only a string, so vocabularies can be dynamic, complex and large.