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
