W3C home > Mailing lists > Public > public-linked-json@w3.org > July 2014

Re: Converting RDF to JSON-LD : shared lists between graphs

From: David Booth <david@dbooth.org>
Date: Tue, 22 Jul 2014 13:45:46 -0400
Message-ID: <53CEA34A.9070208@dbooth.org>
To: Andy Seaborne <andy@apache.org>, public-linked-json@w3.org
Hi Andy,

On 07/22/2014 01:11 PM, Andy Seaborne wrote:
> (not cc'ed to rdf-comments)
>
> David,
>
> It's impractical to take a top-to-bottom design position and simply ban
> it.  That couples application and platform.

I disagree on this, though I certainly respect your position.  I *do* 
think we should come up with a next generation version of RDF that is 
considerably simpler to use.  I think RDF adoption is severely hampered 
by its subtle complexities, such as with bnodes.  Other predicates can 
be used to accomplish the complexity of your use case instead of loading 
rdf:first and rdf:last to do it.

>
> When developing general purpose code for the grungy bit at the bottom,
> code has to (ideally) cope with what's thrown at it, and that means
> coping with future application choices.

I agree with this tool philosophy, so for the existing RDF and JSON-LD 
specs, they should deal with this.  By saying "Don't do that!" I'm 
advocating for a simpler way to work with RDF.  But today's RDF does 
allow that kind of use case -- and others that are even more perverse -- 
so I agree that tools should be able to handle them, unless those tools 
are specifically designed to encourage and enforce Well Behaved RDF.

>
> In the example, it's not even as complicated as a two-headed list.  It's
> one list with added elements.

I guess that's another way of looking at it.

>
> Immutable datastructures so this all the time. Add an element to a list
> and the original list is available and unaltered.  To some people, this
> situation may even seem natural.  It's not about bnodes, it's about lists.

That does pose an interesting question.  It's viewing a list as a 
mutable data structure, with sublists that can be shared, rather than as 
a snapshot.   And it leads to this kind of complexity.  While I agree 
that it is a reasonable way to think about them, I don't think this way 
of treating them is harmful because of the complexity that it causes.

David

>
> It's about writing code that can cope.
>
>      Andy
>
> [*] RDF-2 - first class lists please, not encoded structures.
>
> On 22/07/14 17:30, David Booth wrote:
>> This does not directly address your question, but . . .
>>
>> Don't do that!  ;)   Seriously, I'm sure you have your reasons for
>> wanting to do that, but it violates what I would call "Well Behaved RDF":
>> http://dbooth.org/2013/well-behaved-rdf/Booth-well-behaved-rdf.pdf
>>
>> I would strongly advocate that if you want to create that kind of
>> structure in RDF, you should use different predicates for it -- not the
>> rdf:first and rdf:last predicates.  Then the problem goes away.
>>
>> David
>>
>> On 07/22/2014 05:21 AM, Andy Seaborne wrote:
>>> We are encountering an issue when converting RDF Datasets to JSON-LD.
>>>
>>> The problem is with blank nodes that are shared between graphs and
>>> lists.
>>>
>>> In TriG (yes, this is a synthetic reduced test case that captures a
>>> smaller example that might appear for real):
>>>
>>> ---------------------
>>> # Bnode references across graph and lists
>>> PREFIX :        <http://www.example.com/>
>>> PREFIX rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>>
>>> :G {
>>>    # Written in short form it would be:
>>>    # :z :q ("cell-A" "cell-B")
>>>    # but we want to share the tail ("cell-B")
>>>
>>>    :z :q _:z0 .
>>>
>>>    _:z0   rdf:first "cell-A" .
>>>    _:z0   rdf:rest  _:z1 .
>>>
>>>    _:z1   rdf:first "cell-B" .
>>>    _:z1   rdf:rest rdf:nil .
>>> }
>>>
>>> :G1 {
>>>     # This references the tail  ("cell-B")
>>>     :x :p _:z1 .
>>> }
>>> ---------------------
>>>
>>> The triple in :G1 references into the list in :G.
>>>
>>> But as we understand the conversion algorithm, section 4 only considers
>>> each graph in turn and so does not see the cross graph sharing.
>>>
>>> Is this a correct reading of the spec text?
>>>
>>> Part 4 of the conversion algorithm has
>>> "For each name and graph object in graph map: "
>>>
>>> so 4.3.3.* walks back up the list in one graph only.
>>>
>>> (Conversion generated by jsonld-java : it does not matter if compaction
>>> is applied or not):
>>> ---------------
>>> {
>>>    "@graph" : [ {
>>>      "@graph" : [ {
>>>        "@id" : ":z",
>>>        ":q" : {
>>>          "@list" : [ "cell-A", "cell-B" ]
>>>        }
>>>      } ],
>>>      "@id" : ":G"
>>>    }, {
>>>      "@graph" : [ {
>>>        "@id" : ":x",
>>>        ":p" : {
>>>          "@id" : "_:b1"
>>>        }
>>>      } ],
>>>      "@id" : ":G1"
>>>    } ],
>>>    "@context" : {
>>>      "@base" : "http://www.example.com/",
>>>      "" : "http://www.example.com/",
>>>      "rdf" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>    }
>>> }
>>> ---------------
>>>
>>> There is no _:b1 in :G to refer to because the algorith generated @list
>>> and its implicit bNodes don't have labels.
>>> This is a different dataset with no shared bNode.
>>>
>>> If it is all the same graph (s/:G1/:G/), the RDF dataset structure is
>>> correctly serialized.
>>>
>>>          Andy
>>>
>>>
>>>
>>>
>>
>
>
>
>
Received on Tuesday, 22 July 2014 17:46:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:42 UTC