Re: More review of JSON-LD syntax

Hi Markus,

Most of your responses make perfect sense to me.  I'll just take a 
moment to respond where you needed more information.


On 03/14/2013 03:25 AM, Markus Lanthaler wrote:
> Yes, that's tricky to explain properly. I've clarified the grammar section
> (before I got your review) which now clearly states where
> terms/abs./rel./comp. IRIs are allowed.
I can see your clarifications.  I'm trying to understand the rationale 
for using both base IRI and @vocab.  The former appears to enable 
portability to vocabulary, because terms may have different IRIs 
depending on their location on the web.  Mixing this with the more 
explicit use of @vocab to resolve terms seems fraught with potential 
confusion.

I can see that @base is at risk.   As is I can see the risk of trying to 
do to much with expansion.

>> Until I came to flattening, I thought that JSON-LD was subject to a
>> lot of the same problems as RDF/XML.  My concern had to do with
>> manipulating structures as JSON - if there are a lot of ways to
>> represent something, then one gets into a lot of issues with finding
>> data within the structure.  Flattening seems to get rid of most of
>> those concerns - it should probably be foregrounded as a good
>> canonical representation if you can go that far.
> I completely agree. I've added [1] a section similar to expanded/compacted
> document form: [2].
Thank you that's a good addition.
>
>> 1.1  I think this characterization of JSON-LD is incorrect: "a
>> serialization of Linked Data in JSON."   From what I'm reading, JSON-
>> LD is a method for encoding linked data within JSON documents and
>> generating RDF from them.  While it's possible to create JSON-LD
>> documents that are serializations of linked data, the focus of this
>> document presents JSON-LD as a superset of RDF.  Many things about
>> JSON-LD rely on document scope, and a JSON-LD can contain much more
>> than just the RDF within.  You've probably gone over this point many
>> times before, but JSON-LD seems to be much more about authoring or
>> incrementally creating Linked-Data-ready JSON than it is about writing
>> out Linked Data as JSON.
> Not sure what to do with this. Do you have something concrete in mind I
> could use instead?
I think that RDF/XML could have benefited from a distinction between 
"hey, you can author RDF in XML" and "Here's a way to use XML for RDF 
interchange."   If you can promote the flattened view of RDF in best 
practices and serialization output, then it will be a lot closer to a 
high-fidelity RDF serialization.

Much of the spec has to do with adding RDF to JSON without causing 
pain.  This process itself causes pain.  If you emphasize that there is 
a high-fidelity serialization of RDF, plus some other things, then the 
future users will thank you.

On the other hand, I see I'm crossing the RDF/Linked Data line as well.  
So I've not answered your question at all.  It might be helpful to just 
ponder "serialization" as one use case and "authoring" as another one.

