Re: {} in BRQL? [Fwd: Re: Syntax modifications]

As a cwm/N3 user I very much like the idea of using
URIs and triples. So instead of SELECT I would prefer
<http://www.w3.org/2004/ql#select> or q:select
and the query as a set of triples such as e.g.

[] q:select {?S :employeeId "1234". ?S ?P ?O};
   q:where {?S :employeeId "1234". ?S ?P ?O}.
[] q:select {?S :employeeId "1234". ?O ?Q ?R};
   q:where {?S :employeeId "1234". ?S ?P ?O. ?O ?Q ?R}. 

-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/




Dan Connolly <connolly@w3.org>
Sent by: public-cwm-talk-request@w3.org
10/08/2004 17:47

 
        To:     public-cwm-talk@w3.org
        cc:     "Eric Prud'hommeaux" <eric@w3.org>
        Subject:        {} in BRQL? [Fwd: Re: Syntax modifications]


The BRQL editors are playing with {} in a way that's a
little like N3 but a little different.

I've just started to think thru it. I'm interested to
know what cwm/N3 users think.

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/


Return-Path: <public-rdf-dawg-request@w3.org>
X-Original-To: connolly@homer.w3.org
Delivered-To: connolly@homer.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by 
homer.w3.org    (Postfix) with ESMTP id 474014F17C; Tue, 10 Aug 2004 
10:16:22 -0400 (EDT)
Received: from frink.w3.org ([128.30.52.16] ident=Debian-exim) by 
dr-nick.w3.org with esmtp (Exim 4.32) id 1BuXQM-0004Yd-2h; Tue, 10 Aug 
2004    10:16:22 -0400
Received: from lists by frink.w3.org with local (Exim 4.34) id 
1BuXQI-0001Uz-5G; Tue, 10 Aug 2004 14:16:18 +0000
Received: from dr-nick.w3.org ([18.29.1.73]) by frink.w3.org with esmtp 
(Exim 4.34) id 1BuXQH-0001UE-B7 for public-rdf-dawg@listhub.w3.org; Tue, 
10      Aug 2004 14:16:17 +0000
Received: from homer.w3.org ([18.29.0.30]) by dr-nick.w3.org with esmtp 
(Exim 4.32) id 1BuXQH-0004X6-5l for public-rdf-dawg@w3.org; Tue, 10 Aug 
2004 10:16:17 -0400
Received: by homer.w3.org (Postfix, from userid 12817) id 1F8074F0BE; Tue, 
10 Aug 2004 10:16:17 -0400 (EDT)
Date: Tue, 10 Aug 2004 10:16:17 -0400
From: Eric Prud'hommeaux <eric@w3.org>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: public-rdf-dawg@w3.org
Message-ID: <20040810141617.GA18056@w3.org>
References: 
<E864E95CB35C1C46B72FEA0626A2E80803985245@0-mail-br1.hpl.hp.com>
Mime-Version: 1.0
In-Reply-To: 
<E864E95CB35C1C46B72FEA0626A2E80803985245@0-mail-br1.hpl.hp.com>
User-Agent: Mutt/1.5.6+20040722i
x-original-to: public-rdf-dawg
Subject: Re: Syntax modifications
X-Archived-At: http://www.w3.org/mid/20040810141617.GA18056@w3.org
Resent-From: public-rdf-dawg@w3.org
X-Mailing-List: <public-rdf-dawg@w3.org> archive/latest/1310
X-Loop: public-rdf-dawg@w3.org
Sender: public-rdf-dawg-request@w3.org
Resent-Sender: public-rdf-dawg-request@w3.org
Precedence: list
List-Id: <public-rdf-dawg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe:       <mailto:public-rdf-dawg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1BuXQI-0001Uz-5G@frink.w3.org>
Resent-Date: Tue, 10 Aug 2004 14:16:18 +0000
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on homer.w3.org
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=4.5 tests=AWL,BAYES_00 autolearn=ham 
        version=2.63
