[Versa] Versa issue: subgraph primitives?

[Chimezie Ogbuji]

> The idea would be to simplify some operations within Versa itself.  I
> think it's such an important need that every time you end up trying to
> do without it you end up deciding you need it after all.
> 
> A good example is XPath/XSLT.  Started with no means within the language
> to define extension functions, and we ended up needing the EXSLT
> functions module, which I've found almost indispensable in the end.
> 
> Did you find the example function def above confusing?

Okay

so 

func-def := qname '(' variable ')' ':' query-expression
variable = qname

?
 
> I'm fine with that.  I don't like the proposed { context } query,
> because I think it's a bit of a hacked special case.  

Well, the '{' '}' to me is reminiscent of formulaes in n3:

{ [ x:firstname  "Ora" ] dc:wrote [ dc:title  "Moby Dick" ] } a n3:falsehood .

In which the statements in:
[ x:firstname  "Ora" ] dc:wrote [ dc:title  "Moby Dick" ]

are in a context (subgraph) about which a statement is made, stating
it is a falsehood.  So, { query } is essentially an n3 formulae that
consists of the statements enclosed by the results of the evaluating
the query. And you could query against the same original
deserialization:

{ dc:wrote([ - x:firstname -> eq("Ora") ]) = [ -dc:title->eq("Moby
Dick") ] } . - rdf:type -> *

which returns (n3:falsehood, log:Formula)

So a Versa query is an optional context to use (or the  the default if
left out) and a query expression to evaluate against that context. One
suggestion that comes to mind for me is to be able to isolate contexts
by name (if the underlying model is context-aware: rdflib makes the
distinction between a context aware backend and one that isn't). 
Maybe something like this (this definately is w/out precedent)

('context-name'? '@'? { query })? query-expression

Or if you assume that log:semantics ties a context to a context-name
as associated in the underlying model, you could do:

{ [ |- log:semantics -> eq('ftss:///foo/bar/doc.rdf')] }

Using log:semantics this way wouldn't be far fetched given it's open
ended definition:

"The log:semantics of a document is the formula.
acheived by parsing representation of the document.
 For a document in Notation3, log:semantics is the
log:parsedAsN3 of the log:contents of the document.
For a document in RDF/XML, it is parsed according to the
RDF/XML specification to yeild an RDF formula
(a subclass of N3 log:Formula).

[Aside: Philosophers will be distrated here into worrying about the meaning
of meaning. At least we didn't call this function "meaning"!
In as much as N3 is used as an interlingua for interoperability
for different systems, this for an N3 based system is the meaning 
expressed by a document.]"

I'm probably digressing with this last point, but I think a general
extension (or perhaps just a way of interpreting the name of a
scope/context)  to include the ability to identify a context by name
would complete the requirements needed for effective context-switching
by name.