Yes, I thought of the approach Holger is suggesting and also thought of the fact that FILTER may be slow. I probably should have been more descriptive in the response.
Just like it is for SQL, there are different ways of doing things with SPARQL. And, depending on the model/data and the way query gets formulated as part of the program, an approach may make more sense in one situation and less in another situation. For example, if the items in the OR statement are determined dynamically (let's say a user enters the search values), then the enumeration cannot be created ahead of the query time. This means that before SELECT runs, one would need to create the enumeration members. In these situations Holger's solution can still work quite easily as SPARQLMotion offers an easy way to pipeline operations together. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Holger Knublauch Sent: Monday, June 08, 2009 8:16 PM To: [email protected] Subject: [tbc-users] Re: Logical Operators I am sure you meant FILTER (?label = "forestry" || ?label = "drilling" || ?label = "oceans") . However filtering is typically very slow. But there is yet another approach: put the enumeration into the RDF graph itself and then iterate over all expected strings. In your example, add something like my:Group my:member "forestry" . my:Group my:member "drilling" . my:Group my:member "oceans" . as triples to your model, and then query all values using SELECT ... WHERE { ... my:Group my:member ?label . ?ApplicationUri rdfs:label ?label . ... } This has the advantage that the performance will be good, and also the relevant knowledge is encoded in the model as opposed to the query. For example, multiple queries can this way reuse the same group of values. Holger On Jun 8, 2009, at 5:08 PM, Irene Polikoff wrote: > > I think you could also do FILTER, something like > > SELECT * WHERE{?ApplicationUri a owl:Class. > ?ApplicationUri rdfs:label ?label. > FILTER (?label = "forestry"|| "drilling"|| "oceans") . > ?subClass rdfs:subClassOf* ?ApplicationUri.} > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Scott > Henninger > Sent: Monday, June 08, 2009 7:49 PM > To: TopBraid Composer Users > Subject: [tbc-users] Re: Logical Operators > > > Steve; Although it's not a strict "OR" operator, UNION will work in > this case: > > SELECT * > WHERE { > { ?ApplicationUri rdfs:label "forestry" > } > UNION > { ?ApplicationUri rdfs:label "drilling" > } > UNION > { ?ApplicationUri rdfs:label "oceans" > } > } > > This gets the union of the three graph patterns, binding ? > ApplicationUri to the subject of the resulting graph. > > -- Scott > > On Jun 8, 5:52 pm, dalguy72 <[email protected]> wrote: >> I want to be able to be able to specify two (or possibly a list of >> possibilities) as criteria in my sparql query. If I sql, I would >> use >> the "OR" operator or I would use an "IN" statement. Is there an >> equivalent with sparql. >> >> The simplest example that I come up with is that I want to get the >> URI's for the items with the following labels: "forestry", >> "drilling", >> and "oceans". >> >> To get one of them, I would do something like: >> >> SELECT * WHERE{ >> ?ApplicationUri rdfs:label "forestry" >> >> } >> >> To get all of them in one return set is the goal I am after, and then >> I can place it within a more complex query, such as, in just a >> slightly more complex call, return all the subclassess that use the >> same application uri >> >> SELECT * WHERE{ >> ?ApplicationUri rdfs:label "forestry" . >> ?subClass rdfs:subClassOf* ?ApplicationUri >> >> } >> >> Steve > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
