
New Query Language for Graph Databases to Become International Standard - Anon84
https://neo4j.com/press-releases/query-language-graph-databases-international-standard/?
======
tannhaeuser
There is an ISO-standardized graph query language: Prolog and its decidable
fragment Datalog, both widely used (relatively) for decades. Will the new
language be based on it?

Another question is whether the model having driven ISO standardization in the
past (software vendors working together to create a large, visible, and
diverse market) is still relevant in post-standard cloud times. I sure hope it
is, but we haven't seen public demand for standards (with the exception of web
standards) for well over a decade now.

~~~
jrumbut
I think the cloud times renews the need for standards. Ten years ago devs in
the linux/BSD world had the vast majority of the code that would make up our
stack, from OS kernel to the front end (with perhaps some proprietary driver
or external API call here or there).

The code was the standard, which traded easy readability for complete accuracy
and transparency.

~~~
tannhaeuser
> _The code was the standard_

That's emphatically _not_ what a standard is about. Standards in the field you
described were developed over many years by proprietary Unix vendors
(including BSD as descendents of the original TCP/IP stack), enshrined in
POSIX/SUS (also published as Open Group and ISO standards), and then
implemented on Linux. Apart from early RedHat stuff such as PAM and things
like LSB, it is only since about 2005 or so that Linux dominates the market by
de-facto implementations rather than standards (such as bash, Docker-style
containers based on Linux namespaces, etc.)

~~~
jrumbut
Of course that's not what a standard is about, but I believe it's what
happened for technologies during the time that standards fell off.

I identified 2009 as about when you expected de facto open source
implementations instead of any talk of standards but I would buy 2005 as well.
Obviously it's a fuzzy boundary.

------
sickcodebruh
I spent many years working on a Neo4j Ruby gem and really grew to love Cypher,
their query language. I always found it phenomenally expressive, one of those
things that seems simple (almost trivial) at first but was extremely flexible
and powerful when you needed more from it. It's highly readable, easy to
teach, and intuitive in a way that I never found SQL to be.

It's been years since I've worked with the product and while I don't miss
Neo4j, I do miss the query language. It's a little unclear to me how GQL will
incorporate Cypher but I hope the initiative is successful if for no other
reason than a selfish one: I'd love Cypher to be around if I ever wind up
using a GraphDB again.

~~~
vosper
> It's been years since I've worked with the product and while I don't miss
> Neo4j, I do miss the query language

Would you mind expanding on what you don't miss about Neo4j?

~~~
sickcodebruh
I was trying to use it instead of Postgres as a general database and it just
didn't shine in that role. The value proposition made sense on paper: it's a
more natural way to reason about data than RDBMS, relationships as first-class
citizens offer some really great benefits, avoiding the schema seems
reasonable when the rest of your stack is dynamic, Cypher is more pleasant
than SQL. While some of that might be true, I encountered the following:

\- Using a somewhat esoteric database increased my devops responsibilities.

\- Open source license didn't allow hot backups.

\- Ruby is just slow. I was using it before the binary protocol was
implemented so performance was often lousy compared to Postgres.

\- Writes were slow. Neo4j seemed to excel at reads and, in particular, the
kinds of reads that are best handled by a graph. Shocking, I know.

\- I really didn't have enough data or the need for the kinds of queries that
would really let it shine.

\- A big part of the culture at meetups and tutorials was based on "DON'T YOU
JUST HATE JOINS!?" It felt culty. I was a big part of that problem for a long
time. The last meetup I went to just felt like people bashing Postgres.

So I think that a lot of the things that I don't miss are because I wasn't
right for it, I should have just been using Postgres.

All that said, there was so much about it to love. Cypher, as already
mentioned. While the culture at meetups might have kind of relied on bashing
SQL and RDBMS, the company itself was full of brilliant, generous, creative,
wonderful people. Their CEO (Emil) in particular is a total sweetheart. The
organization was extremely supportive of open source projects, very inclusive,
very eager to get people involved, and it made a big impact on me.

