Re: Semantics necessary not sufficient (was: Re: What is "the serious bug in entailment semantics" found by J. Perez"?)

[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