Re: JSON-LD spec split preview

On Oct 16, 2011, at 22:44 , Manu Sporny wrote:

> On 10/16/2011 05:57 AM, Ivan Herman wrote:
>> Without going into the details of the documents: why did you keep the
>> normalization part in the JSON-LD API spec? I would think that the
>> whole section on normalization should be removed, or simply add a
>> reference to the third document...
> Two reasons (only the second one is valid):
> 1) I didn't have the time yesterday to re-write the normalization
>   section in the JSON-LD API spec and wanted to make sure to take the
>   time to do it correctly.
> 2) I'm unsure that the RDF Graph Normalization spec will be
>   readable if we make it generic to RDF.
>   We may decide that we want to outline /exactly/ what a JSON-LD
>   processor should do instead of leaving it up to implementers to
>   connect the dots between the generic processing rules in the
>   RDF Graph Normalization spec and the specific things they have
>   to do in their implementation.

Disagree: the 1st reason is also perfectly valid!! :-) But yes, the second one is certainly valid, too...

> I agree that almost all of the section on normalization in the JSON-LD API spec should be removed. I also agree that it should normatively point to an external graph normalization specification. It's the details of how this is done of which I'm unsure of at the moment.
> So, the intent is to do what you want, Ivan - but we're still working out the details on how to do that in practice.


>> Also, though this has nothing to do with the split itself. The
>> document contains markup examples: RDFa, Microformats and Microdata.
>> I think it would be important to have a separate section on RDF in
>> general, too.
> A separate section on RDF in which spec?

JSON-LD syntax, as part of the informative appendices that currently show mapping from microdata, microformats, or RDFa.

> We discussed this before re: mentioning RDF in the JSON-LD Syntax document - and there were people that were hostile to doing that.

As far as I remember, the problem was to bind the definition or JSON-LD to RDF (I think 'hostility' might be a little bit too strong, b.t.w.). I am not talking about that. On the other hand, denying/hiding the fact that JSON-LD can *also* be used as a syntax for RDF would equally be a mistake. JSON-LD is a bridge between two worlds, after all...

> However, now that we have 3 specs, maybe the RDF API should say something about RDF?

The API is for implementers. I am talking about RDF authors.

> Although, if I'm reading between the lines correctly, you want the JSON-LD Syntax document to say something about RDF? That may be difficult based on how strongly some of the other folks in this group feel about hiding as much RDF from JSON-LD authors as possible.

JSON-LD authors can safely ignore that part, just as they can safely ignore microdata, RDFa, or microformats! What is the difference?

> If you want to include a separate section on RDF - what would you want to say in that section, Ivan?

Few typical RDF examples, say in NTriples, and how they are translated into JSON-LD. Nothing complicated: simple triples, some examples with literals and datatypes, maybe some nested examples with blank nodes around. Also, if any, we should list those aspects of RDF that cannot be encoded in JSON-LD (I am not sure there is any, though.)

>> The core spec does refer to RDF, but only sporadically
>> because the spec is not defined in RDF terms, the JSON-LD->RDF
>> algorithm is spelled out, but there is no word on what the general
>> approach is to put RDF into JSON-LD. Although we all think that this
>> is trivial (and it is), spelling it out for newcomers may be
>> important.
> Do you mean putting TURTLE into JSON-LD, or N3/N-Triples into JSON-LD? What do you mean by "put RDF in JSON-LD"?

See above. I hope it is clearer.


> -- manu
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Standardizing Payment Links - Why Online Tipping has Failed

Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

Received on Monday, 17 October 2011 08:29:22 UTC