JSON-LD Java Implementation feedback.

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


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


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



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


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


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

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