Re: Extensibility: Fallback vs. Monolithic

Bijan Parsia wrote:
> 
> On Jun 27, 2007, at 11:56 AM, Axel Polleres wrote:
> [snip]
> 
>> a) ignoring X will lead to sound inferences only but inferences
>>    might be incomplete
>> b) ignoring Y will lead preserve completeness but unsound inferences
>>    might arise
>> c) ignoring z will neither preserve soundness nor completeness
>>
>> etc.
>> while the latter two are probvably pointless,
> 
> [snip]
> 
> Since I don't know exactly what's being ignored, my conversations  with 
> various users, esp. those working on biology, certainly suggest  that B 
> is to be preferred to A (i.e., they *really* don't want to  miss 
> answers, and in their case it's pretty easy to check for  spuriousness, 
> and, typically, the likelihood of false positives is low).

That depends on the use case. If you have a use case for B, fair enough.
I just couldn't think of one, whereas I can think of various use cases 
for A.

> Similarly, if I just need *an* answer (not every answer) but I need  it 
> quickly, c could be fine as long as 1) the probability of some  correct 
> answer, if there is one, being in the answer set is high 

the higher this probability, the closer you get to A ;-)
but since I didn't think about probabilistic extensions here yet...
I think then you'd rather need a fallback like:

c') ignoring z will neither preserve soundness nor completeness,
     but preserve soundness with probability greater than <threshold>

anyway, if this threshold can't be named, I don't see good use cases.

> and  2) the answer set isn't to big and 3) I can check for correctness  well enough 
> or the consequence of the occasional wrong answer is low.

... as before: if "well enough" can't be qunatified, I feel a bit unease 
here.

> And of course, if my overall probability of error due to (inherent)  
> unsoundness or incompleteness plus the chance of a bug in my reasoner  
> is much less than the chance of a bug in an inherently sound and  
> complete reasoner, well, that's a reason to prefer the former.
> 
> I imagine that life is easier all around if the ignoring is  
> standardized. It's probably a bit easier to explain to users that the  
> system "ignores these bits and reasons with the rest" than to explain  
> how some particular approximation technique works in other terms. Oh,  
> and clearly a is the easiest to explain because of examples like  yours. 
> It's also easier to get interoperability since you can require  
> soundness and completeness for the pruned document.

I think I agree, though I am admittedly not quite sure what is the 
concrete point you want to make here? :-)

best,
axel

-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Thursday, 28 June 2007 09:07:54 UTC