[Versa] More on literal queries

[Michael Olson]

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

Just to be clear, your not talking about a "context" as shown in the  
above EBNF correct?  In the EBNF, context is the ".".  I've been trying  
to talk about the "scope" of an expression which I think is what you  
mean.


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

Something like that.  I was thinking it would look just like the  
filter/traverse functions (take three arguments) and instead of  
returning a set of subject, or set of objects, would return the entire  
statement.  So we have (with functions) the ability to get a set of  
subject, a set of objects and a set of statements.  Then, the following  
expression would be equivalent

subject(statements(all(),*,*))  == filter(all(),*,*)
object(statements(all(),*,*,*)) == traverse(all(),*,*)



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

Yes, though it is also true for filter (as the only different between  
traverse and filter are what is returned)

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

We talked about it, but then I think you lose the idea of "traverse"

I still think it is convenient to do

all() - ns:spouse -> * - ns:name -> *

for traversal so I don't think we want to lose that.

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

I think through out.  There will not be a lot of built in conversion

resource(statements(all(),*,*)) would be empty I think (unless we want  
to support reification (sorry Uche :)

Mike

> _______________________________________________
> Versa mailing list
> Versa at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/versa
>
------------------------------------------------------------------------ 
-----------------
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