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

11–20 of 49 posts

Re: PathQuery, Google's Graph Query Language

#11

Post by atombender »

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 doesn't have functions, so GetInfo()
      // would need to be inlined here
    }
  }
PathQuery is of course a lot more complex, but the basic structure seems very similar. One thing GROQ does not have yet is recursive querying of the type needed to traverse graphs, but this is on our roadmap to implement.

We've published a public draft specification for GROQ, and hoping it will be adopted by more tools. For example, we already have an open-source JavaScript implementation of it.

(Disclosure: I work on GROQ at Sanity.)

[1] https://github.com/sanity-io/GROQ

[2] https://www.sanity.io/

Re: PathQuery, Google's Graph Query Language

#15

Post by slver »

contravariant wrote: post #7
MikeTaylor wrote: post #4

Strange that this paper doesn't even _mention_ GraphQL.

Probably because GraphQL (despite it's name) isn't made for querying graphs.

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.

Re: PathQuery, Google's Graph Query Language

#17

Post by sanxiyn »

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.

Re: PathQuery, Google's Graph Query Language

#18

Post by mark_l_watson »

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 text make the data types, syntax, and how to perform matches and aggregations easy to follow.

Re: PathQuery, Google's Graph Query Language

#19

Post by staticassertion »

contravariant wrote: post #7
MikeTaylor wrote: post #4

Strange that this paper doesn't even _mention_ GraphQL.

Probably because GraphQL (despite it's name) isn't made for querying graphs.

Sure it is. That's a major component - you can perform joins (edge traversals) across backend APIs.

Re: PathQuery, Google's Graph Query Language

#20

Post by staticassertion »

I feel like graph languages can be so esoteric. It would be nice to have something closer to RDF, but with filter syntax, and the ability to group filters.

I've never built a language, so maybe I'm just crazy, but what's wrong with, say,

https://gist.github.com/insanitybit/cd997e8d367889708edc3ec2...

Basically I defined the subject in a sort of 'namespace' of constraints ("parent", "children", etc), and then the edge or predicate constraint on it.

I guess it's easy to just "make up" a language, and implementing is the difficult part, and then it's like "ok well then how do you solve " but also, graphql, as much as it isn't good for a database API, is also quite straightforward and familiar looking and I feel like taking something like rdf as a basis would be reasonable.

Post reply on HN