On Dienstag, 10. Juni 2008, Sergey Chernyshev wrote: > I'm starting to use Ask queries for RSS and iCal support on the site and > one of the issues I'm having is huge URLs that get generated when queries > are significantly large. > > These URLs can't really be imported into RSS readers or iCal tools > (Outlook, Google Calendar) which defeats the purpose. My current workaround > is to run cron jobs to dump them into the files, but that's not really good > solution as I can't use variables in these queries, for example. > > One of the potential solutions I see is to save queries as articles in some > (Ask) namespace and use page names as shortcuts for these queries. > > Markus, Denny, I'll appreciate your thoughts on how hard will it be to add > this query article reading functionality it to #ask parser function and > Special:Ask code - I just want to understand what it might take for me or > other developer to implement this. Also, I think it's worth discussing > which aspects of the query should be saved and which should still be > specified when this query is used, e.g. which properties to display, how to > format (RSS, iCal) and etc.
I generally like the idea. It would also open new ways for caching queries or
for having some form of access control for query creation (maybe some wikis
do not want anyone to make large queries). But I do not see all the details
yet.
I would like saved queries to specify only the query as such, without
specifics regarding format or printouts. At least that would make it easier
for us to cache results of saved queries (since the cache would always have
the same format, storing only a list of results). It would then be easy to
reuse a saved query in #ask by just replacing the saved query string by
something like [[Query:Name of query]] (so saved queries would work
like "dynamic categories"). One could even combine saved queries with
additional query parameters in this way! For example:
{{#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).
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.
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.
* 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).
* 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.
* 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).
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.
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]
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
