I'd say the fact that you have no idea how to accomplish it ( neither do I ) would mean that you should give it a shot. I think though that instead of a tag cloud, you might want to check out Google Zeitgeist which might be a viable option. I think that with Perl in particular, seeing what people are looking for would help since with a freer form language like Perl, one needs to look at the average choices as well as the total number of choices...

I might give it a shot, but first I'd need the data to make the list with. It would be better to start out simple -- i.e. get the search feed implemented, and get the kinks worked out -- and then start trying to build fancy things on top of it. It's going to be hard to take a shot at creating a list of popular searches if I can't see what people are searching for....

What do you mean by your last statement? I didn't understand what you meant by average choices vs. total number of choices -- could you clarify that?

However, your penultimate question, "Is there any reason that this is not convenient/desirable/possible to implement?" goes to the nub regarding implementation of this (and many other) good ideas.

...convenient?
For whom, for what values of "convenient?" I suspect implementing this within PerlMonks existing (and complex) framework would be arduous (as one possible antonym for "convenient). Moreover, developing a schema for tagging querries, without requiring the user to provide the tags, comes close to requiring natural language parsing, an endeavor which has already proven more than merely arduous. And if the requirement is that the users of SS provide the tags, you have

1. a chicken-and-egg problem (Many who SuperSearch may be unable to accurately tag with words or phrases of which they have no knowledge) and...
2. a massive re-education/culture-change task ahead, as tagging is not a part of this culture.

...possible?
The answer(s) will have to come from the wisest of the Monastery's wise.

That said, this rambling response is in no sense meant to cast ice water on your idea. My breadth of ignorance (and utter lack of any CS background) make it appear to me to have merit. Thanks for an intriguing proposal.

Forgive me if I'm misunderstanding you -- but I don't see what you mean by saying that developing a schema for tagging queries would be difficult. Would something like this not work:


<query>
   <date>
    <month>02</month>
    <day>14</day>
    <year>2008</year>
   </date>
   <time>0830</time>
   <match_text_containing>the search query</match_text_containing>
   <match_text_separator></match_text_separator>
   <match_titles_containing></match_titles_containing>
   <match_title_separator></match_title_separator>
   <match_exclude_authors>exclude</match_exclude_authors>
   <authors>
      <author>Anonymous Monk</author>
      <author>jrtayloriv</author>
   </authors>
   <sort>new_first</sort>
   <result_date_start>
      <month></month>
      <day></day>
      <year></year>
   </result_date_start>
   <search_sections>all_but_selected</search sections>
   <sections_selected>
      <section>sopw</section>
      <section>meditations</section>
   </sections_selected>
   <skip_text_containing>stuff they didn't want</skip_text_containing>
   <skip_text_separator></skip_text_separator>
   <skip_titles_containing></skip_titles_containing>
   <skip_title_separator></skip_title_separator>
   <include_root_nodes>yes</include_root_nodes>
   <include_replies>selected</include_replies>
   <match_exclude_parent_author>exclude</match_exclude_parent_author>
   <root_node_authors>
      <author>Anonymous Monk</author>
      <author>jrtayloriv</author>
   </root_node_authors>
</query>
[download]



I've been overly verbose for illustration, and there is probably a better way to set this up -- but something as simple as this would seem to work. I don't see why anything would have to be done by the user -- i.e. I don't see why they would be required to tag anything themselves. This could happen transparently whenever a search request is answered by the web server, using the values the user input in the search form, and seems to be trivial to implement. It would seem that the resources expended to save the submitted queries in this format would be trivial compared to the server resources used to perform the search itself.

Am I missing something? Sorry if I'm being stupid -- I'm not very knowledgable about this sort of thing, and it's likely that there is something simple I didn't understand...

--jrtayloriv

UPDATE: Elaborated a bit on how the search queries might be formatted in the feed ...

Ummmm....errrrrr.....
No I definitely do NOT think you're being stupid. My selection of "schema" was poor. Maybe "scheme" -- since that has fewer specialized overtones -- would have been better...and there's probably something better yet.

And your comments above must have unlocked a synapse or two. But if you are suggesting that the "tag cloud" be generated from the content of the nodes found by SuperSearch, the issue I raised seems to me to be unresolved: What tools would we use to determine which parts of the returned_content should be applied as tags?

<Grin>... and if we continue this discussion, why -- you may have written the necessary code by the time I attain even minimal understanding of how "convenient" such development would be. In that (happy) event, I expect your elevation to Priest or Abbot or even Cardinal to occur precipitously... concurrent with an invitation to become a Dev(il).