Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

*Discovery Configuration in DSpace 1.7.0
*Discovery Install in pre 1.7.0 HowTo

Design

...

Premise for Discovery

The Design premis premise behind Discovery is to keep as much the implementation of Search and Browse independent of DSpace as possible. The basis for this is to twofold. (a) to reduce cost in maintaining any customized code and (b) to repurpose third party solutions wherever possible (a.k.a. standing on shoulder of giants).  So, the basic tenants are:

  1. Keep as much of the customization and configuration in Solr as possible.
  2. Keep it as generic as possible.
  3. Keep it as simple as possible.
  4. In cases where configuration is outside Solr, Provide provide pluggability to replace functionality easily at end user deployment.
  5. Align Search/Browse capabilities with Solr capabilities, not other way around.  This means, possibly abandon certain strategies for navigating via Browse if it proves these do not fit well with solrSolr.

RoadMap

Discovery is currently and an addon for DSpace that still requires significant addition of configuration files to support.  Planned releases will initially coincide with initially coincide with DSpace Scheduled Releases. Eventually, once completely stabilized.  Discovery , Discovery may be included into DSpace releases as a replacement for DSpace Search and Browse out of the box.

...

Discovery in

...

DSpace 1.8.0

New Discovery back end backend (unconfirmed)

The goal of this task was twofold.

  1. Ensure that discovery doesn't have to use solr Solr as a backend, in other words ensure that user can plug in their own backend implementation.
  2. Rewrite some of the code to make it more logical (example: the sidebar filters for a community page where rendered because the CommunityRecentSubmissionsTransformer extended the AbstractsFiltersTransformer => logically these are 2 completely different things).

This task focuses completely on these 2 pointpoints. Please bear in mind that almost nothing in the UI has been changed. While programming this task I also had a minor feature request which I implemented, namely the following:

The autocomplete filters can be configured not to not split words on a space, this is particularly useful for authors.

The rewrite of the back end is explained below.

  1.   A new discovery sub-module has been created named "dspace-discovery-solr" this module is the only module that contains any solr Solr dependencies and contains the old "SolrServiceImpl" class and the spring-dspace-addon-discovery-services.xml spring Spring file. This module is used by default and ensures that a discovery out of the box will still work. None of the other discovery modules have dependencies on this module so it can be replaced very easily.
  2.  The The "dspace-discovery-provider" module has lost the all the solr Solr dependencies as explained and the "SearchService" interface has undergone some changes, the search methods don't require a solrQuery anymore and do not return a solrResult. Instead 2 new objects have been created
    • DiscoverQuery: will hold all query information
    • DiscoverResult: will contain the resulting dspace objects and/or the facets
    • By doing things this way any programmer can implement the search service and write their own backend.
  3. All the user interface classes have been rewritten to support these new objects.
  4. One logical change was also made namely the following:
    The abstractFilters class has been transformed into the "SidebarFacetsTransformer". The facets will still appear on the same places, but unlike earlier where the only reason the community had sidebar facets was that the "CommunityRecentSubmissions" class extended the filters class the SidebarFacetsTransformer is now called on each community page. I did this because it just makes more sense that way.
  5. I also added an extra method to indexing implementation of solr, Solr named "indexItemFieldCustom", should it ever be required to adjust some simple indexing task the entire "SolrServiceImpl" does not need to be overwritten. One simply extends the class and implement that method (a boolean is returned which can prevent further indexing of the metadata field).

...