Re: Presentation Syntax

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. 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:35:50 UTC