ggleason

7 ms·

31.
by ggleason 5y ago
Surely JSON is going to be an important component of Web3. Web 2.0 was bringing the application to the browser. Web3 is going to be about distributed data architecture and JSON is going to have a big place in that.
32.
What's the Difference: JSON diff and patch(github.com)
39 points by ggleason 5y ago|27 comments
33.
by ggleason 5y ago
My two cents: https://github.com/GavinMendelGleason/syntactic_versioning/b...
34.
by ggleason 6y ago
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 p
35.
by ggleason 6y ago
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 companie
36.
by ggleason 6y ago
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 obligat
37.
by ggleason 6y ago
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 su
38.
by ggleason 6y ago
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.
39.
by ggleason 6y ago
"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'
40.
by ggleason 6y ago
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 ca
41.
by ggleason 6y ago
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 abi
42.
by ggleason 6y ago
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. T
43.
by ggleason 6y ago
For a technical white paper on how we implement this see: https://github.com/terminusdb/terminus-server/blob/1c586290d...
44.
by ggleason 6y ago
I read about OLOGs years ago and was very intrigued. Cool project!
45.
by ggleason 6y ago
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
46.
by ggleason 6y ago
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
47.
by ggleason 6y ago
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: curren
48.
by ggleason 6y ago
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
49.
by ggleason 6y ago
Frankly I think this should be removed. Marketing sometimes get overzealous in trying to present what makes us special.
50.
by ggleason 6y ago
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 se
51.
by ggleason 6y ago
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.
52.
by ggleason 6y ago
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!
53.
by ggleason 7y ago
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.
54.
by ggleason 7y ago
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
55.
by ggleason 7y ago
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 va