[Versa] Issue 3

[Chimezie Ogbuji]

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


On 8/12/05, Michael Olson <Mike.Olson at fourthought.com> wrote:
> >> I guess I should have finished my thought.  Because of the above, then
> >> it makes sense to have some syntactic sweetness (as long as it is not
> >> molasses) for the first to cases (like we have).
> >>
> >> Maybe the answer is
> >>
> >> "statement(traversal expression)" and let the engine work this out....
> >>
> >> That would certainly let us stay at 1.0
> >
> > So it would then be
> >
> > object(statement(traversal expression)) etc.  ?
> >
> 
> 
> I misspoke here a little  I think traverse and filter would remain the
> same.  statement() would become a magic function as you pointed out
> below that can reconstruct the statement.  More likely the
> optimizer/query engine would flag the traverse/filter to return the
> entire statement.
> 
> Maybe the simpliest solution for 1.0 compliance is to modify the
> traverse and filter function calls.  An optional parameter that
> specifies result types.
> 
> 
> Mike
> 
> > We could sneak around on this if we were desperate to keep it at 1.0,
> > but I think it would be improper because it does change the semantics
> > of
> > a traversal expression.  Right now A -> B -> C returns a list of
> > objects, and if statement() has usual function call semantics, I don't
> > know how it can reconstruct full statements from just each object.  If
> > statement is more magic than a function, then we have changed the
> > semantics of the <identifier> '(' <expr> ... ')' production.
> >
> > I think that technically either case still calls for a 2.0.  Or at
> > least
> > a 1.5 ;-)
> >
> >
> > --
> > 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
> 
> _______________________________________________
> Versa mailing list
> Versa at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/versa
> 
>