W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2016

RE: Framing and Query

From: George Svarovsky <gsvarovsky@idbs.com>
Date: Wed, 12 Oct 2016 10:38:51 +0000
To: Gregg Kellogg <gregg@greggkellogg.net>, James Anderson <james@dydra.com>
CC: Linked JSON <public-linked-json@w3.org>
Message-ID: <AM3PR06MB09466FC089E1784E5C36EAD4A0DD0@AM3PR06MB0946.eurprd06.prod.outlook.com>
Thanks James & Gregg

In general my interest in query (as distinct from framing) is not about improving upon SPARQL's capabilities, it's about improving upon the developer experience.

JSON-LD does not have any more capability than Turtle (does it?), and in those terms only improves upon RDF/XML by the latter being unable (inexcusably) to express some graphs. However in terms of developer experience it's in a different league.

I think some of the same thinking can be applied to SPARQL, and as a result, I think it's possible to thereby lift linked data query into wider usage. In particular I'd like to share query syntax across my application stack. Not because I want end-points that allow UI developers or (heaven forbid) users writing any old query; on the contrary, I want to be able to strongly restrict and optimise the available queries coming into my application layer. But I want to do this by declarative choice, not with brittle plumbing.

GraphQL seems to have the right characteristics for this, if made into "GraphQL-LD" in the way I think is being suggested. But it is itself a custom syntax, and I agree with Gregg that it seems like a fair bit of work to define the terms of the marriage.

In particular, if I understand correctly (I have not built anything with it), GraphQL conceptually overlaps almost fully with Framing, since it's almost all about the requested return data structure. 'Query' in GraphQL is all about pattern matching. Its support for filter constraints is via 'arguments', for which there is no specified semantic--they are equivalent to URL query parameters. So I suspect GraphQL doesn't give me enough query capability, without being back to defining my own syntax.

I'm aware that I still haven't put forward any use-cases, so I'll try to set aside some cycles to work on them. But at the end of the day, I've had some experience defining a custom application-level linked data-style query syntax, based on JSON-LD, and found it to be useful; so I personally think there's mileage in discussing it.

With regard to this:

> >    curl -H “Accept: application/ld+json” -H “Content-Type: application/sparql-query+graphql” \
> >          Link: <http://some.context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json” \
> >          —data-binary @- \
> >          http://some.sparql.endpoint <<EOF
> >    { some graphql expression }
> >    EOF

Do I understand correctly that what you are proposing is contextualising the GraphQL expression with a JSON-LD Context, so that, at a minimum, every property in the expression is expandable to a URI? Has anyone supported this in a real application, do you know?

Best regards

George

> -----Original Message-----
> From: Gregg Kellogg [mailto:gregg@greggkellogg.net]
> Sent: 11 October 2016 20:15
> To: James Anderson <james@dydra.com>
> Cc: Linked JSON <public-linked-json@w3.org>
> Subject: Re: Framing and Query
>
> > On Oct 11, 2016, at 4:07 AM, james anderson <james@dydra.com> wrote:
> >
> > good afternoon;
> >
> >> On 2016-10-11, at 12:02, George Svarovsky <gsvarovsky@idbs.com> wrote:
> >>
> >> Hi Gregg, I'm glad to be here and I hope I can be of help.
> >>
> >> I've taken the liberty of renaming this thread, and capturing the main recent salient points on this topic from the previous thread:
> >>
> >> Gregg >>> Additionally, the Framing algorithm [2] has proven to be important, but work on the specification was never complete, and
> implementations  have moved beyond what was documented in any case.
> >> Markus >> It is certainly handy but I'm not sure there's agreement on what exactly it should be. Initially it was just (or at least mostly)
> about re-framing an existing graph... I think what a lot of people (myself included) actually want and need is to query a graph
> >
> > beyond sparql?
> >
> >> and control the serialization of the result.
> >
> > yes, that has been understood to be the jsonld mandate.
> >
> >> Maybe we should start with a discussion on the role of framing!?
> >> George >> I have a particular interest in framing, and I concur with Markus that what I actually want is (some degree of) graph query.
> >
> > what is “graph query”, that is, in a sense which would differ from sparql?
> >
> >> Gregg > I know there has been some discussion on more sophisticated querying, but I’m not aware of any specific proposals. And, for my
> part, it seems to me that SPARQL Construct pretty much handles these use cases, other than for named graphs.
> >
> > wrt which there are known and readily implementable extension proposals. (see
> https://jena.apache.org/documentation/query/construct-quad.html)
>
> Good to know, this seems like a logical extension point given that SPARQL 1.1 did not really consider RDF 1.1 Datasets. I think the
> translation to JSON-LD form for both @construct and @where is fairly clear, given JSON-LD’s native support for datasets.
>
> >> It seems to me that trying to do something very significant could easily be a rat-hole, but it’s worth a discussion.
> >>>
> >>> Another possibility I considered at one point was a JSON-LD based query specification language that would parse to the SPARQL
> Abstract Algebra (or simply generate SPARQL syntax), with triples derived from the JSON-LD used as the implicit dataset. This is probably
> more constrained, and leaves the messy query bits to a mature specification. This is significant enough, that it probably requires a
> specification separate from framing, and presumes that it’s the SPARQL syntax that is the issue being addressed.
> >>
> >> The first internal POC I did with JSON-LD included a JSON query specification language, very closely related to a number of JSON query
> syntaxes such as MongoDB, FreeBase, Backbone-ORM and TaffyDB. In common with these it was deliberately limited in its capabilities,
> particularly for joins (ironically); but it was heavily invested in JSON-LD, effectively being a super-set with query operators. It was intended
> to be backed by our native Oracle schema, but it actually found more traction as an API to JSON-LD in elasticsearch.
> >>
> >> I can go into more detail on that if there's interest. But in the meantime, earlier this year another POC led me to using an actual
> Triplestore for the first time, and I spent some happy hours fighting with constructing SPARQL in Node.js. Long story short, I ended up doing
> precisely what you (Gregg) just suggested :) I've shared it on GitHub and NPM [1].
> >
> > which use cases would
> >
> >    curl -H “Accept: application/ld+json” -H “Content-Type: application/sparql-query+graphql” \
> >          Link: <http://some.context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json” \
> >          —data-binary @- \
> >          http://some.sparql.endpoint <<EOF
> >    { some graphql expression }
> >    EOF
> >
> > fail to support?
> >
> > the non-ddl aspects of graphql are, for the most part, readily translatable into sparql.
> > i would be very curious to hear about those use cases which demonstrate restrictions.
>
> Me too, if GraphQL translates to SPARQL, then this could provide an intermediate level of query support short of full-on SPARQL, but still
> provide a standards-compliant and RDF-compatible mechanism for performing such queries. It would also allow data in other Triple Stores
> to be queried as if it is JSON. Seems like a fair bit of work to define this, though.
>
> Gregg
>
> >>> I think there are several ways we could go:
> >>>
> >>> 1) Improve framing based on the existing algorithms which provide some degree of manipulating and limiting the framed data based on
> existing relationships.
> >>> 2) Consider a way to include a variable syntax, and how this might be used for both matching and constructing data
> >
> > best regards, from berlin,
> > ---
> > james anderson | james@dydra.com | http://dydra.com

>

The content of this e-mail, including any attachments, is confidential and may be commercially sensitive. If you are not, or believe you may not be, the intended recipient, please advise the sender immediately by return e-mail, delete this e-mail and destroy any copies.
Received on Wednesday, 12 October 2016 10:39:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:49 UTC