Re: iTQL evaluation

On 05/06/2004, at 7:06, Kendall Clark wrote:

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

And naturally, I'm honor-bound to provide some of them.  :)

> [itql-] 3.3 Extensible Value Testing

Extensibility is handled by considering a datatype processor to be a 
named graph.  For example, the limited XML Schema support Kowari 
currently has is represented by a named graph that notionally contains 
an infinite number of statements, including 1 < 2, 1< 3, 1 < 4, 
2003-12-31 is before 2004-01-01, and so forth.  You extend by adding 
new datatype processors, which from the language's point of view are 
just new named graphs.  The predicates appearing in the statements 
within those processors are your extended operations.  There's no 
special syntactic support for extensibility; it just falls out of 
having set operations in the "from" clause and being liberal about the 
kinds of graphs the system is willing to query.

> [itql-] 3.4 Subgraph Results

It's true that there's no specific grammar like SeRQL's "CONSTRUCT" to 
generate subgraphs.  For the commands that modify the content of a 
graph and need this functionality (the "insert" and "delete" commands), 
a "select" command is valid as a source parameter as long as it has 3 
columns that can be interpreted as triples.

> [itql-] 3.6 Optional Match

Optional matching is performed using "subquery()" aggregate functions 
in the "select" clause.

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

Quite true.  There is no way to express an iTQL query as a URI.

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

There actually is an "alias" command in an iTQL session which functions 
similarly to the "USING" and "USING NAMESPACE" clauses in RDQL and 
SerQL respectively.  The difference is that "alias" is a separate 
command from the "select" command and sets the namespace mapping on the 
session, rather than being a clause of the "select" command and being 
scoped for that command only.  The rationale for doing it this way was 
that you could run a startup script to predefine all the well-known 
namespace mappings like "rdf" and "dc", rather than repeatedly 
specifying them.  This does presume the existence of a stateful 
session, though.  An "alias" command looks like this:

alias <http://www.w3.org/1999/02/22-rdf-syntax-ns#> as rdf;

After calling this command on the session, <rdf:type> would be 
equivalent to <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
wherever it appeared in subsequent commands.  What iTQL certainly does 
egregiously is to use the same <> syntax for both URI references and 
qname abbreviations.  Aliasing "http" would cause great confusion, for 
instance.  Both RDQL and SeRQL do it properly, making URI refs and 
qnames lexically distinct.

There actually aren't any built-in qnames; rather, there's just a 
default initialization script that runs a list of "alias" commands to 
predefine half a dozen common namespaces.

The $ prefix for variables is actually based on XPath rather than Perl. 
  Given an arbitrary choice, we figured it should look like other W3C 
standards.  :)

Received on Monday, 7 June 2004 11:40:09 UTC