Re: Presentation Syntax

I think the origin of this thread was your proposal to use triples {a b c}
instead of frames. This is unacceptable because frames are not triples.
You can have a[b->c d->e] etc.
Second, {...} is not a good syntax because it means sets. This is what I was
planning to use for aggregates (I proposed this several months ago in an email)
and for shorthands like  a[b->c b->d] == a[b-> {c d}]

michael

On Thu, 12 Mar 2009 09:23:12 +0000
Axel Polleres <axel.polleres@deri.org> wrote:

> Sandro Hawke wrote:
> > Talking after the call today, Axel made a good case for adopting the
> > other solution to the infix-operators problem, namely to pay attention
> > to whether there is a space between the "f" and the "(" in "f(x)".  So
> > "f (x)" is two terms, and "f(x)" is one term.  This is my own
> > preference, and what I implemented before the task force telecon (where
> > I got talked out of it).  One of Axel's considerations is alignment with
> > SPARQL and other RDF-related languages, in user training materials.  If
> > we go with this kind of space-sensitivity, then we can have both the
> > F-Logic and N3 styles available for expressing triples, so you can write
> > your exampes in either one.  And you can use commas if you want, but you
> > can also leave them out.  This means my parser should be able to handle
> > all the existing examples and test cases... a pretty big win, really.
> > The one thing people can't do is write "f (x)" when they mean "f(x)".
> > 
> >      -- Sandro
> 
> In that context, note that in the proposed PS we hav space-sensitivity 
> already anyways, for the '-' operator vs. dashes within IRIs. So, I 
> think that additional space-sensitivity would be totally acceptable.
> 
> Axel
> 
>