W3C home > Mailing lists > Public > public-rdf-comments@w3.org > June 2013

Re: Official response to RDF-ISSUE-132: JSON-LD/RDF Alignment -- Sub-issue on the relationship between JSON-LD and RDF

From: David Booth <david@dbooth.org>
Date: Tue, 11 Jun 2013 02:10:56 -0400
Message-ID: <51B6BF70.2000903@dbooth.org>
To: Sandro Hawke <sandro@w3.org>
CC: public-rdf-comments@w3.org
On 06/11/2013 01:20 AM, Sandro Hawke wrote:
> On 06/11/2013 12:17 AM, David Booth wrote:
>> Below is a specific proposal for resolving the issue that the
>> normative relationship between JSON-LD and RDF is not clear, and the
>> JSON-LD model is not fully aligned with the RDF model.  It clarifies
>> that JSON-LD is a concrete syntax for RDF and ensures complete
>> alignment with RDF while avoiding additional early mentions of RDF in
>> the document.
>> For substantive changes:
>> 1. In RDF conversion algorithms in JSON-LD 1.0 Processing Algorithms
>> and API,
>> http://json-ld.org/spec/latest/json-ld-api/#rdf-conversion-algorithms
>> specify that **when JSON-LD is interpreted as RDF,** (i.e., when the
>> JSON-LD model is converted to the RDF model) skolem IRIs MUST be
>> generated using the well-known URI suffix "json-ld-genid" for any
>> JSON-LD blank node that would otherwise be mapped to an RDF blank node
>> in a position where an RDF blank node is not permitted.  Conversely,
>> when RDF is serialized as JSON-LD (or when an RDF model is converted
>> to a JSON-LD model), skolem IRIs having the well-known URI suffix
>> "json-ld-genid" SHOULD be serialized as JSON-LD blank nodes.  Finally,
>> register the well-known URI suffix "json-ld-genid", in accordance with
>> RFC5785:
>> http://tools.ietf.org/html/rfc5785
>> BACKGROUND NOTE: The existing well-known URI suffix "genid" is for
>> converting to/from RDF blank nodes (in positions where blank nodes are
>> *permitted* in RDF), whereas "json-ld-genid" will be used for
>> *avoiding* blank nodes (in positions where they are not allowed in RDF).
> -0    This is too clever by half, I think.
> If we're talking about blank nodes for predicates, well, people will
> just learn not to use them, I expect.  Or they'll start to use them in
> Turtle, too.   And maybe RDFa and RDF/XML using Skolem IDs, but then
> "json" will be a misnomer.     So for this hack, at least call it
> "generalized-rdf-genid" or something like that.

A different name makes sense, though something shorter would be nicer, 
such as "rdfid".  The practical reason for not using "genid" for this is 
because some processors may wish to blindly transform all "genid" skolem 
IRIs (back) into RDF blank nodes, and that would cause problems in 
places where blank nodes are forbidden.

> For blank node graph names, let's see how ISSUE-131 comes out.   But
> again, I don't see that JSON-LD is any different from any of the other
> syntaxes on this front -- people using them want these features, too.

The intent was to ensure alignment with the RDF model regardless of what 
decision is made by the RDF working group on allowing blank nodes in the 
predicate or graph name positions.

>> 2. Make any other changes needed to ensure that JSON-LD is a normative
>> concrete syntax for RDF.  (Are any other changes needed?)
>> For editorial changes:
>> 3. In section 1
>> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#introduction
>> make the following editorial change to clarify and move the mention of
>> RDF slightly later in the document.  Delete the sentence: "Developers
>> that require any of the facilities listed above or need to serialize
>> an RDF graph or dataset [RDF11-CONCEPTS] in a JSON-based syntax will
>> find JSON-LD of interest.".  Instead, add the following bullet item to
>> the existing bullet list in section 1.1:
>>  - "Software developers who want to generate or consume Linked
>>    Data, an RDF graph or an RDF Dataset in a JSON syntax."
>> 4. Without adding any earlier mention of RDF than the JSON-LD spec
>> already contains, make other editorial changes as needed to avoid
>> implying that JSON-LD is not necessarily RDF.  (However it is fine to
>> say that JSON-LD does not need to be *processed* as RDF.)  Some examples:
>>  - Change "Converting JSON-LD to RDF" to either "Interpreting JSON-LD
>> as RDF" or "Converting a JSON-LD model to an RDF model".
>>  - Change "Convert to RDF Algorithm" to "Interpret as RDF Algorithm"
>> or "Algorithm for Interpreting JSON-LD as RDF".
>>  - Change "Convert from RDF Algorithm" to "Serialize from RDF
>> Algorithm" or "Algorithm for Serializing RDF as JSON-LD".
>>  - Change "This algorithms converts a JSON-LD document to an RDF
>> dataset" to "This algorithm interprets a JSON-LD document as an RDF
>> dataset".
>>  - Change "This algorithm converts an RDF dataset" to "This algorithm
>> serializes an RDF dataset".
>>  - Change "turning a JSON-LD document" to "interpreting a JSON-LD
>> document as RDF".
>> There are many other instances in the JSON-LD document, and I would be
>> happy to help find and fix them.  Most of them can be found by
>> searching for the verb "convert" and changing it to "interpret" or
>> "serialize". Alternatively you could say "deserialize" instead of
>> "interpret".
>> 5. At the beginning of appendix C insert: "JSON-LD is a _concrete RDF
>> syntax_ as described in [RDF11_CONCEPTS].  Hence, a JSON-LD document
>> is both an RDF document and a JSON document and correspondingly
>> represents both an instance of the RDF data model and an instance of
>> the JSON-LD data model."
> 0 on all these.  They seem harmless but unnecessary to me.
>> 6. In appendix C change the following paragraph in accordance with #1
>> above:
>> [[
>> Summarized these differences mean that JSON-LD is capable of
>> serializing any RDF graph or dataset and most, but not all, JSON-LD
>> documents can be directly transformed to RDF. It is possible to work
>> around this restriction, when converting JSON-LD to RDF, by converting
>> blank nodes used as graph names or properties to IRIs, minting new
>> "Skolem IRIs" as per Replacing Blank Nodes with IRIs of
>> [RDF11-CONCEPTS]. A complete description of the algorithms to convert
>> from RDF to JSON-LD and from JSON-LD to RDF is included in the JSON-LD
>> Processing Algorithms and API specification [JSON-LD-API].
>> ]]
>> to:
>> [[
>> The algorithm for interpreting JSON-LD as RDF is specified in the
>> JSON-LD Processing Algorithms and API specification [JSON-LD-API],
>> which is hereby normatively included by reference.
>> ]]
> That makes sense, but we didn't structure it that way because we feared
> problems with json-ld-api would prevend json-ld from going to REC.
> -0.5

But if it isn't structured that way, then I don't see how someone 
reading the JSON-LD spec would know that the API spec is intended to 
define the normative mapping from JSON-LD syntax to the RDF model. 
Would the following wording would be better?
The normative algorithm for interpreting JSON-LD as RDF is specified in 
the JSON-LD Processing Algorithms and API specification [JSON-LD-API].


>> 7. In section C.1
>> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html#transformation-from-json-ld-to-rdf
>> make the following changes:
>> a. Change the title from "Transformation from JSON-LD to RDF" to
>> "Brief Overview of Interpreting JSON-LD as RDF".
>> b. After "This section is non-normative." add: "The complete,
>> normative algorithm for interpreting JSON-LD as RDF is defined in the
>> JSON-LD Processing Algorithms and API specification [JSON-LD-API]
>> secion 10."
> Falls out of decisions above.
>      -- Sandro
>> Thanks,
>> David
Received on Tuesday, 11 June 2013 06:11:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:34 UTC