Prolog Client with Terminus running locally in process

Hello,

I am interested in trying out Terminus DB within SWI Prolog.

Is there a prolog client available or (simple) instructions how terminus could be used as an imported module.

If yes, how would an installation look like to that any Rust based compiled libraries are loaded correctly.

thank you,

Dan

Yeah, this is very possible. If you follow the terminusdb install instructions, you will end up with a built version of the rust library. You can start swipl from the terminusdb installation directory and type:

?- ['src/interactive.pl']

This will allow you to call terminusdb predicates without starting a server.

The interactive use of the database is not documented, but it is ubiquitous in the internals, so you should be able to make out how to use it. Search for ask and you’ll get some examples. In addition the api directory has predicates that are used by the CLI and the server.

I just noticed the terminus_db library, which seems to be implemented here:

I guess this is the most low level API of the triple store.

I am curious, in what way is the underlying rust implementation better suited as basis for Terminus DB than having an equivalent implemented in swi prolog as well …

A few clarifying thoughts would be much appreciated …

Dan

Speed and scaling. You need persistence and you need reasonably small size. We played with alternative arrangements and they just don’t scale to 10s of millions of objects well, so we started using HDT (which Jan wrote a plugin for). We then wrote our own special purpose library in order to deal with some re-entrance bugs and then extended it for our use case.

Essentially we implement a 3-arity predicate which can scale well for simple datalog style terms.

1 Like

Thank you, Gavin,

I hope you don’t mind some further followup questions:

To get a feeling for the runtime behavior of the underlying graph:

Is there some explanation available how the graph was implemented by way of underlying data structures.

In particular to ensure predictable performance as the graph continuously grow, and to deal with Rusts way to avoid double linking, and hence avoid representation of graph like structures through pointers.

I am also curious what kind of indexing or lookup structures were put to use …

any pointers in this direction would be great.

thank you,

Dan

We have a description of the data structures in our white paper, which is in the docs folder of the main repository. That should get you started!

Many thanks for the pointer.

It will take me time to understand the paper in depth, but some questions seem to rise such as:

Storing Identififiers vs. strings

What if the graph database is used to store identifiers to strings rather than strings – such as to establish a multi-lingual structure – would this significantly affect the behavior – since no prefixes string structures would be given.

cost of traversal

GIven, what seems to be, dictionary based on subject-based encoding what is the lookup cost from a object node to a linked subject node.

And, similarly, what if a graph is traversed from object to subject – would this become more expensive?

many thanks

Dan

p.s. i guess there are certain access patterns that are more prevalent with RDF based data – such as subject → predicate → object, or perhaps predicate → subject → object – which are optimized … do i understand this correctly?

  1. Strings are just being used here as identifiers. It doesn’t really matter much either way. The lexical organisation in a dictionary just facilitates search.

  2. Lookup starting at the subject or object is simply the cost of the dictionary lookup + reading the position in the array. Lookup from the predicate first requires reading from a wavelet tree. This later mode is quite rare in practice.

Thank you.

The paper suggests better caching behavior in the current design.

Was this a main reason why dictionary lookups during graph traversal outperformed a pointer linked graph?

Was this perhaps compared during early design explorations?

Dan

We explored a few design aapproaches but this one seemed to perform well for query.