[oslc-core] Fw: Comments on JSON-LD 20120712 working drafts

[Steve K Speicher]

I wanted to share my review comments and have some samples at 
http://open-services.net/bin/view/Main/OslcCoreJSONLD

Please let me know if you have any other comments on this spec.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net

----- Forwarded by Steve K Speicher/Raleigh/IBM on 08/02/2012 09:42 PM 
-----

From:   Steve K Speicher/Raleigh/IBM
To:     public-rdf-comments at w3.org, 
Date:   08/02/2012 09:34 PM
Subject:        Comments on JSON-LD 20120712 working drafts


I'm very supportive of this work and have a comments regarding the working 
drafts published at [1] and [2].  Also a disclaimer that I haven't been 
tracking this so I may be missing some background and context for what 
currently exists in these drafts.  My background on this is the need to 
supporting a lightweight easily consumable by Web browsers in 
RDF-compatible JSON [3] for the purposes of integrating system and 
software development tools [4]. 

These comments are with respect to syntax [1]:
3.4.a) Defining "@type" with existing definition of "rdf:type"
It would be extremely useful to say that by "@type" in this usage has the 
same semantics as "rdf:type" (or why it is different).

3.4.b) Resources that have multiple "types".
I see that "@type" on a resource is a JSONObject and not an array, right? 
How does one express a resource that has a >1 type?
It would seem that coming from an RDF data model into this would lose 
types > 1.  I suggest changing the value type of @type to an array.

4.2) "@type" means either resource type or property value type - how to 
tell which is which
I don't see a normative algorithm how one would determine that a use of 
"@type" meant it was a value type verses resource type. 

4.14) Roundtripping Compact and Expanded forms
My scenario, I have client code that parts of it only understand the 
Compact form and other older code gets by with operating on the JSON 
structures it is used to.  My client GETs the JSON does its thing, then 
submits back to the server.  My client asks for the JSON representation 
again but this time the server decides to give it back in Expanded form, 
my client code is unhappy with this and no longer works.

It appears the client is as the mercy of the server to make its mind which 
form it wants to support.  Perhaps it is enough to say that clients need 
to be written to expect either but this seems to lose some of the value of 
having the Compact form at all unless truly for true producer-only servers 
(read-only).

Examples 52 and 50 highlight the differences in the forms that I'm 
referring.

B.1) Relationship to RDF concepts is very hidden and/or non-normative
It would seem that this statement "JSON-LD is capable of serializing any 
RDF graph, and performing full RDF to JSON-LD to RDF round-tripping" would 
be a normative statement. 

As a side comment, coming from a RDF background, I found it surprising 
that RDF concepts and references weren't more obvious and plentiful 
throughout the specification.  Perhaps this is a desire to "simplify" RDF 
or prevent adopters from running for the hills.   I believe spending too 
much effort separating it from RDF would only hurt the adoption of it and 
RDF in general.  I'm sure this has been part of the discussions that I 
have missed over the last 18 months and I confess, it is not a priority 
for me to get more involved and change this.  So treat this comment as 
just an observation I wanted to pass to the RDF WG.

I have no comments on api [2] (but I hold the right to have them in the 
future;-)

Regards,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net

[1] - http://www.w3.org/TR/2012/WD-json-ld-syntax-20120712/
[2] - http://www.w3.org/TR/2012/WD-json-ld-api-20120712/
[3] - 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations#Guidelines_for_JSON
[4] - http://open-services.net