Steve; Indeed, the key to understanding what UNION does is making the
transition from relational queries to graph queries. The query is a
graph pattern and the result is a graph (that we SELECT variable
bindings from). Assuming ?ApplicationUri matches class definitions, a
result graph might look like the following:
<ClassA> rdfs:label "forestry"
<ClassB> rdfs:label "drilling"
<ClassC> rdfs:label "oceans"
(Note the graph is specified by triples.) You can get this result in
a number of way, as Irene, Holger and I pointed out. Now that you
have this graph pattern, you can begin to specify other patterns you
want to match. For example, if you want the subclasses of the class
defs above, then use your rdfs:subclassOf* (or rdfs:subclassOf+)
query:
SELECT *
WHERE {
?ApplicationUri a owl:Class.
{ ?ApplicationUri rdfs:label "forestry"
}
UNION
{ ?ApplicationUri rdfs:label "drilling"
}
UNION
{ ?ApplicationUri rdfs:label "oceans"
}
?subClass rdfs:subClassOf* ?ApplicationUri.
}
Note I also included the spec that all the classes are of type
owl:Class. This is of course optional, but points out that the UNION
query specifies a set of graph patterns that are concatenated to form
multiple possible graph matches. That sub-graph can then be combined
with other graph patterns.
BTW, a caution on FILTER is that performance will suffer if there are
a lot of class definitions. I.e. the filter approach will need to get
all class defs with a label, then filter the matches specified.
-- Scott
On Jun 9, 8:22 am, dalguy72 <[email protected]> wrote:
> Since I am going to need to do this programatically and generate the
> sparql query on the fly, it looks like I need to go towards Irene's
> suggestion, since the selection of one or more criteria will be done
> by a end user on a form. I do not think that Holger's suggestion
> would be a good one for a dynamically built grouping, and building the
> multiple combination of possibilities of even three items generate 7
> unique combinations (and I have many more than 3 items in my
> possibilities list). It is a very interesting way to deal with it,
> and does help me think of other ways of approaching the problem.
>
> I am unsure about the UNION operator Scott suggests, since I can see
> how it applies for the single subject case and would be generate the
> URIs I needed, but I do not know if or what the syntax would look like
> for the additional properties. Would it be something like:
> SELECT *
> WHERE {
> { ?ApplicationUri rdfs:label "forestry" .
> ?subClass rdfs:subClassOf* ?ApplicationUri
> }
> UNION
> { ?ApplicationUri rdfs:label "drilling" .
> ?subClass rdfs:subClassOf* ?ApplicationUri
> }
> UNION
> { ?ApplicationUri rdfs:label "oceans" .
> ?subClass rdfs:subClassOf* ?ApplicationUri
> }
>
> }
>
> I appreciate the help from each of you on this, since as I am learning
> sparql. I sometimes still frame it in SQL terms that I am familiar
> with, and changing that mindset is sometimes hard. Thank you for your
> help.
>
> 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
-~----------~----~----~----~------~----~------~--~---
