RE: sandro's review of json-ld-api

Sandro, I've addresses the remaining issue you raised in your API spec
review (see below). There are some things for which I didn't make a change,
these are the things for which I asked for clarification in my last mail:

  http://lists.w3.org/Archives/Public/public-rdf-wg/2013Mar/0287.html

but it's probably easier to read at:

  https://github.com/json-ld/json-ld.org/issues/234#issuecomment-15637714

To get a diff for the commits I referenced in the comments below, just
append the commit hash to the following URL:

  https://github.com/json-ld/json-ld.org/commit/




> General Solution   (many times in the document)
> 
> This term really threw me off, and doesn't seem right.   I think you
> mean "Algorithm Overview" or "Algorithm Summary" or "Algorithm
> Sketch".   Since it's always in an Algorithm section it could just
> be "Sketch" or "Informal Summary".

Fixed in d379fc2231fd1c3097b9d9f3b75a820b484efff5


> > 3) In Conformance it says:
> 
> > This specification does not define how JSON-LD Implementations or
> > Processors handle non-conforming input documents. This implies
> > that JSON-LD Implementations or Processors MUST NOT attempt to
> > correct malformed IRIs or language tags; however, they MAY issue
> > validation warnings.
> 
> But, um, no, I don't think it does imply that.   If you don't say
> how systems are to handle non-conforming input documents, then they
> are free to handle it however they want, including by "repairing"
> them in various ways.    If you're forbidding repairing IRIs or
> language tags, then you're very much saying how systems have to
> handle non-conforming input documents.      Which is it?


Fixed in afb28264889d8266af585ce9b1d95523a331bcd0


> > When data such as decimals need to be normalized, JSON-LD authors
> > should not use values that are going to undergo automatic
> > conversion. This is due to the lossy nature of xsd:double values.
>
> I can't quite make sense of this.

Remove in cbcd28960b2014dc45e4e98fb192278c99cd47ff - I don't think it's the
job of this job to warn developers about such things.


> 2) The conformance classes don't seem quite right. Every "JSON-LD
> Implementation" has to implement conversion to and from RDF? I don't
> really see a need to force them to do that (and I don't think they
> will). Every "JSON-LD Processor" has to be written in JavaScript (or
> some other language for which a WebIDL binding currently exists)?
> That seems like a rather counter-intuitive use of the word
> "processor"....
>
> Suggested fix:
> A JSON-LD Processor is a system which can perform the Expansion,
> Compaction, and Flattening operations. JSON-LD Processors providing
> interfaces to languages for which W3C Recommended WebIDL bindings
> exist ?MUST?SHOULD? use the API defined in this specification [etc].
> A JSON-LD Processor With RDF Conversion is a JSON-LD Processor that
> can also perform Conversion to RDF and Conversion from RDF.

I fixed this in 72eca20e3e1382f85ed79ce68c09c450e4092717. Instead of adding
a "JSON-LD Processor With RDF Conversion" I decided to introduce a separate
product class, an "JSON-LD-RDF Converter" which "s a system that can perform
Conversion to RDF and Conversion from RDF".


> > 1) I'm concerned about the restriction on lists of lists.     I
> > don't like the idea that some RDF graphs can't be serialized in
> > JSON-LD.      I could see how compacting them could be hard
> > (nested type information...?) but why not at least allow them in
> > expanded form?
> 
> This restriction exists only if you want to use arrays to represent
> the list (@list). It does not exist if you represent the list as a
> linked list (I assume that's what you mean by expanded form), i.e.,
> a set of blank nodes with first/rest properties. We have been
> discussing (ISSUE #75) whether we allow identifiers for @list but
> decided to not do that. So currently the only way around that
> restriction is really to represent the list as a set of interlinked
> node objects.
>
> > Suggested fix: let's at least make this restriction At Risk, add
> > some test cases, and see how implementers fare with it.   We don't
> > even need to modify the algorithms in the spec; we can just say
> > "In the interest of space and simplicity, the steps necessary for
> > handling lists of lists have been omitted.    Such lists and their
> > elements must, recursively, be handled like other lists.   NOTE
> > this is an AT RISK feature.  The Working Group might either
> > require handling of lists-of-lists or forbid them in JSON-LD.
> > Implementers please send reports of whether you are able to
> > implement handling for lists-of-lists or would instead request
> > such structures be disallowed."

Fixed in add6b8ce63fd9763260ca8cf6d4801299302a343. I've also added the
following sentence:

"Lists of lists can, however, not be represented in JSON-LD using @list;
they have to be represented as a set of interlinked node objects using RDF's
rdf:first and rdf:rest properties."


> > > Issue 217
> > > RDF does not currently allow a blank node identifier to be used as a
graph name.
>
> > This shouldn't be an issue any more should it? How about make it a
> > NOTE, and add another line about how JSON-LD Processors can
> > convert such blank nodes to IRIs as per
> > http://www.w3.org/TR/rdf11-concepts/#section-skolemization if they
> > need to produce valid RDF.
>
>  Would be fine for me. The reason there's still an issue marker in there
is to avoid a potential second last call. Thoughts? 

I think in order to avoid a potential second last call this has to be an
issue marker or am I wrong? I've changed the text to

in 7378aae65ad7387449f6abafe41c53e0d2629048


Please let me know if this addressed you concerns of if there are some
remaining things you want to have fixed before LC.


Thanks again,
Markus



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 1 April 2013 19:01:45 UTC