W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2009

Re: Presentation Syntax

From: Axel Polleres <axel.polleres@deri.org>
Date: Thu, 12 Mar 2009 18:38:56 +0000
Message-ID: <49B956C0.2080801@deri.org>
To: kifer@cs.sunysb.edu
CC: Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
Michael Kifer wrote:
> 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).

 From my personal experiences in Tutorials on RDF, SPARQL and RIF, this 
observation indeed holds for the current PS which is incompatible with 
existing SW languages.

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

As already mentioned, there is no need to waste any time: We can just 
   { Basic Graph Pattern in Turtle Syntax }
synonymously for a conjunction of frames in PS and we are done.

All the specs for that are there and widely used and accepted.


> 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

Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Thursday, 12 March 2009 18:39:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:54 UTC