Re: model theory of error

Bijan Parsia wrote:
> 
> On Jan 10, 2008, at 10:25 AM, Christian de Sainte Marie wrote:
> 
>> Just a small clarification (!), after reading Dave's comment.
>>
>> Christian de Sainte Marie wrote:
>>> How do commonly used implementations of basic logic rule languages 
>>> (e.g. various implementations of Prolog, datalog, whatever) handle 
>>> the case of evaluated functions or predicates when some argument is 
>>> out of there domain of definition?
>>
>> My point is that, if the most usual ways to handle this kind of errors 
>> pratically (that is, in computer implementations), are amenable to one 
>> and the same model theoretic semantics, then it is ok for RIF to 
>> specify it (well, there are always the costs/benefits to be 
>> considered, of course, but that's a different question).
>>
>> Option (b) feels more likely, in that case, but my feeling may not be 
>> the most relevant in that matter :-)
>>
>> But if they are not amenable to a single model theoretic semantics of 
>> error, then we should consider not giving a model theoretic semantics 
>> to error in RIF.
> 
> To make this concrete (and to check my understanding). There are two 
> possibilities on the table: (a) (aim for falsity on error, which I 
> personally like and is good for OWL) and (b) which involves new truth 
> values blah blah but is, potentially, a better fit for SPARQL and for 
> things like SPARQL Rules. 

just for somebody interested... as for the needs of translating SPARQL 
to rules, I could resort the problem of filter evaluation which needed 
the 3-valued semantics of FILTER expressions to calls for external 
built-ins for evaluating these FILTER expressions as a whole... so, in 
the rule language I don't bother with the 3-valued error semantics of 
filter expressions.

What I mean here is, something like

SELECT *
WHERE { ?X :p :o. FILTER( some complex filter expression) }

wil be translated to:

answer( X ) :- rdftriple(X,p.o), &eval[some complex filter expression, 
X, "X"](true).

i.e. I have to parse & evaluate the whole filter expression with an 
external function...

... if this is what you mean by SPARQL rules, if you mean rather having 
SPARQL queries in rule bodies, then these would probably be seen as 
external built-ins anyway.

Axel

> But (b) is hard with a lot of risk, so Michael 
> proposed picking (a), which is simple and well understood.
> 
> But, Christian points out, that means we force SPARQL rules (and any 
> other system that doesn't conform with (a), like, perhaps, prolog with 
> exceptions? which are....I think?...in ISO prolog?) to be incompatible 
> with RIF documents that contain built in functions. So, if I translate 
> my OWL rules (using (a)) to a system that handles error like (b), I will 
> get different answers to my queries in each system. And, in fact, the 
> second system will be *wrong* with respect to RIF, thus should reject 
> all RIF documents with builtins to be safe.
> 
> Christian is asking how likely this scenario is? If it is very likely, 
> then RIF should make it easier to opt out of choice (a) without being 
> forced to avoid built-ins. The simplest way to handle this is to support 
> builtins systactically but say that their semantic on error is 
> implementation dependent. (Though, you could still provide (a) as a 
> default...why not?)
> 
> Christian, have I captured your concern?
> 
> Cheers,
> Bijan.
> 
> 


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

rdf:Resource owl:differentFrom xsd:anyURI .

Received on Tuesday, 15 January 2008 16:01:53 UTC