Re: Presentation Syntax

Sounds good.

I just want to emphasize that my fundamental problem is not with this or that
particular syntax but with unnecessary bloat. Regardless of whether I like or
dislike a particular piece of bloat, the problem is that any new redundant
syntax prejudices future extensions for which that syntax might turn out to be
the most natural choice. We should remember that RIF is not BLD or PRD, but an
extensible framework for exchanging various rule languages through dialects.
It is this extensibility that is prejudiced by the bloat.

michael


On Fri, 13 Mar 2009 01:12:20 -0400
Sandro Hawke <sandro@w3.org> wrote:

> 
> Wow, do I not want us arguing about presentation syntaxes.  :-(
> 
> What I'm picturing now is having one "RIF Presentaiton Syntax" (RPS),
> which is a superset of the current BLD Presentation Syntax, where
> everything added is either needed for PRD or is trivial syntactic sugar
> (like infix operators and simple datatype literals).
> 
> The process I imagine is this.  I'll add anything that:
>   (1) I can implement relatively easily
>   (2) someone wants
>   (3) no one objects to.
> 
> If anyone objects, that's it.  No more discussion in meetings.  You can
> take it off-line with them if you really want, and if you change their
> mind, fine.   But you're encouraged to just let it drop.
> 
> I also picture folks forking RPS.  I hear Michael objecting to Turtle
> syntax, so fine, it stays out.  But that doesn't stop someone from
> creating RPS-T or whatever.  And if there's an implemented translator to
> XML, they can use if for test cases (which is something we already
> decided).  On the other hand (and this is important), it doesn't need a
> formal spec, and it wont actually be mentioned in any of our documents
> -- just used in the test case repository, and maybe the on-line demo.
> 
> Good enough?   Can we do this, and stop arguing about the PS?
> 
> (When I have a next version implemented, I'll document exactly how it
> differs from what's in BLD, for people to potentially object to, and
> potentially add to.   Until then, let's stop talking about the PS.)
> 
>       -- Sandro
>  
> > On Thu, 12 Mar 2009 23:21:56 -0400
> > Chris Welty <cawelty@gmail.com> wrote:
> > 
> > > 
> > > Michael,
> > > 
> > > The presentation syntax is not for "exchanging concrete languages".  The XM
> > L 
> > > syntax, which is not in dispute, is for that purpose.  The presentation syn
> > tax 
> > > is pretty much only for *humans* who want to write (and read) rules in BLD.
> > 
> > It is for the **semantics** and therefore is normative.
> > We also use it for examples etc., for which it is more than adequate.
> > 
> > > Since you think BLD is useless, you shouldn't care what syntax humans want 
> > to 
> > > use to write&read it.
> > 
> > BLD is useless because it is inexpressive (where it matters). But it is part 
> > of
> > the future dialects that I care about. 
> > 
> > >  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 n
> > o 
> > > problem.
> > > 
> > > In fact, the ability to have multiple presentation syntaxes seems to me to 
> > > precisely *demonstrate* the advantages of RIF.  In some sense, each of thes
> > e 
> > > syntaxes can be thought of as different languages which have very good 
> > > interchange properties through RIF-XML.
> > 
> > We are not in the business of defining multiple new languages. RIF was suppos
> > ed
> > to be an exchange format among existing languages. If somebody wants to defin
> > e
> > their own language for whatever use, they can do that and exchange it through
> > RIF. But there is no place for such a language within RIF itself.
> > 
> > > 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.
> > 
> > I don't care if you write 20 new papers on 10 different alternative syntaxes 
> > in
> > the next 5 years. I care about the normative syntax that is used to define th
> > e
> > semantics, especially the semantics of the framework.
> > 
> > michael
> > 
> > 
> > > -Chris
> > > 
> > > Michael Kifer wrote:
> > > > Axel,
> > > > pls see my earlier response to Sandro.
> > > > I believe that all these proposals are leading the group astray and causi
> > ng us
> > > > to loose sight of what RIF is about. To me, RIF is not BLD and not PRD, b
> > ut 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 usele
> > ss
> > > > (IMO) bloat into what is supposed to be a framework for exchanging concre
> > te
> > > > 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 triple
> > s.
> > > >>>> SWC defines them as corresponding [2]:
> > > >>>>
> > > >>>> "This means that whenever a triple s p o is satisfied, the correspondi
> > ng 
> > > >>>> 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 onl
> > y 
> > > >>>> 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 f
> > or 
> > > >>>> 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 s
> > yntax
> > > >>> 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 th
> > e
> > > >>>>>>> other solution to the infix-operators problem, namely to pay attent
> > ion
> > > >>>>>>> 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 (w
> > here
> > > >>>>>>> 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 th
> > e
> > > >>>>>>> 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, bu
> > t you
> > > >>>>>>> can also leave them out.  This means my parser should be able to ha
> > ndle
> > > >>>>>>> all the existing examples and test cases... a pretty big win, reall
> > y.
> > > >>>>>>> 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-sensitivi
> > ty 
> > > >>>>>> already anyways, for the '-' operator vs. dashes within IRIs. So, I 
> > > >>>>>> think that additional space-sensitivity would be totally acceptable.
> > > >>>>>>
> > > >>>>>> Axel
> > > >>>>>>
> > > >>>>>>
> > > >>
> > > > 
> > > > 
> > > 
>

Received on Friday, 13 March 2009 19:49:18 UTC