Re: JSON-LD Syntax request for FPWD via RDF WG

On May 24, 2012, at 7:47 AM, Richard Cyganiak wrote:

> Markus,
> 
> On 24 May 2012, at 10:47, Markus Lanthaler wrote:
>> Honestly, I didn't expect that such an editorial issue will cause so much
>> discussion. The content is there, the round-tripping is to and from RDF is
>> fully specified (and tested). We didn't want to submit the API spec yet as
>> there are still some minor issues with it and we also wanted to make sure to
>> have a number of interoperable implementations of the spec before publishing
>> it.
> 
> Let me summarize what happened: Manu's initial request was about only the JSON-LD syntax spec. It didn't mention the JSON-LD API spec. The key parts of the JSON-LD syntax spec that mention RDF don't link to the JSON-LD API spec. It took questions from WG members until the existence of the JSON-LD API spec was pointed out. Being asked about the plans for the API spec, Manu stated that it's up in the air, and that it would likely not be submitted to RDF-WG. So basically his initial request was that RDF-WG push a non-RDF format through the W3C process, while leaving the mapping to and from RDF as future work. That just didn't make much sense, and is not a mere editorial issue. But I believe we've identified several possible ways forward that resolve this issue.
> 
>> That being said, would it help if we would extract the to/from RDF stuff
>> from the API spec, rewrite according the RDF Concepts and publish that as a
>> separate document? I'm saying as a separate document because we targeted
>> JSON-LD to web developers without any RDF background.
> 
> I guess there are three options:
> 
> 1. Have the to/from-RDF algorithms in the syntax spec and take only the syntax spec to REC
> 2. Have them in a stand-alone document and take that document plus the syntax spec to REC
> 3. Leave them in the API spec and take API and syntax to REC
> 
> Manu has requested RDF-WG to proceed with 3.
> 
> Personally I'm a bit uncomfortable with 3 because the API spec is *big* and contains lots of stuff that doesn't seem to be immediately relevant to RDF-WG, and that seems to be well outside of what RDF-WG is chartered to do. (Our charter doesn't mention APIs, for example.) This may just be a case of me being uncomfortable because I don't understand JSON-LD and all its surrounding algorithms and APIs well enough.

Some of the algorithms are core to JSON-LD, and can't really be separated. Expansion is required for toRDF(). Compaction certainly makes the result of fromRDF() more presentable, but framing and flattening are really required to put it into a useful form to work with for a JSON developer. I think we really need to do option (3).

Regarding the WebIDL aspect, the IDL definitions are really a pretty small part of the document. The core algorithms (expansion, compaction, framing, and RDF) are pretty much divorced from the details of the APIs themselves.

An earlier version of the toRDF algorithm did not rely on expansion, but it ended up repeating many of the steps, so relying on the expansion algorithm really made sense.

The fromRDF algorithm generates expanded JSON-LD, which is heavily normalized.

Compaction is mostly useful as the final step of framing, where the data is placed into a format specified by the developer.

Flattening was part of the framing algorithm, but was separated recently as it is pretty useful in and of itself. A flattened and compacted structure is useful, and will yield predictable (and useful) results. If any algorithm were to be separated out from the API, it would be framing. We did something similar when normalization was split out into a separate RDF normalization document.

The argument that all API methods should remain together is compelling, but allowing for useful extensions to the API, such as framing, might also be worth considering. In many respects, framing shares much in common with SPARQL, as it provides a way to match against a document (similar to SPARQL CONSTRUCT). Although, unlike SPARQL, framing can be performed entirely within the JSON-LD context, fairly easily implemented in browser based on core JSON-LD algorithms.

In fact, we've tried to limit discussion on framing, as the potential rat-hole of identity matching, implications for named graphs, and the possible use of variables could be destabilizing, and could be left for a later round anyway.

In many respects, JSON-LD forms an entire eco-system for JSON developers to work with linked data using RDF principles, without the high barrier to entry that RDF/SPARQL entails. This certainly makes JSON-LD more involved than other more idiomatic RDF serializations, but it makes it much more useful for the typical developer; it could be considered a "gateway drug" to the Semantic Web.

Gregg

>>> Which raises another point: would it be possible (certainly would be
>>> great!) to have a JSON-LD Primer as a WG Note, eventually?
>> 
>> Yes, we planned to write one..
> 
> Great!
> 
> Richard

Received on Thursday, 24 May 2012 16:54:16 UTC