Search Interface class

[Wayne Graham]

Is there an interface class for search results? I think it'd be a nice
thing to have to help further abstract the results to make it a bit
"easier" to write plugins for different searches. I'm specifically
thinking of our Solr stuff, but it could be easily implemented for
Lucene or Sphinx too.

I was thinking of something along these lines:

+ index: begin an index of an item; overloaded for a collection?
+ update: update the index of an item
+ search: search a collection or multiple collections

Any thoughts on an interface/abstract class for a SearchRecord? I'm
thinking here it would be nice to have a contract for what constitutes
a result that could be abstracted for all these different search
engine types.

Wayne

[Dave Lester]

Hi Wayne,

Thanks for committing your initial SolrSearch plugin code and posting
here on the dev list. Will Riley and John Flatness have been
developing a LuceneSearch plugin using Zend_Lucene, so hopefully they
can give some feedback on their approach to displaying search results
and pitch around ideas for how to improve Omeka's core.

Dave

[Will Riley]

Hey Wayne,

Currently, in Omeka, when you search for an item, it sends you to an
items browse page. The view of this ItemController paginates the
results and returns an array of items for the current page. Checkout
the browseAction function in application/controllers/
ItemsController.php. This function uses
Omeka_Controller_Action_Helper_SearchItems class located in
application/libraries/Omeka/Controller/Action/Helper/SearchItems.php
So the Omeka core currently only supports items as results.

If you look at the LuceneSearch plugin, you will see we created a
search controller that can display results for any model.

Given this new information, how you propose creating a universal
search results interface?

-Will

[Wayne Graham]

Hi Will,

Aha! The SearchItems helper is close to what I was looking for. I was
thinking of something along these lines as an Interface class (with
the getItemsPerPage, along with perhaps a getTotalResults,
getTotalItems, getPage, getPerPage broken out a bit further). Maybe
even an abstract class that would set fields like PER_PAGE,
EXCLUDE_TAGS, etc. Might even go further with a Result (or Item) class
with getTitle, getSummary, getLink, getScore, etc. methods. Really I'm
just looking for some assurance that we have some agreement as to what
is in these objects, and how a search engine implementation will
return results back to the framework.

Wayne

[John Flatness]

Hi Wayne,

You're completely correct that having some sort of interface for different search methods to conform to would be very useful; it would allow us to abstract out some common functionality so that every new search plugin doesn't need to reinvent the wheel.

I really like your ideas about abstract classes/interfaces for requesting and returning search results.  The main challenge I would see is striking a balance between being universal and useful.  An Omeka instance contains (or can contain) many types of data, and there are innumerable ways to search on that data.

From what I can ponder, your suggestions on common methods that would be used for the display of search results sound particularly useful; they could allow us to have a common frontend for search, while allowing swappable (or potentially combinable?) backends.  Our current SearchItems helper is somewhat like this, but it's inextricably tied to our existing MySQL full-text search.

I'd be very interested to hear any further thoughts you have on the subject, in any level of detail.

-John Flatness

[Wayne Graham]

Hi John,

Sorry, last week really got away from me. I hope to sit down with the
guys here this week and see if we can't come up with something a bit
more concrete...

Wayne

On Nov 3, 1:31 pm, John Flatness <jflat...@vt.edu> wrote:
> Hi Wayne,
>
> You're completely correct that having some sort of interface for different
> search methods to conform to would be very useful; it would allow us to
> abstract out some common functionality so that every new search plugin
> doesn't need to reinvent the wheel.
>
> I really like your ideas about abstract classes/interfaces for requesting
> and returning search results.  The main challenge I would see is striking a
> balance between being universal and useful.  An Omeka instance contains (or
> can contain) many types of data, and there are innumerable ways to search on
> that data.
>
> From what I can ponder, your suggestions on common methods that would be
> used for the display of search results sound particularly useful; they could
> allow us to have a common frontend for search, while allowing swappable (or
> potentially combinable?) backends.  Our current SearchItems helper is
> somewhat like this, but it's inextricably tied to our existing MySQL
> full-text search.
>
> I'd be very interested to hear any further thoughts you have on the subject,
> in any level of detail.
>
> -John Flatness
>