How would I go about this, define a magic property which would take the
task and return tools + match counts?
In general, nested selects seem to behave a bit strange when using any sort
of aggregation function. In this case, for instance, the counts are always
off by 1 whenever used in a nested select... E.g. A, 1; B, 2 if executed on
their own and A, 2; B, 3 when run in a nested select...
On Tuesday, 21 January 2014 22:53:56 UTC+1, Holger Knublauch wrote:
>
> Michael,
>
> have you tried using another variable than ?this ?
>
> Also, inner (nested) SELECTs may not use the same variable bindings as the
> outer parts of a query. For this reason I usually replace inner SELECTs
> with SPIN magic properties because then I can better control the
> pre-binding of arguments.
>
> HTH
> Holger
>
>
> On 1/22/2014 0:09, Michael B. wrote:
>
> Hi everyone!
>
> I've got a weird case here. I am trying to use SPIN rules to match tools
> and tasks. Each my:Task has a set of owl:Restriction instances. A set of
> spin rules tries to find tools that fulfil specific requirements. I then
> would like to use another SPIN rule to find tools that fulfil ALL the
> requirements of a task.
>
> I came up with something like this:
>
> CONSTRUCT {
>> ?task :suitableTool ?tool .
>> }
>> WHERE {
>> ?task a :Task.
>> ?task :numRestrictions ?x .
>> {
>> SELECT ?tool ((COUNT(?constraint)) AS ?fulfilled)
>> WHERE {
>> ?task :hasConstraintRestriction ?constraint .
>> ?constraint :fulfilledby ?tool .
>> }
>> GROUP BY ?tool
>> } .
>> FILTER (?fulfilled > ?x) .
>> }
>
>
> Since it's quite hard to compare two sets, I'm going with counts here...
>
> In the SPARQL view, I'm getting a nice table of
> X suitableTool B.
> X suitableTool C.
> Y suitableTool C.
>
> When I add this to the spin:rule section of my Task class (I tried Thing
> as well), nothing happens.
>
> The numRestrictions property is filled by a SPIN rule as well:
>
> CONSTRUCT {
>> ?this :numRestrictions ?count .
>> }
>> WHERE {
>> {
>> SELECT ?this ((COUNT(?res)) AS ?count)
>> WHERE {
>> ?this :hasConstraintRestriction ?res .
>> }
>> GROUP BY ?this
>> } .
>> }
>
>
> Is it possible that the order in which the rules are executed causes the
> property to "disappear" (shouldn't incremental reasoning prevent this?)
> during the reasoning?
>
> Regards,
> Michael
> --
> -- You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include Enterprise
> Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid
> Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
> To post to this group, send email to
> [email protected] <javascript:>
> To unsubscribe from this group, send email to
> [email protected] <javascript:>
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
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-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
