Re: UNSAID drafted and mapped to SQL

On Sat, 2004-12-18 at 21:58 -0800, Pat Hayes wrote:
> >In response to a thread on UNSAID in the comments list [1], I've
> >drafted a section on UNSAID [2].
> 
> Let me strongly suggest that we do not include UNSAID in SPARQL.

That's been my position too, but I don't think I agree
with your justification.

>  To 
> do so would violate the basic assumption that underlies RDF and OWL 
> that graphs cannot be assumed to be complete sources of information. 
> RDF graphs cannot be assumed to be databases.

Do you mean "in some cases, RDF graphs are not complete" or
"in all cases, RDF graphs are not complete"? The latter
is not true. In many cases, RDF graphs *are* databases,
and hence assuming they are databases is quite correct.

> The message that started the thread
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Nov/0016.html
> has an example that illustrates the point in its use case 2, the 
> financial institution that must not send its prospectus to customers 
> in the US or Canada. For this institution to rely on an UNSAID query 
> to ensure this rule was obeyed would be very risky, since in general 
> the RDF content against which the query is being evaluated is not 
> known to be complete with regard to citizenship information. It 
> cannot be so known, except by special access to off-web information, 
> as there are currently no Web protocols for communicating the fact 
> that a source is complete in this way.

Do you mean "no standardized protocols"? Perhaps.
But (in later versions) I hope/expect this group to standardize
some design like:

http://www.w3.org/2000/10/swap/log#definitiveDocument

log:definitiveDocument a rdf:Property;
	rdfs:label "definitive document";
	rdfs:domain rdf:Property;
	rdfs:range doc:Work;
	rdfs:comment
"""	When document D is the definitiveDocument for property P,
any statement X P Y is true iff and only if the semantics of document D
include that statement.

For example, there may be a definitive document for the zipcode of
airports by airport code, and so on. This is useful to let a reasoner
know that it can extend its query to the given document.
(Cwm will do this if its mode includes "r").
""".

(also explained in the http://www.w3.org/2000/10/swap/doc/Reach
section of the cwm/n3 tutorial)

>  Unless one is sure that an RDF 
> graph is suitably complete, to conflate not-present-in-the-graph with 
> known-to-be-false is a very dangerous move, and quite likely to 
> result in an invalid inference.

The whole purpose of UNSAID is for the case when one is sure
that the relevant RDF graph is complete in some relevant way.

I prefer designs that do not allow the "background KB" to
go nameless. cwm supports ?G1 log:notIncludes ?G2 which
means "it is not the case that G2 is entailed (in the
sense of rdf simple entialment) by G1". That involves reasoning
about quoted formulas; perhaps that's overkill. But I'd prefer
that UNSAID require that FROM be explicit.

>  The use of UNSAID in SPARQL makes the 
> entailment of a query response by the target hostage to a graph 
> property which cannot itself be communicated by any current Web 
> protocol.

We're making a new protocol.

>  This is a very dangerous precedent to set, and violates the 
> design guides of the entire RDF/RDFS/OWL development effort so far.

Well, yes, it's new territory, to reason about more than one
graph/formula. I'd rather not got there in
SPARQL v1. But I go there routinely in my research work,
as do other implementors, and some use cases clearly benefit
from it.

> If SPARQL contains UNSAID then it will be inconsistent with any 
> account of meaning which is based on the RDF/RDFS/OWL normative 
> semantics.

Please, Pat, don't fling that sort of claim around lightly.
Your credentials mean that most people will believe it without
evaluating it critically. I'm nearly certain it's not true.


>  This will not render SPARQL unusable, but it will place it 
> outside the 'semantic web layer cake' and probably lead to the 
> eventual construction of a different, and rival, query language for 
> use by Web reasoners.

Interestingly, I understand the position of a majority of the
group to be: there are already rivals, and they have this
feature. If we don't standardize it, our work will be ignored.

I disagree; I think that to standardize the very basic
conjuctive query core of RDQL will *not* be ignored; the
other systems will become interoperable with our work,
and they will feed their requirements and experience into
our next round of design.

> Pat

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Sunday, 19 December 2004 14:30:37 UTC