Re: Presentation Syntax

I think all this talk about multiple presentation syntaxes is getting out of
hand. Multiple presentation syntaxes serve no purpose in an exchange language
like RIF. It is a sure way to make RIF so complicated that nobody will use it
(= killing RIF as a viable idea).

I see no chance that something like that will ever get through the decision
process in this group and propose not to waste time on this in our final f2f
meeting.

michael


On Thu, 12 Mar 2009 12:56:36 -0400
Sandro Hawke <sandro@w3.org> wrote:

> 
> > 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 18:17:43 UTC