lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Plebanek <pleba...@gmail.com>
Subject Re: Federated Search - jira issues
Date Fri, 24 Aug 2012 09:23:18 GMT
Hi David,

Look at this from the other side: If You have system based on Solr (e.g.
free books library) and in some cases you would like to include results
from the other sources (e.g. option "include results from associated
book shops") it would be simpler to have it just by enabling Solr
feature than involving another framework.

Of course in a system where kind of metasearch is the main task, this
approach wouldn't fit and dedicated platform is needed.

I think that federated search as Solr feature is very reasonable.
Especially when designed from the beginning as Solr feature and not
trying to make it a universal metasearch solution.

The implementation could be partially similar to existing
DistributedSearch (and concerning Solr instances search part, it could
use DistributedSearch directly). In basic usage it can skip some
complicated parts (like collection representation) and be simple to
customize.

Just like Solr has support for different update formats
(JSON,CSV,XML..), it could have support for different external search
formats (e.g. OpenSearch). So in my example from the beginning, if one
wants to include results from "associated book shop", he will just ask
the shop to expose its search engine throught OpenSearch (if it's not
already). Than he has to only configure suitable Adapter/Connector in
Solr.


With this approach the main advantage is simplicity. Including external
collection in search results would require only customization of
existing adapter or writing dedicated one.
For users: No additional framework, No change in current search API (The
adapter will handle mapping between Solr and external query/data model).


The applications will be limited of course. The Solr federated query
will always have lower performance than native Solr query (limited
functions, lower accuracy) and could be used only in special
circumstances - as a feature, not as a whole solution.


Jacek Plebanek

Interdisciplinary Centre for Mathematical and Computational Modelling
University of Warsaw, Poland


Dnia 2012-08-23, czw o godzinie 21:52 -0700, David Smiley (@MITRE.org)
pisze:
> Hi Jacek,
> 
> This strikes me as a project that would exist separate to Solr because it
> would have little to do with it.  In federated search, you are searching
> multiple search platforms of ideally any flavor.  Why base the federated
> search platform on any one of these (e.g. Solr)?  I think there is little of
> Solr internally that would be re-used if you were federating to other
> platforms and not searching Lucene/Solr itself.
> 
> ~ David Smiley
> 
> 
> 
> -----
>  Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Federated-Search-jira-issues-tp4002796p4003023.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message