Re: [BLD] PS specs amendments - -chairs: requires an action

On Wed, 24 Sep 2008 21:37:52 -0700
"Hassan Ait-Kaci" <hak@ilog.com> wrote:

> Michael,
> 
> Thank you for caring to explain. But we seem to be talking in
> circles. Let me make my position clear:
> 
>    I don't care what the PS looks like - but I would expect it to be
>    parsable; at least if we wish for an implementation.
>    
> > Here we are arguing about the details, not substance. I just pointed
> > out that "..." don't look good here because "http:/bar.baz/fuz#" is
> > supposed to be an xsd:string according to the DTB syntax.
> 
> Notwithstanding whether this "looks good" to you or not, I do not
> agree. We *are* arguing about substance when the issue is about how to
> actually parse your EBNF. As I pointed out repeatedly, the only place
> for these double-quoted occurrences are in the Base and Prefix
> *directives* not *grammar rules*. (See
> http://www.w3.org/2005/rules/wiki/BLD#Formulas, Item 7 of the
> definition of a Document formula.)  They define "shorcuts" precisely
> to allow CURIE notation to be used in the document following their
> occurrence. In other words, I do not agree that "...
> "http:/bar.baz/fuz#" is supposed to be an xsd:string ... ". The
> occurrence there one of a pragma - it is not part of the body of a
> document Uniterm or Frame. I do not see (nor agree) that it must be an
> xsd:string.

Whether it is in a pragma or not, I think an occurrence of a symbol should mean
the same thing in different places. So, if "abc" means "abc"^^xsd:string
elsewhere, it should mean the same thing in a pragma. This is an aesthetic
issue, which is why I said "it does not look good" as opposed to "it is wrong".
If we can make things consistent across the whole spectrum (like using
<...> or using a different set of delimiters) then I'd prefer that.

> > Right. What IRI is in Prefix and Base is up to us.
> 
> Right. So, in what way is what I am suggesting contradicting this? 
> 
> > > So, unless I am missing something that you will explain to me, it is
> > > not that "#4 clash with the assumptions underlying PS&DTB" but rather
> > > that the assumptions underlying PS&DTB EBNF's are inconsistent!
> > 
> > Nope. The example is simply wrong (the book(cpt:author->?Author
> > cpt:title->bks:LeRif) part).
> 
> So what is the correct form? Is - or isn't - cpt:author allowed as the
> name of the argument to book?

It should be book(author->?Author title->bks:LeRif)

This mistake was most likely the result of a global substitution search
(might have been even introduced by me: all it takes is
%s/author/cpt:author/g
in vi   :-).

Note: in frames cpt:author is allowed, but author is not.

The reason is that in frames variables can range over property names, so they
have to be constants. In uniterms, argument names are just labels.
It is possible to define them as constants instead. But then there are problems
like the equality between constants. Some people were very vocal against
allowing repeated arguments with the same label name. If u allow to equate
labels then we cannot reconcile this with the above requirement.
There are also difficulties with implementing such terms, if equality among
labels is allowed (unification and the like). This is why ArgNames is disjoint
from constants.

> The current EBNF surely does not allow a
> CURIE there. So do you mean that *all* the named-argument Uniterm
> examples in the current specs are wrong?

I would not say "all". Some - yes.

> BTW, I do not understand why
> CURIE's should not be allowed as they are in the examples. All I am
> suggesting is that they be allowed as names as well (as the examples
> show).

It is not the curies, but the nature of those argument names: are they
constants (and therefore equatable) or not?

> Regarding what I am proposing and what you are proposing, let me say
> the following: I feel pretty confident that I can provide an
> implementation with the simple amendments I suggested.

See above. One can implement many things, but not all of those things are
equally good. As I explained, there are reasons why the arg names are not
constants. If the group feels that we should make them into constants (and that
the LC situation permits that) then fine.

>  If you have
> better, sexier, anythinger, ideas to make the PS *parsable* by non
> mind-reading voodoo priests, and can explain it to simple minds like
> me, then I am all for it... :-) Basically, the bottom line is:
> whatever suits your taste will be fine with me as long as it is simple
> to understand and *implement*.

The pragma issue is trivial, but, as you may have noticed, once an issue of the
syntax is on the table, heated debates can rage for hours :-)

The issue about the wrong examples has one trivial resolution (fix the
examples) and one non-trivial resolution (change the spec).
Since you have spotted the discrepancy and since it is out of the cage now,
it may be proper to let the group to decide.

michael