Status: O
X-UID: 38744
Content-Length: 5671
X-Keywords:
Content-Type: multipart/signed; micalg=pgp-sha1; 
protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline

I had no problems implementing [1] this new grammar.
I prefer this grammar. More on this later. I just wanted
to give folks a chance to play with it if they wanted.

On Mon, Aug 09, 2004 at 04:31:31PM +0100, Seaborne, Andy wrote:
>
>
> We do not have to pin it down yet but concrete syntax matters in 
expressing
> testcases.  It is helpful to have a syntax that can express the range of
> testcases and then evolves as the draft evolves.
>
> In the initial strawman, there was no graph nesting : graph patterns 
resided
> in clause level only so there was only a restricted form of pattern
> combination.  The requirements on the language (particularly
> 3.13/Disjunction but also 3.6/Optional Match ifnested optionals are 
allowed)
> suggests two or more graph patterns can be combined. Enforcing only top
> level disjunction is a burden on the application writer.  Similarly,
> optional nested matches would need syntax for graph patterns and ways to
> combine such patterns.
>
>
> Proposal (this is a loose description for comment, not a formal 
definition):
>
> 1/ Graph "patterns" are grouped by {}
>
> 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).
>    + Constraints, relaxing the separation between
>      triple pattern and constrinats but retaining
>      the familiar mathematical syntax.
>      Leaves open whether
>    + 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
>
> 6/ Constraints: mix with triple patterns, with or without outer ().
>
> I have mocked it up in javacc and have parsed the examples below.  The
> amount of change in the parser is fairly small because the tokenizer 
didn't
> change - it was just a matter of writing grammar rules.  The impact on 
the
> prototype execution engine will be wider, mainly due to the "OR".  (What 
I'm
> not clear on is the whole (non-syntax) issue of more complex queries and
> mapping to SQL technologies.)
>
> 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 }
>
> SELECT ?name ?mbox
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> WHERE  { ?x foaf:name  ?name .
>          OPTIONAL { ?x  foaf:mbox  ?mbox } }
>
> 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 ]
>        }
>
> Depending on what the outermost grammar production is (element vs 
pattern),
> we require outer {} or not for things like OR:
>
> // Outer rule is "element"
> SELECT * WHERE { ?x :p ?z } OR { ?x :q ?z }
>
> // But this is a bit confusing
> SELECT * WHERE { ?x :p ?z . { ?a :a ?x } OR { ?a :a ?x } }
>
> // Outer rulke is "pattern"
> {} at all times
> SELECT * WHERE { { ?x :p ?z } OR { ?x :q ?z } }
>
> SELECT * WHERE { ?x :p ?z .
>                  { { ?a :a ?x } OR { ?a :a ?x } }
>                }
>
> SELECT * WHERE { ?x :p ?z . ?z < 42 }
> SELECT * WHERE { ?x :p ?z . ?z < 42 . ?a :q ?z }
>
> With javacc, lookahead gloablly 1 (but locally 2 for optional things 
like
> trailing dots and allowing commas in various places), I found this 
works.
>
> We could mandate outer () on expressions:
>
> SELECT * WHERE { ?x :p ?z . (?z < 42) }
>
> Personally, I prefer leaving layout to the application writer, ie. don't
> mandate outer ().
>
> It is possible to write strange queries like "OR {}", "WHERE OPTIONAL 
{}"
> but I suggest we keep a fully general grammar for now and leave aside
> whether to ban any non-queries in the grammar until have a full set of
> semantics for the query language.  We can then decide on grammar
> enhancements to make things clearer.
>
>      Andy
>

[1] http://www.w3.org/1999/02/26-modules/dist/Federate-1.tar.gz
--
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
Shonan Fujisawa Campus, Keio University,
5322 Endo, Fujisawa, Kanagawa 252-8520
JAPAN
+1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.