Jeff; It may be helpful to note that LET binds a variable and nothing more. So in the first two examples below, nothing is returned because the graph pattern does not match anything in your graph. The third one does match (i.e. " ?user :firstName ?value" matches graph data). The LET statement just binds a value to ?user and has no impact on the graph match.
-- Scott On May 28, 10:06 am, "Schmitz, Jeffrey A" <[email protected]> wrote: > "The function returns no binding and therefore ?user is unbound and will > be > iterating over all possible subjects of the firstName triples." > > Hmmm, not what I was expecting. I guess I would have expected it to act > more like normal SPARQL variable chaining occurrs, e.g. in the following > query: > > SELECT ?user ?value > WHERE {?user a :NonExistantClass . > ?user :firstName ?value} > > ?user is "unbound" after the first line (NonExistantClass doesn't really > exist), and this query returns no results instead of everything in the > model with a firstName property. Even if you reverse the order: > > SELECT ?user ?value > WHERE {?user :firstName ?value . > ?user a :NonExistantClass . > } > > You still get no results. But change it to something like: > > SELECT ?user ?value > WHERE {(LET ?user := :filterOnClass(:NonExistantClass) > ?user :firstName ?value} > > And you do get everything in the model with a firstName property. > > Be that as it may, using subqueries I think I'm able to get the behavior > I'm looking for. A little verbose, but if I understand things, I think > you'd have to do this anytime you wanted to use a re-usable SPIN > filtering function: > > SELECT ?user ?value > { > {SELECT ?user > WHERE { > LET(?user := ModelManagement:getProjectUser("DEFAULT_PROJECT", > "xxx")) > } > } > {SELECT ?user ?value > WHERE { > ?user ModelManagement:firstName ?value > } > } > > } > > In the above query, if the user specified in the LET (xxx) doesn't > exist, nothing is returned. > > > -----Original Message----- > > From: Holger Knublauch [mailto:[email protected]] > > Sent: Wednesday, May 27, 2009 9:38 PM > > To: [email protected] > > Subject: [tbc-users] Re: [SPIN] Using FILTER with function arguments > > > On May 27, 2009, at 12:21 PM, Schmitz, Jeffrey A wrote: > > > > It's getting curiousor and curiousor... > > > > Using the TBC SPARQL tab, when I call a function that filters > > > according to an argument, e.g.: > > > > SELECT ?user > > > WHERE { > > > ?project ModelManagement:hasUser ?user . > > > ?user Common:name ?username . > > > FILTER (?username = ?arg1) . > > > } > > > If the function returns no binding then it will be comparable > > to a wildcard in the query below. > > > > As long as I pass in an argument that has a match: > > > > SELECT ?value > > > WHERE {LET(?user := ModelManagement:getProjectUser("john")) > > > ?user ModelManagement:firstName ?value} > > > > the function returns just one result as expected (in this case for > > > some > > > reason the blank result rows aren't returned). However, if I pass > > > in a > > > value that has NO matches: > > > > SELECT ?value > > > WHERE {LET(?user := ModelManagement:getProjectUser("xxx")) > > > ?user ModelManagement:firstName ?value} > > > > It acts like the FILTER statement isn't there, and all > > User's names in > > > the model are returned. I would have expected no results to be > > > returned. Btw, I'm seeing this same behavior in my code too. Am I > > > thinking about this wrong, or is there perhaps a problem with how > > > FILTER > > > works within a Function? > > > No, the behavior is correct (as far as I understand your > > example). The > > function returns no binding and therefore ?user is unbound > > and will be > > iterating over all possible subjects of the firstName triples. > > > In your first email, please keep in mind that the execution order of > > ARQ might be different from what you have typed it. In particular, I > > find often that LET statements are executed at the end, and > > therefore > > lead to more iterations than expected. > > > Holger --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
