in reply to Feed / Tag Cloud of Recent Searches from Super Search

++ for an interesting idea.

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.

  • Comment on Re: Feed / Tag Cloud of Recent Searches from Super Search

Replies are listed 'Best First'.
Re^2: Feed / Tag Cloud of Recent Searches from Super Search
by jrtayloriv (Pilgrim) on Feb 15, 2008 at 01:14 UTC
    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 ...
[reply]
[d/l]

      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).

[reply]
        Ahhhh, I see what you were saying regarding the tags now. I thought you mean the XML tags for the feed itself -- I didn't realize you were talking about the tag cloud.

        Sorry I wasn't clear about that in my original post. Generating the tag clouds is indeed a more complex issue, and I'd have to do quite a bit more research myself before I would be able to post up any concrete solutions for implementing such a thing. One thing I would like to point out is that I was talking more about the tags being generated from the query itself rather than the results. Solutions using the search results would probably prove more interesting/accurate, but the large amount of added complexity might make it unworkable...

        But even if a tag cloud system isn't put up for a while (or ever), that is a separate issue from the search query feed, which should not be difficult to implement and could still prove useful/interesting for other things besides just the tag cloud.

        I also feel that it would be much easier to write the code for the tag cloud system if we had the feed up and working, so that we could have something tangible to test it out on. At the very least, we could experiment with some Free Nodelet solutions to display the last N search queries on the sidebar, or some such thing ...

        Anyhow, thanks a bunch for the input. I'll start thinking about which content the tag clouds might be generated from, and post up anything I come up with.

        --jrtayloriv
[reply]

In Section Perl Monks Discussion