Orientation

In both semantic model standards Topic Maps and RDF/OWL and in many other NoSQL approaches to solve efficiently the problem of how to represent relations and relationships one major stumbling block is raised beyond all efforts: the namespace. It is a language problem, the babel we have in our civilized world is transferred into our IT systems. But machines do not have to understand our language, we do.

Good news for everyone, there is an alternative way of thinking on modelling data:

• token based,
• fully symmetrical,
• bidirectional linking,
• single instance centric,
• data-type agnostic.
• namespace agnostic,
• fully contextualized,
• structure-free, and many more novelties....

Hence AtomicDB Data Model or as I call it AIR 

Atomic Information Resource Data Model

The Entity-Attributes 'Silo' Structure

The problem here is that from a semantic point of view, similar diagrams are in need from users that want to express business processes but when we reach the implementation stage software engineers have to marry business requirements with the technical constrains of the database system hence the ER diagram you see. Generally speaking this is known as "The Model", a conceptual view of the user on data. The ER version of the model has several limitations, due to the architecture of RDBMS. The main one is that each attribute remains enclosed in the table structure and in the case the same attribute appears in another table, the dataset that it represents has to be repeated. In our example above, the primary key (pid) of "Parts" is repeated as a foreign key (catpid) in Catalog. The difficulties that arise in data aggregation due to this limitation are substantial.

How to Break Free from the Entity-Attribute-Value Paradigm

The relational and the entity-relationship model made a huge impact in the IT world for nearly half a century. But during this long period of standardization it meant also one thing, everyone had to comply with the rules and requirements of the model. Everyone had to think in terms of Entity-Attribute-Value or Subject-Predicate-Object as it is known in the RDF semantic model. Programming languages have been affected to from this monolithic way of thinking. Although it proved to be advantageous to program with classes and objects, it created an artificial problem of how to map these onto persistent data structures on the disk, also known as the object-relational impedance mismatch problem. Knowledge representation frameworks did not escape from this too. Ontologies expressed in OWL followed the same paradigm with classes, attributes, and values. Serialization methods such as JSON (object-name-value) and XML (element-attribute-value) also came after the same rationale.

The Signified - Sign - Signifier Alternative Paradigm

The aforementioned Entity-Attribute bond and distinction plays its role here too. But most important another concept, 'value', is added to make this triplet even more difficult to handle in our digital world. This is mainly due to the fact that three perspectives, the conceptual, the representative and the physical layer encoding are mixed in such a way that it is very hard to separate and work with them at distinct levels of abstraction. The R3DM, or S3DM, conceptual framework that we discuss in Part 3 is based on the natural process of semiosis where the signified, i.e. concept, entity, attribute and the signifier, i.e. value are referenced through symbols, i.e. signs, at discrete layers. The same philosophy is shared in the architecture of this database management system and we demonstrate this with the following example.

AtomicDB Model and Concepts

This demonstrates fully the point we have already made about Entities and Attributes. Entities in this diagram are simply formed by grouping Attributes together. One or more Attributes are shared between two or more Entities. According to the AtomicDB terminology, shared attributes are called bridge concepts and this is the equivalent of the relationship that is implemented with primary and foreign keys on two tables but here we are completely independent to mix and match them. For example PartColor, could be merged with another attribute from a different table in another relational database.

Read more about....

• AtomicDB Collections and Records
• Assimilation of Parts Table in AtomicDB with Ouput in Wolfram Language

Join Data Science Central to comment on this post.