W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: more on RIF entailment regime

From: Axel Polleres <axel.polleres@deri.org>
Date: Thu, 25 Mar 2010 08:36:45 +0000
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Chimezie Ogbuji <ogbujic@ccf.org>
Message-Id: <E04E12F9-4C7D-4310-ACFB-784A1DDD5453@deri.org>
To: Axel Polleres <axel.polleres@deri.org>
BTW: I am not sure procedurally, but it may be an issue that strong safeness is only an *informative* part of the RIF spec?
http://www.w3.org/2005/rules/wiki/Core#Strong_Safeness_.28Informative.29

Axel

On 25 Mar 2010, at 08:34, Axel Polleres wrote:

> "Without appropriate safety conditions, cyclic references can rule out the existence of a single intended Herbrand model of the combination and indeed various stratification and stable model theories [STABLEMODEL] have been defined in the literature that use a dependency graph to determine if a ruleset is stratified and incorporate the restricted use of built-in function symbols that allow the truth of a predicate to be well-defined by an external procedure.  This entailment regime restricts the legal graphs to only those that refer to strongly safe RIF core documents. This excludes the use of negated (non-monotonic) atoms and cyclic references between terms in built-ins."
> 
> I think this paragraph might confuse. Stable models, stratification, etc. are only vaguely related to the issue we face here, since they are usually only of interest in the context of rule languages with (non-monotonic) negation. Neither RIF Core nor RIF BLD have negation, so I think it shouldn't be mentioned here.
> 
> I think we are (modulo datatypes, which I am afraid is an issue here as well) fine for strongly safe RIF Core.
> However, as for finiteness criteria for non-strongly safe core, I find it hard however to think of anything else 
> than something operationally defined (as I had sketched it earlier, by e.g. limiting the "levels of recursion" somehow.)
> 
> Axel
> 
Received on Thursday, 25 March 2010 08:37:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT