Re: UNSAID drafted and mapped to SQL

On 2004-12-20 10:12:02 -0800, Pat Hayes wrote:

>>The point of applying UNSAID in the way described in use case 2
>>is, precisely, that the graph that's queried is assumed to be
>>sufficiently complete for the querying party's purposes.

> But that assumption is invisible on the semantic web.

The solution is, then, to define a way for asserting it on the
semantic web, so inferences based on UNSAID can properly be made.
Not specifying UNSAID doesn't solve anything, on the other hand.

> A related matter. UNSAID refers simply to the absence of a
> triple.  But RDF supports entailment of triples by other triples,
> and such entailments become quite complex in RDFS and extremely
> complex in OWL; and RDF/XML is required by the various W3C WG
> charters to be the interchange syntax for these more complex
> languages.  Suppose an OWL/RDF or RDFS triple store does not
> contain a certain triple, but that triple can be inferred by
> valid OWL or RDFS reasoning from triples that it does contain. In
> this case, a reasoner that relied on UNSAID to implement
> negation-by-failure would become logically incoherent, not merely
> mistaken: quite simple inputs would cause it to become enmeshed
> in contradictions. (It might be better to have something like
> UNIMPLIED rather than UNSAID, particularly as an RDF graph can be
> reasonably taken to be 'saying' any RDF-valid consequence of
> itself. )

My proposal here would be that UNSAID's semantics should match those
of other SPARQL queries.  I.e., when a (positive) graph pattern is
only matched against the actual stored graph, then UNSAID should do
the same; when a (positive) graph pattern is matched against the
graph's consequences, so should be UNSAID.

(I do realize that the use of UNSAID in reasoners will require
additional care, hence my earlier suggestion to include an
UNSAID-free profile of SPARQL with the specification that can be
used more safely in reasoning contexts.)

>>Note that this risk is not created by specifying a full version
>>of SPARQL, including UNSAID, and by additionally profiling some
>>subset of it that satisfies whatever assumptions you want to be
>>able to make.

> I feel strongly that UNSAID is in this category of a
> useful-if-you-know-exactly-how but dangerous-and-easy-to-misuse 
> kind of a feature, and one that is better omitted than included.
> And I feel this way even more strongly when the email thread that
> suggested it, and the draft write-up of the language feature
> itself, both misuse it in exactly the dangerous way.

I wonder if there are any specific changes to the language write-up
that would help to mitigate your concern.

Happy holidays, and kind regards,
-- 
Thomas Roessler, W3C   <tlr@w3.org>

Received on Monday, 27 December 2004 12:49:06 UTC