RE: Presentation Syntax

May I suggest that PS concentrates on the simpler (?) needs of BLD /
Core rather than PRD? 

FWIW: it seems likely that in any <BRE PR language> --> <RIF PRD>
mapping, the RIF PRD version is going to effectively obfuscate the
original meaning of the production rules; thence a presentation syntax
of the RIF PRD version is only going to be used for / have a use case of
"explaining the mapping" (i.e. not for general reading and writing of PR
rules). 

[IMHO: we will likely need a RIF PRD-OO (i.e. object oriented) that is a
sub-dialect of RIF PRD before we get widespread support from the BRE
vendors; a Presentation Syntax for RIF PRD-OO would probably require at
least a set of extensions for the RIF PS to be truly presentable].

My 2c...
Paul Vincent 
+1 650 206 2493 / mobile +44 781 493 7229 


> -----Original Message-----
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-
> request@w3.org] On Behalf Of Sandro Hawke
> Sent: 13 March 2009 05:12
> To: kifer@cs.sunysb.edu
> Cc: Chris Welty; Axel Polleres; public-rif-wg@w3.org
> Subject: Re: Presentation Syntax
> 
> 
> 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 12:03:18 UTC