Re: Presentation Syntax

> I think the origin of this thread was your proposal to use triples {a b c}
> instead of frames.

The idea (in my head, and in my implementation) was to support both
syntaxes in the PS; they would turn into the same XML.

> This is unacceptable because frames are not triples.
> You can have a[b->c d->e] etc.

As I understand it, the F-logic

    a[b->c d->e]

is equivalent to the Turtle

    {a b c; d e}     

which is short for:

    {a b c. a d e}     

and they would all three have the same XML representiation.
 
> 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 emai
> l)
> and for shorthands like  a[b->c b->d] == a[b-> {c d}]

CSMA raises one point about this in a separate e-mail; setting that side
and talking just about the use of the "{...}" delimiters, ...

Option 1:  {...} as a statement means it's triples/turtle/n3 inside, while
           {...} as a term means a set.

Option 2:  One or the other can use something other than braces

Option 3:  Give up on a single unified RIF Presentation Syntax; let a
           thousand (or at least 3) syntaxes bloom.

*shrug*

     - Sandro


> 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
> > 
> >

Received on Thursday, 12 March 2009 16:56:45 UTC