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.
-Yaron
On Mon, May 16, 2011 at 7:49 PM, Devayon Das <shya...@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)
>
> ~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
>
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
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
