Hi Dev,

It might make sense to split the different use cases (or "CASES") into different special pages - but I don't think the justification you gave, "less bugs should creep in, and more features could be added", is enough of a reason by itself. If the code is factored out well, it shouldn't be more complex to have all the functionality in one special page, vs. two or three. The only justification I can think of at the moment, actually, is to make things clearer for users.

Being able to disable some or all of the Special:Ask functionality might be nice. For Wikipedia, though, the idea (or at least one idea) was to disable querying altogether - Special:Ask as well as #ask and #show.


On Mon, May 16, 2011 at 7:49 PM, Devayon Das <shyan.s@gmail.com> wrote:
Hi Yaron,
You guessed right about most things. As far as Halo is concerned, yes I was talking about Special:QueryInterface (although their other features are pretty cool too).

>And I also don't know what you meant by "a powerful result printer". Could you clarify these?
I guess I'm mixing up terminology since I'm quite new to SMW :(
What I meant by "a powerful result printer" is simply a system which allows one to access results in the format you desire (for example, a link to results as RSS feeds). That's use-case 1 to me (see below)

I've been thinking more and more about this and can think of three cases of what Special Ask is doing (or should do ;) ) I'm not going into functionality appropriate for completely new extensions, and I'm thinking out loud here, and would love your comments.

(1)CASE 1: .site\wiki\Special:Ask\<some-parameters> gives Tables, RSS Feeds, Google-Maps and more
EXAMPLE: "Special:Ask/-5B-5BLocated-20in::Germany-5D-5D/order%3DDESC/sort%3D/format%3Drss/limit%3D20" generates an RSS feed of pages of entities located in Germany.
I think meddling with this (especially the URL format) would break a lot of things, including Special:QueryInterface. However, Jeroen said that we will ultimately get limited by the URL length of <some-parameters>, so perhaps using POST and/or a totally different parameter-passing-mechanism (such as Json??) might improve this feature in the future.

(2) CASE 2:
Write a query, choose properties and get a URL link OR results OR #ask
Apart from actually 'writing' the query, Special:QueryInterface does this rather well, and is more intutive than Special:Ask. The only place QueryInterface falters is that you cannot paste a query and edit it; you have to store it for future editing. Improving usability here, such as more auto-complete, error-reporting, and some hints (isn't the search page at GitHub nice?) would help the user along quite well, I think.

Markus had some great plans for CASE (2); he was thinking about a visual query/URL builder (something like Simulink) where one just plugs in properties and format options to a query and gets the correct URL or #ask! That would be neat! I think if one had access to CASE (1), and a clear idea about the correct parameters to be generated, this could be built with some JavaScript on the client with some asynchronous JS calls to Special:Ask.

(3) CASE 3: Edit an existing #ask OR Special:Ask\<someparameters> OR query
For example, given a link which gets me an RSS feed, can I edit it to
(i)change query parameters ?
(ii)change the export format ?
(iii)get the equivalent #ask ?
(iv)get the equivalent query?
(v) change sorting options?

This should work for three kinds of input: (1) #ask, (2)the query we type in the current Special:Ask box and (3)the Special:Ask/URL. Jeroen had told me that this is quite a useful idea, and it is if you wanted to tweak some existing feeds or exports.

I know Special:Ask can't do this right now (apart from pasting in a query which have saved in your notes maybe ;) ), but does anyone else know of any other extension which does this?

I'm hoping to move CASE (2) and CASE (3) out of Special:Ask to different Special Pages. My reasoning for this is (I hope not too many people are getting angry right now) that if in the long run Special:Ask concentrates on just one feature (use CASE (1): URL to Results) then less bugs should creep in, and more features could be added. This would also mean that going to wiki/Special:Ask (without any other parameters) would have nothing to show the user at all! (maybe a helpful redirect to CASE 2 or CASE 3?). This is where I really need your opinion (be gentle!).

Another thing I'm thinking about is to be able to disable CASE (1), without disabling CASE (2) and CASE (3) especially for #ask. For a site which can't handle traffic, maybe one wouldn't want third-parties generating feeds/maps of data (and burdening the server for every client who views the RSS feed), but would still want the ability to create and edit queries and #ask. Isn't that why Wikipedia wants to disable query features if they include SMW in Wikipedia?

The points you raise about re-naming Special:Ask are interesting. In fact Markus had asked me to think "What should Special:Ask do?". Indeed S.Ask does so many things that naming it is a problem ;). My hope is that 'Ask' is a good name for CASE 1 ("ask and you shall find"). "Query Creator" is more suited to CASE 2 and "Query Editor" is more suited to CASE 3 (provided that you agree that CASE 2 and 3 are indeed separate use-cases)


On Sun, May 15, 2011 at 10:46 PM, Yaron Koren <yaron@wikiworks.com> wrote:
Hi Dev,

It's great to hear from you, and great to see that you're approaching this project with a lot of both enthusiasm and thought.

So - you bring up a few different things in this email. First, there are the "quick wins" (well, hopefully quick) - things that could be improved in Special:Ask without needing to change the interface. The autocompletion currently times out the whole page if there are too many properties defined on the wiki - that can be fixed by just putting a limit on the number of properties retrieved, or, more sophisticatedly, by switching to "remote autocompletion" if there are more than x properties - so that the the property names aren't stored directly within the page HTML. And if a query is badly formed, the page should definitely display an error message at the top.

Second are the interface improvements. In my opinion, and I think it's shared by some developers I've talked to, the single biggest improvement to the Special:Ask interface would be to turn the two textareas on the page into groups of rows, that users can add to and remove from (via Javascript). For the first textarea, the one to define the set of pages queried, there could be one row for each "filter" - that way, users wouldn't have to learn the syntax ("[[a::b]]", etc.), and you could have autocompletion and such. Actually, it might be good to have three different such groups: one for categories, one for concepts (if there are any on the wiki), and one for properties. And that approach probably makes sense for the 2nd textarea as well, especially given the "display parameters" (defined by "|+") that are now possible in queries.

You seem to be getting at something more, though, especially in this paragraph:

One of the ways many others have attacked the problem is by building
extensions for SMW which make it easier to find data or build queries, such
as Halo, Drilldown and Exhibit. These products do a great job, but they have
common aspects (which people at the dev-list were kind to point out) that
could be abstracted out. In short, if we could separate (i) a powerful
result printer and (ii)a clean usable interface, from Special:Ask, then in
the future one could build an awesome query builder/a new result printer/a
data-explorer by writing less code.

This paragraph confused me, actually. Semantic Drilldown and Exhibit definitely have aspects in common - SD's "filters" and Exhibit's "facets" are basically the same thing. For Halo - I assume you're talking about Special:QueryInterface, but maybe you're talking about the SMW+ "Faceted Browser" extension. In either case, I don't know what you mean about abstracting out common aspects. And I also don't know what you meant by "a powerful result printer". Could you clarify these?

Finally, this is kind of a minor point, but we had a brief discussion on the mailing list a while ago about maybe renaming "Semantic search" (the current title of Special:Ask) to something that sounds less intimidating - I suggested "Query creator" or "Create a query". If you're already overhauling the page, that might be worth thinking about too. And the actual name of the page, "Special:Ask", could be changed as well, if some other name makes more sense.


Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
Semediawiki-devel mailing list

WikiWorks MediaWiki Consulting http://wikiworks.com