Re: Comments on JSON-LD 20120712 working drafts

Manu Sporny <msporny@digitalbazaar.com> wrote on 08/02/2012 11:48:57 PM:
> On 08/02/2012 09:34 PM, Steve K Speicher wrote:
> You may also want to look here to try out JSON-LD markup and see the
> results - live, online JSON-LD to RDF tool:
> 
> http://json-ld.org/playground/
> 

I have played on the playground some and have unfortunately hit a few 
issues, which I plan to take up separately (like it allows multiple 
"@type" names on input but jslint indicates that duplicate names objects 
is wrong).  If I get a little more time I'll submit problems that I think 
I found.

> > 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).
> 
> I'm not disagreeing with you. Why would it be "extremely useful"?
> 
Because I know what rdf:type is.  This sounds like it, now I have to learn 
what this is and compare and contrast from current knowledge.  Defining 
new things that are the same as something else, seems like there is value 
in making that clear.  Since the approach is to define something RDF-like 
(without every saying RDF) and then make that late binding in the API 
conversion to RDF, I can read the spec that way.

> It is mentioned normatively here:
> 
> 
http://www.w3.org/TR/2012/WD-json-ld-api-20120712/#convert-to-rdf-algorithm

> 
> What is the exact wording you would use?
> 
But sure seems like the algorithm would MUST simpler if you had 
"@valueType" instead of overloading its meaning based.

> > 3.4.b) Resources that have multiple "types". I see that "@type" on a 
> > resource is a JSONObject and not an array, right?
> 
> The value of @type must either be a JSON string or a JSON array
> containing strings. We should add a JSON array example.
> 
> > How does one express a resource that has a >1 type?
> 
> Like so:
> 
> "@type": ["typeA", "typeB"]
> 
> > 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.
> 
> I think the above addresses your concern, we should clarify this in the
> spec.
> 

Yes, I know what an array would be but this now means that for all clients 
they are probably only looking for an object so they would break with this 
change.  An approach we took to make it simpler, is to just make it an 
array.

> > 4.2) "@type" means either resource type or property value type - how 
> > to tell which is which
> 
> This is a summary of the algorithm, but the use of '@type' is dependent
> on what it's paired with. In a JSON object:
> 
> '@type' specifies an 'rdf:type' if a corresponding '@value' key is not
> found at the same level.
> 
> '@type' specifies an RDF literal datatype if a corresponding '@value'
> key is found at the same level.
> 
> // rdf:type example
> {
>   "@type": "schema:Person"
> }
> 
> // RDF literal datatype
> {
>   "@value": "0.3589",
>   "@type": "xsd:double"
> }
> 
> > 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.
> 
> The full algorithm is specified here:
> 
> 
http://www.w3.org/TR/2012/WD-json-ld-api-20120712/#convert-to-rdf-algorithm

> 

I see it now but seems not too obvious.  I'd recommend adding the example 
you have above.

> > 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.
> 
> If you have a client that doesn't fully understand JSON-LD, this will
> always be the case. What we've found over the years of designing JSON-LD
> is this:
> 
> The best scenario is one where you deal with all of the arbitrary RDF
> graph stuff on the server and /never/ expose those arbitrary graphs to
> the outside world via JSON-LD. Make your REST API very strict in what it
> produces and never assume that there is a JSON-LD API on the client-side
> to clean things up. This means - produce something that looks very much
> like JSON, which always has a regular form. We use the JSON-LD API
> .frame() method to do this on our production systems.
> 
> The second you deviate from the above, you place the burden of
> supporting full JSON-LD onto the client, and thus greatly increase the
> complexity of client implementations.
> 
> > 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).
> 
> Yes, these are system design trade-offs. If you want to use the full
> power of JSON-LD, you need to support the JSON-LD API on both the client
> and server side. However, I think that 90% of Linked Data applications
> won't need this. Another way to look at it is this: if you think you
> need expose a full RDF-y arbitrary graph to your clients, and you're not
> a data warehouse, you've probably not thought about your APIs deeply
> enough... or, you shouldn't be using JSON-LD.
> 
> JSON-LD is for Web app developers that care about the benefits of Linked
> Data, but are hesitant to adopt the full nightmare that having to deal
> with arbitrary RDF graphs summons.
> 
> If you're not going to provide something consistent for these JSON-happy
> Web app developers, then they're probably going to be very unhappy with
> the full nightmare you've provided them.
> 
> At the end of the day, this boils down to a best practice and a contract
> that the Web service has with it's customers. I don't know how much of
> that we need to elaborate upon in the spec. What spec text would you
> like to see?
> 
> > 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.
> 
> Why should that be a normative statement? Why can't it just be a regular
> statement? The normative part of that is achieved in the JSON-LD API
> .toRDF() method.

