[Versa] Welcome to the Versa list

[Chimezie Ogbuji]

I also think we should shoot for a 1.0 version. 
 
> I vote for keeping it 1.0 and getting a good polished release out.
> Having been through the spec recently I think it is very close.
> Personally, I have some additional needs for it which we can hash out
> on the list.

I also have some needs / suggestions most of which have come from our
use of Versa here at CCF.  I volunteering to do the specification
editing (any or all of it).  I think as it is, it's sufficient from a
technological stand point but I think the language can be extended to
make it more approachable to 'RDF-query laymen'.  The main complaint I
hear - mostly from SPARQL heads, to be fair - is that the learning
curve is pretty high.  I think that can easily be addressed by
broadening out the language and including more examples (so the spec
by itself can be the end-all reference instead of requiring companion
tutorials/articles).  The suggested test case suite(s) will also help
in that regard.  In my opinion, the learning curve by itself almost
completely hides how much more effective/expressive/comprehensive
Versa is as an RDF query language to the SQL-clones in the mainstream.

> What I plan on doing is, as issues and changes are resolved, building a
> set of conformance test cases, similar to those the W3c uses for RDF
> and OWL.  Then, once he have a home for versa making this all available
> separate from 4Suite.

Some suggestions of my own (see:
http://www.xml.com/pub/a/2005/07/20/versa.html?page=4):

I. Additional functions to the core specification (although I can see
them as extensions to the core functions - but there isn't any
explicitly defined extension mechanism - we could easily burrow from
XPaths):

class([member])

as shorthand for:

[member] - rdf:type -> * 

value([valuedResource])

as shorthand for:

[valuedResource] - rdf:value -> * 

rdf:list([rdfList])

which takes an rdf:List instance (Bag/Sequence/Alt) and converts it to
a *Versa* list (or set).  As a shorthand for traversing
rdf:first,rdf:rest,rdf:li,rdf:_1 properties explicitely.  I'm
suggesting the rdf namespace so it's distinguished from list (which
converts any Versa data type to a Vers a list), but once again (though
I'm not as sure about this as I am about the extension mechanism) the
mechanism for using QNames for function references isn't explicitely
spelled out.

I'm suggesting these because rdf:type,rdf:value, and rdf:Lists have
recently been promoted to core concepts in the RDF model, so it's
useful for an RDF query language to be able to handle them
implicitely.

2.  The use of ^^xsd:dataType (as in "1.0"^^xsd:float) to explicitely
type Versa literals.  But would that require adding the other core xsd
datatypes to the set of Versa Datatypes (or are they all covered by
strings and numbers)?.  I think MIke made the same / similar
suggestion

3.  Using [ .. ] (formerly represented traversal filters, but fell out
of the spec - I think) to represent existenstial placeholders (blank
nodes) - ala.  Notation 3 / Turtle.  As in:

[ - ns:price -> lt("30")] - list(dc:title,ns:price) -> *  

as an alternative to

(all() |- ns:price -> lt("30")) - list(dc:title,ns:price) -> *

Blank nodes are also central to the RDF data model but are only
included as a subset of Versa resources.  I think they should be
promoted to first class objects in a way that allows queries on blank
nodes to be expressed concisely.

4.  (taken from page 4 of the above XML.com article)

"IV. Finally, Python list iteration and indexing operators (such as in
[:3], [1:3], and [:-4]) can be adopted as alternatives to: member,
item, rest, tail, and slice.

Consider the following query that returns the title of the most recent
rss:item in a feed:
sortq(type(rss:item),'. - dc:date-> *')[-1] - rss:title -> * "

Both python and Notation 3's  use of [..] seems very appropriate by
themselves - but they clash unfortunately.  I can't think of a better
alternative.

5.  Boolean syntax ( <.<=,>,<>, or != ) syntax should be adopted as
alternatives to their functional equivalents (lt,lte,gt,neq).

Chimezie