W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Re: Syntax modifications

From: Alberto Reggiori <alberto@asemantics.com>
Date: Mon, 30 Aug 2004 17:33:07 +0200
Message-Id: <E41A6DDE-FA99-11D8-A917-0003939CA324@asemantics.com>
Cc: public-rdf-dawg@w3.org (RDF Data Access Working Group)
To: Andy Seaborne <andy.seaborne@hp.com>

Andy, thanks for the clarifications - some short replies inline below...

On Aug 27, 2004, at 4:47 PM, Seaborne, Andy wrote:
> 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.

I think it was already clear to me why we need grouping now (and I was 
not arguing/talking whether or not we need it) I simply wonder what 
would be the best syntactic choice from an average programmer/user 
point of view. And I feel it is good to have this syntax discussion now 
and avoid to postpone it - rather we start prototyping the future DAWG 

> 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.

sure it is clear

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

I would vote for this - which is also closer to current RDQL syntax - 
or just replace AND with a better WITH or CONSTRAINTS keyword, to avoid 
to confuse the users with the meaning of that "and"  (due a 
graph-pattern is a bunch of AND-ed triple-patterns)

E.g. " ( pattern ) WITH constraints"

> 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.)

clear - but I find this N3/Lisp like syntax a bit far from simpler 
original SquishQL/RDQLsyntax - which most users still like...

that's also why I always liked the simplicity of rdfdb query language


(see also simple insert syntax)

> 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.

humm rules...ok...I will not speak about this :) I would rather leave 
it for discussion to others DAWG-ers...

> 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.

yes your feeling is right - I never learned Lisp :o)

> 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).

yes it makes sense - but I then do not understand why we need to make 
the syntax so much N3 like, using PREFIX and use :prefix notation 
instead of current RDQL USING prefix FOR <URI>

anyway, yet another syntax discussion :)


Received on Monday, 30 August 2004 15:33:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC