iTQL evaluation

Peeps,

No one asked for this; but iTQL[1] hasn't been mentioned here before
(or much, anyway), so I thought I'd take a look at it. But I've only
used it briefly; I welcome comments, clarifiations, amplifications.

Best,
Kendall Clark

[1] http://www.kowari.org/

An Evaluation of Kowari's iTQL 
------------------------------

[itql+] iTQL supports the requirement or design objective
[itql-] iTQL does not support the requirement or design objective
[itql?] iTQL's support is unclear or underterminable by me

(Here I'm collapsing the server, its protocols for data access, and
the query language per se into the single term "iTQL", which is,
speaking precisely, the query language only.)

In general, iTQL looks like this:

select <columns> from <models> where <constraints> order by
<variables> limit <count> offset <count>;

Query Exemplar (optionally formatted for legibility):

select 
     $title $link $description 
from 
     <rmi://192.168.1.100/server1#sampledata>
where 
      $article <http://purl.org/rss/1.0/title> $title  
and 
      $article <http://purl.org/rss/1.0/link> $link 
and 
      $article <http://purl.org/rss/1.0/description> $description;

Requirements
------------

[itql+] 3.1 RDF Graph Pattern Matching
where 
      $article <http://purl.org/rss/1.0/title> $title  
      ...;

[itql+] 3.2 Variable Binding Results
select
      $title $link $description

[itql-] 3.3 Extensible Value Testing 

[itql-] 3.4 Subgraph Results

[itql+] 3.5 Local Queries 
  URIs in the from clause can be of the type file:// and the Kowari
  driver is decoupled from the various means -- RMI, SOAP, Beans -- of
  remote access.

[itql-] 3.6 Optional Match

[itql+] 3.7 Limited Datatype Support
  Supports < and > on doubles; 'before' and 'after' for xsd:date &
  xsd:dateTime typed literals.

[itql-] 3.8 Bookmarkable Queries
  I've seen no method for expressing an iTQL query as a URI.

[itql+?] 3.9 Bandwidth-effificent Protocol
  Depends on whether you think RMI is efficient. But see next item.

[itql+] 3.10 Result Limits

  "order by" specifies a sort order of the results as one or more
  variables. Not a protocol feature, per se, but could be construed as
  making results easier to handle in bandwidth-constrained use cases,
  I suppose.

  "limit" takes a positive integer that represents the maximum number
  of solutions in the query result. Recommends use of order by with
  limit, but both are optional.

  "offset" takes a positive integer that represents "the number of
  leading rows to skp at the beginning of the query result"; also
  recommended to be used with order by.

[itql-] 4.1 Human-friendly Syntax
  IMO, of course. Warts:
      
      - lower case keywords are hard to read
      - unclear how to shorten URIs, if possible at all
      - seem to be some builtin qnames which use visually-busy <> delimiters
      - "$" variable prefix is more Perlish than the more common "?" prefix.
      - visual looseness of the where clause bits very hard to read, though 
      	optional parens help a bit here

[itql-] 4.2 Provenance

[itql-] 4.3 Non-existent Triples 

[itql+] 4.4 Aggregate Query
  In spades. Tutorial worth quoting at length --

     Because models are sets of statements, it's meaningful to compose
     them using set operations. The FROM clause permits set union
     using the or operator and set intersection using the and
     operator, with parentheses used to control association. For
     example:

     ... from <rmi://site.domain.net/server1#model1> and
     <rmi://site.domain.net/server1#model2> and
     <rmi://site.domain.net/server1#model3>

     would query only statements appearing in all three
     models. Distributed queries are expressed by composing models
     from different servers, for example:

     ... from <rmi://site.domain.net/server1#model1> or
     <rmi://othersite.otherdomain.net/server2#model2> ...

     would query the combined statements of two models at different
     sites. Note that distributed queries require much more network
     traffic than queries to a single server, and are consequently
     slower.

     ... from <rmi://site.domain.net/server1#model1> xor
     <rmi://othersite.otherdomain.net/server2#model2> ...

     in parallel would query two models at different sites forming a
     single result set. Assumes each site is capable of resolving all
     contraints delcared in the WHERE clause.

[itql-] 4.6 Additional Semantic Information

Received on Friday, 4 June 2004 17:07:46 UTC