Re: Framing and Query

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)

> 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.

> 
>> 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

Received on Tuesday, 11 October 2016 11:07:38 UTC