I have read the introduction of “Exploring Graphs with Elixir” and I have come to the conclusion that it may need rework, hence the following suggestions.
On page 4, we read:
In a sense these two approaches to managing data—open world versus closed world—echo the developments we have seen in modern science, where an earlier classical physics dealt with facts and certainties but a newer quantum physics introduced uncertainties. Both types of physics are still valid but apply in their own separate regimes. One tends to a mechanistic description, the other to an organic description.
This seems to be an inappropriate metaphor. There is nothing “organic” about Quantum Mechanics, in fact it is perfectly described by well-specified differential equations and linear operators, it’s just that at the end, when the QM system needs to tell the universe at large about its state, you need to throw dice (for some reason that probably has to do with copying of state). The difference with Newtonian mechanics is that the former assumed the possibility to have perfect information about a system’s state (missing the fact that this demands an infinite number of bits, but that was before Shannon et al.) whereas the latter says no, you can’t have perfect info even in principle (whatever you can extract will always be a limited number of bits with some randomess throw in). So this is all not applicable to what one wants to say in the introduction.
On page 3:
With graphs, we are typically working with an open world assumption and thus with partial knowledge. We cannot conclude anything definite from missing data. Any missing data may arrive at any future time. This is in contrast to more familiar data models which commonly use a closed world assumption where everything is known ahead of time and locked down. Those data models are predictable and provide solid guarantees about data integrity. The down side is that they are regimented.
There is nothing in the relational approach that precludes the addition and removal of data at will, which is why SQL INSERT and SQL DELETE exist. The “closed world assumption” is about the fact that if at time “t” a statement cannot be proven true from the contents of the database, then it is assumed to be false (Is Dave a customer? If the customer relation has no entry for Dave, assume that Dave is not actually a customer).
But this is also the case for graph databases. If there is no information about a link between A and B, then it is generally assumed that there is indeed no link between A and B. Of course, one can always change the logic, and add more truth values or add negative information to the database, but that is somewhat another level. (As a great source of food for thought about introducing negative information into a relational model - based on Prolog - I can only recommend Gerd Wagner’s “Vivid Logic: Knowledge-Based Reasoning with Two Kinds of Negation”, Springer LNAI 764, 1994)
Also,
We cannot conclude anything definite from missing data.
Well, how do we know it is missing in the first place? We MUST be able to conclude something from missing data, otherwise we are just frozen in indecision. And even in the relational model we do: You can run a query that does not use WHERE NOT EXISTS, allowing one to make only positive conclusions: “Dave is a customer and he has bought something”. Maybe we will find out later that Mary is a customer too and she hasn’t bought anything, but that’s neither here nor there.
Anyway, what the introduction should be more about is:
- graphs are a way to think about and describe and model the world
- in particular they can be used to describe the content of a relational database
- and a relational database can describe a graph (this is a matter of implementation only)
- it may well be useful to make the graph abstraction directly accessible at the database level if that abstraction is much better than a relational model at what we want to describe and model
- hence “graph databases”
- in particular, a graph describing the content of a relational database would be highly regular! Any irregularity and exceptions (highly likely to be encountered when modeling the world) would mess it up - thus using the graph abstraction directly is the way to proceed. (and the underlying engine can be optimized for access and modification of course)