> -----Original Message-----
> From: Michael Kifer [mailto:kifer@cs.sunysb.edu]
> Sent: Thu 9/25/2008 5:45 AM
> To: Hassan Ait-Kaci
> Cc: public-rif-wg@w3.org
> Subject: Re: [BLD] PS specs  amendments
>  
> 
> 
> On Wed, 24 Sep 2008 17:44:43 -0700
> "Hassan Ait-Kaci" <hak@ilog.com> wrote:
> 
> > Michael Kifer wrote:
> > 
> > > On Wed, 24 Sep 2008 05:47:25 -0700
> > > "Hassan Ait-Kaci" <hak@ilog.com> wrote:
> > > 
> > > > Hello,
> > > >
> > > > In the light of the recent discussions regarding parsing the
> > > > RIF BLD into RIF XML, I would like to submit the following
> > > > to this WG to decide.
> > > >
> > > > I propose to change the current RIF BLD EBNF to:
> > > 
> > > Hassan,
> > > 
> > > #1 and #4 clash with the assumptions underlying PS&DTB.
> > 
> > Michael,
> > 
> > In several mails preceding the one in which I listed these 4 points,
> > I pointed out in some details some of the problems caused by not having
> > them.
> > 
> > Re: #1, allowing IRI's to appear unquoted (note that the <...>
> > notation poses no problem, while something it is something like:
> > 
> >    Prefix ( foo http:/bar.baz/fuz# )
> > 
> > does), for example, the ':' in the IRI is not the ':' of a CURIE. How
> > does a tokenizer know that ? All I am proposing is to change the
> > notation to:
> > 
> >    Prefix ( foo "http:/bar.baz/fuz#" )
> > 
> > so that the problem disappears.
> 
> Here we are arguing about the details, not substance. I just pointed out that
> "..." don't look good here because "http:/bar.baz/fuz#" is supposed to be
> an xsd:string according to the DTB syntax. This is why I mentioned <...>
> as a better alternative. (Also, see below before rushing to respond to that
> one.)
> 
> > Re: #4, in a recent email, I pointed out to Harold that the current
> > EBNF rules are inconsistent as they stand with his using CURIE's as
> > argument names (see
> > http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0146.html).
> > 
> > So, unless I am missing something that you will explain to me, it is
> > not that "#4 clash with the assumptions underlying PS&DTB" but rather
> > that the assumptions underlying PS&DTB EBNF's are inconsistent!
> 
> Nope. The example is simply wrong (the book(cpt:author->?Author
> cpt:title->bks:LeRif) part).
> 
> > > #3 is already in DTB, and I do not quite understand what you mean by #2.
> > 
> > #3 is indeed in the current spec, but not for named arguments Name's
> > that do not derive CURIE's although all the examples Harod uses employ
> > CURIE's for names of arguments.  Again, this is referring to recently
> > exchanged email on the RIF list (e.g.,
> > http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0154.html).
> 
> Yes, and this is a mistake. (See the end of the msg about the possible ways
> out.)
> 
> > Perhaps I have missed something that will explain to me.  Please go ahead.
> 
> as above.
> 
> > > Re #1, double quotes are reserved for the abridged syntax for strings in
> > > DTB. The abridged syntax for IRIs is <...>.
> > 
> > Look at the examples. BTW, it is not true that "the abridged syntax
> > for IRIs is <...>." The notation <foo> stands for "foo"^^rif:iri.  The
> > use of IRI's in the EBNF is only limited to Prefix and Base grammar
> > productions. As they appear there in the PS, there is not quoting
> > and it is explained to "Recall that an IRI has the form of an
> > internationalized resource identifier as defined by [RFC-3987]."
> 
> Right. What IRI is in Prefix and Base is up to us. We made it into a sequence
> of unicode chars that form an IRI, but it could well be and IRICONST. There are
> no objective criteria to decide, so we chose one of them (recall that we were
> barred from making PS into a concrete language, and we were forced to
> include statements to that effect in various places).
> 
> The problem is that "..." is a ^^xsd:string. So, if we want delimiters then it
> should be something else. For example, '...'. Or we could make it into an
> IRICONST.
> 
> > Again, what am I missing? Please explain.
> > 
> > > I do not understand what you are trying to achieve with #4.
> > 
> > What about: make the BLD examples consistent with the specs?
> 
> As I said, the example was wrong.
> 
> > > As far as I can see, it is not easy to reconcile this with PS, and I do not
> > > understand why do you need this particular change.
> > 
> > From what I can read and understand from the documents available today,
> > I beg to differ. But I concede that I may not have understsood everything.
> > Again, whatever I am missing, I would be happy to understand.
> 
> The EBNF is consistent with the normative English spec for PS.
> The examples have a problem. The easiest way out is to fix the examples.
> Alternatively, we could generalize the spec. But in that case the solution is
> not what you have proposed but rather get rid of the simplifying assumption
> that the argument names come from a separate set ArgNames and instead use
> arbitrary constants there.
> 
> I don't know whether it is ok to do such a generalization after the last call,
> and I am not sure that this generalization is a good one either.
> 
> > Thanks for explaining.
> 
> Thanks for spotting the mistakes in the examples :-)
> 
> michael
> 
>  
> > >         --michael 
> > 
> > -hak
> > 
> > > 
> > > > 1. allow IRI's only within double quotes;
> > > >
> > > > 2. do not perform expansion of relative IRI's;
> > > >
> > > > 3. allow CURIE's everywhere as specified in the EBNF today
> > > >    as CONSTSHORT's;
> > > >
> > > > 4. allow Name's to derive CURIE's.
> > > >
> > > > With the above simple amendments, I am confident that I can
> > > > specify a workable tokenizer and Jacc grammar for a new
> > > > version of my BLD->XML tool.
> > > >
> > > > In order to speed things up a bit, it would be nice if the
> > > > above issues could be settled soon, so that I can proceed
> > > > with the new release.  I will be travelling starting
> > > > tomorrow and will spend the whole month of October working
> > > > in ILOG France.  I will not attend this F2F in NYC - not
> > > > even remotely (in fact I will be in planes most of its
> > > > duration). I will attend the F2F debrief planned for next
> > > > Tuesday's telecon.  Only after then will I have time to
> > > > start implementing the above amendments.
> > > >
> > > > Have a fun F2F in NY, NY (my kinda town!)...
> > > >
> > > > Cheers,
> > > >
> > > > -hak
> > > > --
> > > > Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
> > > > http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
> > 
> > 
> > -hak
> > --
> > Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
> > http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
> > 
>

Received on Thursday, 25 September 2008 05:19:30 UTC