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

Re: Presentation Syntax

From: Chris Welty <cawelty@gmail.com>
Date: Thu, 12 Mar 2009 23:21:56 -0400
Message-ID: <49B9D154.1000705@gmail.com>
To: kifer@cs.sunysb.edu
CC: Axel Polleres <axel.polleres@deri.org>, public-rif-wg@w3.org, Sandro Hawke <sandro@w3.org>


The presentation syntax is not for "exchanging concrete languages".  The XML 
syntax, which is not in dispute, is for that purpose.  The presentation syntax 
is pretty much only for *humans* who want to write (and read) rules in BLD.

Since you think BLD is useless, you shouldn't care what syntax humans want to 
use to write&read it.  You can use your personal syntax for the dialect that you 
find useful, as long as it is 1-1 translatable to the XML syntax there is no 

In fact, the ability to have multiple presentation syntaxes seems to me to 
precisely *demonstrate* the advantages of RIF.  In some sense, each of these 
syntaxes can be thought of as different languages which have very good 
interchange properties through RIF-XML.

Neither RDF nor OWL have suffered from multiple equivalent syntaxes (though the 
same arguments were made against them at the time), I see no evidence that it 
would bloat or harm adoption of RIF at all.  Quite the opposite.


Michael Kifer wrote:
> Axel,
> pls see my earlier response to Sandro.
> I believe that all these proposals are leading the group astray and causing us
> to loose sight of what RIF is about. To me, RIF is not BLD and not PRD, but a
> framework for dialects. BLD, IMO, is mostly useless. I see the future of RIF in
> dialects that extend BLD. You are proposing to introduce completely useless
> (IMO) bloat into what is supposed to be a framework for exchanging concrete
> languages.
> michael
> On Thu, 12 Mar 2009 18:35:09 +0000
> Axel Polleres <axel.polleres@deri.org> wrote:
>> Michael Kifer wrote:
>>> On Thu, 12 Mar 2009 16:44:10 +0000
>>> Axel Polleres <axel.polleres@deri.org> wrote:
>>>> 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."
>>> I am saying: frames are not triples, but triples are frames.
>> That's ok.
>>>>> 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.
>>> Hmm. You don't expect me to like that, do you?
>> There are many people who do like and regularly use that.
>>>>> 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.
>>> Set notation is fundamental, and there has been demand for that in use case
>>> examples. I didn't introduce that before because originally the
>>> presentation syntax was supposed to be abstract syntax. But now when we are
>>> moving towards a concrete syntax this is on the agenda. Aggregates are
>>> definitely on the agenda even if the set syntax won't make it.
>>>>> 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.
>>> See above.
>>>> 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).
>>> This is doomed to failure and is a waste of time.
>> Well, we are already there: it needs no time at all, if we just accept 
>> Turtle style patterns in { ... } as a notation for conjunctions of 
>> frames. So, no additional time needed, and no time wasted.
>>>> 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?
>>> No. Why duplicate and complicate?
>> It does not complicate anything in my opinion, and it is a reasonable 
>> alternative to frames style syntax with - for a W3C WG in the Semantic 
>> Web activity - a significant community behind.
>>>>   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...
>>> Don't forget that RIF is an exchange syntax despite all the talk about the
>>> presentation syntax. If you want to use turtle syntax then use Turtle syntax
>>> and translate it to (XML) RIF.
>> Just to clarify: Turtle is not a rules language, but it can model the 
>> part covering conjunctions of frames/triples.
>> best,
>> Axel
>>> cheers
>>> michael
>>>> 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. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
Received on Friday, 13 March 2009 03:22:52 UTC

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