ggleason

My two cents: https://github.com/GavinMendelGleason/syntactic_versioning/b...

We don't believe the GPL was technically an impediment to using our database because everything involves communication over API.

Moving to LGPL doesn't improve anything with regards to the non-problem of using the GPL for this purpose in the first place.

The problem lies outside of the technical/theoretical legal entitlements.

We want the database to have 100% of the features and not have to have a proprietary split between the database we offer to enterprise and to our open source community.

We want people to build stuff on our database whether they are companies or individuals and we don't want to encumber this with stumbling blocks.

We intend to do this by having a SaaS revenue model which doesn't require we hobble anything in the database in order to make money.

The substantive points have little bearing on perceptions held by those that are key to the survival of a small startup and that can't realistically be changed by a small startup.

One could of course feel that the difference in obligations are more important, but those who believe this are also free to fork the project and demonstrate just how easy survival would be trying to ignore the consequences of the perceptions.

It's clearly possible for some GPL projects to keep forging ahead despite the difficulties, but survival rates paint a picture that isn't so kind.

I'm a big fan of the various "gradual" approaches so this paper really caught my eye.

Gradualizing the Calculus of Inductive Constructions (https://hal.archives-ouvertes.fr/hal-02896776/)

I'm not sure if this is precisely the direction things should go in order to improve the utilisation of specification within software development but it's a very important contribution. As yet my favourite development style has been with F-star but F-star also leaves me a bit in a lurch when the automatic system isn't able to find the answer. Too much hinting in the case of hard proofs.

Eventually there will be a system that lets you turn the crank up on specification late in the game, allows lots of the assertions to be discharged automatically, and then finally saddles you with the remaining proof obligations in a powerful proof assistant.

LukeEF mentioned the fact that all contributors consented in another comment.

However, since the code was GPLed, it's still GPLed at the commit prior to the licence change. One could theoretically fork at that commit.

"So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc."

That's correct.

"I think it's definitely worth supporting differing depths of reference embedding along different paths."

Yeah, path unfoldings were something we were thinking about but ended up on our very tall stack of things we want to do. You can generally get around it just by calling the get_document API on the client end from javascript, although it is true this will be much slower.

1. We do support framing. Our documents are defined using a special superclass called "terminus:Document". Anything in the downward closed DAG up to another "terminus:Document" is considered part of that document. You can ask for some number of unfoldings of the internal documents by passing a natural number - in which case you will frame the underlying documents. We might extend this framing to allow more sophisticated approaches later if there is interest.

2. We have not performed benchmarks against RedisGraph. We intend to do benchmarks in the future but are currently focusing on collaboration features rather than raw speed.

I had just come up with some methods of using GPUs to speed up graph search when I saw the RedisGraph whitepaper and that they had already done it. I have to admit I was more than a little jealous! It's a good idea.

We'll look at the approach again in the future - our next steps are exposing CLP(fd) in our query language.

We evaluated Jena (we actually prototyped the first system in Jena) and RDF4j. At the time we didn't look into Blazegraph. In beginning the project we began to develop hypotheses of the kinds of features we would need. Namely the ability to check the instance data against a very complex and evolving schema. The need to do schema and instance updates in a single transaction. The need to recieve a program interpretable "witness of failure" (a refutation proof) so that automatic strategies could be undertaken to correct failures in certain cases.

As we went forward we also acquired the collaboration and time-travel requirements to facilitate large team data curation - which aren't present in these offerings.

As for SPARQL, it's essentialy a messy and truncated datalog. It just seemed a bit silly not to use an actual datalog! Then as I've said elsewhere, we needed to be able to do fast time-window queries which CLP(fd) is excellent at and which SPARQL doesn't support.

JSON-LD is most definitely not human friendly, and turtle is certainly better. In our interface you can manipulate the schema in turtle as it's far clearer.

The advantage of JSON-LD is as an interchange format. With turtle you are pasting together strings. With JSON-LD libraries for querying the database are just functions which build JSON-LD. It also simplifies parsing on the opposite end.

But in addition JSON-LD + strong schema give you a way to treat segments of the graph as documents! We can use our get_document word and you'll get back the JSON-LD fragment of the graph associated with an ID. JSON-LD was carefully designed so that this bidirectional interpretation is possible.

We debated using SPARQL initially, and even had a test implementation leveraging the version shipped with SWI-prolog. However we found SPARQL to have a number of short comings that we wanted to see addressed.

Firstly, there were features. Tighter integration with OWL and schema-awareness was something we wanted to build in at a low level. We also wanted to leverage CLP(fd) for time and other range queries. If we were going to need to fundamentally alter the semantics anyhow, it didn't seem that important to start with SPARQL. Other features that are coming down the pipes very soon are access to recursive queries and manipulation of paths through the graph.

Secondly, we wanted better composability. One of the real strengths of SQL as a language is that it is very easy to compose language elements. By contrast SPARQL feels quite ad-hoc, mimicing some of the style of SQL but losing this feature.

Lastly, we wanted to have a language which would be easy to compose from Javascript, or python. Javascript, because we live in a web age, and python, because it's the choice for many datascientists. JSON-LD provides a nice intermediate language in which to write queries in either of these languages. No need to paste together strings! And then, because of the choice of JSON-LD, we can naturally store our queries in the graph (and even query our queries).

For a technical white paper on how we implement this see:

https://github.com/terminusdb/terminus-server/blob/1c586290d...

I read about OLOGs years ago and was very intrigued. Cool project!

Prolog implementations are very efficient at implementing back-tracking, so if you end up using a lot of back-tracking it definitely makes sense. My first prototype was started in java and it was a nightmare. Secondly, for writing the query compiler, prolog was just such an elegant language.

SWIPL has a large enough and nice enough library that it makes it feel similar to other dynamic languages (python, etc.) in terms of implementing run-of-the-mill glue code.

I'm very fond of prolog as the implementation language for the constraint checking, and especially CLP(fd). I think CLP(fd) is such a killer feature, that once people start using it in their queries, they're going to wonder how they got-on before.

I would like prolog to be a lot more feature-mature for the current age however. It needs a bigger community to help flesh the language out! So many things could be made better - better mode analysis, better type checking and simply more libraries.

Without schemata, you end up with spaghetti pretty quickly and no way to ensure data-quality. It's also impossible to treat segments of the graph as documents. With a strong schema you can move seemlessly between objects and graph view.

It is currently deployed in several industrial settings.

JSON-LD allows us to marshall queries into and out of the database as objects in their own right.

The verbosity isn't a problem as we don't actually write queries in JSON-LD. We use a fluent style in a programming language: currently, either Python or Javascript.

OWL as a schema language is quite rich and well developed allowing multiple-hierarchies and complex constraints. Having a well defined rich schema language for graphs is extremely important, and something that isn't widely available.

The reason is that we were positioning to deal with customers who had financial data which was stored as time-series. We aren't hoping to compete with kdb+ on speed (which would be hopeless) but we have a prototype of Constraint Logic Programming [CLP(fd)] based approaches to doing time queries which is very expressive and which we hope to roll out in the main product in the near future on hub.

The graph database is still in its infancy and there are a lot of graph query languages about. We played around with using some that already exist (especially SPARQL) but decided that we wanted a number of features that were very non-standard (such as CLP(fd)).

Using JSON-LD as the definition, storage and interchange format for the query language has advantages. Since we can marshall JSON-LD into and out of the graph, it is easy to store queries in the graph. It is also very simple to write query libraries for a range of languages by just building up a JSON-LD object and sending it off.

We are firmly of the belief that datalog-style query languages which favour composibility will eventually win the query language wars - even if it is not our particular variety which does so. Composibility was not treated as centrally as it should have been in most of the graph languages.

Frankly I think this should be removed. Marketing sometimes get overzealous in trying to present what makes us special.

We generate data-input forms automatically from the structure of schema definitions in the database - the same definitions which make it possible to marshall data from JSON-LD documents into a graph and back. It's AI in the symbolic sense.

Not a stupid question! The database is in memory but we journal all transactions to disk, so it is persistent. In fact it's so persistent that it never goes away. We have an append-only storage approach allowing you to do time-travel. You can query past versions, or look at differences, or even branch from a previous version of the database.

TerminusDB is used commercially and most of it is written in prolog, although the underlying storage engine is written in Rust.

Datalog is still a good idea imho!

We evaluated the use of Mercury before settling on prolog for terminusDB. Mercury is a great language, but the community and library support is just a bit too small.

TerrminusDB originated in 2015 when Kevin Feeney and myself started working on the information architecture for the Seshat Global Historical Databank, an ambitious project to store information about every society in human history. We needed a database that could enable collaboration among a very distributed team on a shared database whose primary function was the curation of high quality datasets with a very rich structure, storing information about everything from religious practices to geographic extent. We trialled a number of graph databases and RDBMSs but found all of them wanting (though for different reasons). Thus we began our journey creating our own database from scratch. In designing the database, we focused on the elements we felt were weakest in existing information architectures, namely the ability to have very rich schemas and very fine grained revision control which was data aware - enabling features such as branch, merge, push, pull, fork etc. Essentially, we wanted to bring the sort of automation present in code pipelines using git with CI/CD to the realm of databases. With the latest release incorporating our own terminus-store backend, we now have a database architecture that is a substantial way along the journey to providing this new approach to data curation and management.

TerminusDB does use a Datalog-like language as the query language for its public web API. Datalog has long seemed to me to be the obvious "next step" for query languages as it enables richer manipulations than those provided by vanilla SQL-like languages in a clean fashion.

However, as j-pb noted in another comment:

"GraphQL queries describe Tree unfoldings of graphs, and thus return trees.

Datalog describes recursive conjunctive queries on hypergraphs (relational model) without or limited negation, and thus return a set or bag of hypergraph edges."

TerminusDB allows you to use both approaches. Due to the way we have designed our graphs, with a strongly typed schema langage, you can extract sub-graphs as unfolded trees using a special predicate exposed in our datalog language.

This approach (hopefully) gives the best of both worlds, allowing graph traversal and extraction of objects/documents in a single framework, all communicating information via JSON-LD.