[Versa] More on literal queries

[Chimezie Ogbuji]

> > query-expression :== filter | traverse | funtion-call
> >
> > forward-filter :== set-expression '-' set-expression '->'
> > filter-expression
> > #plus all of the rest of the filters and traverses
> >
> >
> > set-expression :== query-expression | pattern | context |
> > variable-reference
> >
> > filter-expression :== query-expression | pattern | operator-expression
> > | context | variable-reference
> >
> > pattern :== uri-pattern | literal-pattern | wild-card
> >
> > function-call :== qname '(' argument-expression ? ( ','
> > argument-expression) * ')'
> >
> > argument-expression :== query-expression | constant |
> > variable-reference - context | '{' argument-expression '}'
> >
> > context :== '.'
> >
> > wild-card :== '*'
> >
> > constant :== uri-constant | literal-constant | string-constant |
> > number-constant | boolean-constant
> 
> Looks about right, but I do wonder whether the recent discussion over
> scope affects some of this as well.


I'm honestly still unclear about the introduction of a 'context' into
the current data model.  I probably need to digest the above grammar
and think through all scenarios (the concept of RDF contexts in a data
store is complicated by itself without trying to resolve how it
interoperates with other data types in the query space).  But so far
what I do follow:

A context is essentially a set, the difference is that a context is a
set of statements.  Statements would be a newly introduced item in
Versa 2.0.  What I'm not clear about is how statements would be
constructed and how would they be 'handled' (i.e. how are they casted
to the other data types).  Would constructing statements require the
explicit use of a statement function?  Such a function *could* work in
the following way:

statement(subj) => set(stmt1,stmt2,..stmtN)
where stmt1 ... stmtN all have subj as their subject

statement(subj,pred) => set(stmt1,stmt2,..stmtN)
where stmt1 ... stmtN all have subj as their subject and pred as their pred

and so on ...

Where either subj,pred (or obj) is converted to a set.  So multiple
candidates can be submitted for each statement component.

So, 'statement'  would essentially be the functional analog of forward
traversal expressions with the exception that it returns statements.

Or (I don't think anyone is advocating this option) the current
built-in expressions would be modified to return statements instead of
statement parts, but that would require utility functions (which may
be needed anyways) to decompose statements to resources and literals.

If statements are introduced as first class objects do we *only* allow
their use as the context for scoped queries, or do we have to account
for them *throughout* the grammar, and if so what are the semantics in
each scenario?