- From: Pat Hayes <phayes@ihmc.us>
- Date: Sat, 19 Aug 2006 17:14:38 -0700
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
[snip] >> >[Bijan:] >Here's a problem, in general, I have about told BNodes, they are not >really part of RDF as specified. Really, this is not true. RDF nowhere specifies what the 'scope' of bnodes is, other than by talking about an RDF graph: but it also doesn't specify what counts as the boundary of a graph. Allowing told bnodes amounts to extending the scope of the told bnodes over several queries and answers - call this a 'session' - so that 'the RDF graph' involved is something that extends over an entire session, i.e. the entire session is about a single graph. There is nothing in the RDF specs that says that this is illegal or in any way suspicious. RDF does not require that RDF graphs are identified with document boundaries. >They *are* part of RDF as practiced. They are quite consistent with the RDF specs, if we take care to interpret them properly. >But part of our job is to make specs cohere and to make things, >generally, less confusing than more. So, I would prefer to tackle >this head on rather than slide around it. Tackling it head on, imho, >means either respecting the current semantics, or *changing* them. No, it does not. None of the SPARQL designs we have considered require any changes to the RDF specs. [snip] >>>[Bijan]I do think that this should be *available* and the >>>*default*, but i think too that if we don't make the irredundent >>>answer sets available (if only by special user demand) then we >>>aren't cohering with the semantics of RDF. >> >>[Pat] Hmm. Not sure I agree with the "semantics of RDF" point >>exactly, but never mind. > >[Bijan] Let me put it this way, either redundancy is semantically >significant, or it isn't. Seems to me that its not *semantically* significant pretty much by definition. Explanation: what we mean by redundancy is two graphs/answer sets which have exactly the same models but one is a subgraph/subset of the other. Having exactly the same models means that the differences between them are semantically *invisible*. Which is why, of course, we have to resort to other criteria than semantically defined ones - restricting the allowed *form* of answer bindings (rather than what they denote), etc.. So, my answer would be: no, semantic redundancy is not *semantically* significant, since removing the redundancy does not change what the answers actually mean. Which of course is not to say that it may not be of great practical significance, etc.. >(Or significant in some cases and not in others.) There's one story >where redundancy is like redundancy in SQL, that is, a *purely* >computational hack/convenience/whathaveyou. DISTINCT gives you the >"real" answer set, in some sense (at least from the POV of the >underlying formalism). So, if we treat BNodes as told systematically >throughout the processing of a query (and even unto separate >queries), always, and only, then we are treating redundancy which is >*not* significant, by the semantics of the underlying formalism, as >very significant. I cannot follow what the above is saying. >I think it would be a legitimate objection to the spec if that were >the case. I think if the group wants to do that, then it should face >the tension with the RDF Semantics document head on. There is no tension with the RDF semantics either way. The difference between allowing told bnodes and not allowing them have to do with different choices about how bnodeIDs in the surface documents (queries and answer documents) are related to RDF graphs, in particular to the scoping graph. Told bnodes amount to treating all these documents as having a shared bnodeID scope, which is indeed unusual (and AFAIK, new), but has no bearing on the RDF semantics, which is entirely connected to the RDF graph 'abstract' syntax. Refusing to allow told bnodes amounts to the more conventional route of treating answer documents (or maybe query/answer document pairs) as defining local bnodeID scopes separate from any other document-defined scope. The RDF semantics (and the RDF graph syntax model) applies happily to both cases. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Sunday, 20 August 2006 00:14:52 UTC