- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Thu, 13 Dec 2007 11:19:18 +0000
- 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 extension. 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. Dave [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