Re: RDQL functionality vs. DAWG requirements

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

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 Tuesday, 1 June 2004 14:09:37 UTC