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)
~dev
On Sun, May 15, 2011 at 10:46 PM, Yaron Koren <ya...@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.
>
> -Yaron
>
------------------------------------------------------------------------------
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.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
