[Versa] Issue 3

Uche Ogbuji uche.ogbuji at fourthought.com
Fri Aug 12 08:04:47 MDT 2005


On Fri, 2005-08-12 at 00:54 -0600, Michael Olson wrote:
> Currently, in a traverse operation you can get back either the subject  
> or object of the statement.  I would like to propose the ability to get  
> the entire statement as I need to make queries like

Yeah, adding a statement type (not "triple", though, to allow for
implementations with scope/context) was on my list for Versa 2.0.  I do
think this would be too big a change for 1.0, though.  We really would
need to think through all the semantics in the language to do it
rightly, IMO.


> some_node - all() -> eq(.'foo')
> 
> to find out all of the properties on a node that have the value foo.   
> 
> Executing this on the following graph:
> 
> some_node --> p1 --> foo
> some_node --> p2 --> foo
> 
> would tell me there are two foos, but I need to know the bigger  
> picture.  Now, I could do this with map() and properties() (I think)  
> but it seems wasteful.
> 
> Maybe a slight modification to the query like
> 
> some_node -* all() -> eq(.'foo')
> 
> Which kind of leads to:
> 
> expression - expression -> filter     --> results in object
> expression -| expression -> filter   --> results in subject
> expression -* expression -> filter    ---> results in statement
> expression -& expression -> filter    ---> results in predicate????
> 
> (and the same for backwards)
> 
> maybe one for statement URI?
> 
> This means that statement would need to be added as a data type.  with  
> conversion and a set of functions......

I think this also dovetails into a 2.0 discussion, because I think
that's a lot of syntax to add to 1.0.  Actually, I think it's a lot of
syntax to add, period, and would make the language a lot more complex.
I'd prefer to change the semantics of traversals to allow this without
too much added syntax (and maybe even unify traversal and filter syntax
a bit).  I already think that Chime's point about slow learning is
remembering:

A) ... - ... -> ... = forward traversal
B) ... <- ... - ... = backward traversal
C) ... |- ... -> ... = forward filter
D) ... |<- ... - ... = backward filter (?)

I think the fwd vs backward traversal syntax distinction is probably
palatable, but throw in the filter variations and it goes over the top.
I think your suggested further additions would make this worse.

My thinking, if we have statements might go along the lines of Python's
list comprehensions.  Caution: very flammable straw man :-) :

[ object(s) for s in { all(), dc:title, "Versa" } ]

Alternatively, we could go back to the explorations of XPath's axis
notation.  I remember shying away from that way back when we first
cooked up Versa, but maybe it's worth another look.

Regardless of specific approach, I agree with you in principle, but I
don't think we can squeeze it into Versa 1.0 very well.


-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html
Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/
Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html




More information about the Versa mailing list