Universal Data (UD)
Any data that has been expressed using the semanto-relational data model is called universal data or UD.
UD is called universal because it has no protocol overhead, it is pure information (in theory at least, in praxis there is some administrative and technical overhead). That makes it universal in the sense that it is not specific to any application or protocol. Nor is it limited in any way as of what kind of information it can hold (again, in theory, there might be technical restrictions in praxis).
UD and SRDM are content-neutral, they do not know what information they are handling and they do not care about any structures or patterns that might be inside that data. To them, the content has no meaning. This mainly means that a UD-repository (database) can hold arbitrary information, regardless of complexity. Moreover, it means that a UD-repository does not need to be prepared in any way to hold a certain type of information. It just absorbs information. A UD-repository is like a big bucket in which one can throw anything. As long as the thing fits, the bucket will hold it.
Universal data storage is chaotic. That means that the order of single information-bits is irrelevant, they can appear in any order. This fantastic feature has far-fetching consequences.
Maybe the most surprising consequence of the chaotic storage is automatic information merge: Any (well-expressed) information merges automatically with any related information. This feature is universal; it does not matter if you merge just an entity with one additional property or if you merge two complete books. In the first example, you would get an extended version of the entity, in the case of the two books it would result in a complex union of the complete contents of both books, down to the smallest detail.
If we go back to the bucket-analogy, things get a bit weird: This is like a bucket that pulverizes things thrown into it; anything that we add is ground up and mixed with anything that was in the bucket before, ending up in a homogeneous pile of elementary particles. Nevertheless, no matter how much we shake the bucket and stir its contents, if we grab one single piece of matter that is in there and pull it out, the object it once was part of materializes in front of us, all the pieces necessary to recreate it just “magically” stick in the right order at the right place.
Consequently, we can design new information distribution concepts. As UD is content neutral, we can store any information inside a UD-repository. It also does not really matter how many repositories we have or where they are located as long as we are somehow able to query them. We can store any full or partial information in any randomly selected repository, in any order. Later, if we need to retrieve a specific information we just query all available repositories and add all results into a new, ad-hoc repository where they automatically merge into a union of the individual results. We should end up with an exact copy or an enhanced version of the original information.
Using UD without a graph language does not make much sense, graph languages give universal data meaning and structure. Graph languages understand the data; they can query, analyze, interpret and structure it.
In praxis, that can potentially mean interesting new features for users. It could be the end of scattered files across single-structured file systems that never seem to be in the right place. The end of multiple proprietary file formats for the same thing that never seem to be compatible with each other. The end of having to distinguish between file, information and metadata. One repository – one big bucket – that holds all information. Pictures, documents, contact information, memos, ideas, orders or tax returns. Anything. Related information automatically merge. It is a bit like storing information in our brain, we can add any type of information in a chaotic way and they still end up creating a coherent picture of the world they describe.
This post is part of a comprehensive introduction into SRDM, graph languages and Havel.
Continue reading: Graph Languages
Comments