Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PathQuery, Google's Graph Query Language

arxiv.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: PathQuery, Google's Graph Query Language

#41

Post by lmeyerov »

oddthink wrote: post #39
ampdepolymerase wrote: post #33

Earlier quoted context omitted.

You might like Google's Logica https://opensource.googleblog.com/2021/04/logica-organizing-... (Datalog/Prolog family language compiled to SQL)

I've been using this fairly heavily recently (internal to Google), to the point where I'm thinking of investing in writing an org-babel mode for it. It's a really nice way to structure queries!

Oh wow that is neat!

And yes, this kind of thing is why datalog is a lot more amenable to fast query plans & runtimes than prolog. This part is especially cool: https://github.com/EvgSkv/logica/blob/main/compiler/dialects...

Re: PathQuery, Google's Graph Query Language

#42

Post by slver »

contravariant wrote: post #28
slver wrote: post #15

Earlier quoted context omitted.

Technically it is. But in a very restricted way. Any graph, when you traverse it from a specific node, with fixed depth, and you don't explicitly work with node references, but rather node "values", looks like a tree that sprawls from that node. Anyway, PathQuery is a completely different beast regardless.

If that counts as querying a graph then SQL is also a graph language. If anything SQL is more advanced because it can query a hypergraph.

SQL is neither a graph or hypergraph query language, because relations don't define the graph (or hypergraph). The query does. Deriving a graph and querying a graph are two different things.

A graph query language implies you're querying a graph with specific edges, not ones constructed on the fly from the query.

GraphQL's goal isn't to be "advanced" either. Its goal is to allow access to any data structure (be it backed by graph, RDBMS, file system, NoSQL, etc. etc.) without burdening said structure with capabilities that are not characteristic to it.

Like, if you query a graph, the idea the query may provide any arbitrary join expression would completely drive that graph's performance into the ground.

Re: PathQuery, Google's Graph Query Language

#43

Post by darrenoc »

criddell wrote: post #27
mark_l_watson wrote: post #18

I was invited to work at Google in 2013 on an internal project using their Knowledge Graph. I had just written two books on RDF/SPARQL/linked-data and at first I was taken aback by the query language used at the time. However, when I realized how well the KG scaled and how fast the queries were, I became a fan. BTW, I think this paper is very well written. Graph queries is not an easy topic and their examples and tex…

More than a decade ago I worked for a few years on a product that was based on OWL/RDF/SPARQL and since then I still see a lot of problems I'm facing in terms of subject, predicate, object triples. The semantic web feels like a fad that has clearly passed but there are plenty of good ideas from that field that are under-utilized. For example, a lot of what gets encoded as JSON can be described with these triples and…

I think it's far from a fad, the adoption of the semantic web has been enormous in the past 5 years. Almost every major tech company (and many financial institutions) now have their own Knowledge Graph team.

Re: PathQuery, Google's Graph Query Language

#44

Post by fragile_frogs »

snicker7 wrote: post #31

One issue I have with query languages is how poorly they interact with the "host language" . SQL requires non-composable string templating or complex, low-performance ORM's. The only query languages that do this "right" are datalog (Datomic) and Q/K (KDB+, Shakti).

I think RethinkDB also did a great job with ReQL: https://rethinkdb.com/docs/sql-to-reql/javascript/

Re: PathQuery, Google's Graph Query Language

#45

Post by contravariant »

slver wrote: post #42
contravariant wrote: post #28

Earlier quoted context omitted.

If that counts as querying a graph then SQL is also a graph language. If anything SQL is more advanced because it can query a hypergraph.

