Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

• master

Tags

model.mdwn

First let’s model the database representation. Before I open Dia and make some nice diagrams, let’s plan things in words.

A database will be represented as a Saugus::Repository. The idea it to take the repository and a given query, and return the solution. Since Saugus is itself a semantic store, its backends don’t have have any standard interfaces for querying, therefore Repository has a query member function which runs the query and returns the result. In addition, it should be possible to have a query_async function which returns the answer later. But for this I’ll probably need C++11 or Boost or Glib threading support, so we’ll see about it later.

Our Repository implementation will start as a hardcoded in-memory structure, because it’s enough for Naya’s design work, at least for now. There are several options for organizing the quads:

1. Ordered container (e.g. vector or deque or std::array)
2. Sorted container (std::set, std::multiset or the maps, e.g. sort by subject)
3. Associative container (std::unordered_set or std::unordered_map, e.g. mapping by subject or by predicate)

In any case, this should be implementation detail for performance tweaking. I suggest we start with something simple like a vector, and traverse it seqientially. This works great for selection queries. For modification, it may not be best, although the fact the order doesn’t matter allows to copy things from the end to the deleted spots, so it would even work reasonably well with such queries.

Each container element is a Statement. Each Statement has four components. Although types don’t make a difference yet, “5” and 5 are not the same and the representation should take that into account. Reminder: The different kinds of entities are:

• resource uid
• character
• string
• number
• boolean

Actually I don’t remember if characters are still in. How do I check now? The most recent Smaoin documents are not even in the wiki yet. I’ll try to search “character” in the latest files and see if I find anything…

All I found is a mention of the idea that when treating types as representations without meaning, there is no reason to have characters as a separate type. That is true, but who said Values don’t have any meaning? You can still have functions and relations over them and so on. Hmmm… until I import all the Smaoin content and organize it, let’s keep the Character type. It’s easier to have and remove, than to not have and add later.

I also wrote a lot about rules of uids - which characters are allowed in them, and which aren’t. This could actually help use strings for everything, but let’s not get into technical details. I will use separate constructs.

Note that 3 out of the 4 components are always of the first kind: uid. These indeed can be strings directly. There are therefore 2 options:

1. Each component is a value-type pair anyway
2. uid-only components belong to a Resource class, but one is Entity

The only operation currently done on entities is comparison. Later it may also be hashing or something like that. But anyway, it doesn’t contribute anything to have classes for such small things. Let’s just ignore the memory efficiency for now, especially because it’s not a disk storage representation, and use a simple consistent model.

Statement will have 4 Entity components, where each has a value and a type. The type can be represented as an enum class.

Let’s skip the diagrams for now. I want to stabilize the model first and have some code that works.

Coding in Saugus…

I also need classes for the query and for the returned result. I can call it Graph or something like that. In fact, Graph can be simply a wrapper around the in-memory repository implementation. Or the other way around: the implementation can be written using Graph as the actual data structure to operate on. Hmmm… the second options sounds better. But don’t worry, things will change a lot anyway, e.g. query results don’t have to have 4 columns so they can’t really be Graph. Hmmm… let’s take this a step forward and have a QueryResult which is not dependent on row length :-)

Graph is still a good thing to have.

By the way, I can also use Boost Graph Library with directed labeled edges.