W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2006

Re: ISSUE: Inconsistent graphs (and illformed literals)

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Fri, 18 Aug 2006 06:47:35 +0100
Message-Id: <A1EE5435-7117-4B87-9859-0D06B9A74197@cs.man.ac.uk>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: Pat Hayes <phayes@ihmc.us>

Ok, there is another option. One could return an error + the union of  
all the sets of miniminally inconsistent subsets of the graph (or the  
lean union).

I.e., error + explanation.

If we wanted to define another sort of entailment (paraconsistent  
RDFS), then you could chose to always query under it, query under  
normal RDFS except when the graph is inconsistent in which case, upon  
examining the explanation, choose to requery under the paraconsistent  
RDFS (or seek to repair the graph).

Oo, how about allowing the virtual constructions of query targets.  
For example, suppose I have:
	G1: {a b c. a b2 c. e b d.}
	G2: {a b2 c}

Now, why can't I query G1\setminus G2? Even better if I can embed the  
G2 in my query.

So, the scenario would be: I query an inconsistent graph. I get back  
an explanation (i.e., union of all the minimally blah blah). If I  
want to repair the graph a particular way, I delete selected triples  
untiil the explanation is consistent. Call the set of those removed  
triples a "repair" of the KB.

Now I can run my query against the graph \setminus the repair. I  
think (and i've only had 4 hours sleep in the past two days :)) that  
if you treat the whole explantion as the repair, you get the  
skeptical paraconsistent answers. (Right? G |= P just incase *every*  
maximally consistent subset of G |= P. But any element of a minimally  
inconsistent subset cannot be in every maximally consistent subset.)

If you are worried about the burden, make it permissible to return an  
error with no explanation.

Oh, I think it's impossible to have a single SPARQL query to test for  
inconsistency of all graphs. You need to work your way through the  
subproperty tree (at least), so need some sort of transitivity.

Plus, we don't have a test function for illformed literals. Since we  
have no function that is sensitive to xmlliterals (that I know of),  
we have no way to detect, in sparql, whether an XMLLiteral is  
illformed. I think we should have such a test function.

Received on Friday, 18 August 2006 06:06:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:51 UTC