[Versa] Versa issue: subgraph primitives?

[Uche Ogbuji]

On Sun, 2005-08-28 at 23:22 -0600, Michael Olson wrote:
> On Aug 13, 2005, at 8:22 AM, Chimezie Ogbuji wrote:

> >> Traversal expressions would return a subgraph rather than a list of
> >> statements (or scalars right now).
> >
> > So all() |- dc:title -> contains('Article') would return a subgraph
> > containing all dc:title statements containing 'Article'?  Then you
> > could do:
> >
> > scoped-subgraph('type(xsd:string)','all() |- dc:title ->  
> > contains('Article')')
> >
> > to get all such titles?
> >
> 
> Hey, I just didn't read far enough
> 
> Maybe, a query should be expanded to be
> 
> query := context?  expression
> context = '{' sub-graph expression '}'
> 
> and if context is not specified, then it is the entire model.

I think we need to generalize this considerably.  

I've given myself a while to think about the interlocking bits of
context, subexpressions, subgraphs, functions, etc.  For this particular
case, I think it's a matter of allowing general context definition as
part of a query.

Here's an idea that I've thought out in the mechanics, but am still
considering in substance:

* A query comprises zero or more definitions followed by one expression

A definition is one of the following:

1) A namespace declaration, e.g.

xmlns dc: http://purl.org/dc/elements/1.1/;

2) A variable assignment, e.g.

docs = all() |- dc:title -> *;

3) A function defn, e.g.:

tagmatch(doc, tag): contains($doc - dc:subject -> *, $tag)  ;

4) A subgraph definition:

subgraph: join(statements($docs, *, *), statements($authors, *, *));

I'm especially not set on the syntax of (1) or (4).

Definitions are read from left to right (they always end with a
semicolon).  The query starts with the context provided by the host
system, and each definition can modify this context.  This means that we
now have side effects with respect to context, but since there are no
flow of control constructs, I don't think this presents much of an
issue.  One very useful result would be that we now have a host variable
binding mechanism: the host system can read variables set by the query,
rather than just slicing at the big hairball of results.

The problem is that leaving this sort of thing to the host system, as we
did for Versa ~1.0 simplifies the language greatly, which is a good
thing.  I think that we should consider doing the same for Versa 2.0,
but if so, I think that all (1) through (4) of the above should be
treated this way.

In other words, I don't think we should have subgraph definitions unless
we also have variable , namespace, etc. definitions.  I see them all as
context-setting operations.

But maybe it's worth defining a small, nonnormative host language,
either in text or in XML, that allows for context-setting operations.


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