Re: Comments on JSON-LD 20120712 working drafts

On 08/02/2012 09:34 PM, Steve K Speicher wrote:
> I'm very supportive of this work and have a comments regarding the 
> working drafts published at [1] and [2].

Thanks for taking the time to review, Steve. :)

These are preliminary responses and are not binding in any way. We are
tracking this issue here:

https://github.com/json-ld/json-ld.org/issues/152

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

For your reference, most decisions made by the JSON-LD CG can be found
here (as well as full text and audio logs):

http://json-ld.org/minutes/

I don't expect you to read through the entire backlog, just giving you
the link in case you have particular keywords you want to scan for... or
if you are in desperate need of entertainment on an international flight
and all other avenues have failed you. :P

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/

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

Sounds ideal for JSON-LD.

> 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"?

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?

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

> 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

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

> 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

> 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'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. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/

Received on Friday, 3 August 2012 03:49:30 UTC