Re: JSON-LD Java Implementation feedback.

Hi Stephane, thanks for the great work you're doing on this. Some responses (mine only) below:

On Oct 20, 2011, at 7:17 AM, Stephane Fellah wrote:

Hi,

I am currently working on the JSON-LD implementation in Java. I would to provide some initial feedback about the specifications.


 *    About the spec in general

Overall I think the specification is over-engineered and too complex to implement all the aspects of the specification. The specification needs to be broken down into several parts. (JSON-LD Syntax, JSON-LD Primer, JSON-LD Processing). The current specification is biased to a consumer scenario (mainly javascript client). The specification needs to address the conversion in both direction (JSON-LD to RDF and RDF to JSON-LD), as I see a large use of JSON-LD on server side to interact with web clients (for example semantic form could encode their data in json/json-ld and sent it to the server to be converted to RDF automatically using external or inline context ).

In fact, has been accomplished: there are now three specs: JSON-LD Syntax, JSON-LD API and RDF Graph Normalization [1].

My implementation [2] does have an RDF to JSON-LD conversion, but there's no specification for doing this. Typically (other than for RDF/XML), specs don't concern themselves with serialization, only with effective processing. If you can serialize a graph and then processes it with a conforming processor, then your serialization should be adequate. In my case, I try to make the most use of a @context to reduce the markup overhead needed. Of course, Expansion, Compaction and Framing do address serialization concerns.

 *   About normalization

I also question the need of the normalization of the JSON-LD. What is the use case on the client side ? I think graph normalization should be described at the level of RDF graph, not at the level of a format. This is already a problem that has been solved (Jena supports graph isomorphism for example). In addition the algorithm is much simpler when you use the RDF Graph model than using a model driven by a syntax. My suggestion would be to drop completely the normalization part from the spec. This would help the adoption of the specification at large.

Normalization has been split into a separate spec, and is intended to be generic to RDF, not specific to JSON-LD. Normalization is required for, among other things, signing graphs, an important use case for PaySwarm.

 *   Expansion

What is the use case for using this method, except as a step to produce RDF graph model ? This should part of the JSON-LD processing document to describe the RDF conversion from JSON-LD)


 *   Compaction

I do not see a real use case to convert an existing JSON-LD document to a more compact version. This is at the discretion of the implementers. However compaction algorithm is needed to convert a RDF graph to JSON-LD. The part is completely missing in the specification.

This discussed the need for Expansion, Compaction and Framing before on the mailing list [3], although I can't find the specific conversations. My own serializer does not yet support this either, as from an RDF perspective it doesn't really matter. But, from a JSON consumer's perspective, having a predictable and useful serialization can be useful.

 *   Processor API

The Processor API should be aligned with RDF Interface API describing concepts of RDFNode, ResourceNode, IRINode, BlankNode and Literal, Triple and Graph.

The processor API could be simplified to the following methods:

object write(graph input, optional object? context)
graph read(object input,optional object? context)
void triples(object input,JsonLdTripleCallback tripleCallback, optional object? context)


 *   JsonLdTripleCallback alignment with RDF Interface API

We could align the JsonLdTripleCallback with RDF Interface API and having an interface like this:

interface JsonLdTripleCallback {
  void triple(ResourceNode s, IRINode p, RDFNode o)
}


 *   Framing

I do not think this is bringing to much value to write a specification for framing, as there are other mechanisms that could be used on the server side such a template  (freemarker, jsp, velocity, ASP).


 *   Coercion to datatypes.

The current implementation of the datatype coercion is using a mapping from datatype to terms.This forces the implementation to check whether a term is used in two different datatypes, adding extra processing code. Instead of this,  I suggest we reverse the mapping from term to datatype uri, so we can leverage the checking of the unicity of the terms automatically from JSON parser.
While this approach may be more verbose, this would simplify the implementations.
This would look like this:

"@coerce" {
       "@iri": "homepage"
       "age" : "xsd:integer",
       "birthday" : "xsd:date"
}

We recently agreed to reverse this, for the reasons you note. Spec hasn't been updated to reflect this, though.

 *   List

What about bag and alt ? JSON-LD needs to be able to convert RDF and JSON-LD without any loss of information. We need to find a solution to indicate the type of the element of the container or list in order to properly convert to RDF Node.

"@coerce" {
       "@iri": "homepage"
       "age" : "xsd:integer",
       "birthday" : "xsd:date"
}

As Seq, Bag and Alt seem to be on a road to deprecation, I don't see a great amount of value in having direct syntactic support. However, being compatible with RDF serializations, JSON-LD can support it in much the same way as Turtle and RDFa: by using explicit RDF properties. If it were to be directly supported, it would probably require adding @seq, @bag and @alt keywords that are treated much as @list, with specialized processing rules.

 *   PrefixMapping

I would be nice to provide a mechanism to transfer prefix mapping defined in the context to the graph model, so it can be serialized using similar mapping, a vice versa. Right now the context does not really distinguish the notion of prefix mapping with namespace, with name mapping. I suggest we introduce a additional tag for @prefixMapping to capture this notion in the context.

This has been a controversial topic. The wording now describes _terms_, which are mapped to IRIs in @context. They can be used as prefixes too, with some minor processing of a JSON key into _prefix_ and _suffix_, with _prefix_ being defined as a _term_.

Well that's about it for the moment. I will provide more feedback as I am moving forward in my implementation.

Best regards
Stephane Fellah
smartRealm LLC

Gregg Kellogg

[1] http://json-ld.org/spec/latest/
[2] http://github.com/gkellogg/json-ld
[3] http://lists.w3.org/Archives/Public/public-linked-json/