Re: proposal for resolving deadlock

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

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

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

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.

> [...] 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?

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

Christian

Received on Friday, 14 December 2007 12:55:46 UTC