W3C home > Mailing lists > Public > public-rif-wg@w3.org > September 2008

RE: RIF-Core: proposing resolutions to current issues / RE: [Core] Core telecon Monday, September 22

From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
Date: Fri, 19 Sep 2008 21:50:03 -0400
Message-ID: <E4D07AB09F5F044299333C8D0FEB45E904FFE4A7@nrccenexb1.nrc.ca>
To: "RIF WG" <public-rif-wg@w3.org>

This is a reminder about the Core telecon Monday, September 22:
http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0112.html

It's also a fwd of, and preliminary answer to, an email Dave sent
today to the Core co-editors.

I wonder if all might agree with the PROPOSEDs where Dave agrees
(... or would not formally object):

> > http://www.w3.org/2005/rules/wg/track/issues/48
> > PROPOSED: Keep membership/subclass in Core
>
> My preference is to drop membership/subclass but I don't think I'd go
as 
> far as formally objecting to them being included.

> > http://www.w3.org/2005/rules/wg/track/issues/71
> > PROPOSED: Core should keep unrestricted equality and external
function 
> > calls in rule bodies and keep external functions calls in rule
heads. 
>
> Agreed.

> > http://www.w3.org/2005/rules/wg/track/issues/74
> > PROPOSED: Core should keep both frames/objects and
> > (positional-argument) predicates/relations.
>
> I'd accept this but would like to check what others think.

> > http://www.w3.org/2005/rules/wg/track/issues/75
> > PROPOSED: Core should keep disjunction in rule bodies (cf. Gary's
UC).
>
> Reluctantly agreed, so long as marked as "at risk" at this stage.

> > http://www.w3.org/2005/rules/wg/track/issues/76
> > PROPOSED: Core should keep unrestricted equality in rule bodies (cf.
> > ISSUE-71).
>
> Agreed.

Also some clarification:

> > http://www.w3.org/2005/rules/wg/track/issues/70
> > PROPOSED: Parameterize the conformance clauses of Core with
> > safeness requirements "strict", "weak", and "none" (default:
"none").
>
> This is the one I didn't understand.
>
> What does this parameterization mean? Is it a property of an 
> implementation (in which case what does "default" mean) or of a rule
set?
> What is the definition of these different class of safeness
requirement?
>
> My preferred resolution is (c) on the list on the issues pages:
>
. . . see below . . .

I meant "strictly-safe" (a), "weakly-safe" (b), and "unsafe" (d)
conformance levels similarly as defined/linked in/from issue 70.
Perhaps a version of Dave's (c) could become another level.

Harold


-----Original Message-----
From: Dave Reynolds [mailto:der@hplb.hpl.hp.com] 
Sent: September 19, 2008 11:32 AM
To: Boley, Harold
Cc: Axel Polleres; Gary Hallmark; Adrian Paschke; kifer@cs.sunysb.edu;
team-rif-chairs@w3.org
Subject: Re: RIF-Core: proposing resolutions to current issues

Boley, Harold wrote:

> Hi All, I started to incorporate Axel's suggestions in the unbundled
> update below.

Thanks. I didn't quite understand your response on my request to take 
the discussion to the wider list but I've been out for a couple of days.

Let me respond here for now.

> http://www.w3.org/2005/rules/wg/track/issues/48
> PROPOSED: Keep membership/subclass in Core

My preference is to drop membership/subclass but I don't think I'd go as

far as formally objecting to them being included.

In general I'd rather keep Core as small as possible to simplify 
implementation of Consumers, dropping things which are essentially 
syntactic sugar.

In this case there is the specific (but non-technical) problem of the 
confusion with the RDFS constructs. My primary interest is in having RIF

Core be able to exchange semantic web rules and the introduction of 
constructs which are similar but not identical to the existing ones will

lead to confusion and support load. The relationship between #/## and 
rdf:type/rdfs:subClassOf has been precisely defined and implementation 
cost is small but for us support costs swamp implementation costs.

 > (maybe limiting these constructs to rule bodies).

How would that be useful?

In the case of object-based systems such as Oracle's (which I take to be

the motivation for this suggestion) then the member/subclass are defined

externally to the rule set and need to be made accessible to rules. My 
understanding was that this would be done as a set of RIF facts which 
obviously correspond to rule heads, not to rule bodies.

There is also the question of new/skolem functions.

> http://www.w3.org/2005/rules/wg/track/issues/70
> PROPOSED: Parameterize the conformance clauses of Core with
> safeness requirements "strict", "weak", and "none" (default: "none").

This is the one I didn't understand.

What does this parameterization mean? Is it a property of an 
implementation (in which case what does "default" mean) or of a rule
set?
What is the definition of these different class of safeness requirement?

My preferred resolution is (c) on the list on the issues pages:

No safety criteria for Core itself. The conformance statement for a Core

Consumer only requires conformance over a safe subset.

Jos, argued for (d) saying [1] the current notion of a conformance based

on translation to an "implementation language" implicitly allows for 
incomplete processors. I don't understand precisely what that means for 
implementers enough to be completely happy with it but it seems like a 
valid option. Follow up Jos' suggestion was one reason I wanted to take 
this discussion to the wider list.

> http://www.w3.org/2005/rules/wg/track/issues/71
> PROPOSED: Core should keep unrestricted equality and external function

> calls in rule bodies and keep external functions calls in rule heads. 

Agreed.

> http://www.w3.org/2005/rules/wg/track/issues/72
> PROPOSED: Do not include Skolem functions or a 'New' builtin for Core
> (a 'New' construct can be developed for PRD).

I would prefer to include the "new" builtin and have that available in 
both BLD and PRD.

My primary motivation is that a substantial number of "in the wild" RDF 
rule sets do something like this to construct new bNodes. For the 
observed usages then the proposed "new" builtin would be sufficient and 
would be implementable in both a BLD and PRD setting.

However, PRD seems to be opting for the "new" action, rather than the 
builtin/skolem function, and that seems to have a Gensym semantics. 
That's clearly a problem. I assume PRD doesn't want two different forms 
of "new" and the true Gensym form can't be in Core.  I'd like to at 
least understand the PRD position here before agreeing to this proposal.

> http://www.w3.org/2005/rules/wg/track/issues/74
> PROPOSED: Core should keep both frames/objects and
> (positional-argument) predicates/relations.

I'd accept this but would like to check what others think.

The reason for raising the issue is that the rule languages I'm 
interested in exchanging between represent facts as either objects or 
RDF triples.

Given that a a lot of PRD systems use an object model or something like 
Jess' unordered facts it seems reasonable to ask whether relations are 
really in the PRD/BLD overlap or whether frames-only is closer to the 
common denominator.

> http://www.w3.org/2005/rules/wg/track/issues/75
> PROPOSED: Core should keep disjunction in rule bodies (cf. Gary's UC).

Reluctantly agreed, so long as marked as "at risk" at this stage.

I would like to argue that this is syntactic sugar and can be removed by

L-T but Gary's argument that the result of such a transform blows up 
enough to be non-tractable in practical settings is a good one.

It remains a worry though. Including it in Core means that languages 
without disjunction (a lot of them, ours included) will not be able to 
effectively implement Core (by Gary's argument).

I recall Jos being particularly opposed to inclusion of disjunction. I'd

like to understand whether he has other reasons for this.

> http://www.w3.org/2005/rules/wg/track/issues/76
> PROPOSED: Core should keep unrestricted equality in rule bodies (cf.
> ISSUE-71).

Agreed.

Dave

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Aug/0148.html

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Saturday, 20 September 2008 01:50:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:54 GMT