Search API

A common desire with Apache Solr search servers is to get the "best of both" stemming and not stemming terms, indexing both the original term and the stem with something like SnowballPorterFilterFactory. Stemming matches grammatical variations, while indexing the original boosts exact matches to rank higher than near matches, and protects against awkward cases where after stemming, the original term no longer matches.

the latest version of Nutch 2.1 seems to work quite nicely with Solr 4.0 and am wondering if others have tried sending results to Search API and / or Apache Solr Search Drupal modules ?

there are lots of possibilities with integrating web-crawls into Drupal views, searches etc

Nutch 2.1 / Solr 4.0 (Gora+Mysql) running using this tutorial
http://nlp.solutions.asia/?p=180

Nutch 2.1 + Aegir BOA?
http://drupal.org/node/1851318

Drupal Nutch module and 2.1?
http://drupal.org/node/1851324

Drupal Elastic Search module and Nutch
http://drupal.org/node/1851064

Project information

Project page on drupal.org: not created yet
Student: Michael Timofeev (mtee)
Mentor: Thomas Seidl (drunken_monkey)
Co-mentor(s): (klausi)
Local mentor(s): Thomas Seidl
Current status: developing

Overview

The Entity Translation module is the latest and greatest way to manage multilingual content in Drupal. However, no Drupal search solution currently supports the field based translation it is built on. We'd like to share how we solved this challenge, made field based translations searchable and came up with the brand new Search API Entity Translation module.

Search API Entity Translation is a minimalist approach of making multilingual content managed via entity translations searchable via Search API.

Hi everyone,

I'm looking for some guidance in regards to a current project i'm working on:

Details:

Display businesses for a certain city by using geo data, a proximity slider from a pre-defined center point (supplied by field in the entity, url or defined in the view) and predefined start radius (also defined in the view or by url) - closest distance to center point are displayed first - with distance to center point calculated.

As some of you might know, in last year's GSoC I created the Search API module, which has already gained some fame since then. It's a highly flexible search solution for Drupal 7, already coming with support for Views and facetted searches out-of-the-box, amongst other things.
Still, like all software, it isn't perfect and there are still a number of known shortcomings, as well as other potential for improvement. So for this Google Summer of Code, I propose to fix some of these shortcomings, and add some additional features.
The tasks I'd have in mind are the following (in order of importance):

• Add autocompletion feature
• Provide ways to index other data than entities
• Add a "More like this" feature
• Add hierarchical facets for taxonomy terms
• Add additional little multi-language features
• Extend test coverage
• Extend documentation

The last two are of course the buffers for any remaining time at the end — even when I'm done with the others, there will always be numerous ways to improve tests and documentation.

The goal of this project is to build a generic Search API that will on the one hand abstract from the data source (using the entity_metadata module) — thus allowing all kinds of entities to be as easily indexed and searched as nodes —, and from the indexer / search engine on the other hand, making concrete implementations like Solr, Lucene, Xapian, … implement only the specific details and thereby eliminating unnecessary code duplication.
Also the gathered metadata and the search engine interface could be used to create a generic Views integration for all searches, thus letting all supported searches display their results as a configurable view.
The planned overall design is sketched in the attached diagram.