Re: proposal for resolving deadlock

Dave Reynolds wrote:
> 
> 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."

It is not so remote, IMO.
What's so wrong with the following:

a) an overall abstract model which dialects may extend and constrain,
    by constraints in a chosen formal or maybe even written in natural
    language,plus
b) an XSD (ideally a lifting- and loweringschemaLocation
    reference from SAWSDL which shows how we get from-to the abstract
    model), plus
c) a list of built-ins with binding patterns and
d) (where not "private" agreement) a document describing the
    semantics

These components together define  a dialect.

Furthermore, the extensibility document should mention the principles of 
reuse and conservative extensions i.e.: explain what invisible 
extensions are and that they should be avoided when defining a dialect, 
plus giving some guidelines how to do this, e.g. that elemants of the 
abstract model with a specific semantics should not reused in a 
semantics changing its semantics (example: negation as failure).

Isn't that sufficient?


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

As mentioned at the the last  face to face, i would prefer  datalog at 
the core, ie. no function symbols (at least we based our promise for a 
core implementation on that assumption)

>>     - no equality
>>     - no slotted predicates/functions
>>     - frames? Do not know - either way is fine

Slots+Frames: why not? Aren't they just syntactic sugar on datalog?
Especially if we use them for the RDF(S) encoding it would be nice to 
have them immediately.

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

Indeed!

> 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

> 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

Axel

-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

rdf:Resource owl:differentFrom xsd:anyURI .

Received on Friday, 14 December 2007 03:12:06 UTC