(response from Chime)

(since he's not on the list.)

Forwarded message 1

  • From: Chimezie Ogbuji <ogbujic@ccf.org>
  • Date: Tue, 20 Jul 2010 23:10:46 -0400
  • Subject: Re: Solicitation of feedback
  • To: "Axel Polleres" <axel.polleres@deri.org>, "Sandro Hawke" <sandro@w3.org>
  • cc: "Dave Reynolds" <dave.e.reynolds@googlemail.com>, public-rif-wg <public-rif-wg@w3.org>, "Ivan Herman" <ivan@w3.org>, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk>, "Lee Feigenbaum" <lee@thefigtrees.net>
  • Message-ID: <C86BDD76.12830%ogbujic@ccf.org>
Comments, response below:

On 7/20/10 5:43 PM, "Axel Polleres" <axel.polleres@deri.org> wrote:
>>>> On Mon, 2010-07-19 at 10:26 -0400, Chimezie Ogbuji wrote:
>>>>> 7.2 (Simple) RIF Core Entailment Regime
>>>>> "It is unclear whether safe RIF-Core rules used to form combinations for
>>>>> this entailment regime guarantee uniqueness (up to RDF graph equivalence)
>>>>> on
>>>>> answer sets [...]
 
> uniqueness, I would think yes, finiteness obviously no.
> Or, what exactly do you mean by uniqueness here, Chime, could you give an
> example?

By uniqueness I'm referring to the part of condition 4 that requires "the
set of triples obtained by instantiating BGP with each solution μ is
uniquely specified up to RDF graph equivalence"

>> Without strongly safe restrictions, there may be
>>> If I recall correctly the issue was that people treat rule systems,
>>> especially production rule systems, like programming languages. They use
>>> the expressivity of cyclic dependencies while, in practice, ensuring
>>> appropriate termination conditions. An artificial example being
>>> something like:
>>> 
>>>    p(0) .
>>>    p(?x + 1) :- p(?x), ?x >= 0, ?x < 10 .
>>> 
>>> The strong safety conditions would exclude such rule sets.
>>> 
>>> We wanted Core to be a useful subset of both PR and BLD and felt that
>>> the restriction to strongly safe rules would eliminate too many rule
>>> sets used in practice (that would otherwise be within Core).
>> 
>> That sounds right, yes.
> 
> Yup, overall, a majority of the group found the finiteness restriction
> too strong for RIF Core, which is why it ended up as being informative only.

Ok, thanks that helps.
 
>>> I guess you could say that the SPARQL-RIF Core entailment regime is only
>>> defined over strongly safe rule sets and that interoperation is not
>>> guaranteed for other rule sets.
> I would rather say "interoperation is undefined by the SPARQL entailment spec"
> than "not guaranteed" (though that probably boils down to the same)

>>> Or could you  say that interoperability is only guaranteed over rule
>>> sets which terminate (on the given proof engine) and that strong safety
>>> is one way to ensure that?

This seems to be preferable and close to what we have in the current
entailment specification.  I.e., in condition 4:

"Each SPARQL extension?MUST?provide conditions on answer sets which
guarantee that the set of triples obtained by instantiating BGP with each
solution μ is uniquely specified up to RDF graph equivalence,
and?SHOULD?provide further conditions to prevent trivial infinite answers as
appropriate to the regime. "

The SHOULD criteria *can* be met through the use of strong safety conditions
while at the same time ensuring interoperability with other rule engines
with the understanding that this could be too restrictive for certain
rulesets.

>> Yes, exactly. Strong safety is one way to get certain guarantees, but
>> it's very limiting. I have the impression that neither rule system
>> vendors nor rule systems users have any interest in sticking to
>> strongly-safe rules, and a lot of them are not interested in sticking to
>> RIF Core (or even BLD or PRD).

FYI, my rule system is.  For one thing, limiting the expressive power to a
well-studied KR language allows the re-use of a significant body of
literature on query optimization, re-writing, etc. for the purpose of
efficient SW logical reasoning.

>> For the SPARQL WG to come in and
>> restrict them to a subset of what they want to do seems, well, let's
>> just say "sub-optimal".

The restriction isn't arbitrary but attempts to address the conditions that
extensions to basic graph matching need to fulfill.  In addition, the
characteristic of 'safety' (assurance of finite answers, basically) for
query languages is very common.

>> I'm pretty sure the right thing for SPARQL is to leave it to RIF, which
>> in this case means that systems doing RIF must implement RIF core, and
>> may implement additional features (eg PRD, or xml-data, or their own
>> built-ins.).  Rule authors have to decide what their audience is, and
>> pick the appropriate dialect; if they want the maximal audience, they
>> should stuck to RIF Core.

-- Chime


===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S.News & World Report (2009).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Wednesday, 21 July 2010 05:02:09 UTC