Re: Presentation Syntax

Michael Kifer wrote:
> 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.

SWC defines them as corresponding [2]:

"This means that whenever a triple s p o is satisfied, the corresponding 
RIF frame formula s'[p' -> o'] is satisfied, and vice versa[...]where 
s', p', and o' are RIF symbols corresponding to the RDF symbols s, p, 
and o, respectively."


> You can have a[b->c d->e] etc.

That is not a problem, in PS I would likewise suggest to allow not only 
frame style but also turtle style abbreviations, cf. [1] i.e.

{ a b c; d e } etc.

> Second, {...} is not a good syntax because it means sets. 

not in RIF. From that point of view, one could equally argue "[...] is 
not a good syntax because it means array or lists". So, again, I don't 
see the problem.

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

I do not see this approved anywhere, as of yet. Alternatively, I suggest 
for that case to use the Turtle style abbreviation [1] using commata for 
separating multiple values, i.e.

   { a b c, d }

or, in  frame style:

   a[b-> c, d]

My preferences is compatibility among W3C promoted languages (RIF, RDF, 
SPARQL). FWIW, I don not necessarily propose to *replace* frames, but to 
  allow Triple/Turtle style syntax alternatively at lease for the sake 
of this aimed compatibility. Would that be acceptable for you?
  The SW community is becoming very used to this kind of syntax and a 
compatible PS would certainly be appreciated from that side.

BTW, I would actually not expect too many people wanting to mix Turtle 
style and frame style syntax in the same PS document...


best,
Axel

1. http://www.w3.org/TeamSubmission/turtle/#sec-tutorial, Section 2.3.
2. http://www.w3.org/2005/rules/wiki/SWC#RDF_Compatibility, Section 3
> 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 16:44:52 UTC