Re: Framing and Query

I agree too. JSON-LD querying may be something to get back to, but it should be it’s own spec. Framing was always intended to be a core algorithm, but was left out of the JSON-LD API doc because of timing issues. Once some of the existing issues on framing are addressed, I think it is more that useful. Querying could build on top of it.

I have a branch with updates that I’m not quite prepared to merge yet, but comments are welcome.

https://rawgit.com/json-ld/json-ld.org/issue-110-frame-matching/spec/latest/json-ld-framing/index.html

We might want to think about some forward looking changes to replace certain framing flags to be more in line with what a hypothetical query variation might be.

* @explicit could be eliminated if we had a wild-card in the property position. Then, each property listed would be used to match, and any other properties would be added if the wildcard was present.
* @embed could be eliminated if the value is a node object which is not a simple node reference.
* @requireAll could be implied, with the addition of a @optional value, similar to @default. This sets up for optional query support, is more precise as to which properties are optional.
* We should determine if @omitDefault has real-world value.

A hypothetical frame might be the following:

{
  “@context”: {},
  “@type”: “Library",
  “name”: {},
  “description”: {“@optional”: {}},
  “contains”: {
    “@type”: “Book”,
    “@any”: true,
    “contains”: {
      “@type”: “Chapter”,
      “@any”: true
    }
  }
}

In this case, normal frame-matching structures such as {} and [] could stand for query filters. A future query spec could expand on the framing syntax.

Anyway, most important now is to complete work on issue #110 for merging, and consider other open framing issues.

Gregg Kellogg
gregg@greggkellogg.net

> On Oct 13, 2016, at 5:16 AM, George Svarovsky <gsvarovsky@idbs.com> wrote:
> 
> I agree. I don't envisage a benefit (whether in expressiveness or usability) to bundling query capability into Framing.
> 
> My particular area of interest is in having a simple query syntax that combines easily with Framing and is uniform with it and with the data, for usability's sake. That's the concept that Gregg and I have been bouncing around on another branch of this thread. Equally though, for that idea to be persuasive its benefits need to be demonstrated, so I'll work on that.
> 
> To re-iterate, I think in the general case there's too much complexity in interlacing the Query (constraint-matching existing relationships), with the Frame (the structure I want to return). But a (1.1) Frame does already have a 'filtering' aspect to it, via the Frame Matching Algorithm, and so perhaps it would be good to have a clear statement of how this relates to the wider topic of 'query'?
> 
> Best regards
> 
> George
> 
> 
> From: james anderson [mailto:james@dydra.com]
> Sent: 13 October 2016 08:04
> To: Linked JSON <public-linked-json@w3.org>
> Subject: Re: Framing and Query
> 
> 
> On 2016-10-13, at 04:18, David Booth <mailto:david@dbooth.org> wrote:
> 
> First off, thanks to all of you for this thread, and for the renewed interest in JSON-LD Framing!
> 
> 
> 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 and control
> the serialization of the result. Maybe we should start with a discussion on the role of framing!?
> 
> Andrew >> I agree that there is often a need to query and then Frame the result, but I'm concerned that bundling both capabilities into one syntax/solution might be a mistake at this point.   Framing seems hard enough by itself.  Wouldn't it be better to just tackle Framing first, and later look at the possibility of bundling a query capability?
> 
> James >> the case would need to be made, that a bundled query capability provides sufficient additional expressiveness when compared to combining simple framing with other independent facilities to outweigh the significant additional complexity.
> 
> best regards, from berlin
> ---
> james anderson | mailto: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 Thursday, 13 October 2016 16:39:51 UTC