[Versa] More on literal queries

[Michael Olson]

On Sep 6, 2005, at 7:19 AM, Chimezie Ogbuji wrote:

> Okay, I have a suggestion regarding the need to query for a resource
> by name and a literal by value.  This came from an exchange Uche and I
> had on IRC.  If we leave the current Versa data model as is, we have
> URI references (not 'resources' as we currently call them, which is
> misleading)  - which may or may not refer to rdf resources  in the
> underlying model - and literal values which only exist in the query
> space and may not have any corresponding literal value in the
> underlying model.
>
> There is a need to query or match resources by URI and match literals
> by value w/out having to resort to convoluted queries such as:
>
> filter(all(),type(rdfs:Literal),eq("3.0"))
> filter(all(),eq('<mailto:foo at yahoo.com>'))
>
> We could define a function that takes a set of Versa data types
> (resource or literal) and 'grounds' them to the underlying model.
>
> For each data type leave it in the set if there is a corresponding RDF
> resource in the graph (by identity operation).  Otherwise, remove it
>
> So:
>
> filter(all(),type(rdfs:Literal),eq("3.0"))
>
> becomes
>
> ground("3.0")    => empty set or set("3.0")  - depending on if there
> is a "3.0" in the graph
>
> filter(all(),eq('<mailto:foo at yahoo.com>'))
>
> becomes
>
> ground(<mailto:foo at yahoo.com>) => empty set or  
> set(<mailto:foo at yahoo.com>)
>
> I'm suggesting the term 'ground' because it is used to describe the
> process of assigning unused URIs to blank nodes in a graph, which is
> (somewhat) similar in some ways to what is being done here, resolving
> a URI reference or literal in the query space to actual
> resources/literals in the underlying graph.
>
> We probably would also need to make sure our definition of eq is clear
> about the semantics of comparing a resource in the underlying model
> with a URI ref.  Do we mention that the model has the right to
> determine how it calculates the identity operation, since this
> apparently may involve more than just a string comparison of the
> URI's?

This is a good solution for me.  Here is what I see ignoring the issue  
of scopes and only highlighting what the changes.

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


What this allows then is we would not need to wrap all of our  
filter-expressions in "eq" if we don't want because

all() - rdf:value -> "foo"

would become a valid query as "foo" becomes a literal-pattern.

Mike


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