KnAlledge (part of Colabo.Space ) is a data store for Colabo.Space applications.

IMPORTANT DON'T MOVE THIS - IT'S placeholder FOR A TOC

Basic Principles

KnAllEdge - Colabo.Space Data Store

The following figure is a conceptual representation of KnAllEdge, a data store for Colabo.Space applications.

It is a graph-oriented store, and it is best imagined as a social graph, where each person is represented by a node, a social connection by an edge, and finally, a social group by a container in the KnAllEdge store.
Its focus is on simplicity, generalization and supporting a declarative and semantic design of the application’s entities.

Demonstration of KnAllEdge benefits

We will go through a real usecase implemented in the LitTerra Ecosystem.

LitTerra is a world of literature; a place where readers can explore books and walk through them.

We will see how the system implementation and development is drastically simplified after being implemented on top of the Colabo.Space and KnAllEdge foundation

KnAllEdge - Data Store - LitTerra Example (initial)

Let’s see an example. Here we have three types of entities: books, books’ chapters, and books’ authors

Entities are realized as KnAllEdge nodes, while the relationships between the entities are realized as KnAllEdge edges
Finally, corpora are realized as KnAllEdge containers.
This is all fine. However, ...

KnAllEdge - Data Store - LitTerra Example (changed)

… the main problem with this is that entities change over time; Books should support multiple authors, and multiple books might need to be organized in corpora:

This requires changes in the model, and changes require additional development time and costs and introduce delays and bugs.

Conventional Application Stack

In a Conventional multi-tiers App Stack (illustrated) there is no single point of truth, which means that if we need to change entities, like supporting multiple book authors, we will need to change the application at multiple places.

Additionally, many parts of our application will need to be replicated for each of our entities; books, authors, chapters, etc.

Colabo.Space Application Stack

When we build multi-tier app on the Colabo.Space and KnAllEdge stack, we can simplify the process by describing our entities through schemas. We will have one schema for each entity; like the book, author, and chapter schemas.

This helps us to have a generic application with a single point of truth - instead of changing the application at many places we can simply change the schema.

Design Patterns

When should we identify (isolate) something as a separate entity

Short answer: It is all about data integrity and single point of truth.

Imagine you have a book entity and one of its properties is the name of the book publisher. It makes sense to provide just a textual field which will contain the publisher name and provide it for each book.

The first problem is: what about repeating the same publisher in mulitple books:

• Retyping
• Providing mistakes
• what if publisher name change, should we propagate change in every book, etc

What if we want to provide the publishers' address?

It seems that publisher is an independent of book, and as such it should be isolated as an unique entity which will be associated with book through edge.

IMPORTANT DON'T MOVE THIS - IT'S FOR A DATE IMPORTANT DON'T MOVE THIS - IT'S FOR TOC