Re: Thoughts on querying JSON-LD

On Jul 24, 2012, at 2:23 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:

>> One of the consequences of pursuing using a connect/graphiphy/link-type
>> API call to create an in-memory graph out of JSON-LD as an alternative
>> to framing is that this does not come with a query mechanism.
> 
> Gregg, I asked that already in the telecon but let me ask again. Do you see
> this discussion as "either framing or graphiphy" or an "introduction of
> graphiphy"?

I think graphify plus search makes framing unnecessary. I also find framing difficult to understand, particularly when things don't work right.

> I would say supporting and allowing to combine both, framing (which should
> support at least basic queries, a.k.a value matching and deep-filtering [1]
> and aggressive re-embedding [2]) and graphiphy, would give us the most
> flexible solution and allow developers to build more sophisticated solutions
> on top of it.

I think a SPARQL construct like interface, or possibly describe, serves the purpose of framing use cases. Graphify means that the shape of the data is no longer very important for practical purposes, but we do need a mechanism to create the shape of the JSON-LD that comes out. Construct seems more natural to me, but perhaps aspects of framing would work just as well.

>> A SPARQL expression is typically transfered to an abstract syntax,
>> which can be represented using S-Expressions. For example, consider the
>> following query:
>> 
>>    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>>    SELECT *
>>    WHERE {
>>        ?x foaf:name "Gregg Kellogg";
>>             foaf:knows ?y .
>>       ?y foaf:name ?n .
>>    }
>> 
> [...]
>> 
>> Alternatively, a more sophisticated query engine, might create a nested
>> query as follows:
>> 
>>    {
>>      "@id": "?x",
>>      "foaf:name": "Gregg Kellogg",
>>      "foaf:knows": {
>>        "@id": "?y",
>>        "foaf:name": "?z"
>>      }
>>    }
> 
> The question I ask myself here is which form is easier to understand for a
> Web developer? Currently I lean towards the latter but I definitely see
> value in automatically transforming SPARQL queries to frames.

The JSON representation is great, but we also need to support OPTIONAL, filters and functions. Whatever we do should map well to or from SPARQL.

Gregg

> If we use this (with some sensible flags to explicitly define what should be
> included in the result graph and what not) to find the entry point of the
> graph and then allow to graphiphy the result I think we have a very powerful
> solution.
> 
> Btw. I've already implemented value matching and deep-filtering in my
> processor. See [3] for an example. You can fine-tune the result by playing
> with @explicit , @embed, and @embedChildren.
> 
> 
> [1] https://github.com/json-ld/json-ld.org/issues/110
> [2] https://github.com/json-ld/json-ld.org/issues/119
> [3] http://bit.ly/NsNS6V
> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Tuesday, 24 July 2012 13:44:32 UTC