[Versa] Issue 3

[Michael Olson]

>
> A - B -> * was syntactically attractive when it represented a traversal
> of a path from one end to another.  It loses its attraction to me if we
> change it to return statements so that you have to wrap it in  
> subject(),
> object(), etc.
>

I agree.  Currently, I'm leaning towards keeping the traversal/filter  
syntax and result types as is.  I think then we can add a function
statements(filter_expression,filter_expression,filter_expression)

or maybe statements(filter_expression)

That returns a list of statements.  After all, getting the statement  
results is used a lot less.....

We can still support subject(),predicate(),object() on a set of  
statements.  Even extensions scope(), etc.

> It also pushed Versa more from a pathy language to an aggregate-type
> language such as SPARQL.  I would like to maintain separate syntax for
> path traversals versus statement pattern aggregations.  I think they  
> are
> conceptually very different.
>

Agreed

> I worry that this entire discussion is taking us a big step backwards  
> to
> 4RDF "complete".
>

I don't know if that is horrible, as long as we keep what we have.  I  
think the current traversals and filters are great.  I also think the  
flexibility of a function like complete is powerful (and thus does not  
require us to come up with a syntax for every possible permutation of  
the result sets).  Maybe we rename the "statements" function I talk  
about above to be "complete"?

>>>
>>
>> I've actually come full circle on this.   At one time I was in the
>> avoid triples camp.  It turns out, for me atleast, that "little bit of
>> extra time in the query" is greatly overshadowed by the cost of
>> supporting interfaces for all of the different results types.  Besides
>> "statement" results, two that I've found that fo greatly improve
>> performance are the idea of a "count" results (ie, number of  
>> statements
>> that match these criteria) and a "contains" results ie (boolean of is
>> there at least one statement that matches).  Performance wise, the  
>> last
>> being much more important that the first.  I do a lot of
>> "isInstance(resource,type)" type method calls where my only concern is
>> there is one statement that matches.
>
> My experience is the opposite.  Moving from triples-oriented to
> path-oriented, I've found that I'm a lot more productive, my queries  
> are
> easier to compose and follow, and that it's easier to see where
> optimization goes.  So even though pathy queries might be slower the
> first time I write them, it's a lot easier to touch things up so that  
> my
> use case is optimized (as well as similar, future use cases).
>

I agree for large queries.  My use cases have been more from the realm  
of implementing say OWL DL.

"give me all of the sub properties of this property"

This being a simple example of a query that works will in complete and  
versa.

However, what I also need to ask is "give me all of the statements on  
this node".  This works very well in a complete type of method, but not  
in versa.

So....why not both?

either as "complete()" or "{}"

Mike


> But there is also a sociological dimension.  One of the reasons I think
> that Versa can hold its own as an alternative to SPARQL is that it
> offers a fundamentally different approach to query (path traversal
> versus tabular aggregates).  I think that if we head back towards the
> triple centric, one begins to wonder, "why not just use SPARQL?"
>

I agree.  And I think we need to _not_ lose the path expressions.

>
> --  
> 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
>
------------------------------------------------------------------------ 
-----------------
Mike Olson                                                Principal  
Consultant
mike.olson at fourthought.com                +1 720 253 4662
Fourthought, Inc.                                       
http://Fourthought.com
PO Box 270590,                                       http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management