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 former; but more to the point, some are complete and some are 
not, and there's no way to say which are which.

>The latter
>is not true. In many cases, RDF graphs *are* databases,

Right, and I wish there was a way to say so. (Later: OK, you have a 
way... .great!)

>and hence assuming they are databases is quite correct.

Nyaaah, wait a minute. Its never correct to assume on no evidence, 
seems to me. Even if you are right, its only because you were lucky.

>  > 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"?

Right.

>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.

OK, terrific idea! If we can do (something like) that, then I have no 
problems with UNSAID. But I'd like the documentation to talk about 
them in the same breath, as it were.

>(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.

How does one get that sure? Here I am, an innocent and rather dumb 
software agent, and I come across an RDF graph. I know how to draw 
positive conclusions from it, and I might even know about NAF. But 
how can I tell if NAF is safe to use on this graph? Its not good 
saying that I can use it when I know the graph is closed, if there 
absolutely no possible way for me to find out or to be told if the 
graph is closed. Under those circumstances, I can never know the 
graph is closed.

I think the folk who want NAF-style reasoning so badly are imagining 
situations where software argents havn't really arrived yet, and the 
Sweb is really just a lot of conventional DB software built into Web 
applications which do a limited, fixed job using known data sources. 
In this kind of application, I agree my scenario is kind of 
irrelevant.

>I prefer designs that do not allow the "background KB" to
>go nameless.

I like that, too. We included that in the OWLQL design. We figured 
that any service that can't identify its source (such as a syndicated 
news feed, or some such, which is getting information from all over 
the place)  should give itself as the source, and consider itself to 
be a (maybe dynamic) virtual RDF graph.

>  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.

Well, not just that. The more expressive the language gets, the 
harder it is to establish non-entailment. Its usually harder to 
determine non-entailment than entailment. OWL is right at the edge of 
the cliff.

>But I'd prefer
>that UNSAID require that FROM be explicit.

I think that ought to be essential, agreed.

>  >  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.

Ah, indeed. I had assumed that this would be restricted to queries, 
but having issue of closure in its scope is a very good idea.

>  >  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.

I really do believe it is true, with the simple unqualified form of 
UNSAID which is the one I thought we were talking about, and with the 
assumption written into the draft concerning the assumed relationship 
between UNSAID and NAF. You obviously have a lot more structure and 
future work in mind, and my strong words may well not apply to the 
results of that future work. In fact they already do not apply to 
that 'definitive document' idea.

However see my recent msg to Bob McGregor for some of the 
(interesting) complications that I think we will need to go into to 
make this work in practice.

>  >  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.

I agree with you there. All the SWeb experience so far has argued for 
the utility of very simple steps, and being willing to take the next 
step quickly.

Pat

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


-- 
---------------------------------------------------------------------
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
phayes@ihmc.us       http://www.ihmc.us/users/phayes