[Versa] Issue 3

[Uche Ogbuji]

On Sat, 2005-08-13 at 00:41 -0400, Chimezie Ogbuji wrote:
> Along the lines of promoting subjects to first class Versa datatypes
> (and the problem of such a major change), I had the idea that perhaps
> you could maintain the current infrastructure but have a way to
> extract / project statements as a set of 3 item lists
> (subject,predicate,object) and have 3 functions for extracting the
> parts of the lists:
> 
> subjects(x)  =>  map(x,'.[1]')
> predicate(x)  =>  map(x,'.[2]')
> objects(x)  =>  map(x,'.[3]')
> 
> Consider a 'Statement Pattern' expression (different from a traversal
> operator) that allows you to extract statements (as a set of 3 item
> lists):
> 
> {SPF SPF SPF} => set(list(s1,p1,o1),list(s2,p2,o2),list(s3,p3,o3),...)
> 
> where SPF (statement pattern filter) is either an expression which is
> converted to a list which serves as a filter against the corresponding
> components (subject/predicate/object) of candidate statements. 
> Statements are included only if the corresponding part is a member of
> the list.  SPF can also be '*' in which case it is a wildcard and no
> filtering is done for those components.
> 
> So:
> A - B -> *     becomes  objects({A B *})
> all() |- B -> eq('foo')  becomes  objects({* B 'foo'})
> 
> Such patterns can do everything traversal operators do now in addition
> to address the original *issue* of returning predicates.  My use of {
> .. } clashes with my earlier suggestion to use them as existential
> placeholders, but I'm quickly running out of grouping characters that
> are not used :)
> 
> This is just an idea to allow statements to be visible to the Versa
> data core w/out breaking it's current infrastructure but perhaps
> Uche's example use o filter to retrieve the properties on a resource
> with a particular value solves the original problem and this isn't so
> neccessary.
> 
> Just some food for thought

I do think that for Versa 2.0 we should make statements first class.
Your syntax suggestion is similar to what I was trying to get at
earlier, but I think you solved my semantic problem for me with {SPF SPF
SPF}.  Each SPF would be resolved into a pattern as follows:

* If the SPF is *, it is resolved into a pattern that matches anything
* If the SPF is a primitive scalar, datatyped literal or resource, it is
resolved into a pattern that must match that string or resource exactly
* If the SPF is a list or set, it is resolved into a pattern that must
match one of the items in the list or set exactly
* If the SPF is a function, f, then it is a special filtering function
pattern, and the pattern is equivalent to the resulting list from
filter(<all possible values>, f).  (This means that the function must
take each item to be filtered as its first parameter)

As you say in your examples:

A - B -> *     becomes  objects({A B *})
all() |- B -> eq('foo')  becomes  objects({* B 'foo'})

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.


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