Re: one thing we forgot

On Sat, 05 Jul 2008 20:53:51 -0400
Sandro Hawke <sandro@w3.org> wrote:

> > On Sat, 05 Jul 2008 14:19:40 -0400
> > Sandro Hawke <sandro@w3.org> wrote:
> > 
> > > 
> > > > You cannot determine a dialect just by its syntax. Examples are: LP
> > > > with stable model semantics and with well-founded semantics. 
> > > 
> > > In that case, as we've been over before, we just use different NAF
> > > operators (smnaf and wfnaf were Axel's examples).
> > 
> > If we use this as a guiding principle then yes, it solves the problem.  But
> > this has serious cost attached. I am just concerned with the notation
> > explosion effect and other undesirables.
> 
> Yeah, there are costs to any approach, for sure.
> 
> > For instance, suppose I am writing a stratified program that uses naf.
> > This would be within both stable model and W-F semantics. Which NAF
> > symbol am I supposed to use? If I want my ruleset to be acceptable by
> > both, one would need to invent a new dialect, which is in the
> > intersection of the two dialects.  Or it will require those two
> > dialects to carry one additional kind of negation, stratified-naf,
> > which can only be used in a stratified way, but otherwise would be
> > upward-compatible with both stable-model and w-f semantics.  Neither
> > seems to be a good alternative.
> 
> I don't remember the full discussion we had, looking at Axel's NAF
> proposal, but I think it's probably okay to have stratnaf be the first
> cut, and when people need something more they have to pick wfnaf or
> smnaf.

1. Axels proposal had many holes, which he never closed to come up with a
   concrete proposal.
2. His proposal does NOT address the problem, which I noted above.

We cannot base extensibility and possibly make irreversible decisions based on
a proposal that is in such a preliminary stage.

Regarding your "it's probably okay to have stratnaf be the first cut" I will
not comment technically because you obviously did not think this through.


> > > > Closer to home: BLD and a (syntactically) BLD-like document with F-logic
> > > > semantics. The former does not have inheritance, while the latter does.
> > > 
> > > I'm not familiar with this difference.   Can you give me a test case?
> > > Two small RIF documents which would have different entailments or
> > > consistency?
> > 
> > Scratch that: inheritable methods use a different notation (*-> vs. ->).
> >
> > But there are other examples. For instance, rule ids are used in
> > different wa ys by different semantics (while syntactically there is
> > no difference).  For instance, BLD with courteous semantics (even
> > without negation) would have a different meaning.
> >
> > This one can also be overcome by changing notation, but I feel that
> > this will backfire on us. It is not hard to come up with a scenario
> > similar to the one I gave earlier.
> 
> There may be nightmare scenarios...    I'm expecting we'll find clever
> ways, if necessary, to make them not too, too bad.

This is not an argument that we can use in making technical decisions.

<snip>

> > > (Meanwhile, it's up the the chairs, but I don't see any new information
> > > here, and we already decided at F2F10 not to make any other changes, so
> > > this discussion (as something that goes into BLD now) seems out of
> > > order.
> > 
> > The example about SMS and WFS above is new information.
> 
> I'm not sure how it's different from what we've talked about before, eg
> http://www.w3.org/2007/07/10-rif-minutes.html
> 
>     axel describes his extension on NAF
> 
>     axel: extension of core with naf
> 
>     ... three extensions stratified negation, well-founded semantics
>     semantics and stable model semantics for negation 

This proposal has not been worked out and was never discussed as a basis for
any architectural decisions. Because it was never put up as something that
will be at the very basis of things, serious objections were never raised.


> > Actually, I do not remember that we made a resolution that no dialect
> > attribute will be allowed. Did we?
> 
> I doubt such a resolution was made, per se, but I know the "Last Call"
> resolution was:
> 
>     RESOLVED: Advance BLD to Last Call, pending satisfactory completion
>     of the edits decided at this meeting. 
> 
> ... and adding this attribute was not such an edit.

As you may have noticed, I retracted my original objection and do not insist on adding this attribute to BLD.
But it must be in FLD and compliance with FLD will have to be appropriately specified. This is the next fight :-)


> > > A dialect tag could be proposed as an extension, of course.)
> >
> > Agreed. For BLD we do not need this attribute, but it could be added
> > to FLD as optional. Then the designers of new dialect would be free
> > to decide to include them or not.
> 
> Vendors can't add this local extension unless FLD licenses it?  That
> can't be right.


Yes, this is the purpose of FLD.
FLD is our best chance at extensibility currently.


> > This would work if you will not insist that such a thing violates some
> > higher laws and cannot be accepted as a matter of principle.
> 
> Heh.  I think the most we can to is give dialect/extension designers
> good reasons for designing certain kinds of dialects/extensions and hope
> they are persuaded.

If they want to be officially sanctioned then they should convince us why a
particular dialect does not fit in the framework.


	--michael

Received on Sunday, 6 July 2008 01:21:01 UTC