All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
Another example: Using the standard search, a user would search for something like [wetland + "dc.author=Mitsch, William J" + dc.subject="water quality" ]. With filtered search, they can start by searching for [wetland ], and then filter the results by the other attributes, author and subject.
...
...
config/modules/discovery.cfg
and config/spring/api/discovery.xml
...
Info |
---|
Starting from DSpace 3.0 discovery , Discovery is also supported in JSPUI. |
...
XMLUI-only:
Bugfixes and other changes
You can independently enable Discovery
...
for XMLUI or JSPUI. Follow the steps below.
...
As with any upgrade procedure, it is highly recommend that you backup your existing data thoroughly. Although upgrades in versions of Solr/Lucene do tend to be forwards forward-compatible for the data stored in the Lucene index, it is always a best practice to backup your [dspace-install-dir]/solr/statistics
cores to assure no data is lost.
config/xmlui.xconf
SearchArtifacts
Uncomment: Discovery
Code Block | ||||
---|---|---|---|---|
| ||||
<xmlui> <aspects> <!-- @deprecated: the Artifact Browser has been devided into ViewArtifacts, BrowseArtifacts, SearchArtifacts <aspect name="Artifact Browser" path="resource://aspects/ArtifactBrowser/" /> --> <aspect name="Displaying Artifacts" path="resource://aspects/ViewArtifacts/" /> <aspect name="Browsing Artifacts" path="resource://aspects/BrowseArtifacts/" /> <!--<aspect name="Searching Artifacts" path="resource://aspects/SearchArtifacts/" />--> <aspect name="Administration" path="resource://aspects/Administrative/" /> <aspect name="E-Person" path="resource://aspects/EPerson/" /> <aspect name="Submission and Workflow" path="resource://aspects/Submission/" /> <aspect name="Statistics" path="resource://aspects/Statistics/" /> <!-- To enable Discovery, uncomment this Aspect that will enable it within your existing XMLUI Also make sure to comment the SearchArtifacts aspect as leaving it on together with discovery will cause UI overlap issues--> <aspect name="Discovery" path="resource://aspects/Discovery/" /> <!-- This aspect tests the various possible DRI features, it helps a theme developer create themes --> <!-- <aspect name="XML Tests" path="resource://aspects/XMLTest/"/> --> </aspects> |
Add discovery to the list of event.dispatcher.default.consumers
Code Block |
---|
# default synchronous dispatcher (same behavior as traditional DSpace) event.dispatcher.default.class = org.dspace.event.BasicDispatcher #event.dispatcher.default.consumers = versioning, search, browse, eperson, harvester event.dispatcher.default.consumers = versioning, search, browse, discovery, eperson, harvester |
Change recent.submissions.count to zero
Code Block |
---|
#Put the recent submissions count to 0 so that discovery can use it's recent submissions, # not doing this when discovery is enabled will cause UI overlap issues #How many recent submissions should be displayed at any one time #recent.submissions.count = 5 recent.submissions.count = 0 |
If all of your traffic runs over port 80, then you need to remove the port from the URL
Code Block |
---|
##### Search Indexing ##### solr.search.server = http://localhost/solr/search |
From the command line, navigate to the [dspace] directory and run the command below to index the content of your DSpace instance into Discovery.
Code Block |
---|
.[dspace]/bin/dspace update-discovery-index |
Panel |
---|
NOTE: This step may take some time if you have a large number of items in your repository. |
...
...
As with any upgrade procedure, it is highly recommend that you backup your existing data thoroughly. Although upgrades in versions of Solr/Lucene do tend to be forwards compatible for the data stored in the Lucene index, it is always a best practice to backup your [dspace-install-dir]/solr/statistics
cores to assure ensure no data is lost.
config/dspace.cfg
org.dspace.app.webui.search.LuceneSearchRequestProcessor
Uncomment: org.dspace.app.webui.discovery.DiscoverySearchRequestProcessor
Code Block | ||||
---|---|---|---|---|
| ||||
plugin.single.org.dspace.app.webui.search.SearchRequestProcessor = \ org.dspace.app.webui.discovery.DiscoverySearchRequestProcessor |
Add discovery to the list of event.dispatcher.default.consumers
Code Block |
---|
# default synchronous dispatcher (same behavior as traditional DSpace) event.dispatcher.default.class = org.dspace.event.BasicDispatcher #event.dispatcher.default.consumers = versioning, search, browse, eperson, harvester event.dispatcher.default.consumers = versioning, search, browse, discovery, eperson, harvester |
Note |
---|
As it is not possible in JSPUI to use both search provider providers (Lucene and Discovery), it it is generally more appropriate, but not required, to remove the "search" consumer from the list above. The "browse" consumer can be removed as well if you configure the Browse System to use Solr/Discovery as its backend (see Defining the Storage of the Browse Data) |
Enable facet showing in the Repository, Communities and Collections home pages
Code Block |
---|
plugin.sequence.org.dspace.plugin.CommunityHomeProcessor = \ org.dspace.app.webui.components.RecentCommunitySubmissions,\ org.dspace.app.webui.discovery.SideBarFacetProcessor plugin.sequence.org.dspace.plugin.CollectionHomeProcessor = \ org.dspace.app.webui.components.RecentCollectionSubmissions,\ org.dspace.app.webui.discovery.SideBarFacetProcessor plugin.sequence.org.dspace.plugin.SiteHomeProcessor = \ org.dspace.app.webui.discovery.SideBarFacetProcessor |
Note |
---|
Please note that JSPUI (in contrast to XMLUI) still relies on the Browse Engine to show "recent submissions". The browse engine can be configured to use Solr/Discovery as its backend (see Defining the Storage of the Browse Data) |
Enable a JSON endpoint to provide the autocompletion feature in the search form
Code Block |
---|
plugin.named.org.dspace.app.webui.json.JSONRequest = \ org.dspace.app.webui.discovery.DiscoveryJSONRequest = discovery |
If all of your traffic runs over port 80, then you need to remove the port from the URL
Code Block |
---|
##### Search Indexing ##### solr.search.server = http://localhost/solr/search |
From the command line, navigate to the [dspace] directory and run the command below to index the content of your DSpace instance into Discovery.
Code Block |
---|
./bin/dspace update-discovery-index |
Panel |
---|
NOTE: This step may take some time if you have a large number of items in your repository. |
...
Property: | search.server |
Example Value: |
|
Informational Note: | Discovery relies on a Solr index for storage and retrieval of its information. This parameter determines the location of the Solr index. |
Property: | index.ignore |
Example Value: |
|
Informational Note: | By default, Discovery will include all of the DSpace metadata in its search index. In cases where specific metadata is confidential, repository managers can include those fields by adding them to this comma separated list. |
Property: | index.authority.ignore[.field] |
Example Value: |
|
Informational Note: | By default, Discovery will use the authority information in the metadata to disambiguate homonymoushomonyms. Setting this property to false will make the indexing process the same as the metadata doesn't include authority information. The configuration can be different on a field (<schema>.<element>.<qualifier>) basis, the property without field set the default value. |
Property: | index.authority.ignore-prefered[.field] |
Example Value: |
|
Informational Note: | By default, Discovery will use the authority information in the metadata to query the authority for the prefered label. Setting this property to false will make the indexing process the same as the metadata doesn't include authority information (i.e. the prefered form is the one recorded in the metadata value). The configuration can be different on a field (<schema>.<element>.<qualifier>) basis, the property without field set the default value. If the authority is a remote service, disabling this feature can greatly improve performance. |
Property: | index.authority.ignore-variants[.field] |
Example Value: |
|
Informational Note: | By default, Discovery will use the authority information in the metadata to query the authority for variants. Setting this property to false will make the indexing process the same, as the metadata doesn't include authority information. The configuration can be different on a per-field (<schema>.<element>.<qualifier>) basis, the property without field set the default value. If the authority is a remote service, disabling this feature can greatly improve performance. |
...
Class: | DiscoveryConfigurationService |
Purpose: | Defines the mapping between separate Discovery configurations and individual collections/communities |
Default: | All communities, collections and the homepage (key=default) are mapped to defaultConfiguration |
Class: | DiscoveryConfiguration |
Purpose: | Groups configurations for sidebar facets, search filters, search sort options and recent submissions |
Default: | There is one configuration by default called defaultConfiguration |
Class: | DiscoverySearchFilter |
Purpose: | Defines that specific metadata fields should be enabled as a search filter |
Default: | dc.title, dc.contributor.author, dc.creator, dc.subject.* and dc.date.issued are defined as search filters |
Class: | DiscoverySearchFilterFacet |
Purpose: | Defines which metadata fields should be offered as a contextual sidebar browse options, each of these facets has also got to be a search filter |
Default: | dc.contributor.author, dc.creator, dc.subject.* and dc.date.issued |
Class: | HierarchicalSidebarFacetConfiguration |
Purpose: | Defines which metadata fields contain hierarchical data and should be offered as a contextual sidebar option |
Class: | DiscoverySortConfiguration |
Purpose: | Further specifies the sort options to which a DiscoveryConfiguration refers |
Default: | dc.title and dc.date.issued are defined as alternatives for sorting, other than Relevance (hard-coded) |
Class: | DiscoveryHitHighlightingConfiguration |
Purpose: | Defines which metadata fields can contain hit highlighting & search snippets |
Default: | dc.title, dc.contributor.author, dc.subject, dc.description.abstract & full text from text files. |
...
In addition to the summarized descriptions of the default values, following details help you to better understand these defaults. If you haven't yetalready done so, download the configuration file and review it together with the following parameters.
The file contains one default configuration that defines following sidebar facets, search filters, sort fields and recent submissions display:
...
Note |
---|
After modifying sidebarFacets and searchFilters, don't forget to reindex existing items by running |
Below is an example of how one of these lists can be configured. It's important that each of the bean references corresponds to the exact name of the earlier defined facets, filters or sort options.
...
Warning |
---|
This paragraph only apply to XMLUI. The JSPUI does not currently support the "More like this" feature. |
The '"more like this'"-configuration element contains all the settings for displaying related items on an item display page.
Below is an example of the "more like this" configuration.
Code Block | ||
---|---|---|
| ||
<property name="moreLikeThisConfiguration"> <bean class="org.dspace.discovery.configuration.DiscoveryMoreLikeThisConfiguration"> <property name="similarityMetadataFields"> <list> <value>dc.contributor.author</value> <value>dc.creator</value> <value>dc.subject</value> </list> </property> <!--The minimum number of matching terms accrossacross the metadata fields above before an item is found as related --> <property name="minTermFrequency" value="5"/> <!--The maximum number of related items displayed--> <property name="max" value="3"/> </bean> </property> |
...
Discovery is built as an application layer on top of the Open Source Enterprise Search Server Solrthe Solr open source enterprise search server. Therefore, Solr configuration can be applied to the Solr cores that are shipped with DSpace.
The DSpace Solr instance itself now runs two cores. One for collection DSpace Solr based "statistics", the other for Discovery Solr based "search".
...