ISSUE: Inconsistent graphs (and illformed literals)

I hope this is an easy point to resolve.

In <http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ 
0101>, I pointed out this phrase:

See <http://www.w3.org/TR/rdf-mt/#RDFINTERP>

""""""An ill-typed literal does not in itself constitute an
inconsistency, but a graph which entails that an ill-typed literal
has rdf:type rdfs:Literal, or that an ill-typed XML literal has
rdf:type rdf:XMLLiteral, would be inconsistent.""""""

However, RDF does not allow us to express such inconsistency, since  
we can neither have a literal in a subject position, nor can we  
equate a URI with a particular literal, nor can we fix the range of a  
BNode to illtyped literals (though in RDFS we can). (At least, I  
couldn't think of how to write an RDF-inconsistent graph...Pat?)

And of course datatyped interpretations allow for more inconsistency.  
OWL, of course, allows for much more.

Simple interpretations (and I believe RDF interpretations) never  
result in inconsistency.

Hmm. Do I have an example of an inconsistent RDFS without D  
Entailment graph? I guess it doesn't matter since we sanction D  
entailment. RDF + D entailment + our sanctioned datatypes can  
definitely have inconsistent graphs:

	:x rdf:type xsd:positiveInteger.
	:x rdf:type xsd:negativeInteger.

(See <http://www.w3.org/TR/rdf-mt/#DTYPEINTERP> for example of other  
inconsistent, typically RDFS, graphs.)

(Ooh, there is some trickiness when dealing with illtyped literals  
and the comparison operators. For example, is isLiteral 
("adfadf"^^xsd:integer) true? I think not by D-Entailment, since it's  
a illformed literal and

	 """The condition also requires that an ill-typed literal, where the  
literal string is not in the lexical space of the datatype, not  
denote any literal value. Intuitively, such a name does not denote  
any value, but in order to avoid the semantic complexities which  
arise from empty names, the semantics requires such a typed literal  
to denote an 'arbitrary' non-literal value. """"

So it denotes a *non*-literal value, thus it isn't a literal, thus  
the isLiteral is false! Tricky to get around this if literals are  
supposed to "give" their values from the graph.)

Personally, I think inconsistent graphs by RDF, datatype, or RDF/ 
Datatype, or RDFS or RDFS/Datatype interpretations are rather rare.  
But it's worth settling the corner case.

Inconsistent graphs entail everything, thus entail all answers.  
That's obviously silly.

There are two additional choices:

	1) An inconsistent graph returns no answers
	2) A query on an inconsistent graph returns an error, oh,  
"inconsistent graph".

I personally prefer the latter.

Note, just as an aside, I think this shows that the original idea of  
just doing graph matching and then doing graph matching against  
"virtual graphs" is not, by itself, a sufficient way of  
specification, even aside from the other problems it has with scaling  
to OWL. There are other side conditions that one must check.

Oh, there is a third choice, though I tend not to take it seriously:
	3) An inconsistent graph returns the set of answers that graph  
matching against a graph generated by forward chaining application of  
the entailment rules + some hacking to avoid BNode proliferation.

3 can be used as a way to detect contradictions, since there is a  
(large, disjuncitve) query that should test for datatype clashs. But  
clearly this particular incompleteness isn't sanctioned by the  
semantics, and we have to be *very* careful about specifying the  
rules and how they are applied to assure interoperability.

It wouldn't be that hard to come up with a paraconsistent reading of  
all this so as to get some version of 3 (i.e., "useful answers" out  
of the graph). For example, we could sanction all answers following  
from every maximal consistent subgraph of the inconsistent graph. It  
would still be good to distinguish between some answers that don't  
follow because the triples *aren't there* and some answers not  
following because they depend on *inconsistent* triples.

Cheers,
Bijan.

Received on Wednesday, 16 August 2006 13:37:33 UTC