W3C home > Mailing lists > Public > public-rif-wg@w3.org > December 2007

Re: proposal for resolving deadlock

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Thu, 13 Dec 2007 11:19:18 +0000
Message-ID: <47611536.2090305@hplb.hpl.hp.com>
To: Michael Kifer <kifer@cs.sunysb.edu>
CC: RIF WG <public-rif-wg@w3.org>

Michael Kifer wrote:
> Gang:
> We have been deadlocked on a number of issues, including class hierarchies,
> equality, named arguments in predicates, with no end in sight.  We have
> wasted a lot of time in email conversations and F2Faces and still have not
> reached a solution.
> We need to move on with our work, so let me reiterate in a more articulate
> form what I believe is a way out of this deadlock.
> 1. Define BLD to include the features that make technical sense (free of
>    political considerations). This should include everything that we have
>    right now: equality, frames, classification, slotted terms.

Disagreement on requirements is not the same as politics.

>    This dialect makes perfect sense not only technically but also
>    pragmatically. One feature (equality) is a bit challenging to implement,
>    but not insurmountable.

> 2. Use the profile mechanism to define the core and other dialects (if
>    necessary).

I was going to ask the same question Chris did. I can't see on [1] where 
there is a mechanism described. There is a comment:

   "RIF dialects can choose to support all or some of the aforesaid 
categories of terms."

There is also a notion of symbol spaces is this supposed to be part of 
the profile mechanism?

[The "symbol spaces" paragraph is confusing. You seem to be 
distinguishing things of type rif:iri from other things identified by 
IRIs such as xsd:integer, in general there is no such distinction. You 
describe rif:IRI as denoting "resources on the Web" but that's not the 
case - rif:IRI can designate anything in the domain including abstract 
concepts not just web resources.]

>    I already explained that profiles give us a simple mechanism to define
>    subdialects. The dual approach advocated by some people, i.e.,
>    developing an extensibility mechanism, is currently pie in-the-sky. It
>    is a research issue, which is very interesting, but we have nothing
>    concrete and we should not base our decisions on a **very remote** (IMO)
>    possibility that a useful extensibility mechanism will become available
>    in the future.

That's a much more serious issue. If that's the case then that 
invalidates what we agreed at F2F8 as the basis for asking for a charter 

Our charter says (under 2.2.1 Extensibility):
   "The essential task of the Working Group in Phase 1 is to construct 
an extensible format for rules."

At F2F8 we enumerated [2] what it would take to get to LC and the first 
item on the list was "proven extensibility" which we then moderated to 
"extensibility mechanism".

If we are not going to deliver an extensibility mechanism then we won't 
hit that last call requirement. That is vastly more serious than the 
boundaries of what is or isn't in BLD.

To be clear, the notion of a profile mechanism to support partial 
conformance with a dialect is a reasonable one. However, it is no a 
substitute for the extensibility mechanism.

> 3. The CORE would be essentially a Datalog profile of BLD, plus or minus.
>     - not sure if function symbols will be allowed (I think yes)
>     - no equality
>     - no slotted predicates/functions
>     - frames? Do not know - either way is fine
>     - classification: I am fine with not including it in the core
>     - this minus function symbols is also probably acceptable as a core of PRD

This seems like a fine description of the Core.

Given that we have an committed requirement to deliver an extensibility 
mechanism then surely BLD can be an extension of this Core in the way we 
have discussed it up till now.

[1] http://www.w3.org/2005/rules/wg/wiki/FLD/Overview
[2] http://www.w3.org/2007/09/28-rif-irc-ed.html#item12

Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Thursday, 13 December 2007 11:19:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:48 UTC