Thank you Tommaso, I might need help or at the very least simple pointers and debates over certain principles and guidelines. First one being: the choice to either abstract everything related to search (such as Sorting fields, query, filters and facets) or to use the Lucene native objects. Small overview of pros and cons (for the rdf.cris package, not the implemenation packages). Native Lucene + Objects already exists, well implemented (SortField, Facet, …) - Bounds to lucene semantics (fairly easy to use but certain impl providers will have to rewrite using Lucene translation… In case someone wants to make a "Fast" or GSA impl for clerezza). Note that Lucene, Solr and Elastic can fairly easily work with Native Lucene Objects +/- Should put all search-ability logic into helper classes as to not force external package to talk "Lucene" Abstracted Classes - LOT of re-coding concepts that are straight forward in Lucene + No Lucene dependancies and no need of helper classes + Not bound to anything impl, rewrite for possible solr, GSA, fast, … will not require basic knowledge of Lucene. I'd be interested on you POV on this. My Main goal is for ppl outside of the rdf.cris package never having to learn any specialised API while yet taking advantage of all the IR features of any search engine. _Stephane On October 3, 2013 at 1:59:07 PM, Tommaso Teofili ([email protected]) wrote:
|
- Search in rdf.cris Stephane Gamard
- Re: Search in rdf.cris Tommaso Teofili
- Re: Search in rdf.cris Stephane Gamard
- Re: Search in rdf.cris Tommaso Teofili
