v5 data model.

This described the data model in a previous version (v5). Current version is looking into building on existing data model.

Data can be anything:

  • Text
  • Images
  • Checklists
  • Numbers and forms
  • Mind-maps
  • Programs
  • Forms
  • Webpages
  • JSON-data
  • Etc. etc.

In order to work efficiently with data, we want a simple structure. Data consists of items. For example if we have a dictionary, it consists of a collection of entries that contains a term and defintion. These items have different types: "collection", "entry", "term" and "definition".

If an item is something that can have a type, some content, and a list of subitems, then this structure covers all the kinds of data above, and makes it easier to work with the data in a structured way.

Let us see a document as items instead of lines of text. Then we navigate between chapters, sections and paragraphs, instead of pages and lines. And we can work directly with the conceptual rather than presentational content.

Let us see the mathematical operations in a calculator, or the filters applied to an image, as a structure of items. Then we have a new powerful way to interact with apps.

Let us see program code and data as items of an "abstract syntax trees". Then we can navigate and work within the structured data rather than a text file.

If we have an efficient tool to work with this kind of items, then we can apply it to any kind of data.

This is Veduz, the app I am building.

Data structure (technical)

The core item data structure consist of:

  • a type
  • binary data (possibly with zero-length)
  • a list of items (possibly with zero-length)

Each item can be written within square brackets, where the type if followed by a colon, and then the actual data, ie. the JSON:

{foo: [1, 2, 3, "blah"], 
 baz: null, 
 blah: true}

can be represented like:

[Dict: 
   [Key:foo [Arr: [Num:1] [Num:2] [Num:3] [Str:blah]]]
   [Key:baz [Nil:]]
   [Key:blah [Bool:true]]]

While this is more verbose, it is also more general.

The item data structure is immutable, and the implementation i swappable.

The initial simple implementation is just a list of items. A more efficient implementation, would have specialised implementations based on small list length. And clojure-like persistent vectors for large lists, – with HAMT-indexing of Key's. And also specialisation on type name (as an implicit enum).