Re: proposal for resolving deadlock

> 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.

Let me put it differently: free of endless arguments about the requirements.


> >    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."

In my reply to Cris I qualified that the description is very brief.

But the mechanism is very simple. You just remove the syntactic features you do
not want and possibly impose other syntactic restrictions. As a result, you
get a profile without the need to repeat the syntax and semantics.
The profile mechanism can be further developed, of course, and should be
part of the extensibility framework (whatever will become of it in the end).

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

In general - yes. But not in BLD. BLD's signatures are already very
restricted, and I do not see why restrict them further in the core.


> [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 think you did not really intend to say that there is no distinction
between rif:IRI and xsd:integer (because there are many).
I took notice of the other minor point above, but this is introduction and is
supposed to be informal.


> >    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."

Extensibility is a vague term. I claim that the framework being defined in
http://www.w3.org/2005/rules/wg/wiki/FLD/ is extensible.
Perhaps not in the way you wanted, but then it is quite possible that what
you want is not achievable in a useful way.


> 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.

Would you task yourself to develop an acceptable 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.

So, do you agree to the proposed plan or not?


	--michael  


> 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 17:59:37 UTC