[Versa] Issue 3

[Uche Ogbuji]

On Sun, 2005-08-14 at 22:49 -0600, Michael Olson wrote:
> On Aug 13, 2005, at 7:29 AM, Uche Ogbuji wrote:

> > As you say in your examples:
> >
> > A - B -> *     becomes  objects({A B *})
> > all() |- B -> eq('foo')  becomes  objects({* B 'foo'})
> 
> I wonder what we need to change so much syntactically?
> 
> Why can't  "all() - B -> we("'foo') return statements.  Then use  
> "object(expression)" or "subject (expression)" to filter the results.

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.

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.

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


> As far is "SPF"s.  Isn't "all()" equivalent to "*" already?

No.  The difference between the two is exactly what Chime and I are
expressing in our discussion of lists versus predicates.


> we already  
> support #2 which is literals and scalars. We support #4 for objects  
> now, it would just be a matter of supporting them for subjects and  
> predicates.  I think #3 is a great addition as well.
> 
> 
> qname("foo",union("a",b")) - map(properties(<rdfs:class>),{. -  
> rdfs:subPropertyOf *}), gt("1"^^"xsd:int")

Hmm.  That takes me a lot of squinting to decipher.


> So, using many new ideas
> 
> "Give me, all _statements_ where the subject us the URI from the  
> expanded prefix "foo" and the local name of "a" or "b".  The predicate  
> is one of the subProperties of any property that is used on the  
> resource "rdfs:Class" and the object is the integer value greater then  
> one.

I guess we can mark this as a use case.  I'd like to see if we can find
a more elegantly compositional way to express it.


> > I wonder whether this is taking us back to the limited triple-based API
> > that we'd been hoping to get away from in creating Versa.  I'd have to
> > think through some more complex examples to decide for myself.
> >
> 
> 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).

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?"


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