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 <
[EMAIL PROTECTED]> 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
> again).
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.
Sergey
Best regards,
>
> Markus
>
> >
> > 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 http://semantic-mediawiki.org
> http://korrekt.org [EMAIL PROTECTED]
>
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
