- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 17 Mar 2011 21:35:26 -0500
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- Cc: Mark Wallace <mwallace@modusoperandi.com>, Alan Ruttenberg <alanruttenberg@gmail.com>, Reto Bachmann-Gmuer <reto.bachmann@trialox.org>, Ivan Shmakov <oneingray@gmail.com>, Ivan Shmakov <ivan@main.uusia.org>, "<semantic-web@w3.org>" <semantic-web@w3.org>
Um... Look, there really isn't a problem here. That is, there's nothing at all mysterious or intuitively wrong about bnodes. It is entirely a matter of scoping. An RDF graph with bnodes in it is like an existentially quantified sentence in logic. (exists (x)( has(Joe, x) & Called(x, "Bill") & Dog(x) ) entails, among other things, both (exists (x)( has(Joe, x) & Dog(x) ) and (exists (x)( Called(x, "Bill") & Dog(x) ) But these two together do NOT entail the first sentence, because there is nothing to guarantee that the two x's that exist are the same x. This is exactly what happens when you take a subgraph of an RDF graph which splits apart an RDF 'molecule' [1] and then try to put the pieces back together. As I say, nothing mysterious or surprising or even counterintuitive. RDF behaves, in this respect, just like logics have behaved since around 1890. Pat [1] http://ebiquity.umbc.edu/paper/html/id/240/ On Mar 17, 2011, at 12:07 PM, Hugh Glaser wrote: > > On 17 Mar 2011, at 14:37, Mark Wallace wrote: > >> On 3/17/2011 6:34 AM, Hugh Glaser wrote: >>> If I take a graph of any kind and use a particular serialisation method, and communicate that somewhere else, and then de-serialise, do I end up with the same graph? >>> For most serialisations, the answer will be "no". >>> >> (Daring with trepidation to enter these waters... :-) ) > You and me both mate :-) >> >> I would think the opposite would be true. I understand that RDF is first and foremost a graph model, independent of serialization. Given that, I would expect that for most serializations, the pre-serialized and post-serialized versions of the graph (i.e., in memory) would be the same. The *serializations* would not be the same, but shouldn't the *logical graph model* be the same? Isn't that the point of the RDF spec separating serialization from logical model? >> >> E.g. with Jena, given this file (test.ttl) >> @prefix : <http://example.com/demo#> . >> :joe :has [ a :dog ] . > Just to be clear, this is a serialisation already. >> I serialize it as RDF-XML: >> C> java jena.rdfcat test.ttl >> <rdf:RDF >> xmlns:rdf=MailScanner has detected a possible fraud attempt from "www.w3.org" claiming to be "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >> xmlns=MailScanner has detected a possible fraud attempt from "example.com" claiming to be "http://example.com/demo#"> >> <rdf:Description rdf:about=MailScanner has detected a possible fraud attempt from "example.com" claiming to be "http://example.com/demo#joe"> >> <has> >> <dog/> >> </has> >> </rdf:Description> >> </rdf:RDF> >> Or I serialize it as N-Triples: >> C> java jena.rdfcat -out ntriple test.ttl >> <http://example.com/demo#joe> <http://example.com/demo#has> _:A113e01ecX3aX12ec4399200X3aXX2dX8000 . >> _:A113e01ecX3aX12ec4399200X3aXX2dX8000 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.com/demo#dog> . >> >> Or I serialize it as N-Triples and then de-serialize that back into memory in order to de-serialize it as RDF-XML: >> C> java jena.rdfcat -out ntriple test.ttl | java jena.rdfcat -out xml -n - >> <rdf:RDF >> xmlns:rdf=MailScanner has detected a possible fraud attempt from "www.w3.org" claiming to be "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >> xmlns:j.0=MailScanner has detected a possible fraud attempt from "example.com" claiming to be "http://example.com/demo#" > >> <rdf:Description rdf:about=MailScanner has detected a possible fraud attempt from "example.com" claiming to be "http://example.com/demo#joe"> >> <j.0:has rdf:nodeID="A0"/> >> </rdf:Description> >> <rdf:Description rdf:nodeID="A0"> >> <rdf:type rdf:resource=MailScanner has detected a possible fraud attempt from "example.com" claiming to be "http://example.com/demo#dog"/> >> </rdf:Description> >> </rdf:RDF> >> >> I do all that and then pipe it back to N-Triples again: >> C> java jena.rdfcat -out ntriple test.ttl | java jena.rdfcat -out xml -n - | java jena.rdfcat -out ntriple -x - >> <http://example.com/demo#joe> <http://example.com/demo#has> _:AX2dX59ad73bbX3aX12ec43a94a9X3aXX2dX8000 . >> _:AX2dX59ad73bbX3aX12ec43a94a9X3aXX2dX8000 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.com/demo#dog> . >> >> Yes the serializations all differ, but the graph represented is the same. Right? > This graph is pretty simple, so is not likely to show any problems (but a good point to start discussion). > If you start with a graph that was a fragment of a graph (that is, it was connected), then things might look different. > Consider if the original store also had (in addition to your fragment): > _:A113e01ecX3aX12ec4399200X3aXX2dX8000 rdfs:label "Bill" > So :joe has a dog called Bill. > If I combine your second serialisation with this triple, I do not get the connection. > The graph then roughly says that :joe had a dog, and there is a dog in the world called Bill. > Clearly the reason is that the b-node identifier being used is not global, so if I move the graph our of the local, to the global and then back again, I have lost information. > Unlike if it was a URI, which has a global meaning. > So the problem, if it is one, is because of the b-nodes, which is where we came in... :-) > Best > Hugh >> >> -Mark > > -- > Hugh Glaser, > Intelligence, Agents, Multimedia > School of Electronics and Computer Science, > University of Southampton, > Southampton SO17 1BJ > Work: +44 23 8059 3670, Fax: +44 23 8059 3045 > Mobile: +44 78 9422 3822, Home: +44 23 8061 5652 > http://www.ecs.soton.ac.uk/~hg/ > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Friday, 18 March 2011 02:37:19 UTC