[Versa] More on literal queries

[Michael Olson]

Does the this mean the following query

"some string value"

should only return a result if there exists a literal in the form of:

"some string value"
or
"some string value"@some_language
or
"some string value"^^xsd:string

??

same concept for number and boolean literals.


If so, then it leads me to think we need to restructure our EBNF (and  
the spec) some WRT these "queries" because they are not literals.  It  
leads me to

expression ::= all of the current stuff except literal
                            | resource-query

resource-query :== node-query
                                   | boolean-query
                                   | string-query
                                   | number-query
                                   | literal-query

Where

node-query ::== ('@' '"' URI '"') | ('<' URI '>') | qname

and returns a set that has 0 or 1 members based on wether the node  
exists

boolean-query :== 'TRUE' | 'FALSE'

and is syntactic sugar for the query "true"^^xsd:boolean or  
"false"^^xsd:boolean

string query :==   ' [^']* '  | " [^"]* | """ .* """

and returns a set with 0 or more literals that match (there could be  
the same string in multiple languages, or datatypes)
#NOTE: I'm thinking of adding the triple quoted strings as a way to add  
big strings without having to embed \n and \"

number-query :== NUMBER

and is syntactic sugar for "NUMBER" ^^xsd:int or "NUMBER"^^xsd:float  
depending on if the number has a decimal

literal-query :== (string-query '@' language') | (string-query '^^'  
resource-query)

and returns a set of 0 or 1 literals that match.



I like how this feels, so for

all() - rdf:type -> <http://foo.com>

A parser would expand this to

[all resource in model] - [resource rdf:type if it exists] -> [resource  
http://foo.com if it exists]

Then, in python, your filter becomes something of

for st in statement:
   if st.subject in expanded_subjects and
      st.predicate in expanded_predicates and
      st.object in expanded_objects:
   res.append(st.subject)

I like how it brings together the concept of "filter-expression" and  
"set-expression" we currently have.

thoughts?

Mike


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