Re: notes from Presentation Syntax task force meeting

Good progress. Sorry I could not attend the telecon.
But I do have a number of comments, below.
michael

On Fri, 20 Feb 2009 13:21:42 -0500
Sandro Hawke <sandro@w3.org> wrote:

> 
> IRC log: http://www.w3.org/2009/02/20-rif-irc
> Present: Harold, Chris, Sandro
> Agenda:  http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0113
> 
> (Here's what I think we agreed.  Chris and Harold, correct as desired.)
> 
> Conclusions on presentation syntax issues:
> 
>    -- We agreed that "pd" in the metadata of example 4 of BLD was an
>       error and should be "_pd" or "pd"^^<rif:local>
> 
>       At some point we might allow a declaration ("local(pd)") which
>       would allow one to use "pd" like that.
> 
>    -- We agreed to add separators to the syntax, making it more like
>       other languages with infix operators, so that:
>           Group(p(a b (c+d) e(c+d) f (c+d)) q(a))
>       would instead be written something like:
>           Group(p(a, b, c+d, e(c+d), f, c+d); q(a))
> 
>       This will alas require transforming all existing test cases and
>       examples; Sandro will investigate automating that transforming,
>       or simply saying those are written in a different PS.
> 
>       (I'm not really happy about this, but have no better idea.)
> 
>    -- We agreed that CURIES and bare IRIs which do not contain
>       delimiters (but do contain operators) could be allowed.  As a
>       consequence, infix operators like "-" and "+" will have to be
>       surrounded by whitespace.
>            f(my:max-width - 12)  has a subtraction
>            f(my:max-width-12)    has no subtraction
>            f(4-12)           is disallowed, to keep people using spaces
> 
>       (I'm not really happy about this, but have no better idea.)
>            
>    -- String literals can have escapes (like \") as in turtle
>       http://www.w3.org/TeamSubmission/turtle/#sec-strings
>       (except the \>, which isn't needed since in RIF you can always
>       use rif:iri instead of <foo:bar>)
> 
>    -- We'll allow C++ syntax comments as a shortcut
>       for (* _some_new_term[rdfs:comment->"...stuff..." *)
>       if Sandro can come up with a decent way to parse & attach them
>       (Actually we said comments starting with "#", but in typing this
>       I realized that conflicts with InstanceOf)
> 
>       Actually does it need to be 
>         (* _some_new_term _some_new_term[rdfs:comment->"...stuff..." *)
>       ?  I can't tell from the spec.

I don't really understand how you are planning to do that without requiring
some kind of structure in those C++ comments.

> 
>    -- Regarding literals like 123.456, we'll require a suffix to tell us
>       which datatype to use:
>           123.456d ==> "123.456"^^<xs:decimal>  
>           123.456e ==> "123.456"^^<xs:double>   (as in Java/C)
>           123.456f ==> "123.456"^^<xs:float>    (as in Java/C)
>       (123.456e+02 and 123.456f+02 are double and float, as usual)
> 
>    -- We'll allow formulas as terms in the general grammar
>       eg:   p(1, 2, (p(1) :- q(2)), 3)
>       since some dialects might use them

This is allowed in FLD, yes. The formula is treated as being reified.


>    -- Responding to Chris's strong dislike of "->" as very confusing in
>       a logic language, we finally settled on "::" to replace it in NAU
>       and frames.
>       eg:    p(b :: 1, bb :: f[my:color :: your:red])

I can't imagine anything uglier than this particular choice.

 
> Conclusions on other issues:
> 
>    -- It would be nice to anonymous frames.  In PS, the syntax could be
>       _[attr->value]    (or  _[attr :: value])

There is more to anonymous frames than that. What is needed is a general syntax
for skolem functions/constants. The anonymous frame is just a special case of
that. In FLORA-2, there are two kinds of symbols for Skolem symbols: _# and
_#<number> (ie, _#1, _#2, etc.). This allows skolems to be cross-referenced
within the same formula (eg., when you skolemize an existential var, which
occurs in several places in the same formula).

>    -- It would be nice to have nested frames, and more generally frames
>       in terms.  Can we please add them back?  They're just syntactic
>       sugar (unless you have anonymous frames).

In FLD, a nested formula is not syntactic sugar. It is a reified formula.
To distinguish syntactic sugar from reification, some syntax is needed.
For instance, a[b->{c[d->e]}].

Received on Sunday, 22 February 2009 03:18:03 UTC