- From: Stephane Fellah <fellahst@gmail.com>
- Date: Thu, 20 Oct 2011 17:13:01 -0400
- To: Gregg Kellogg <gregg@kellogg-assoc.com>, public-linked-json@w3.org
- Message-ID: <CALfZuNp=Rtoys7+09E7pdRxqbd90=SwjgX3KA5CNSMTY_WKAnA@mail.gmail.com>
Hi Gregg,
Than you so much for your reply. My answers are inline.
On Thu, Oct 20, 2011 at 4:01 PM, Gregg Kellogg <gregg@kellogg-assoc.com>wrote:
> 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.
>
+1 for splitting the specs.
May be we should provide a section of best practices for serialization to
JSON-LD. Basically if you want to produce JSON-LD from RDF Model, you could
use a prefix mapping (associated with the model) and optionally an ontology
to discover the type of the properties (Object or DatatypeProperty) as well
as their range. This information could be used to create the @coerce object
automatically. The rules of compaction should be defined properly in the
specification.
>
> - 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.
>
I do not understand why the RDF Graph Normalization should be addressed by
the JSON-LD working group. Papers have already been written on this subject.
For example: http://www.hpl.hp.com/techreports/2001/HPL-2001-293.pdf . This
is the one we are using in knowledgeSmarts, our geo-social semantic web
middleware platform.
I think submitting this standard to RDF Group or Digital Signature WG would
be more appropriate. It is just confusing for people who are just interested
in JSON serialization of RDF. The Graph normalization should not depend on
the syntax (it seems that are many references to JSON-LD in the existing
document). If you want to normalize JSON-LD document, the algorithm should
first convert the format to the RDF Model (composed of triples) and then
apply the algorithm (referred above). May be I am missing something, but I
do not think there is any benefit writing a normalization algorithm for
every RDF formats out there (RDF/XML, N3, Turtle, N-Triples,...). There are
all representing the same RDF model.
>
>
> - 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.
>
+1. I am going to reflect this change in my API.
>
>
> - 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_.
>
> Here my suggestion: @prefix is used to define mapping between prefix and
namespace. Token is used to describe a shortname (without prefix) associated
with a property uri (used in full form or qname form if prefix is defined),
term is used for key of json (union of token and qname )
"@context": {
"@prefix" : { // property namespace prefix mapping
"foaf": "http://xmlns.com/foaf/0.1/"
}
"@token" : { // token is a property uri
"name": "http://xmlns.com/foaf/0.1/name", // can
fully specified as iri
"age" : "foaf:age", // or can leverage prefix
mapping
"homepage": "foaf:homepage"
}
"@coerce": {
"@iri": "homepage"
"age" : "xsd:integer",
"birthday" : "xsd:date"
}
}
}
Comments are welcome
Sincerely
Stephane Fellah
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/
>
>
>
Received on Thursday, 20 October 2011 21:13:31 UTC