[Versa] Issue 3

[Uche Ogbuji]

On Fri, 2005-08-12 at 09:03 -0600, Michael Olson wrote:
> >>
> >> 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????
> >
> > So, 1 and 2 we have already.  3 would require promoting statements to
> > first class Versa datatypes (which I think would have benefits - but
> > how would statement data types work with the other data types for
> > conversion to and from, etc..).  4 would just be an extension of the
> > traversal syntax and would solve the original problem.
> >
> 
> What if statement datatypes were the results of a traversal?  Then  
> different functions to convert to the different pieces of the  
> statements.
> 
> subject(* - rdf:type -> rdf:Property)   would be the set of all  
> resources in the system that are properties.

I thought of this, but I'm vexed by the question of whether those
subexpressions should all be match lists, or whether object should still
be a functional predicate.  You take the former approach in your
example.

Either way, again, it's a backward incompatible change, and calls for
2.0.


> > I think if you promote statements to first class objects then you also
> > expose statementUri's and Scopes/Context to Versa.  Currently I can
> > only expose (or filter by) scopes with the explicit use of a scope
> > function, however if you model statements as first class objects with
> > the following properties:
> >
> 
> Just wanted to add that context/scope are 4RDF'isms so they should be  
> extension functions to versa.

Well, most engines out there support some context/scope/named-subgraph
capability, so they're far more than just 4RDFisms.  The idea is also
there in shadow form in SPQRQL (in the form of named subgraphs).

Despite that, I agree that they should be extensions, just to help keep
Versa core simpler.


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