So, again, while Postgres is the tool I always reach for first, I think that
Neo4j as an organization does great work and as a product has a lot to offer
if you're the right fit for it. I'm glad to see they're doing well.

------
the_duke
So, is there a draft spec yet? I can't find anything.

Also, the name is of course justified, but it will be a mess to search for due
to (Facebook) GraphQL.

~~~
irrational
Is GQL already used elsewhere? As long as nobody calls it graphql we should be
fine, right? Nobody says structured ql or even structured query language, its
just sql.

~~~
fuddle
Yes, it's used by a lot of GraphQl libraries:

    
    
        graphql-python/gql: A GraphQL client in Python
    
        graphql-python/gql-next: A Python GraphQL Client
    
        grooviter/gql: Groovy GraphQL library
     
        99designs/gqlgen: go generate based graphql server

------
blumomo
That's quiet an unfortunate name clash with the existing GraphQL language in a
similar domain.

~~~
gizmo385
I think GQL from Neo4J has been around for quite a while before GraphQL.

~~~
dragonwriter
> I think GQL from Neo4J has been around for quite a while before GraphQL.

Cypher has been, GQL has not.

GQL from _Google_ has, but that's another problem with the (EDIT: naming of
the) new GQL.

~~~
b3tt3rw0rs3
How would you think anyone should call a graph query language done by the SQL
committee?

~~~
dragonwriter
SGQL? SQL-GRAPH? G?

Or, heck, Cypher (with SQL itself, and most other languages, ISO didn't change
the name even though the spec they adopted didn't necessarily exactly match
what existed previously, they kept the name of the existing language they were
standardizing.)

------
okram
There is something really special about the graph database space. For as long
as the space has been around (15 or so years), every vendor and dedicated
practitioner has taken solid jabs at trying to realize "the best way" to think
about graph traversals.

This behavior seems particular to the graph space (vs. document, wide-column,
relational, key/value, etc.). While this speaks to the complexity of the type
of problems you can solve with graphs, thinking back, I believe this was a
cultural anomaly. When it was Neo4j, OrientDB, TinkerPop: the language
trifurcation occurred.

I'm excited that Neo4j is continuing to take the query language seriously. In
an age when software development is about making it easy for the 90% of
developers out there with REST APIs, GraphQL, and overly SQL'd embeddings, ...
graph is still searching for "that best way."

I, personally, have moved on from language-level. However, our new work is
going to help my fellow data system colleagues get there languages exposed to
as many developers as possible regardless of data model. It is important to me
that people can come to respect the numerous ways in which we think about data
and has the language we use is so important. The difference between living in
Plato's Cave or not.

In an effort to support query languages in general, I'll be working on mm-ADT
designing a new cluster-oriented virtual machine architecture for storage,
processing, and query language developers. I see a veritable Tower of Babel on
the horizon!

Congrats Neo4j on reaping the benefits of your hard work. I hope our work will
converge in for a positive collaboration in 2020.

~~~
namedgraph
For some reason you neglect to mention RDF graph data model and its SPARQL
query language, which have been W3C standards since 1997 and 2008,
respectively.

They have a healthy ecosystem of both open-source and commercial software, and
unlike property graphs were designed with data interchange in mind from the
outset.

SPARQL was the first and still is the only standard NoSQL query language.

~~~
tasogare
> , which have been W3C standards since 1997 and 2008, respectively.

While RDF forms a graph, it is not a general graph model. In particular, two
things that are enabled by graph databases (having data in the node itself,
and associating data with edge) are not directly possible and need tricks such
as relationship reification.

On the social side, the sectarism and bikeshedding tendencies of the community
can be another turn off.

~~~
namedgraph
RDF is a directed graph model. Nowhere does it say properties have to have
properties in a graph model. You can always model them as intermediary nodes.

~~~
tasogare
Using intermediate node is changing the structure of the graph. RDF is not a
general graph model. The fact that a node cannot hold data by itself (a link
to literal is required) is risible.

Naming of nodes with IRI is also a ridiculous, especially in Linked Data where
changing your hosting domain (and even the protocol to access data) requires
changing the data itself.

~~~
namedgraph
Are you kidding? IRIs is what sets RDF above and beyond other data models.
Global identifiers are crucial if you want to work with data interchange on a
web scale.

Show me a definition of a "general graph model"? Nothing shows up on
Wikipedia.

There is on the other hand a directed graph model:
[https://en.wikipedia.org/wiki/Directed_graph](https://en.wikipedia.org/wiki/Directed_graph)
This is exactly what RDF is, with labeled vertices and edges.

~~~
tasogare
You can have global identifier without IRIs, for example using GUID (that’s
the solution used for COM components for instance).

The thing is you can’t represent "A"->"B" directly in RDF. You need to stretch
the representation to at least use a resource node as subject, but also for
the object too if this node could be used as subject in another predicate. And
of course both these resources must be encoded as IRI and then linked to the
literals that contains the data. That’s four nodes and three links instead of
two and one. It’s a lot of boilerplate code for a simple problem. And as said
before, putting key:value on an edge require reification of the edge... which
undermine the simple SPO model because it’s now SP(O as P)PO.

You may think it the same but it’s not. Usability matters and that’s why the
SemWeb stack has almost zero adoption since its inception while graph
databases are trendy.

~~~
namedgraph
> SemWeb stack has almost zero adoption since its inception while graph
> databases are trendy

Where is my LOL GIF :D

RDF Knowledge Graphs used by: Elsevier, Bloomberg, Thomson Reuters/Refinitiv,
Uber, Zalando, Microsoft, Apple, Amazon, HSBC... do I need to continue?

If you mean "mainstream developer" adoption, that is a poor and irrelevant
indicator, because mainstream is not where the innovation happens.

------
rambojazz
What's wrong with SPARQL? What advantages has this over SPARQL?

~~~
jerven
Very few real advantages on a technical level.

Practically, the PG model has many syntactic advantages over the equivalence
in expression power RDF+reification. (See excitement over RDF*, which is can
be pure syntactic sugar) Syntax is important for usability.

I don't believe that PG in Cypher or GQL will be significantly more expressive
than SPARQL 1.1. And in any case are quite different from the tinkerpop model.

I believe it is essential for Neo4J as a growing company that they move beyond
their own Cypher to something that is more defined and critically allows them
to check a "we are a standard" box on big deals. OpenCypher has solid adoption
but lacks coherence between implementations. i.e. same data same query,
different result.

Still a more grounded GQL will allow Neo4j competitors to gain on them.

~~~
moxious
> Still a more grounded GQL will allow Neo4j competitors to gain on them.

Can you expand on this? What do you mean?

~~~
jerven
Currently it is relatively difficult to move data from one (open)cypher
implementation to an other. Also as support is uneven for all features it is
not so simple to get started on Neo4J and then evaluate e.g. TigerGraph if you
find that Neo4J is not ideal for your usecase.

If your application only uses GQL then you could start on Neo4J but after two
years in production cheaply move to a competitor. By just switching your
backend and run your test cases etc. your data did not change, your queries
remain the same, so evaluation is relatively straightforward.

I see this quite often in the SPARQL world. First few years of a product is
with engine A, then some annoyance in production show up. Engines B-D are
evaluated and a different one is chosen. Or sometimes both are run at once for
different query workloads on the same data. Which is relatively cheap in the
SPARQL environment. But because of custom engineering in the property graph
world to move from engine 1 to engine 2 it is much more expensive in
engineering hours.

~~~
namedgraph
Basically Neo4J thrives on vendor lock-in and standards lower the lock-in.

------
sandGorgon
why did Tinkerpop's Gremlin not work out ? anyone has a summary of the
discussion from a language design perspective ?

A lot of the Google-able references talk about how Gremlin is more optimizable
than Cypher, etc.

~~~
maxdemarzi
Gremlin was written by a genius level developer to be used by other genius
level developers. There are maybe a handful of Gremlin experts in the entire
world and less than 100 that are any good at it.

It is extremely powerful, but after a few lines, the mental acrobatics needed
to understand what the query does is beyond your average developer.

My first paid Neo4j gig 7 years ago was writing a rules engine in gremlin. It
was about 25 lines of code. If you were to ask me today what each of those
lines did, I would be at a loss. So would anyone who didn't live in those
specific queries day in and day out.

Graph adoption was severely limited by its use. Cypher can be learned in a
day, and "business people" can look at a cypher query and understand what is
going on for the most part.

It takes about a week to "bolt on" Gremlin to any database. I've done it
myself, that's why you see it so often. It takes months to be any good at it.

~~~
rajman187
Far from a genius myself, I've quite enjoyed using Gremlin and the Apache
Tinkerpop project. If you start thinking of it as a functional language, I
believe that helps clarify quite a bit what is going on.

Unfortunately when using it with a distributed backend (Cassandra, for
example), having to write query templates to take advantage of bit-wise
comparisons for parameterizing, all in Groovy, was extremely painful mostly
because I found Groovy to be very awkward.

But there are language-native protocol implementations of Gremlin now.

The little self-contained Apache Tinkerpop project was always fun to play with
toy graphhs in.

And there was an ambitious project to implement the Tinkerpop engine on top of
a Redis backend (akin to RedisGraph which is now an official module using
Cypher) but it is far from a straightforward project. There is even a
Tinkerpop implementation on top of PostgreSQL which looks interesting.

I'm not sure this is a death blow for Tinkerpop so much as a marketing coup
the grace for Neo4J. They have a strong product (despite the index-free
adjacency!) and an even strong branding behind it. Anything that brings graph
DB/technologies into the mainstream is always nice, though. Not that
everything in the world is a graph problem...but surely there are plenty that
can be classified as such.

------
mehrdadn
I'm rather uninitiated on this... what's the difference between a graph
database and a traditional relational database that makes them need different
query languages?

~~~
pcl
SQL generally doesn't have primitives that let you traverse arbitrary
relationships. You can join multiple tables together, but the nature of those
relationships is expressed directly in the SQL statement you're writing.

Some RDBs provide extensions to the SQL standard to do some basic graph
traversals (Oracle's CONNECT BY, for example), but these are just the most-
basic sorts of graph traversals.

In a graph database, the primary notions are nodes and edges and properties
associated with them, whereas in a relational database, the primary notions
are tables (aka "relations"), foreign keys that allow you to connect together
multiple tables, and rows in those tables. Those differences in primary
notions surface in the query languages as well.

~~~
mehrdadn
Thanks for the response. I'm having trouble seeing what kinds of queries come
up of this nature that SQL wouldn't be fit for, though. What would be an
example of a realistic graph query one would want to do that would be too
difficult to do in SQL?

~~~
pcl
Let's assume we're playing the Kevin Bacon game. We've got actors, movies, and
roles. Here's some sample data:

    
    
        INSERT INTO actors (id, name) VALUES (1, 'Kevin Bacon')
        INSERT INTO actors (id, name) VALUES (2, 'Frank Langella')
        INSERT INTO actors (id, name) VALUES (3, 'Cameron Diaz')
        
        INSERT INTO movies (id, name) VALUES (1, 'The Box')
        INSERT INTO movies (id, name) VALUES (2, 'Frost/Nixon')
        
        INSERT INTO roles (movie_id, actor_id) VALUES (1, 2)
        INSERT INTO roles (movie_id, actor_id) VALUES (1, 3)
        
        INSERT INTO roles (movie_id, actor_id) VALUES (2, 1)
        INSERT INTO roles (movie_id, actor_id) VALUES (2, 2)
    

Given the above data model, it's not possible to select all the actors that
are within 6 degrees of Kevin Bacon with a SQL statement.

(Data from the incredible Oracle of Bacon, which uses custom graph traversal
to serve up results:
[https://oracleofbacon.org/how.php](https://oracleofbacon.org/how.php))

~~~
seanhunter
This is an elegant and simple formulation of the problem and shows how bad SQL
is at this. However, you can do this in SQL.

    
    
        with recursive bacon_movies as (
            select
                a.id as actor_id
                , 0 as bacon_degree
            from
                actors a
            where
                a.name = 'Kevin Bacon'
            union
            select
                r1.actor_id
                , b.bacon_degree + 1 as bacon_degree
            from
                bacon_movies b
            join roles r on r.actor_id = b.actor_id
            join roles r1 on r.movie_id = r1.movie_id and r1.actor_id <> b.actor_id
            where b.bacon_degree < 6
        )
        select
            a.name
            , min(b1.bacon_degree) as bacon_degree
        from bacon_movies b1
        join actors a on a.id = b1.actor_id
        group by a.name
        order by bacon_degree asc;
    

...not saying it's a good way to do this

~~~
taffer
> ...not saying it's a good way to do this

It really depends. If you do these kinds of queries all the time, it's a good
idea to use a graph DB, but if these queries are rare, it often doesn't make
sense to add a new technology to your project.

------
lpghatguy
Should GQL be pronounced with a hard or soft G?

Is "geequel" going to take off akin to "sequel" for SQL?

------
vkhn
oh good, I wonder if they realize developers frequently refer to GraphQL as
gql.

------
RocketSyntax
So will neo4j switch to gql? and will spark support switch to gql?

~~~
johnymontana
Yup, you can think of ISO GQL as the future of Cypher.

------
Vaslo
So if I want to learn this GQL, where do I even start? I'm also confused about
the naming, is there more than one language that could be called GQL?

~~~
johnymontana
While the ISO GQL standards draft is being prepared, the best way for a
developer to learn and prepare for ISO GQL is to learn the Cypher query
language.[1] Many of the concepts from Cypher will be carried over into ISO
GQL.

[1]: [https://neo4j.com/developer/cypher-
basics-i/](https://neo4j.com/developer/cypher-basics-i/)

------
maitredusoi
Anyone know the difference with ArangoDB's AQL ? (I haven't use neo4j as I use
ArangoDB)

~~~
b3tt3rw0rs3
AQL is a vendor-specific multi model language that lately has picked up some
ideas from openCypher, like pattern matching.

GQL is a project for creating an International Standard language in the
process of being created by experts from many countries that represent the
interests of multiple vendors.

------
peterwwillis
Huh.

Now if only we could do this for configuration management, service
mapping/scheduling/coordination, resource allocation, monitoring, alerting,
logging, access control, artifact packaging, and execution pipelines.

------
The_rationalist
What advantages/limitations does it have compared to SHACL?
[https://en.m.wikipedia.org/wiki/SHACL](https://en.m.wikipedia.org/wiki/SHACL)

------
westurner
Graph query languages are nice and all, but what about Linked Data here?
Queries of schemaless graphs miss lots of data because without a schema this
graph calls it "color" and that graph calls it "colour" and that graph calls
it "色" or "カラー". (Of course this is also an issue even when there is a defined
schema; but it's hardly possible to just happen to have comprehensible inter
or even intra-organizational cohesion without e.g. RDFS and/or OWL and/or
SHACL for describing (and changing) the shape of the data)

So, the task is then to compile schema-aware SPARQL to GQL or GraphQL or SQL
or interminable recursive SQL queries or whatever it is.

For GraphQL, there's GraphQL-LD (which somewhat unfortunately contains a
hashtag-indeterminate dash). I cite this in full here because it's very
relevant to the GQL task at hand:

"GraphQL-LD: Linked Data Querying with GraphQL" (2018)
[https://comunica.github.io/Article-ISWC2018-Demo-
GraphQlLD/](https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/)

> _GraphQL is a query language that has proven to be a popular among
> developers. In 2015, the GraphQL framework [3] was introduced by Facebook as
> an alternative way of querying data through interfaces. Since then, GraphQL
> has been gaining increasing attention among developers, partly due to its
> simplicity in usage, and its large collection of supporting tools. One major
> disadvantage of GraphQL compared to SPARQL is the fact that it has no notion
> of semantics, i.e., it requires an interface-specific schema. This therefore
> makes it difficult to combine GraphQL data that originates from different
> sources. This is then further complicated by the fact that GraphQL has no
> notion of global identifiers, which is possible in RDF through the use of
> URIs. Furthermore, GraphQL is however not as expressive as SPARQL, as
> GraphQL queries represent trees [4], and not full graphs as in SPARQL._

> _In this work, we introduce GraphQL-LD, an approach for extending GraphQL
> queries with a JSON-LD context [5], so that they can be used to evaluate
> queries over RDF data. This results in a query language that is less
> expressive than SPARQL, but can still achieve many of the typical data
> retrieval tasks in applications. Our approach consists of an algorithm that
> translates GraphQL-LD queries to SPARQL algebra [6]. This allows such
> queries to be used as an alternative input to SPARQL engines, and thereby
> opens up the world of RDF data to the large amount of people that already
> know GraphQL. Furthermore, results can be translated into the GraphQL-
> prescribed shapes. The only additional requirement is their queries would
> now also need a JSON-LD context, which could be provided by external domain
> experts._

> _In related work, HyperGraphQL [7] was introduced as a way to expose access
> to RDF sources through GraphQL queries and emit results as JSON-LD. The
> difference with our approach is that HyperGraphQL requires a service to be
> set up that acts as a intermediary between the GraphQL client and the RDF
> sources. Instead, our approach enables agents to directly query RDF sources
> by translating GraphQL queries client-side._

All of these RDFS vocabularies and OWL ontologies provide structure that
minimizes the costs of merging and/or querying multiple datasets:
[https://lov.linkeddata.es/dataset/lov/](https://lov.linkeddata.es/dataset/lov/)

All of these schema.org/Dataset s in the "Linked Open Data Cloud" are easier
to query than a schemaless graph: [https://lod-cloud.net/](https://lod-
cloud.net/) . Though one can query schemaless graphs with SPARQL, as well.

For reference, RDFLib has a bunch of RDF graph implementations over various
key/value and SQL store backends. RDFLib-sqlachemy does query parametrization
correctly in order to minimize the risk of query injection. FOR THE RECORD,
SQL Injection is the CWE Top 25 #1 most prevalent security weakness; which is
something that any new spec and implementation should really consider before
launching anything other than an e.g. overly-verbose JSON-based query language
that people end up bolting a micro-DSL onto.
[https://github.com/RDFLib/rdflib-
sqlalchemy](https://github.com/RDFLib/rdflib-sqlalchemy)

Most practically, I frequently want to read a graph of objects into RAM;
update, extend, and interlink; and then transactionally save the delta back to
the store. This requires a few things: (1) an efficient binary serialization
protocol like Apache Arrow (SIMD), Parquet, or any of the BSON binary JSONs;
(2) a transactional local store that can be manually synchronized with the
remote store until _it 's_ consistent.

SPARQL Update was somewhat of an out-of-scope afterthought. Here's SPARQL 1.1
Update:
[https://www.w3.org/TR/sparql11-update/](https://www.w3.org/TR/sparql11-update/)

Here's SOLID, which could be implemented with SPARQL on GQL, too; though all
the re-serialization really shouldn't be necessary for EAV triples with a
named graph URI identifier:
[https://solidproject.org/](https://solidproject.org/)

5 star data: PDF -> XLS -> CSV -> RDF (GQL, AFAIU (but with no URIs(!?))) ->
LOD [https://5stardata.info/en/](https://5stardata.info/en/)

~~~
moxious
Linked Data tends to live in a semantic web world that has a lot of open world
assumptions. While there are a few systems like this out there, there aren't
many. More practically focused systems collapse this worldview down into a
much simpler model, and property graphs suit just fine.

There's nothing wrong with enabling linked data use cases, but you don't need
RDF+SPARQL+OWL and the like to do that.

The "semantic web stack" I think has been shown by time and implementation
experience to be an elegant set of standards and solutions for problems that
very few real world systems want to tackle. In the intervening 2 full
generations of tech development that have happened since a lot of those
standards were born, some of the underlying stuff too (most particularly XML
and XML-NS) went from indispensable to just plain irritating.

~~~
westurner
> _Linked Data tends to live in a semantic web world that has a lot of open
> world assumptions. While there are a few systems like this out there, there
> aren 't many. More practically focused systems collapse this worldview down
> into a much simpler model, and property graphs suit just fine._

Data integration is cost prohibitive. In n years time, the task is "Let's move
all of these data silos into a data lake housed in our singular data
warehouse; and then synchronize and also copy data around to efficiently query
it in one form or another"

Linked data enables data integration from day one: enables the linking of
tragically-silo'd records within disparate databases

There are very very many systems that share linked data. Some only label some
of the properties with URIs in templates. Some enable federated online
querying.

When you develop a schema for only one application implementation, you're
tragically limiting the future value of the data.

> _There 's nothing wrong with enabling linked data use cases, but you don't
> need RDF+SPARQL+OWL and the like to do that._

Can you name a property graph use case that cannot be solved with RDFS and
SPARQL?

> _The "semantic web stack" I think has been shown by time and implementation
> experience to be an elegant set of standards and solutions for problems that
> very few real world systems want to tackle._

TBH, I think the problem is that people don't understand the value in linking
our data silos through URIs; and so they don't take the time to learn RDFS or
JSON-LD (which is pretty simple and useful for very important things like SEO:
search engine result cards come from linked data embedded in HTML attributes
(RDFa, Microdata) or JSON-LD)

The action buttons to 'RSVP', 'Track Package', anf 'View Issue' on Gmail
emails are schema.org JSON-LD.

Applications can use linked data in any part of the stack: the database, the
messages on the message queue, in the UI.

You might take a look at all of the use cases that SOLID solves for and
realize how much unnecessary re-work has gone into indexing structs and forms
validation. These are all the same app with UIs for interlinked subclasses of
[https://schema.org/Thing](https://schema.org/Thing) with unique inferred
properties and aggregations thereof.

> _In the intervening 2 full generations of tech development that have
> happened since a lot of those standards were born, some of the underlying
> stuff too (most particularly XML and XML-NS) went from indispensable to just
> plain irritating._

Without XSD, for example, we have no portable way to share complex fractions.

There's a compact representation of JSON-LD that minimizes record schema
overhead (which gzip or lzma generally handle anyway)

[https://lod-cloud.net](https://lod-cloud.net) is not a trivial or
insignificant amount of linked data: there's real value in structuring
property graphs with standard semantics.

Are our brains URI-labeled graphs? Nope, and we spend a ton of time talking to
share data. Eventually, it's "well let's just get a spreadsheet and define
some columns" for these property graph objects. And then, the other teams'
spreadsheets have very similar columns with different labels and no portable
datatypes (instead of URIs)

~~~
moxious
> Can you name a property graph use case that cannot be solved with RDFS and
> SPARQL?

No - that's not the point. Of course you can do it with RDFS + SPARQL. For
that matter you could do it with redis. Fully beside the point.

What's important is what the more fluent and easy way to do things is. People
vote with their feet, and property graphs are demonstrably easier to work with
for most use cases.

~~~
namedgraph
“Easier” is completely subjective, no way you can demonstrate that.

RDF solves a much larger problem than just graph data model and query. It
addresses data interchange on the web scale, using URIs, zero-cost merge,
Linked Data etc.

~~~
moxious
> “Easier” is completely subjective, no way you can demonstrate that.

I agree it's subjective. While there's no exact measurement for this sort of
thing, the proxy measure people usually use is adoption; and if you look into
for example Cypher vs. SPARQL adoption, Neo4j vs. RDF store adoption, people
are basically voting with their feet.

From my personal experiences developing software with both, I've found
property graphs much simpler and a better map for how people think of data.

It's true that RDF tries to solve data interchange on the web scale. That's
what it was designed for. But the original design vision, in my view, hasn't
come to fruition. There are bits and pieces that have been adopted to great
effect (things like RDF microformats for tagging HTML docs) but nothing like
what the vision was.

~~~
westurner
What was the vision?

The RDFJS "Comparison of RDFJS libraries" wiki page lists a number of
implementations; though none for React or AngularJS yet, unfortunately.
[https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_...](https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries)

There's extra work to build general purpose frameworks for Linked Data. It may
have been hard for any firm with limited resources to justify doing it the
harder way (for collective returns)

Dokieli (SOLID (LDP,), WebID, W3C Web Annotations,) is a pretty cool - if
deceptively simple-looking - showcase of what's possible with Linked Data; it
just needs some CSS and a revenue model to pay for moderation.
[https://dokie.li/](https://dokie.li/)

------
paul009
Isn't xquery basically a graph query language similar to GraphQL? If so, why
are we not using xquery to query objects and sub-objects?

~~~
lmkg
I'm not familiar with xquery, does it handle general graphs or only DAGs? Your
mention of "objects and sub-objects" makes me think you're expecting a
different use-case than actual graph databases, which deals more with peer-to-
peer connections (like knowledge graphs) than hierarchical models.

------
The_rationalist
Neo4j would become the standard while being far less used than Gremlin? This
is nonsense isn't it?

~~~
maxdemarzi
Neo4j is by far used more than any other graph database out there. Regardless,
the standard is not Neo4j specific. It was a collaboration from many companies
in the space. They all agree it's a good move.

~~~
The_rationalist
Well I've no statistics about tinkerpop vs neo4j and other usage, I may be
wrong. But I know for sure that far more graph databases supports gremlin than
supports opencypher. E.g the latest graph database from Microsoft
[https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-
intro...](https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-introduction)
Also, Cypher has performance and expressivity issues.

~~~
b3tt3rw0rs3
Just looking at [https://db-engines.com/en/ranking/graph+dbms](https://db-
engines.com/en/ranking/graph+dbms) clearly shows Neo4j as the most prominent
graph db.

I think even Cosmos as number 2 might be misleading here, as Cosmos is a
multi-model product and db engines doesn't distinguish between graph and non-
graph use in the ranking. (Same for ArangoDB)

------
pcr910303
Hmm... There's this big, great, 'perfect', heavyweight graph query language
(GQL) that is on process of standardized while an alternative (GraphQL)
language is more readable (much more lightweight syntax IMO), has gained much
more traction, etc...

While GQL and GraphQL's target is different(one is for interacting with Graph
DBs while the other one is interacting with backends), there is a lot of
overlap ongoing, and I just can't erase the feeling of the overlap between XML
& JSON (where while XML was more 'perfect', JSON won the war).

Edit: Ok, GraphQL is insufficient for GraphDB Querying. Thanks for everyone's
clarification.

~~~
SuperFerret
GraphQL has nothing to do with graph databases.

~~~
pcr910303
Why? GraphQL is about modeling business domain objects in graphs [0] and
querying them. Isn't that basically what Graph DB languages do too?

[0] [https://graphql.org/learn/thinking-in-
graphs/](https://graphql.org/learn/thinking-in-graphs/)

~~~
frant-hartm
It is a query language for APIs, name like RestQL or JsonQL would be much more
suitable.

The expressiveness of GraphQL is severely limited, it doesn't allow you to
express even simple patterns like triangles, depth n, paths etc..

