RE: Syntax modifications

-------- Original Message --------
> From: Alberto Reggiori <>
> Date: 27 August 2004 09:52
> 
> see some short comments below...
> 
> On Mon, 9 Aug 2004, Seaborne, Andy wrote:
> > 
> > Proposal (this is a loose description for comment, not a formal
> > definition): 
> > 
> > 1/ Graph "patterns" are grouped by {}
> 
> ok clear - we need grouping now - any reason why we could not use () to
> group triple/graph patterns as well?
> 
> > 2/ A pattern is a list (set) of elements, interpretted as a
> > conjunction of elements.
> > 
> > 3/ Elements are:
> >    + patterns
> >    + triples, no parenthesises, with trailing dot to
> >      terminate/separate (Not allowing N3 style ; and , for the
> > moment). 
> 
> I would not be a big fun of this N3 like syntax...can you explain why we
> need a trailing dot to close the triple-patterns instead of using
> simpler 
> nested () again ?

First: now is probably a good time to have discussion syntax.  It isn't
something to rush.  

Second: I have no strong feeling on the specifics of the syntax I wrote
about.  My query system is insulated from the grammar and I anticipate the
WG will make decisions that invalidate current designs.  Something has to be
decided for lists and containers.  reification is another possible construct
to provide syntactic support for.


There are a number of reasons behind the proposal: none of these is a single
reason to go one way of another.

1/ We do need some kind of grouping because disjunction is a requirement.
It also makes nested optionals possible but we haven't decided on those yet.
The proposal isn't finished or fixed; at least it can capture the test cases
we will need.

2/ We may relax the WHERE/AND split, so expressions can appear where it is
most natural for them to appear in the query pattern  Something has to be
done as constraints apply to a graph pattern group, not the whole query,
when we have grouping.  It has been pointed out that constraints and triples
and no different aside from syntactic form.  A WG decision which I await.

Constraint expressions also use () for their usual mathematical use so ()
brackets are overloaded.  They can be the start of constraint expression or
a graph pattern.  This can be of arbitrary depth if () is both graph pattern
and expression - no amount of lookahead will help).

A form based on "( pattern ) AND constraints" would work if the WG decides
to keep them separate.  

3/ The usage of triples written in () is not found else where.  It is yet
another way to write graphs (with variables).  Writing out all the triples
can be a bit tedious and N3 (rather Turtle+vars) allows ";" and "," to be
more concise.  Makes no difference to query execution if the syntactic sugar
is just flattened into triple patterns.

This has the advantage that the query has at least a similar form to one of
the data representations.  (RDF/XML is not a natural option for templating
here as far as I can see because of the need to write variables into the
XML.)

4/ The WG has a duty to not make alignment with rules difficult for no good
reason.  Yet-another-pattern language is just a nuisance.  Maybe we can get
sufficiently close, at least in part of the query language, to help
application writer, maybe we can't.  That suggests not using [] for
optionals BTW.

5/ "Simpler" is a value judgement - you aren't a lisp programmer are you
:-)?  The counter argument is that multiple use of the same symbol is
confusing.


The actual parser grammar differences between {braces} and (parens) are very
small.  Its of the order to 10 lines of code in a hand written parser where
can be factored out anyway, and maybe 5 lines for my javacc grammar file.
The investment in the testcase suite would be significantly more.


Re: USING:  having USING at the end is at odds with RDF serializations where
namespace prefixes are declared first.   It also requires a two-pass paring
process (second pass somewhere to fix up qnames into URIs).

> in general - very good work - but I am wondering if this new syntax
> might 
> be confusing, especially to programmers familiar with SQL syntax rather
> than N3/Turtle...

True.  SQL is an important community to consider.

Thanks for the comments,

	Andy



> 
> I expect the parser could always be able to distinguish whether or not
> is 
> a triple-pattern, graph-patterns or a combination of the two - or not?
> 
> > 
> + Constraints, relaxing the
> separation between >      triple pattern and constrinats but retaining
> >      the familiar mathematical syntax.
> >      Leaves open whether
> 
> yes - it makes sense
> 
> >    + optional sub patterns
> > 
> > 4/ Graph patterns can be combined with OR (and AND)
> > 
> > Other:
> > 
> > 5/ Prefixes don't have to be defined last, but can occur before use.
> >     The only reason for making them first is because it is nice to
> >     have SELECT/CONSTRUCT/DESCRIBE/ASK first
> 
> again - I would not be a big fun of this N3 like syntax (also FOR
> keyword 
> has been dropped it seems) - the USING clause in RDQL/BRQL as it is
> today 
> is pretty clear already I think...
> 
> > 
> > Examples:
> > 
> > SELECT * WHERE { ?x ?y ?z }
> > SELECT * WHERE { ?x ?y ?z . }
> >    Trailing . is optional
> >    WHERE is actually unnecessary for a grammar.
> > 
> > SELECT ?name ?mbox
> > PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> > WHERE  { ?x  foaf:name  ?name .
> >          ?x  foaf:mbox  ?mbox }
> 
> or
> 
> SELECT ?name ?mbox
> WHERE
> 	( ( ?x foaf:name ?name) ( ?x foaf:mbox ?mbox) )
> USING foaf FOR <http://xmlns.com/foaf/0.1/>
> 
> > 
> > Could use [] for optional:
> > SELECT ?name ?mbox ?shoe
> > PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> > WHERE  { ?x foaf:name  ?name .
> >          [ ?x  foaf:mbox  ?mbox .
> >            ?x  foaf:shoeSize  ?shoe ]
> >        }
> 
> or
> 
> SELECT ?name ?mbox ?shoe
> WHERE  ( (?x foaf:name  ?name )
>          [ (?x  foaf:mbox  ?mbox )
>            (?x  foaf:shoeSize  ?shoe) ]
>        )
> USING foaf FOR <http://xmlns.com/foaf/0.1/>
> 
> in general - very good work - but I am wondering if this new syntax
> might 
> be confusing, especially to programmers familiar with SQL syntax rather
> than N3/Turtle...
> 
> cheers
> 
> Alberto

Received on Friday, 27 August 2004 14:48:59 UTC