good afternoon; > On 2017-05-01, at 09:58, Laura Morales <[email protected]> wrote: > >> Do you have any implementation for GraphQL on Jena? > > Nope. I was simply wondering if it would make sense to define an API with > GraphQL, and use Fuseki (via HTTP requests) as a "resolver" function for the > various GraphQL "types". I have this question because from my understanding, > GraphQL calls several "resolvers" one after another to retrieve all the data > asked by the user, which I think is very handy in the context of RDBMSes > because you don't have to deal with complex, multi-JOINs, queries. However in > the context of graph databases it seems rather inefficient because I could > already traverse the graph using a single, simple SPARQL query. What would be > useful I guess is a converter from GraphQL query language to SPARQL. But it's > just an idea, a random thought that I had while thinking about > GraphQL+graph-databases.
plugging a sparql processor into a graphql server affords access to rdf stores as one element in heterogeneous graphql combinations. that is an attractive capability. the limitation is that while "you don't have to deal with complex, multi-JOINs”, the described control model for graphql resolvers (as per the api definitions) entails implementing what are necessarily, internally joins as nested loops. it is as if one were to segment a sparql query into nested service clauses and stipulate that the implementation must pass exactly one values clause with each remote service invocation. this does not tend to be the best approach for an rdf store. the graphql->sparql translation process is more likely to yield an effective implementation and it would be nice if one could integrate that into the resolver architecture, but it is not clear whether the api affords access to the necessary query state to be able to perform a high-level translation. best regards, from berlin, --- james anderson | [email protected] | http://dydra.com
