Sorry for late response - I've been busy with Linked Data Planet conference and other stuff. Please see my comments below.

On Wed, Jun 11, 2008 at 4:47 AM, Markus Krötzsch <> wrote:

{{#ask: [[Query:French cities]] [[Population::>1000]] }}

where [[Query:French cities]] is the query "[[Category:City]] [[located
in::France]]". This would give you some ways of refining a saved query in
different ways, and one could still benefit from caching (since we would work
directly with the French cities insternally, and not look at all cities

I was thinking about deriving good cache algorithm from queries separately from this issue, but if saved queries can help with cache, it can be very helpful.

Caching would of course be somewhat independent from saving queries: one could
save a query and just have it as a syntactic shortcut, or one could have it
pre-computed (maybe offline, maybe using some useful update strategy during
editing). The latter case allows things to get slightly out-of-date, but
would provide very stable performance even on huge wikis.

Yes, it's still not very clear how this cache will be invalidated when pages get changed, but performance can be more important in some cases.
So let us think about how to do that:

* We need a new namespace of some name (seeing the potential use of queries in
#ask, I suggest not to use "Ask:" as a namespace). Otherwise this is a piece
of cake.

Yes, "Ask" is a good candidate - pages in this namespace should probably also automatically display results of the query in some default format.
* We need to define how users would enter queries that they would like to be
saved. I think each query-page would hold one query and arbitrary bits of
documentation. To enter the query, users would use the syntax as in #ask.
There are some options for the details:
** We use a special property such as [[query:: [[Category:City]] ... ]].
** We use a new parser hook such as {{#query:  [[Category:City]] ... }}.
** We overload #ask for pages in that namespace, i.e.
{{#ask:  [[Category:City]] ... }} would work differently on those pages (it
could still show the results, but it would also be required to be unique, and
its query part would be saved).

There is another approach - Semantic Forms and Widgets extensions just use <include>/<noinclude> tags to identify what gets displayed and what gets used by Form/Widget engine. It doesn't make much sense to transclude pages in Ask namespace so this makes sense.

Also, it makes no sense to have multiple queries defined on one page in Ask namespace so using a parser function ({{#query}}) or property style ([[query::...]]) might bring some unexpected results. And definitely overriding a #ask is a bad idea since documentation piece of the page might want to include some arbitrary query results.
* We (or at least I) need to consider how to store queries in the database. I
can treat them similar to property values that can be very long (Type:Text).
As long as there is no caching, the query string would thus be processed in a
purely syntactic manner: you use it in a query, and SMW replaces it with its
real query string.

If we use method I suggested, then query text is going to be just page text with <include>/<noinclude> rules applied. You can also store parsed query code in database or cache if you think it makes sense.

* I can use the page id of the query page to identify the queries internally,
e.g. to store the information about them being cached (including location in
DB, date of last refresh), or for certain statistic data (result count, used
in query optimisation).

Yep, queries being pages is a good thing. The only problem I ran into is that using ask query in documentation piece of the page that defines that query requires refresh of the page after it's saved because at the parsing stage where you need to use pages content for query (in my case widget code), it's obviously not saved yet.
I think that is almost an implementation plan. Let us decide quickly on the
open questions, and I shall have that done (at least without the caching)
before the next release.

That would be great! I hope my late response will still have you consider my comments.


Best regards,


> I can definitely give various examples based on TechPresentations
> experience, like topic RSS feeds, event series iCal feeds and so on.
> Will appreciate any feedback on this.
> Thank you,
>          Sergey

Markus Krötzsch
Semantic MediaWiki

Sergey Chernyshev