Re: proposal for resolving deadlock

Christian de Sainte Marie <csma@ilog.fr> wrote:
>
> (resent because it seems that the original did not make it through)
> -------
> Michael,
> 
> Michael Kifer wrote:
> > 
> > 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.
> 
> I think that you are saying that that definition of BLD makes technical 
> sense as a rule language for the Web.
> 
> I understand that the discussion has been whether it makes technical 
> sense from the view point of standardising rule interchange: this being 
> a different technical domain, different criteria apply to what makes 
> technical sense.


It makes perfect sense from the standardization point of view as well.


> I believe that this (different people talking about different things) 
> is, at least part of, the reason for the deadlock (I mean: rather than 
> politics, misunderstanding or disagreemant that classification is useful 
> in a rule language and that it is not that difficult to implement in a 
> reasoner).
> 
> >    This dialect makes perfect sense not only technically but also
> >    pragmatically. One feature (equality) is a bit challenging to implement,
> >    but not insurmountable.
> 
> Perfect case in point: equality is challenging to implement in a 
> reasoner. But there is no real challenge in implementing a translator 
> from/to RIF and a rule language, if that language has equality...

There were difference points of view on what does it mean to "implement" a
dialect. So, rather than bickering about this or that we should start
working on a host of issues that have been pushed aside because of the deadlock.

If you remember, 5 weeks ago I promised a draft by mid December, if "people
will be agreeable". I was hoping that it was understood that I meant that I
do not have much time and that I should be able to write things if I could be
spared from arguing. But, it seems, the Dec 15 deadline will come and go...


> So, from a standardisation point of view, the (technical) question is: 
> what rule languages do we want BLD to cover? Equality not being a basic 
> feature of logic rule languages seems to plead for equality not being 
> included in RIF-BLD (but there may be good reasons to include it 
> nonetheless: let us just be sure that we focus on the relevant arguments).

Equality is a basic feature. Not everybody implements it, and this is why
we do not include it in the core.

> Regarding classification and membership, the question is whether it 
> makes sense to include them in a rule interchange format, not whether 
> they make sense in a rule language.

You are opening up another Pandora box, and if this group keeps doing this
we will never have anything done (and I will have no time to write).  From
the theoretical point of view, for an interchange format we do not need
anything more than plain predicates.  So, now you are opening the door for
further endless arguing about the features that "make sense" (whatever this
means) in an interchange format and those that do not.


> > [...] 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.
> 
> I am confused: why do you say that we have nothingf concrete on 
> extensibility? Isn't slotted syntax specified, in the BLD document, as 
> an extension of the (non-slotted) condition language?

We are supposed to come up with an extensibility ***mechanism***.
So far, we have only a "restriction" mechanism, which can be part of
the extensibility mechanism.


> I do not understand why extending is more difficult than profiling?

I explained this several times. To extend something, you need to give a
precise definition of the syntax and semantics. You must also make it
compatible with the base, which you are extending. This is difficult---at
least for me.

An "extensibility mechanism" is supposed to be a framework that would make
certain extensions easy. By the very nature of logic-based languages, such
mechanism will be very limited because coming up with non-trivial
extensions is hard (cf. the well-founded negation).


	--michael  


> Christian
> 
>

Received on Friday, 14 December 2007 18:15:21 UTC