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
Tags
design5.mdwn
The work on [[design4]] was interrupted by my end-of-semester exams. The exam period is not over yet, but I don’t want to put Naya on hold. I didn’t make any progress in the last 2 weeks, which is already bad because Naya requires more attention and focus than usual.
This page, design5, will try to rebuild things from the bottom up while planning the solver algorithm skeleton.
Basic Query
Let’s start from the most basic query we can write, which still can make sense. This query contains a list of parameters we use, and a single quad expressing a condition. In other words, it may for example look like this:
q = (P, s)
- P = $i $s $p $o
- s = ($i $s $p $o)
This will give you a copy of the whole database. Some notes:
- Each parameter must appear in the statement pattern
- Each statement pattern component is either a parameter or a Smaoin entity
Now, how do we resolve such a query? Ideas:
- Brute force: Go over all the statements in the database and try to match
- Indexing: If one of the statement pattern components is an entity, we could create an index which maps entity-role pairs to groups of statements in which the specified role (component) has the specified entity. We could even map just entities, and ignore roles. It would allow us to execute the brute force algorithm on just a subset of the database, ignoring a possibly large number of statements which we know are irrelevant and won’t match.
In any case, it seems we have to do the go-over-statements process with some group of statements. Let’s assume for simplicity we use brute-force, so we need to match all 4 components in order to determine whether a candidate is a valid match.