- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 27 Aug 2004 15:47:58 +0100
- To: Alberto Reggiori <alberto@asemantics.com>
- Cc: public-rdf-dawg@w3.org
-------- 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