Re: Presentation Syntax

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

Axel

> 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, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Thursday, 12 March 2009 18:39:38 UTC