RE: More review of JSON-LD syntax

On Monday, March 18, 2013 10:04 PM, Charles Greer wrote:

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

@vocab and @base is something I'm worried about myself. We dropped it at
some point but brought both back because people had use cases which they
simplify and most in the group thought the complexity is acceptable. 

The difference between the two is that @vocab acts kind of like a global,
implicit prefix. So all JSON keys, values of @type, and values type-coerced
to @vocab are expanded to IRIs by prepending @vocab (it's prepending and not
relative IRI resolution). @base is used for values of @id and values that
are type-coerced to @id. In this case it's not prepending but really
relative IRI resolution.


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

OK. So if I understand you correctly you are saying that there are basically
two use cases: a) *serialize* some RDF data in (flattened) JSON-LD and b)
you *author* JSON data and add a context which allows you to interpret the
data as RDF.

What about adding a sentence like this to the introduction:

"JSON-LD is a lightweight syntax to serialize Linked Data in JSON. Its
design allows existing JSON to be transformed to Linked Data with minimal
changes."

And then at the end of the introduction:

... "The syntax is designed to not disturb already deployed systems running
on JSON, but provide a smooth upgrade path from JSON to JSON-LD. Since the
shape of such data varies wildly, JSON-LD features mechanism to reshape
documents into a deterministic structure which simplifies their processing."


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

RDFa has Initial Contexts
(http://www.w3.org/TR/rdfa-syntax/#s_initialcontexts):

"RDFa permits Host Languages to define an initial context. Such a context is
a collection of terms, prefix mappings, and/or a default vocabulary
declaration. An initial context is either intrinsically known to the parser,
***or it is loaded as external documents*** and processed."

So it might be loaded form an external document. I think the concept of
having remote contexts is very important for the acceptance of JSON-LD.
Especially when you think about Web APIs where the individual documents tend
to be created from templates which all use the same context so it's much
more efficient to reference a context which then can be cached. Of course,
it's always a trade-off. If you want the document to be self-contained, just
embed the context directly into the context. This is similar to external CSS
definitions.


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

Does the sentence above address your concerns?


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

Great!


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 19 March 2013 16:19:41 UTC