Re: Reactivating the CG to work on updated versions of the specs

Hi Markus,

> On Oct 10, 2016, at 1:54 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
> 
> It is great to see you taking the initiative on this Gregg!
> 
> On 30 Sep 2016 at 11:31, Gregg Kellogg wrote:
>> JSON-LD 1.0 and JSON-LD API 1.0 have been out and successful for many years now.
>> JSON-LD has succeeded beyond the wildest dreams of the CG, thanks to broad adoption.
> 
> Indeed!
> 
> 
>> 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.
> 
> 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!?

Well, the first attempt is to describe existing behavior better, and to implement pieces from Issue #110 [1], which seem to have general agreement.

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

We should probably re-assert agreement on #110 before considering something more extreme.

>> I think it’s time to get back to these documents to create a future 1.1 Community Group
>> release of the specifications;
> 
> 1.1 sounds like minor tweaks to the existing official W3C specifications but some of the discussions and proposals I just saw go way beyond that. What do you consider to be in scope for 1.1?

Issues marked for 1.1 have been in the issue tracker for some time, many with quite a bit of discussion. It seems to me that these make a good list of issues to be considered for 1.1, and people should weigh in on the issue tracker if they disagree that they should be included in 1.1. This is certainly not a fixed set; other things may be considered, and some may be too ambitious for this round.

Indeed, many of the issues are not really “minor tweaks”, but they do address important use cases in the community, and the CG seems like the best place to explore them.

>> At this point, I’d be happy to see active engagement on the mailing list to move these issues
>> forward; I’m prepared to do the heavy lifting on the specification documents, and to
>> maintain tests and my own Ruby implementation to match. Hopefully, other implementors
>> and heavy users can actively engage in making this happen (perhaps an hour a week). It may
>> be that we’ll want to start up the bi-weekly calls we used to discuss and resolve on these
>> issues prior to moving into the RDF WG.
> 
> I'd definitely like to help with this but unfortunately my spare cycles are quite limited.

Of course, any time you can spare would be most helpful.

> Cheers,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler

Gregg

[1] https://github.com/json-ld/json-ld.org/issues/110

Received on Monday, 10 October 2016 22:45:05 UTC