- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Wed, 16 Aug 2006 14:37:05 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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