- From: <henry.story@bblfish.net>
- Date: Tue, 22 Jul 2014 22:44:06 +0200
- To: David Booth <david@dbooth.org>
- Cc: Dan Brickley <danbri@google.com>, Linked JSON <public-linked-json@w3.org>, public-rdf-comments <public-rdf-comments@w3.org>
On 22 Jul 2014, at 20:11, David Booth <david@dbooth.org> wrote: > Hi Dan, > > On 07/22/2014 01:34 PM, Dan Brickley wrote: >> On 22 July 2014 17:30, David Booth <david@dbooth.org> 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 >> >> Your PDF says "It is worth pointing out that these difficulties were >> foreseen (at least in principle) by the authors of the W3C >> Architecture of the World Wide Web (AWWW),[12] as the use of blank >> nodes clearly violates the web architectural good practice that >> anything of importance should be given a URI. As the AWWW states: “A >> resource should have an associated URI if another party might >> reasonably want to . . . make or refute assertions about it . . . .” " >> >> I suggest this is a mistaken reading of the holy text. > > How so? It seems to me that there is an inherent tension between being nice to RDF consumers (by using URIs for things that other might want to refer to, as AWWW recommends) and author convenience, which leads to bnode use. > >> >> Even if we (by some vast and mystically-tinged effort) give URIs to >> all entities known to humanity, ... that's not the same thing as >> always having-to, wanting-to or being-able-to provide a well-known URI >> whenever those entities are mentioned in an RDF description. > > Agreed. > >> >> It is entirely reasonable to want to represent fragments of partial >> information, even if the lack of shared URIs is inconvenient. >> Reference-by-description is as old as human communication, is >> intrinsic to it, and isn't going away anytime soon. > > Agreed. > >> Andy's use case seems entirely sensible to me. > > Sure it's sensible, but it leads to subtle complexity that I think is harmful to RDF adoption in the long run. I think the JavaScript infrastructure has show that complexity is not a problem where there is the will. Good libraries can hide complexity very well. It's the programming abstractions that need to be worked on. I have found for example that working with the notion of a pointed graph as suggested by Alexandre Bertails defined as a pair of a graph and a pointer with an algebra to use it such as val timbl = PG(timblfoafGraph,timblUri) for ( personPG <- timbl/foaf.knows ) yield { (persongPG/foaf.name).head.toString } makes it much easier to develop code for newbies. See the banana-rdf https://github.com/w3c/banana-rdf library. The thing is to find the right abstractions that helps one to work with blank nodes and clarify the use of distinctions between bnodes and uris. A notion such as a case class NamedPointedGraph(store: Store, name: URI, pointer: URI) with functions that allow one to jump around the web asynchronously or synchronously makes bnodes very important and easy to use. I got some newbies to write some very nice code with this type of abstraction e.g.: https://github.com/read-write-web/react-foaf That was just a first prototype using timbl's rdflib. I think we can do a lot better using scala-js ( http://www.scala-js.org/ ) which makes it easy to think OO & Functionally about code and develop powerful algebras. > > David > >> >> Dan >> >>> 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 Social Web Architect http://bblfish.net/
Received on Tuesday, 22 July 2014 20:44:46 UTC