Re: Another try at subclass

> 
> Michael Kifer wrote:
> 
> > These two proposals are orthogonal. The classification stuff is not the
> > only impasse. My proposal solves 3 of them and opens a general way of
> > getting rid of others, which we might encounter in the future.
> 
> Good point.
> 
> I have two concerns regarding your proposal:
> 
> First, as you know, I have some reservations wrt defining basic dialects 
> as profiles of another dialect, rather than directly. That is because 
> basic dialects, like Core and BLD, are meant to be extended, and 
> extending a profile adds some difficulty because of the indirection.

This is a non-issue as far as I am concerned.


> So, here is a subtle modification of your proposal that does not require 
> to decide between profile and extension at this stage (that's the 
> proposal I wrote in IRC at the very end of Tuesday's meeting): we can 
> keep the BLD document complete with all that is already specified, but 
> use the conformance section to specify, not just one, but several 
> dialects: Core, BLD, BLD++ (or whatever their names) etc.

What is BLD++? Your proposal made no sense to me. You said that BLD should
be BLD without classification and BLD++ should include it. In the above,
however, you are saying that BLD should include everything that has already
been specified. So, what do you mean by BLD++ now?

> It would help, 
> of course, to rearrange the current spec to make sure that all the 
> features that we put in Core are defined first, then the additional 
> features that we put in BLD, then the additional features that we put in 
> BLD++, etc; but that is true also if we define Core and BLD as profiles 
> of BLD++, anyway.

So?


> My second concern has more to do with the bundling of features in RIF 
> dialects (and/or profiles): we have a requirement that RIF has only a 
> limited number of dialect ("RIF must have a standard core and a limited 
> number of standard dialects based upon that core"). Whatever limited 
> means, the point is that we do not have only to decide whether each 
> specific feature makes sense by itself to be included in a RIF dialect, 
> but what bundle of features make sense as standard dialects/profiles.
> 
> So, suppose that we have a Core that is more or less Datalog, possibly 
> with procedural attachments and, since they are only syntactic sugar, 
> frames, the question is: what is the next bundle of features that make 
> sense on top of that, for logic rule languages and from a rule 
> interchange point of view (that is, in terms of coverage)? For instance, 
> do we really need a standard logic dialect on top of Core that has no 
> negation (remember that we are currently talking about adding two 
> dialects on top of Core before adding one that would include negation)?

Sorry, you got me confused. I do not understand what you want to say.

We will have as many dialects as it makes sense. It will be a "limited"
number, since we are limited. We will define the bundles that make sense
through profiling and/or through extensions.  Extending to first-order
logic would require an FOD (first-order dialect), which will be defined
precisely and with a great attention to details, like BLD. It will require
a lot of work, like BLD. It will be easy to show that the core is a profile
of FOD (as well as of BLD).


	--michael  

> 
> Cheers,
> 
> Christian
> 
> 
>

Received on Friday, 14 December 2007 18:26:38 UTC