Re: Scheme Request for Implementation: Generic Tuple Store (SRFI-168)

I created a repository to make it easier to test a real implementation
of that specification:
https://github.com/scheme-live/srfi-167-and-168-tutorial#setup

On preliminary benchmarks that code is faster than blazegraph!

This is not perfect (one of the cloned repository is 1G big) but it should
get you going.
Also it does require a linux box but doesn't require system installation.

I made progress regarding the functional store aka. fstore ie. a versioned
generic
tuple store (which is the reason I needed the nstore and eventually
discovered it
can be useful in other contexts).

It is bundled in the above repository, it is not documented [1] but there
is a beginning of test
suite at:

https://git.sr.ht/~amz3/chez-scheme-arew/tree/master/src/arew/data/base/fstore-test.scm

[1] well, the API of fstore is the same as the API nstore, except you have
to specify a branch
against which the query must happen.

Le sam. 8 juin 2019 à 13:51, Amirouche Boubekki <
amirouche.boubekki@gmail.com> a écrit :

> I am pleased to announce that we reached the last call for comments on
> SRFI-168.
>
> That is, a generic approach to triple and quad store. It support tuples of
> n-items.
>
> While it might seem overkill to support tuples of n-items, it was somewhat
> easy to implement (once you know the math
> <https://math.stackexchange.com/q/3146568/23663>). Also, I need such a
> database
> abstraction to implement something (that I think) will be suitable to
> version
> tuples in a direct-acyclic graph (ala git).
>

I got a question off-list about what permutation-prefix means and where it
is
useful.

There is a sister question on stackoverflow that try to explain in terms of
programming what problem I am trying to solve:
https://stackoverflow.com/q/55143485/140837

I will work on a document that will better explain how it is used and why
it is useful.


> This work was inspired from:
>
> "Collaborative Open Data versioning: a pragmatic approach using Linked
> Data"
> Federico Morando, Raimondo Iemma, Simone Basso et Lorenzo Canova
> https://iris.polito.it/handle/11583/2617308
>
> Hopefully, it will allow to build some kind of portable and scalable
> wikidata & wikibase.
>
> The very last version of the specification can be read at:
>
>
> http://htmlpreview.github.io/?https://github.com/scheme-live/srfi-168/blob/master/srfi-168.html
>
> A few hints:
>
> - It is supposed to be supported by an ordered key-value (wiredtiger,
> foundationdb, Oracle
> BerkeleyDB, TiKV, leveldb, rocksdb...), see SRFI-167
> <http://htmlpreview.github.io/?https://github.com/scheme-live/srfi-167/blob/master/srfi-167.html>
> .
>
> - It can support (only!) scheme base data types but not complex ie.
> bigint, float, string,
> symbol, bytevector and vector and list of those preceding. This is
> implementation dependant
> but the implementations so far only support those.
>
> - The query language is based on stream-processing. All queries are at
> least O(n)
> where n is the length of the seed generator (nstore-from).
>
> - The specification is written in a way that will allow support geospatial
> indexing
> directly in the nstore and outside the nstore but inside the same database
> so that
> ACID semantic still holds. More generally, the nstore abstraction can live
> along side
> other abstractions in the same okvs database, which allows to implement
> specific
> indexing scheme to support geospatial indices or better pagination.
>
>
> It is still time to make feedback and I hope you do :)
>
>
> Amirouche ~ amz3
>