Ok, now puntual comments:<br><br><div class="gmail_quote">2010/3/8 Sebastian Trueg <span dir="ltr">&lt;<a href="mailto:trueg@kde.org">trueg@kde.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


1. In TagsFacet::queryNextResult<br>
<br>
term.addSubTerm(Query::ComparisonTerm(Soprano::Vocabulary::NAO::hasTag(),<br>
Query::LiteralTerm(label)))<br>
<br>
should be<br>
<br>
term.addSubTerm(Query::ComparisonTerm(Soprano::Vocabulary::NAO::hasTag(),<br>
Query::ResourceTerm(query-&gt;binding(0).uri())))<br>
<br>
This will prevent the query from using a string matching. This should<br>
speed up the query significantly (BTW: I suppose this is why the UI is<br>
blocking).<br>
<br></blockquote><div><br>Indeed, it was this that was blocking the UI: thanks!<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. Restricting by folder (as you do by default using a FILTER) slows<br>
down the query A LOT.<br>
<br></blockquote><div><br>Well, somewhere I need to restrict tags and their count to the current folder: if the user changes it through the normal browsing, then the tags and also the tag counters need to be restricted to that folder.<br>

For now I&#39;m doing this directly in the main query, the one getting the list of tags; the only alternative that I see here is to get the list of tags directly (not through the tagged file list), and then restrict by folder when asking for the count of each tag; this may speed up things, the only drawback is that it will get _all_ the tags in the first place, so that the pruning of the tag list will be done through the model (which drops tags with zero as counter) instead of through the query itself... in a standard db this would be ugly, but maybe in our case it is better, given the fact that sparql is way much slower than sql.<br>

 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. It probably is not necessary to re-query the tags each time the<br>
factes change. Although I am also not sure if it would change much.<br>
<br></blockquote><div><br>Yes, but at least I need to update the counters.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4. OpenLink is currently accessing the perfect indexing scheme for us.<br>
This in combination with proper inferencing should give us another<br>
performance boost.<br clear="all"></blockquote></div><br>Nice to hear that!<br><br>-- <br>Sivieri Alessandro<br><a href="mailto:alessandro.sivieri@gmail.com">alessandro.sivieri@gmail.com</a><br><a href="http://www.chimera-bellerofonte.eu/">http://www.chimera-bellerofonte.eu/</a><br>

<a href="http://www.poul.org/">http://www.poul.org/</a><br>