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.
Which two? On ACID, I hear the arguments on Mongo Atlas since they integrated the wiredtiger tech (to basically become a RDBMS), but still not ACID. The other is cloud native I suppose? Again, have moved along and we gave the a balanced score.
Yeah, just lead with the plain facts. Your product is awesome, you've got nothing to prove. But then again, I'm biased to the technical side of things, and I'm imagining that your early adopters will be curious technical people (as contrasted with folks who might be moved by marketing copy alone.)
I’m using my own (hyper)graph API I developed over years so I have some (albeit limited) experience in the matter. My opinion after reading the home page is that most of the points are straight up bullshit (cloud native and AI code generation).
The second very worrying fact is the query language. Not only it’s not using something existing (cypher, gremlin) or the new upcoming Graph Query Language that will unify them, but it uses some ad-hoc JSON-LD. I couldn’t think of a worst idea. Verbosity (reinforced by JSON-LD compared to JSON), no comment possible, usage of the RDF data model, there are many disadvantages for no benefit (except for RDF that can be useful for interoperability in some cases).
Finally the comparison is listing Oracle Database but not MS SQL, which is rather strange given the later has some support for graph and geo queries.
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.
I checked the origin of the project and it seems to be an European grant to a few universities working on Semantic Web. Given the track record of this technology I’ll pass my turn. Neither the home page nor the doc provide any compelling arguments or killer feature for it’s use over existing solutions.
I’m not convinced either that a strong schema is really important for a graph database. In fact, even in OOP long chain of inheritance have proven bad practice. I also found myself that working with flat-type (no inheritance) nodes and edges simplify the code a lot.
You checked the origin as in you read my comment on this thread? Pretty clear when I said it started in Trinity College Dublin working with linked data. Semantic web certainly suffers from true believers that refuse any break with orthodoxy, but there is a core of wisdom & imho if you can do something practical the best ideas can emerge.
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.
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.
> We generate data-input forms automatically from the structure of schema definitions in the database
That's a lot better and clearer than "AI code generation" :)
> It's AI in the symbolic sense.
Unfortunately that AI still seems to be caught in winter. While we wait for spring to thaw a new round of hype, maybe something simpler, like "smart datagentry forms" or "data-mapper"?
Really happy about this nicely followed up show hn - logic/prolog and graph DBs seems like such an obvious complement to rdms - and as demonstrated by json/jsonb in postgres - simple document data can be rather nicely shoe-horned into heterogeneous relational systems. But proper graph DBs... Not so much? Nice to see more projects in this space.
It is trying to get something into a snappy form that is clear enough to as many people as possible. I like 'data - mapper' but it still needs explanation, so probably better to leave that stuff to the tutorials and try to highlight something else in a comparison table!
I see this mentioned in the product comparison chart, but no mention of what that actually means.