>> 5. Basic concepts A note on 'serialization' above -- dereferencing
>> contexts make JSON-LD really different from other serializations of
>> RDF.  Perhaps that's why you've shied away from the term "RDF."  Maybe
>> only documents that are fully expanded/dereferenced actually conform
>> to RDF.  It means that without the ability to dereference a context,
>> the JSON-LD document has different data in it than it would were the
>> context fully realized.
> Obviously, if the context changes, the data changes as well. I wouldn't go
> as far as saying that only expanded JSON-LD conforms to RDF. The situation
> is similar to RDFa which has some predefined prefixes [3].
Sorry for my ignorance here.  Does RDFa change prefixes based on 
external conditions like the host name?  It just seems odd that a 
document might need dereferencing in order to be completely identified.  
It sounds like JSON-LD is setting itself up for the whole mess XML got 
in with catalogs.  This isn't an objection, just something that catches 
me up.
>
>
>> 5.2 I find the introduction of relative IRIs disorienting here.  It's
>> taken up later in the document, but not completely; this paragraph has
>> the only mention of "base IRI" in the document, and the reference to
>> 'directory path' seems to just muddy the issue further. In general
>> the interaction between relative IRIs and other terms seems to be a
>> difficult part of this document to understand.  As an example, it
>> would seem that using @vocab would rid a document of relative IRIs --
>> you might want to state that explicitly as a #5 at the end of this
>> section "unmatched terms are relative IRIs"
> I removed the "directory path" fragment [1] and there's also a new example
> showing how a relative IRI might be used. The grammar section makes it clear
> where relative IRIs can be used. Furthermore, there's now a section Base IRI
> [4] which references RFC3986 and explains the @base keyword and a section
> Default Vocabulary [5] explaining @vocab.
Yes it all holds together better, especially when I'm reading your 
latest edits :)
>> 6 Advanced Concepts
>>
>> On Compact IRIs, it surprises me that this is part of the normative
>> section.  I can see why it is, but nonetheless it might be useful to
>> point out why a separate syntax is part of this document, as opposed
>> to an updated version of CURIE.  (Please disregard this comment if I'm
>> being silly).
> Simply speaking, in JSON-LD there are no restrictions at all except that, by
> definition, the prefix cannot contain a colon (terms can but they will never
> be selected as prefixes as they won't match anything).
OK
>
>
>> If a prefix:suffix pattern is not matched in the context, is it a
>> relative IRI? (in 6.3 this is prohibited - we have a hole)
> No, an absolute IRI -- that's also what the current text says btw. :-)
Yes I see this.  I think it was another reading-wrong-version mistake.  
I doubt anyone would ever intend this to be an absolute IRI, but it's 
the only solution that makes sense.
>> 6.4 "last-defined-wins mechanism."  This looks more like a "most
>> recently defined" mechanism, because of nested scopes.  I could be
>> misinterpreting "last-defined-wins" though.
> I, as a non-native speaker, can't really see a difference. It's not the
> temporally last (which most recently would suggest to me) but the "closest"
> one if you look from the current element towards the tree's root.
Yes, this is an ambiguity in English.  I don't think your language is 
unclear at all when one pays attention to it, but I try to avoid the use 
of "last" because of its ambiguity with regard to 'most recent' or 
'temporally last".
>
>> 6.5  application/ld+json is introduced in a slightly jarring way.
>> Moreover, there's a MUST stipulation attached to its usage, but later
>> in the document its usage is MAY identify a node.  I'm just confused
>> by this paragraph.
> You are referring to this sentence:
>
> "Please note that JSON-LD documents served with the application/ld+json
> media type MUST have all context information, including references to
> external contexts, within the body of the document. Contexts linked via a
> http://www.w3.org/ns/json-ld#context  HTTP Link Header MUST be ignored for
> such documents."
>
> I don't understand what you mean by "later in the document its usage is MAY
> identify a node". The intention of this paragraph is to say that, if a
> document is server as application/ld+json the context must be referenced
> from within the document and not via a HTTP Link header. In other words, if
> you want to use the link header, you must serve the document as
> application/json.
Got it.
> This is how most multi-lingual JSON is currently expressed. The advantage of
> doing it this way is that you can access the desired language directly
> (doc.occupation.en for the English string) instead of having to filter the
> occupation array. It's always a tradeoff, but we believe that the API is
> powerful enough to deal with this. If you prefer to have just the occupation
> as key, just expand the document and re-compact it with a context that
> doesn't use the container.
Good point.  I'm not sure if you talk about expand/re-compact in the API 
doc, but it's a useful way to consider variation in the JSON authoring 
process.
>> 6.14 Expanded Document Form and 6.15 compact form.  in api doc these
>> are non normative.  Perhaps you don't mean that the API doc defines
>> them, just refers to them?
> The text says:
>
> "The JSON-LD Processing Algorithms and API specification [JSON-LD-API]
> defines a method for expanding"
>
> The API spec defines (normatively) the algorithms to expand/compact
> documents. The result of those algorithms are documents in
> expanded/compacted document form.
>
>
>> Appendix A I don't think a JSON-LD document serializes a collection of
>> graphs.  Maybe you can define a subset of JSON-LD that does, however.
> Well, it serializes a RDF Dataset which is defined as "a collection of RDF
> graphs" in RDF Concepts. Why do you think it doesn't
For the same reason as above.  It seems to me that a JSON-LD document 
can generate an RDF dataset, and that you can serialize a that same 
dataset as JSON-LD, but those two documents could be very different.  
I'm just pointing out the superset aspect of JSON-LD again.

OK that's enough from me.  I like the changes you've incorporated and 
the document reads really well now.

Charles

-- 
Charles Greer
Senior Engineer
MarkLogic Corporation
charles.greer@marklogic.com
Phone: +1 707 408 3277
www.marklogic.com

Received on Monday, 18 March 2013 21:04:35 UTC