W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Re: possible syntax changes

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 31 May 2005 18:35:13 +0100
Message-ID: <429CA051.2050407@hp.com>
To: Dave Beckett <dave.beckett@bristol.ac.uk>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>



Dave Beckett wrote:
> I had a skim through
> http://www.w3.org/2001/sw/DataAccess/rq23/#grammar
> $Revision: 1.367 $ of $Date: 2005/05/31 08:31:36 $
> 
> 
> and here are some comments
> 
> 1. Query verb tokens
> 
> tokens [5]-[8] SelectQuery...AskQuery have changed structure a lot.
> I'm pretty unlikely to be able to implement them with my current
> approach as this part seems to require a lot of look ahead.

Could you say where?

I parse these constructs with lookahead of one with an LL parser.  FROM/FROM 
NAMED is a point that does need something but it is written the way it is to 
just cover zero or one FROM and zero or more FROM NAMED.

There is no necessity to use exactly the same grammar to get the same language. 
  There are many grammars for one language.

[PS http://compilers.iecc.com/comparch/article/05-04-059]

> 
> 
> 2. Optional WHERE
> 
> WHERE is still optional.  I prefer not, and won't teach it as
> optional, will give syntax warnings when recognising this.  It just
> ends up allowing bizarro queries.
> 
> 
> 3. Optional '.'s
> 
> Too many of these,  I can't recall if I've caught them all.  If it
> makes my grammar have some shift/reduce conflicts or require
> excessive lookahead, I probably won't.

What counts as excessive?  Is it unbounded?

It is, of course, your choice as to what you implement.

> 
> 
> 4. Casting support
> 
> We lost the foo:bar() vs &foo:bar() distinction some grammars back.
> which is syntax for a casting operation and an extension function.
> 
> I think overloading these is a mistake.  The spec defines a set of
> required casting operations named for their datatype like xsd:byte()
> This means you can take any literal and make a datatype of that form,
> with the value that the datatype defines.
> 
> In RDF itself, you can easily make a lexical form for any RDF
> datatyped literal in RDF/XML or other syntax, and you can do that in
> in SPARQL if you only want to talk about a constant datatype:
> "abc"^^dave:type.
> 
> However, if you want to use it in expressions you can't do much
> except use constants.  So whereas:
>   FILTER "abc"^^dave:type = "abc"^^dave:type
> is true by RDF rules, you can't take a variable ?x with the literal
> value "abc" and do:
> 
>   FILTER ?x^^dave:type = "abc"^^dave:type
> 
> however, if dave:type is one of the built-ins, you can:
>   FILTER xsd:integer(?x) = "10"^^xsd:integer
> 
> but you could previously, when we had syntax for it:
>   FILTER dave:type(?x) = "abc"^^abc:type
> 
> which does the *make an rdf datatyped literal* operation but is now
> used solely for functions.
> 
> So, I'd like a new operator CAST
>   CAST(URI u, Unicode string s) returning what would be written as s^^u

Does this include:

CAST(?x, "foobar")

that is, a dynamic cast?  This seems more like a constructor than a cast as the 
value is changed.  This would make compiling to SQL quite hard, I guess.

What about language tags? Do you want

lang("chat", "fr")?

to complete the set?

> 
> 
> 5. Turtle parts of grammar 
> 
> Around tokens [28] to [44] I gave up trying to follow the grammar and
> instead used the Turtle grammar itself and the lex+yacc code I
> already had for that.  

OK - note that Turtle requires whitespace where N3 does not:

N3:: <s><p><o>.
Turtle:: <s> <p> <o>.

also SPARQL went for XML qnames as per the discussion in section 8 not as per 
the gramamr which limits to letters in a-z


[re: @charset: We have had bad experiences with declaring charsets inside a file 
(e.g. it can disagree with the MIME type; it might be opened with a I/O stream 
that already does conversion (usually wrongly!)).]

	Andy

> 
> There were a few minor changes that sparql needs beyond Turtle, such
> as []s for variables in places that Turtle doesn't allow, such as
> for predicates.
> 
> At present Turtle won't be allowing [ :a : b ]. as a triple, only as
> an object or '''long literal''' with single quotes (CWM/N3
> compatibility issues need to be thought about).
> 
> 
> 6. ASC, DESC changes
> 
> Fine.
> 
> 
> 7. XML EBNF used
> 
> Hurrah for this.
> 
> --
> 
> Of course, I've implemented no syntax changes since the last WD so
> this is all by inspection only.
> 
> Dave
> 
Received on Tuesday, 31 May 2005 17:35:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:23 GMT