SQL is neither a graph or hypergraph query language, because relations don't define the graph (or hypergraph). The query does. Deriving a graph and querying a graph are two different things. A graph query language implies you're querying a graph with specific edges, not ones constructed on the fly from the query. GraphQL's goal isn't to be "advanced" either. Its goal is to allow access to any data structure (be it ba…

I can get behind the idea that SQL is a bit too powerful to allow it to talk to other databases easily.

And not automatically joining by foreign key is a mistake that's going to haunt us for a while I bet.

However when we're arguing capability then it's just as capable of querying a graph as graphDB is. More if the version of SQL supports recursive joins.

Re: PathQuery, Google's Graph Query Language

#46

Post by slver »

contravariant wrote: post #45
slver wrote: post #42

Earlier quoted context omitted.

SQL is neither a graph or hypergraph query language, because relations don't define the graph (or hypergraph). The query does. Deriving a graph and querying a graph are two different things. A graph query language implies you're querying a graph with specific edges, not ones constructed on the fly from the query. GraphQL's goal isn't to be "advanced" either. Its goal is to allow access to any data structure (be it ba…

I can get behind the idea that SQL is a bit too powerful to allow it to talk to other databases easily. And not automatically joining by foreign key is a mistake that's going to haunt us for a while I bet. However when we're arguing capability then it's just as capable of querying a graph as graphDB is. More if the version of SQL supports recursive joins.

The thing I can't seem to get across to you, is that you don't query a graph by specifying a join expression. Graph databases aren't built for that. So no, SQL is not "capable of querying a graph". It's capable of deriving a graph out of relational data. Two completely different things. It's a bit like confusing a restaurant's chef with the restaurant's customer. They both have a meal in common, but one is consuming what the other is producing.

And no, arbitrary join expressions are not a feature that "haunts" SQL databases, because unlike graph databases, relational databases ARE built for that, and it's one of the primary reasons SQL databases are very resilient to change in face of constantly changing ad-hoc query requirements. And it's an important feature of relational algebra that is used every day by countless applications.

SQL and GraphQL serve different purposes at different application layers. Both do precisely what they have to do. The fact they're a bit similar is not coincidental, but also they're not mutually replaceable.

Re: PathQuery, Google's Graph Query Language

#47

Post by scott_meyer »

jeffbee wrote: post #26
mark_l_watson wrote: post #18

I was invited to work at Google in 2013 on an internal project using their Knowledge Graph. I had just written two books on RDF/SPARQL/linked-data and at first I was taken aback by the query language used at the time. However, when I realized how well the KG scaled and how fast the queries were, I became a fan. BTW, I think this paper is very well written. Graph queries is not an easy topic and their examples and tex…

I'm interested in industry history, so I wonder if you can comment on how much of this, if any, came into Google from Metaweb. There are no Metaweb-connected people among the authors (that I can tell) but Warren Harris is acknowledged. Was it a language that was in development before the acquisition, or was it needed mainly after?

PathQuery was started by Warren Harris. At Metaweb, Warren did a rewrite of MQL in OCaml which we never shipped because of the Google acquisition. He spent much of the first year at Google working on a prototype of PathQuery in Haskell. The prototype was rewritten in C++ and used in the first KG-serving infrastructure sometime around 2012/2013.

Re: PathQuery, Google's Graph Query Language

#48

Post by atombender »

sanxiyn wrote: post #17
atombender wrote: post #11

PathQuery looks a lot like GROQ [1], which is the query language used by the Sanity data store [2]. For example, one of the queries in the paper: @entities .[/type == (Id(/ museum ) , Id(/ theme_park ))] .{ id: ?cur require name: /name.[TextLang() == en ] @merge : events::GetInfo() } can be written something like: *[type == "museum" || type == "theme_park"] { id, name: select(name[lang == "en"] => name), ...{ // GROQ…

It seems PathQuery's entire novelty is better handling of recursive querying for query optimization, but "details are admittedly not discussed herein". So the paper has a sort of weird feel. It goes like this: PathQuery is a good language, because it has good semantics and it is optimizable. Some words on its good semantics. We don't discuss how it is optimizable, but trust us, it is.

From what I can tell, PathQuery is also clever in how queries express the shape of the returned data, which we in GROQ call projection. For example, in GROQ you can do:

  *[type == "user"] {
    id, name,
    "slug": id + "-" + lower(name),
    "photos": photos[] {
      url, width, height
    } | order(position),
    "newestComment": *[_type == "comment" && author == ^.id] | order(createdAt desc)[0] {
      id, body
    }
  }
PathQuery seems to give you similar tools in transforming data as part of your pipeline, which I think is how query languages should be like.

Re: PathQuery, Google's Graph Query Language

#49

Post by liminal »

I've tried using SPARQL in the past and found it to be very difficult. There are some aspects here that seem like improvements: - I really like that a query only operates on a single graph. Quads make what should be simple triple queries on a graph much harder than necessary in RDF/SPARQL. - I like the path-oriented declarative design. It seems like a declarative version of the imperative graph traversal libraries. - The inline creation of records based on state in a traversal is also intuitive. - The simple type system is a welcome change from RDF's xsd monstrosity

It still seems to be missing some things. For example, they show a recursive query, but no way to return the actual path taken, only the start and end points (I also can't figure out how to do in SPARQL); I don't see a way to explore predicate relationships; is there a method for reification?

Post reply on HN