I was leaving that task to the spec editors.  Though I suppose my desire 
is more of a statement from the JSON-LD (RDF WG) to claim this as a hard 
requirement for JSON-LD (so maybe not a normative statement in this spec). 
 As long as it is covered in the .toRDF() method, then it satisfies my 
concerns.

> > 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.
> 
> Yes, it's a very deliberate attempt to not drive Web app developers away
> from Linked Data. This flows over into the tutorials we're doing as well
> (note the number of times RDF is mentioned):
> 
> What is Linked Data?
> http://www.youtube.com/watch?v=4x_xzT5eF5Q&feature=g-upl
> 
> What is JSON-LD?
> http://www.youtube.com/watch?v=vioCbTo3C-4&feature=g-upl
> 

Seems like we'll take a tangent on defining what the world means by 
"Linked Data", I typically use the definition at 
http://www.w3.org/DesignIssues/LinkedData.html which uses the dirty 3 
letter acronym.  That is one of the motivating points for the W3C Linked 
Data Platform WG, is to give a clear definition to some aspects of Linked 
Data.

> > I believe spending too much effort separating it from RDF would only 
> > hurt the adoption of it and RDF in general.
> 
> I disagree. I think that putting RDF out there front and center in all
> of the Semantic Web specs has hurt the brand because people equate it
> with RDF/XML. I think we're past the point of diminishing returns on
> "educating" people about the difference between RDF and RDF/XML. I'm not
> saying that we shouldn't continue to do that... but JSON-LD is an
> attempt at shifting the conversation away from the RDF/XML+Semantic Web
> religious war and toward the more accepted JSON+Linked Data 
conversation.
> 

I think if carefully represented in the JSON-LD it could work.  It would 
help spoon-feed those that need it and pacify folks like me who keep 
asking how this relates the the RDF concepts I know and are spec'd.

I do agree with the points on the confusion with RDF and RDF/XML, I fight 
that battle every day with people confusing plain old XML with RDF/XML and 
RDF with RDF/XML.

> > 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.
> 
> You are not alone in this opinion... this has come up with almost every
> review comment from folks with an RDF background. That said, we've
> discussed this quite extensively and keep coming back to the notion that
> we're developing JSON-LD for people that 1) Don't know about RDF, and
> don't care to know about it, or 2) People that know about RDF, and think
> it's over-engineered for their needs.
> 
> JSON-LD is a bridge between the Semantic Web, Linked Data, and Web
> developers. Mentioning things like 'RDF' only works with those that have
> a positive opinion of RDF... and those people are not the primary
> audience for this specification. People that have a positive opinion
> about RDF are already happily using, or actively looking for an excuse
> to use it in their projects.
> 
> So, I don't think that adding more references to 'RDF' in the syntax
> specification helps us in any way. In the worst case, it actively hurts
> the spec. We've stated very simply that you can do full round tripping
> with RDF and JSON-LD... the JSON-LD API elaborates on exactly how this
> is accomplished... I think this is the best balance. Others may 
disagree. :)
> 

Thanks for the explanation and assumed this was the path taken.  I guess 
my biased is towards some of the specification work I have done, I find it 
helpful to draw the comparison and just do a good job of writing a 
specification that is clear and easily consumable (perhaps these are at 
odds).  I just feel like some statement near the introduction as the 
approach taken would have saved this email exchange.

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

Received on Friday, 3 August 2012 17:28:46 UTC