Dean; The things you can express in ApplyConstruct and the selectQuery in CheckConstraints are precisely the same, you would have the issue of "context beyond just the Concept that's being checked" in either case.
We have also tried to reproduce your results and have not been able to. In all our test cases using the selectQuery in CheckConstraints takes less time with the kind of queries we believe you are running (skos:Concept hierarchies). We will need to exchange some more detailed information, offline if desired, to understand the issue better. In terms of Holger's suggestion, you can unbind ?this by opening the constraint in composer and choosing "Set spin:thisUnbound to true". That action will use ?this as a normal SPARQL variable instead of being bound to a member of the class. -- Scott On Oct 26, 3:34 pm, Dean Rzonca <[email protected]> wrote: > Thanks, Scott. > > I considered this approach, but the problem is that some of our > constraints require context beyond just the Concept that's being > checked (for example, duplicate property values, depth in the Concept > tree, etc). > > Holger, can you elaborate on your suggested workaround? > > On Oct 24, 11:31 pm, Scott Henninger <[email protected]> > wrote: > > > Another thought is to create a graph of the triples you want to check > > constraints on through an ApplyConstruct module with replace=true and > > leave the query in CheckConstraints blank. The CONSTRUCT query would > > be: > > > CONSTRUCT {?selectedResource skos:narrower ?checkMe .} > > WHERE { ?selectedResource (skos:narrower)* ?checkMe . } > > > -- Scott > > > On Oct 22, 4:49 pm, Holger Knublauch <[email protected]> wrote: > > > > Hi Dean, > > > > I assume this is because by selecting each resource, the system needs to > > > ask many many small queries (with ?this pre-bound), and there is some > > > overhead in creating the query executions etc. I will run this through a > > > profiler to see if we can optimize that. If you run all constraints, then > > > those just need to be executed with ?this unbound, which is usually > > > faster. > > > > The only work-around right now that comes to my mind is to put the > > > subgraph into a separate sub-graph and then use named graphs to query > > > them. But this may not be a realistic set up in your scenario. > > > > Holger > > > > On Oct 23, 2010, at 4:00 AM, Dean Rzonca wrote: > > > > > I've noticed a strange issue with performance in the CheckConstraints > > > > SPARQLMotion module in Composer 3.3.3. It seems like performance > > > > degrades significantly when the selectQuery parameter is populated. > > > > > For example, we have a graph with 426 SKOS Concepts. If I leave > > > > selectQuery blank and run CheckConstraints on the entire graph, the > > > > operation completes in less than one second. However, if I populate > > > > selectQuery with something like: > > > > > SELECT ?checkMe > > > > WHERE { > > > > ?selectedResource (skos:narrower)* ?checkMe. > > > > } > > > > > where ?selectedResource is the root Concept in the graph, the > > > > operation takes upwards of one minute to complete. In practice, we > > > > don't plan to use a selectQuery to validate an entire graph, but > > > > rather a single subtree of Concepts within a graph. I only used it as > > > > an example to show the difference in running time on what looks like > > > > the same size data set. > > > > > Is there a better way to check constraints on a subtree of Concepts in > > > > a graph? Or, is there any way to tune performance when using a > > > > selectQuery on this module? Any help is appreciated. > > > > > Thanks, > > > > Dean > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Group "TopBraid Suite Users", the topics of which include TopBraid > > > > Composer, > > > > TopBraid Live, TopBraid Ensemble, SPARQLMotion 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 Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion 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
