Tone is narcissistic and self-important - it does not even tip a hat to address prioritisation or resource constraints - it's just "this is important to me THEREFORE IT IS IMPORTANT, GNASH, WAIL". I also think the author does not understand end-user software - if you package everything up so it is very secure by default, almost nobody will ever use it and nobody will care except the people who are capable of securing it themselves.
In our world the diffs are actually simply triples - the consequences of, for example, changing a class can be complex though but the diffs are just "these triples minus, these triples plus" which really helps simplify things.
We also support a bi-modal interpretation of ontologies - if you put them in a graph of type "schema" they are interpreted in a closed world way, in a graph of type "inference" they are interpreted as being open world.
In our experience the inference stuff is super cool (for example we use a property chain rule in our system database to allow arbitrary nesting of authority domains) but 99% of the effort is trying to make sure that your data and schema line up and for this, you really want to be operating in a closed world regime.
Yes, because the desktop client runs on localhost (or 127.0.0.1 actually), there is no way to produce a valid self-signed cert that won't cause browsers to complain. The desktop electron app causes this problem to disappear from view, but otherwise it's more or less unavoidable if you want to allow people to connect over https to a service running on loopback - in our case it's really what we want as we're a bit paranoid about exposing users to internet-borne risk!
I don't think a reverse proxy would work in this case due to the JWT security requirements (callbackable internet accessible endpoints). In any case, that's one of the big reasons we are favoring the electron app as the primary desktop interface because it takes the problem away. The browser based interface is targeted at server deploys and in those cases if you're hosting from a proper ip address, you want to install your own cert of course.
It is a major concern - one of the things driving our focus on getting the electron / desktop out to fix the problem - which came out yesterday and makes that terrible warning disappear - allowing your users to authenticate directly from localhost to whatever internet authentication providers they want is one of the few situations where reverse proxying can't work (it's a man in the middle attack). If you could set up reverse proxies that allowed you to, for example, sign in to your google account or other oauth provider from port 80 and it did all the https for you, the internet would be in big trouble. It's one of the big reasons driving the popularity of stuff like electron IMO - it allows you to hide all the browser generated warnings that come with running https on localhost (which you really want to do for security reasons anyway) and it's one of our major and main motivations for choosing electron as our primary desktop package.
In terms of framing - yes we do! Exactly like that.
TerminusDB has a document api endpoint and a special Document class - anything that inherits from this class is considered to be a complex document with internal structure - if you send a document id ("employee:bob") to the endpoint it will give you the full document for that id - and it will clip the document when you get to another document which gives you a way of supporting both document and graph views of the same data.
2. We've been keeping an eye on RedisGraph and they definitely do well when it comes to graph matrix operations - which we don't do yet, but in other areas we should be very competitive with their performance and we have more stuff going on - especially schema checking of transactions
Yes - we have worked with Peter on building the Seshat Databank of world history. His work on modelling long term dynamic processes is great - definitely worth reading any of his stuff.
aha - don't mention the war - I'm in the process of completing a release of the Seshat dataset with a TerminusDB tutorial on how to build it into a graph and query it. But I keep getting distracted when I'm just about finished. Thanks for the interest thought - it will encourage me to get it finished!
Yes, although with databases as against log files, you also need to be able to somehow append 'deletes' and updates to existing records as well as just adding new records. The advantages of doing so is that it greatly simplifies transactional processing and makes it much more parellelisable - because you never change any existing data, just add new records on top. Blockchains have similar 'immutable' characteristics. The other reason why append only storage is desirable is that it allows you to time travel simply by backtracking through the append-logs and you can then do stuff like reconstructing future states by replaying all of the append events that got you there.
There are a variety of databases and database management systems that try to do this - most of them run into problems with the meta-language needed to describe updates and deletes to, for example, SQL Tables or something similar. This is a hideously tricky and detailed problem because there are all sorts of ways in which an SQL table can be changed many of which have implications for all sorts of other bits of data and you have to capture all of this in your 'update' append log.
On the other hand, if like TerminusDB, you use RDF triples as an underlying language, then the problem is pretty trivial - every update can always be expressed as a set of deleted triples and a set of added triples.
But, wouldn't an append only database demand substantially more storage which would also increase at a faster rate? How is that handled given we won't be able to fit the database on a single disk?
Also, I wanted to understand how databases work and wanted to build one from scratch. Is there any website/tutorial/blog you think could help me out? Thanks a lot!
Yes, this is an unfortunately buzzwordy phrase. In this case it does have some meaning though - we generate what we call class-frames from the AI - simple logical javascript programs which know how to render documents and talk to the API, but definitely AI Code generation is not a good phrase.
This is a database written in Prolog: https://github.com/terminusdb/terminus-server - albeit with a RUST storage engine - prolog's lack of types means there are better storage solutions, but for constraint logic, it's unbeatable.
Mercury is cool. I translated a simple Prolog program to it once, and it was a head trip. Hard to get my mind around, but also helped me see the connection between functions and relations.
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.
