RE: RDQL functionality vs. DAWG requirements

-------- Original Message --------
> From: Alberto Reggiori <>
> Date: 1 June 2004 19:10
> 
> On Jun 1, 2004, at 4:23 PM, Eric Prud'hommeaux wrote:
> > 
> > rdql- : 3.3 Extensible Value Testing
> >   Has support for equality and comparison operators for integers.
> 
> yes - and I would like to point out (Andy correct me if I am wrong
> here) that current RDQL spec [1] does not allow arbitrary "function
> calls" on purpose (due they were breaking interoperability) - while an
> earlier version of the BNF did [2] I.e. the BNF re-addition would be
> cheap :)

True - at the time qnames had to be quoted so bare names were function
calls.  The grammar should allow "ex:fn(?x)" still if you don't mind the
lookahead to find the "(" to determine what's going on.  Else, use an
indicator char for functions like & "&ex:fn(?x)" which makes it very easy to
know the parser choice.  Or lisp syntax.

The N3/cwm way would be predicates that evaluate the subject to give the
object.  That is, pushing the work to the RDF graph or havign the QL know
certain predicates.  Jos's example of the "find all the places with 50miles
of somewhere" did this.  I would say that it was not human-friendly syntax
though.

	Andy
> 
> At the moment (in our code) we still do not use any built in extension
> function - but we are planning to add "default" ones for some internal
> development (xsd:date operators and some GEO related ones). I.e. we do
> support 3.3 requirement (and 3.7 then?)
> 
> Anybody else here experimenting on RDQL++ extensions via function calls?
> 
> > 
> > rdql- : 3.4 Subgraph Results
> > 
> > rdql+ : 3.5 Local Queries
> >   The specification does not describe the result format or mechanism,
> >   however, an API implementation of this protocol would be able to
> >   perform local queries.
> 
> we do support generic RDQL syntax like
> 
> SELECT
> 	?foo
> FROM
> 	<URI>
> WHERE
> 	(?foo ......)
> 
> where <URI> can be:
> 
> 	--> empty (in-memory DB) implicit parse/connect done via
> DBI->connect() API call
> 	--> local file (RDF/XML or N-Triples) e.g.
> file:///Users/foo/myfiles/myrdf.rdf (parsing and in-memory ingestion
> on-the fly)
> 	--> remote URL via HTTP GET e.g. http://xmlhack.com/rss10.php (same
> HTTP GET + RDF/XML parsing + in-memory store)
> 	--> local DB rdfstore://mydb/dir/database (custom protocol)
> 	--> remote DB rdfstore://www.foo.com:1234/myremote/dir/database/name
> (custom protocol)
> 
> and will soon allow URIs like
> 'jdbc:postgresql://www.foo.com:5555/lat-long' - which might as well use
> a customized protocol - not sure what 'Local Queries' would mean though
> in our case...
> 
> > rdql- : 3.6 Optional Match
> 
> we mimic that via boolean OR operator on each part of a triple-pattern
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0317.html
> 
> > 
> > rdql- : 3.8 Bookmarkable Queries
> >   RDQL does not spcify a canonicalization into a local part of a URI.
> 
> right
> 
> what would a 'bookmarkable query' look like in RDQL syntax? Joseki
> URL-encoded like or more like a XPath/Xpointer single bounded var?
> 
> again - it seems query language and protocol requirements overlapping a
> bit here...
> 
> > Design Objectives:
> > 
> > rdql+ : 4.1 Human-friendly Syntax
> >   RDQL queries read like a sentence. They allow the use of
> >   qnames. Term-enclosing parens could be replaced by a single
> >   delimiter ala N3, but I it is, in my opinion, easy on the eyes.
> 
> yes - in our experience RDQL syntax is very familiar to users and they
> pick it up quickly
> 
> > 
> > rdql- : 4.2 Provenance
> 
> (see other email reply to Steve)
> 
> > rdql- : 4.4 User-specifiable Serialization
> >   RDQL does not specify results format/protocol nor provide syntax to
> >   select such.
> 
> yes - but at the API level you can always choose how to return/stream
> results generally (DBI->fetch_row(), RDF/XML result sets, N-Triples and
> so on)
> 
> > 
> > rdql- : 4.6 Aggregate Query
> 
> we allow "simple" (and blind) graph merging by allowing multiple URIs
> on the FROM clause part
> 
> select
> 	?bar
> from
> 	URL1.rdf
> 	URL2.rdf
> where
> 	(?bar....)
> 
> where the query is being run on the merged graph of the "union" of the
> RDF triples obtained from URL1 and URL2 (perhaps keeping track of
> provenance info too)
> 
> Yours
> 
> Alberto
> 
> [1] http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/
> [2] http://www.hpl.hp.com/semweb/rdql.htm#prod38

Received on Wednesday, 2 June 2004 09:12:31 UTC