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

On Tuesday, June 11, 2013 8:11 AM, David Booth wrote:
> 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.

Could you please explain why it is important to be able to distinguish them?
Is it for streaming generators that need to know at the first occurrence
whether such a IRI should be replaced with a bnode identifier or not?


>>> 2. Make any other changes needed to ensure that JSON-LD is a normative 
>>> concrete syntax for RDF.  (Are any other changes needed?)

You should tell us :-P


>>> For editorial changes:
>>>
>>> 3. In section 1
>>>
https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.ht
ml#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."

I would be fine with that change but fear that this will just re-open
another discussion. That specific sentence was added due to a request by (I
think) David would.


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

I agree with Sandro. Looks like hair splitting to me but if enough people
think it is important it's way simpler to just do it than to continue these
discussions.


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

As Sandro already said, we structured it that way to avoid a normative
dependency between the API spec and the syntax spec. I think we should keep
it the way it is



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 11 June 2013 09:54:03 UTC