We've started to formalise TypeQL (TypeDB's query language) using dependent type theory, which fit together very nicely. Interestingly, the formalisation shows us how to consistently and safely extend the language with new structures for higher levels of expressivity, which is a huge benefit of type theoretic formalisms of production languages IMO.
I work on TypeDB (https://vaticle.com/typedb), and it sits somewhere at this intersection. The exposed query language has elements of both logic programming constructs and graph-like structures. Both amount to a kind of "constraint" programming.
A quick peek shows it seems along similar lines as TerminusDB sorta kinda, but they have WOQL [0]. At this time I start to worry again about all the different kinds and flavours of query languages that are emerging.
Agree, only concern is that whatever emerges here has conceptual clarity and doesn't get bastardized by people who haven't studied the foundations of the relational model.
I have this fear because there's a history of that with novel query languages and DB platforms tossing in network/hierarchical/"document"/object-oriented features, and creating a dog's breakfast which loses the compositional/expressive power of the relational algebra. Think MongoDB or Redis. Conceptually a big mess.
RDF itself has a history of this as well. Appeals to novelty.
Or even Google's F1, which smashes hierarchical tree-structured protobufs into a SQL DB, and so has really weird behaviour on joins and projections.
Well, whatever, you know my opinions on this stuff, I think :-)
At this point I'd settle (or ask for) for a network available tuplestore which just receives relational-algebraic operators from a client, and optimizes/executes, and returns pure tuples, and the client-side could formulate whatever query language (or API) it wanted on top of that. I started playing with building something like that between the two jobs, but never got far.
I've had these for about 12 years, they don't get mentioned enough!
Downsides were that in the US there were expensive, and need proper daily cleaning, but the tradeoff is worth it - only need 1 pair per year - less waste too!
Going to get Lasik this year because they don't play nicely with travel in developing countries, but they were absolutely fantastic for school and university.
I think that you're correct in your assessment of relational vs graph-like structures: it's closer to our data domains we model and think of, more flexible, etc. We may be seeing something similar in the ML world where things are moving from tabular-dominant data to being able to process graphs more natively. A table is just a very structured graph after all!
SQL is the standard because, as others have pointed out, it's so entrenched and also builds upon a solid theoretical foundation. And given its dominance, it has been optimised and performed extremely well until recently, where data complexity is catching up again.
Recent noSQL databases won't take over SQL because of the lack of schema/typing. They do scale nicely, but aren't as constrainable as SQL, which is a feature (compare building a large software in Python vs Rust or Java) that enforces safety and good abstractions. There are some newer DBs which are combining strict schemas with NoSQL, which is promising!
Disclaimer: I work on TypeDB (vaticle.com/typedb) which is a native ERA (entity-relation-attribute) model with strict typing via the schema.
Same question! As I understand it:
CO2 pulled out of the ocean is replenished by atmospheric CO2, because limestone in the ocean dissolves too slowly to make up for the imbalance and it more readily comes in from the air.
But if that's true, then the calcium will actually not be replenished quickly in the ocean (not sure what the significance of this is)!
If it were true that the calcium is dissolved fast enough to replenish, then there must also be CO2 released from underwater limestone? Which means extracting Ca and CO2 will not remove any atmospheric CO2 really.
Alternatively, we do end up extracting Ca from the ocean that is not replenished (there's probably so much we don't care) and rely on the atmospheric CO2 to correct ph balance of the ocean?
Hiya - I don't live in a dengue hotspot country but have had it (grandparent lives in a tropical country) and would like to get Dengvaxia to make it a bit less risky to go back... do you know if your country would allow flying in to get the vaccine? May I ask which country it is?
You want to try Farmacias Sucre out here for vaccines (I think they were the only ones I could find who did the yellow fever one), although maybe the best way to take it would be seeing a doctor to get a prescription after checking your antibody levels. Most pharmacies here have a general practitioner in there who maybe even owns the place for consultation... just look for the person in the white jacket. Chances are their English is fine. Also looks like Clinica Biblica has it for only about 88$, they're alright:
The company I work for, Grakn Labs (grakn.ai), builds a database that does datalog + negation type rules! You can add/remove data as you go, and also add/remove rules in the schema over time.
The terminology the post here uses is different from ours, but roughly we do "Backward-chaining", which starts from the query to the set of facts that are inserted, which the article calls "top-down".
We don't do this right now - optimising for incremental changes is actually better done by maintaining forward-chaining inferences (like the OP) rather than backward chaining, and then invalidating and updating just the inferences that have modified dependencies.
Which you want depends on use case often: if you have often changing data backward chaining is generally better, but if it's largely static you can get large performance wins by materialising all the inferences, once, via forward-chaining.
Isn’t datalog with backward chaining just prolog? Datalog was known for forward chaining (bottom up) while prolog was known for backward chaining, datalog with backward chaining sounds like a misnomer.
You're not wrong - the other big difference between datalog and prolog is that datalog is a subset of prolog's functionality that enables forward-chaining to be safe (gets trickier with negation for example). I was mostly referring to the fact that Graql implements datalog semantics/capabilities, plus negation - but the execution strategy is backward-chaining.
It's always funny to see people mentioning hypergraphs in relation to knowledge graphs, this is exactly what we do at Grakn Labs (disclaimer: work there) https://grakn.ai
For others: we're also starting to look into ML on knowledge graphs, check out our initial work at https://github.com/graknlabs/kglib :D
If you look into Bazel (build system), you start getting to the point where everything including dependencies, build system, and deployments can be defined as "source" code and ideally should be treated as a first class software
