[Versa] Issue 3

[Uche Ogbuji]

On Fri, 2005-08-12 at 09:34 -0400, Chimezie Ogbuji wrote:
> On 8/12/05, Michael Olson <Mike.Olson at fourthought.com> 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
> > 
> > some_node - all() -> eq(.'foo')
> > 
> > to find out all of the properties on a node that have the value foo.
> 
> Hmm.. For now the best you could do is:
> 
> some_node - properties(some_node) -> eq('foo')
>  
> or
> 
> all() |- properties(.) -> eq('foo')
> 
> but that would only give you the objects where the properties have a
> value of foo (not the properties themselves) in the first case and
> *all* the nodes that have such properties (not the properties
> themselves) in the second.

You can use filter:

filter(properties(some_node), "some_node - . -> eq('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.
> 
> Yeah, it twists my head to think how you would use either filter/map
> in conjunction with properties to do this.  I don't think you can.

Hmm.  It seemed pretty straightforward to me.  Did you find some
conceptual limitation in the description of filter()?


> > 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.
> 
> > maybe one for statement URI?
> 
> 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:
> 
> - subject
> - predicate
> - object
> - statementUri
> - context/scope
> 
> You can kill two birds with one stone.  But what would be the
> semantics of working with statements as objects.  What would be the
> kinds of things you would want to do with statements as a whole (as
> opposed to just their parts)?
> 
> > 
> > This means that statement would need to be added as a data type.  with
> > conversion and a set of functions......

I think this is all good discussion, but again, I think too much for
Versa 1.0.

I think we need to be unconstrained by backwards compatability, and I
think this means 2.0.

Note: I don't think 2.0 has to be a 3 year process.  I think that we can
get it out as quickly as we could get out a 1.0, especially considering
the size of some of the changes suggested for 1.0.


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