All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
The Discovery Module for the XML user interface enables faceted searching & browsing for your repository.
...
Watch the DSpace Discovery introduction video
Info |
---|
Since DSpace 3.0 Discovery is supported also in the JSP UI |
From the user perspective, faceted search (also called faceted navigation, guided navigation, or parametric search) breaks up search results into multiple categories, typically showing counts for each, and allows the user to "drill down" or further restrict their search results based on those facets.
...
config/modules/discovery.cfg
and config/spring/discovery/spring-dspace-addon-discovery-configuration-services.xml
...
Info |
---|
Starting from DSpace 3.0 discovery is supported also in JSP UI |
General improvements:
XML UI only:
As 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 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 = search, browse, eperson, harvester
event.dispatcher.default.consumers = 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 |
---|
./bin/dspace update-discovery-index
|
Panel |
---|
NOTE: This step may take some time if you have a large number of items in your repository. |
The configuration for discovery is located in 2 separate files.
...
...
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 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 = search, browse, eperson, harvester
event.dispatcher.default.consumers = search, browse, discovery, eperson, harvester
|
Note |
---|
As it is not possible in JSP UI to use both search provider (Lucene and Discovery) it is generally more appropriate, but not required, to remove the search consumer from the list. The browse consumer can be removed as well if you configure the Browse System to use SOLR DAOs (see Browse DAOs configuration) |
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 JSP UI instead of XML UI still rely on the Browse Engine to show Recent submission. The browse engine can be configurated to use SOLR DAOs |
Enable a JSON endpoint to provide autocomplete 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. |
The configuration for discovery is located in 2 separate files.
discovery.cfg
file located in the [dspace-install-dir]/config/modules directory
.discovery.xml
file is located in [dspace-install-dir]/config/spring/api/
directory.Note |
---|
Only for JSP UI some enabling configuration are placed in in the |
config/modules/discovery.cfg
)The discovery.cfg
file is located in the [dspace-install-dir]/config/modules
directory and contains following properties:
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 homonymous. 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 disable this feature can improve a lot 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 field (<schema>.<element>.<qualifier>) basis, the property without field set the default value. If the authority is a remote service disable this feature can improve a lot performance |
config/spring/api/discovery.xml
)The discovery.xml
file is located in the [dspace-install-dir]/config/spring/api
directory.
This file is in XML format, you should be familiar with XML before editing this file. The configurations are organized together in beans, depending on the purpose these properties are used for.
This purpose can be derived from the class of the beans. Here's a short summary of classes you will encounter throughout the file and what the corresponding properties in the bean are used for.
Download the configuration file and review it together with the following parameters
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 yet, 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:
Many of the properties contain lists that use references to point to the configuration elements. This way a certain configuration type can be used in multiple discovery configurations so there is no need to duplicate them.
This section explains the properties for search filters & sidebar facets. Each sidebar facet must occur in the reference list of the search filters. Below is an example configuration of a search filter that is not used as a sidebar facet.
Code Block | ||
---|---|---|
| ||
<bean id="searchFilterTitle" class="org.dspace.discovery.configuration.DiscoverySearchFilter">
<property name="indexFieldName" value="title"/>
<property name="metadataFields">
<list>
<value>dc.title</value>
</list>
</property>
</bean>
|
The id & class attributes are mandatory for this type of bean. The properties that it contains are discussed below.
Sidebar facets extend the search filter and add some extra properties to it, below is an example of a search filter that is also used as a sidebar facet.
Code Block | ||
---|---|---|
| ||
<bean id="searchFilterAuthor" class="org.dspace.discovery.configuration.SidebarFacetConfiguration">
<property name="indexFieldName" value="author"/>
<property name="metadataFields">
<list>
<value>dc.contributor.author</value>
<value>dc.creator</value>
</list>
</property>
<property name="facetLimit" value="10"/>
<property name="sortOrder" value="COUNT"/>
<property name="type" value="text"/>
</bean> |
Note that the class has changed from DiscoverySearchFilter to SidebarFacetConfiguration this is needed to support the extra properties.
Discovery supports specialized drill down in hierarchically structured metadata fields. For this drill down to work, the metadata in the field for which you enable this must be composed out of terms, divided by a splitter. For example, you could have a dc.subject.taxonomy field in which you keep metadata like "CARTOGRAPHY::PHOTOGRAMMETRY", in which Cartography and Photogrammetry are both terms, divided by the splitter "::". The sidebar will only display the top level facets, when clicking on view more all the facet options will be displayed.
Code Block | ||
---|---|---|
| ||
<bean id="searchFilterSubject" class="org.dspace.discovery.configuration.HierarchicalSidebarFacetConfiguration">
<property name="indexFieldName" value="subject"/>
<property name="metadataFields">
<list>
<value>dc.subject</value>
</list>
</property>
<property name="sortOrder" value="COUNT"/>
<property name="splitter" value="::"/>
<property name="skipFirstNodeLevel" value="false"/>
</bean>
|
Note that the class has changed from SidebarFacetConfiguration to HierarchicalSidebarFacetConfiguration this is needed to support the extra properties.
This section explains the properties of an individual SortConfiguration, like sortTitle and sortDateIssued from the default configuration. In order to create custom sort options, you can either modify specific properties of those that already exist or create a totally new one from scratch.
Here's what the sortTitle SortConfiguration looks like:
Code Block | ||
---|---|---|
| ||
<bean id="sortTitle" class="org.dspace.discovery.configuration.DiscoverySortFieldConfiguration">
<property name="metadataField" value="dc.title"/>
<property name="type" value="text"/>
</bean> |
The id & class attributes are mandatory for this type of bean. The properties that it contains are discussed below.
The DiscoveryConfiguration Groups configurations for sidebar facets, search filters, search sort options and recent submissions. If you want to show the same sidebar facets, use the same search filters, search options and recent submissions everywhere in your repository, you will only need one DiscoveryConfiguration and you might as well just edit the defaultConfiguration.
The DiscoveryConfiguration makes it very easy to use custom sidebar facets, search filters, ... on specific communities or collection homepage. This is particularly useful if your collections are heterogeneous. For example, in a collection with conference papers, you might want to offer a sidebar facet for conference date, which might be more relevant than the actual issued date of the proceedings. In a collection with papers, you might want to offer a facet for funding bodies or publisher, while these fields are irrelevant for items like learning objects.
A DiscoveryConfiguration consists out of five parts
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 |
---|
Each sidebar facet must also occur in the list of the search filters. |
Code Block | ||
---|---|---|
| ||
<property name="sidebarFacets">
<list>
<ref bean="sidebarFacetAuthor" />
<ref bean="sidebarFacetSubject" />
<ref bean="sidebarFacetDateIssued" />
</list>
</property> |
The search sort field configuration block contains the available sort fields and the possibility to configure a default sort field and sort order.
Below is an example of the sort configuration.
Code Block | ||
---|---|---|
| ||
<property name="searchSortConfiguration">
<bean class="org.dspace.discovery.configuration.DiscoverySortConfiguration">
<!--<property name="defaultSort" ref="sortDateIssued"/>-->
<!--DefaultSortOrder can either be desc or asc (desc is default)-->
<property name="defaultSortOrder" value="desc"/>
<property name="sortFields">
<list>
<ref bean="sortTitle" />
<ref bean="sortDateIssued" />
</list>
</property>
</bean>
</property> |
The property name & the bean class are mandatory. The property field names are discusses below.
Default filter queries are applied on all search operations & sidebarfacet clicks. One useful application of default filter queries is ensuring that all returned results are items. As a result, subcommunities and collections that are returned as results of the search operation, are filtered out.
Similar to the lists above, the default filter queries are defined as a list. They are optional.
Code Block | ||
---|---|---|
| ||
<property name="defaultFilterQueries">
<list>
<value>query1</value>
<value>query2</value>
</list>
</property> |
This property contains a simple list which in turn contains the queries. Some examples of possible queries:
The items returned by discovery are all the items the user logged in has access to. So the results may differ if you are logged in. This feature can be switched off it isn't requested by going to the [dspace.dir]/config/spring/api/discovery.xml file & commenting out the bean & the alias shown below.
Code Block | ||
---|---|---|
| ||
<bean class="org.dspace.discovery.SolrServiceResourceRestrictionPlugin" id="solrServiceResourceIndexPlugin"/>
<alias name="solrServiceResourceIndexPlugin" alias="org.dspace.discovery.SolrServiceResourceRestrictionPlugin"/> |
Warning |
---|
The browse system support the "Access item based" approach only with the SOLR DAOs implementation. If you need it be sure to enable it in the browse configuration |
The DSpaceObject class has an updateLastModified() method which will be triggered each time an authorization policy changes. This method is only implemented in the item class where the last_modified timestamp will be updated and a modify event will be fired. By doing this we ensure that the discovery consumer is called and the item is reindexed. Since this feature can be switched off a separate plugin has been created: the SolrServiceResourceRestrictionPlugin. Whenever we reindex a DSpace object all the read rights will be stored in the read field. We make a distinction between groups and users by adding a 'g' prefix for groups and the 'e' prefix for epersons.
When searching in discovery all the groups the user belongs to will be added as a filter query as well as the users identifier. If the user is an admin all items will be returned since an admin has read rights on everything.
Warning |
---|
This paragraph only apply to XML UI. JSP UI rely on the Browse Engine to show recent submission |
...
config/modules/discovery.cfg
)The discovery.cfg
file is located in the [dspace-install-dir]/config/modules
directory and contains following properties:
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. |
config/spring/spring-dspace-addon-discovery-configuration-services.xml
)The spring-dspace-addon-discovery-configuration-services.xml
file is located in the [dspace-install-dir]/config/spring
directory.
This file is in XML format, you should be familiar with XML before editing this file. The configurations are organized together in beans, depending on the purpose these properties are used for.
This purpose can be derived from the class of the beans. Here's a short summary of classes you will encounter throughout the file and what the corresponding properties in the bean are used for.
Download the configuration file and review it together with the following parameters
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 yet, 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:
Many of the properties contain lists that use references to point to the configuration elements. This way a certain configuration type can be used in multiple discovery configurations so there is no need to duplicate them.
This section explains the properties for search filters & sidebar facets. Each sidebar facet must occur in the reference list of the search filters. Below is an example configuration of a search filter that is not used as a sidebar facet.
Code Block | ||
---|---|---|
| ||
<bean id="searchFilterTitle" class="org.dspace.discovery.configuration.DiscoverySearchFilter">
<property name="indexFieldName" value="title"/>
<property name="metadataFields">
<list>
<value>dc.title</value>
</list>
</property>
</bean>
|
The id & class attributes are mandatory for this type of bean. The properties that it contains are discussed below.
Sidebar facets extend the search filter and add some extra properties to it, below is an example of a search filter that is also used as a sidebar facet.
Code Block | ||
---|---|---|
| ||
<bean id="searchFilterAuthor" class="org.dspace.discovery.configuration.SidebarFacetConfiguration">
<property name="indexFieldName" value="author"/>
<property name="metadataFields">
<list>
<value>dc.contributor.author</value>
<value>dc.creator</value>
</list>
</property>
<property name="facetLimit" value="10"/>
<property name="sortOrder" value="COUNT"/>
<property name="type" value="text"/>
</bean> |
Note that the class has changed from DiscoverySearchFilter to SidebarFacetConfiguration this is needed to support the extra properties.
Discovery supports specialized drill down in hierarchically structured metadata fields. For this drill down to work, the metadata in the field for which you enable this must be composed out of terms, divided by a splitter. For example, you could have a dc.subject.taxonomy field in which you keep metadata like "CARTOGRAPHY::PHOTOGRAMMETRY", in which Cartography and Photogrammetry are both terms, divided by the splitter "::". The sidebar will only display the top level facets, when clicking on view more all the facet options will be displayed.
Code Block | ||
---|---|---|
| ||
<bean id="searchFilterSubject" class="org.dspace.discovery.configuration.HierarchicalSidebarFacetConfiguration">
<property name="indexFieldName" value="subject"/>
<property name="metadataFields">
<list>
<value>dc.subject</value>
</list>
</property>
<property name="sortOrder" value="COUNT"/>
<property name="splitter" value="::"/>
<property name="skipFirstNodeLevel" value="false"/>
</bean>
|
Note that the class has changed from SidebarFacetConfiguration to HierarchicalSidebarFacetConfiguration this is needed to support the extra properties.
This section explains the properties of an individual SortConfiguration, like sortTitle and sortDateIssued from the default configuration. In order to create custom sort options, you can either modify specific properties of those that already exist or create a totally new one from scratch.
Here's what the sortTitle SortConfiguration looks like:
Code Block | ||
---|---|---|
| ||
<bean id="sortTitle" class="org.dspace.discovery.configuration.DiscoverySortFieldConfiguration">
<property name="metadataField" value="dc.title"/>
<property name="type" value="text"/>
</bean> |
The id & class attributes are mandatory for this type of bean. The properties that it contains are discussed below.
The DiscoveryConfiguration Groups configurations for sidebar facets, search filters, search sort options and recent submissions. If you want to show the same sidebar facets, use the same search filters, search options and recent submissions everywhere in your repository, you will only need one DiscoveryConfiguration and you might as well just edit the defaultConfiguration.
The DiscoveryConfiguration makes it very easy to use custom sidebar facets, search filters, ... on specific communities or collection homepage. This is particularly useful if your collections are heterogeneous. For example, in a collection with conference papers, you might want to offer a sidebar facet for conference date, which might be more relevant than the actual issued date of the proceedings. In a collection with papers, you might want to offer a facet for funding bodies or publisher, while these fields are irrelevant for items like learning objects.
A DiscoveryConfiguration consists out of five parts
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 |
---|
Each sidebar facet must also occur in the list of the search filters. |
Code Block | ||
---|---|---|
| ||
<property name="sidebarFacets">
<list>
<ref bean="sidebarFacetAuthor" />
<ref bean="sidebarFacetSubject" />
<ref bean="sidebarFacetDateIssued" />
</list>
</property> |
The search sort field configuration block contains the available sort fields and the possibility to configure a default sort field and sort order.
Below is an example of the sort configuration.
Code Block | ||
---|---|---|
| ||
<property name="searchSortConfiguration">
<bean class="org.dspace.discovery.configuration.DiscoverySortConfiguration">
<!--<property name="defaultSort" ref="sortDateIssued"/>-->
<!--DefaultSortOrder can either be desc or asc (desc is default)-->
<property name="defaultSortOrder" value="desc"/>
<property name="sortFields">
<list>
<ref bean="sortTitle" />
<ref bean="sortDateIssued" />
</list>
</property>
</bean>
</property> |
The property name & the bean class are mandatory. The property field names are discusses below.
Default filter queries are applied on all search operations & sidebarfacet clicks. One useful application of default filter queries is ensuring that all returned results are items. As a result, subcommunities and collections that are returned as results of the search operation, are filtered out.
Similar to the lists above, the default filter queries are defined as a list. They are optional.
Code Block | ||
---|---|---|
| ||
<property name="defaultFilterQueries">
<list>
<value>query1</value>
<value>query2</value>
</list>
</property> |
This property contains a simple list which in turn contains the queries. Some examples of possible queries:
...
The recent submissions configuration element contains all the configuration settings to display the list of recently submitted items on the home page or community/collection page. Because the recent submission configuration is in the discovery configuration block, it is possible to show 10 recently submitted items on the home page but 5 on the community/collection pages.
...
Warning |
---|
This paragraph only apply to XML UI. JSP UI doesn't support highlighting & search snippets at the moment |
The hit highlighting configuration element contains all the settings to display search snippets & enable hit highlighting.
...
Below is an example configuration of the hit highlighting.
Code Block | ||
---|---|---|
| ||
Code Block | ||
| ||
<property name="hitHighlightingConfiguration"> <bean class="org.dspace.discovery.configuration.DiscoveryHitHighlightingConfiguration"> <property name="metadataFieldshitHighlightingConfiguration"> <list> <bean class="org.dspace.discovery.configuration.DiscoveryHitHighlightFieldConfiguration"> <property name="field" value="dc.title"/> DiscoveryHitHighlightingConfiguration"> <property name="snippets" value="5"/metadataFields"> </bean><list> <bean class="org.dspace.discovery.configuration.DiscoveryHitHighlightFieldConfiguration"> <property name="field" value="dc.contributor.authortitle"/> <property name="snippets" value="5"/> </bean> <bean class="org.dspace.discovery.configuration.DiscoveryHitHighlightFieldConfiguration"> <property name="field" value="dc.contributor.subjectauthor"/> <property name="snippets" value="5"/> </bean> <bean class="org.dspace.discovery.configuration.DiscoveryHitHighlightFieldConfiguration"> <property name="field" value="dc.description.abstractsubject"/> <property name="maxSize" value="250"/> <property name="snippets" value="25"/> </bean> <bean class="org.dspace.discovery.configuration.DiscoveryHitHighlightFieldConfiguration"> <property name="field" value="fulltextdc.description.abstract"/> <property name="maxSize" value="250"/> <property name="snippets" value="2"/> </bean> </list> </property> </bean> </property> |
The property name & the bean class are mandatory. The property field names are:
*
if all the metadata fields should be highlighted)....
<bean class="org.dspace.discovery. |
...
configuration.DiscoveryHitHighlightFieldConfiguration">
<property name="field" value="fulltext"/>
<property name="maxSize" value="250"/>
<property name="snippets" value="2"/>
</bean>
</list>
</property>
</bean>
</property> |
The property name & the bean class are mandatory. The property field names are:
*
if all the metadata fields should be highlighted).The org.dspace.discovery.DiscoveryQuery object has a setter & getter for the hit highlighting configuration configured in the discovery configuration. If this configuration is given the resolveToSolrQuery method located in the org.dspace.discovery.SolrServiceImpl class will use the standard solr highlighting feature (http://wiki.apache.org/solr/HighlightingParameters). The org.dspace.discovery.DiscoverResult class has a method to set the highlighted fields for each object & field.
The rendering of search results is no longer handled by the mets format but uses a special type of list named "TYPE_DSO_LIST". Each metadata field (& fulltext if configured) is added in the DRI and IF the field contains hit higlighting the java code will split up the string & add DRI highlights to the list. The xsl for the themes also contains special rendering xsl for the DRI, for Mirage the changes have been located in the discovery.xsl file. For themes using the old structural.xsl look for the template matching "dri:list[@type='dsolist']".
Warning |
---|
This paragraph only apply to XML UI. JSP UI doesn't support the More like this feature at the moment |
The 'more like this'-configuration element contains all the settings for displaying the 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 accross 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> |
The property name & the bean class are mandatory. The property field names are discusses below.
The org.dspace.discovery.SearchService object has received a getRelatedItems() method. This method requires an item & the more-like-this configuration bean from above. This method is implemented in the org.dspace.discovery.SolrServiceImpl which uses the item as a query & uses the default Solr parameters for more-like-this to pass the bean configuration to solr (http://wiki.apache.org/solr/MoreLikeThis). The result will be a list of items or if none found an empty list. The rendering of this list is handled in the org.dspace.app.xmlui.aspect.discovery.RelatedItems class
The rendering of search results is no longer handled by the mets format but uses a special type of list named "TYPE_DSO_LIST". Each metadata field (& fulltext if configured) is added in the DRI and IF the field contains hit higlighting the java code will split up the string & add DRI highlights to the list. The xsl for the themes also contains special rendering xsl for the DRI, for Mirage the changes have been located in the discovery.xsl file. For themes using the old structural.xsl look for the template matching "dri:list[@type='dsolist']".
The 'more like this'-configuration element contains all the settings for displaying the 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 accross 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> |
The property name & the bean class are mandatory. The property field names are discusses below.
The org.dspace.discovery.SearchService object has received a getRelatedItems() method. This method requires an item & the more-like-this configuration bean from above. This method is implemented in the org.dspace.discovery.SolrServiceImpl which uses the item as a query & uses the default Solr parameters for more-like-this to pass the bean configuration to solr (http://wiki.apache.org/solr/MoreLikeThis). The result will be a list of items or if none found an empty list. The rendering of this list is handled in the org.dspace.app.xmlui.aspect.discovery.RelatedItems class.
The items returned by discovery are all the items the user logged in has access to. So the results may differ if you are logged in. This feature can be switched off it isn't requested by going to the [dspace.dir]/config/spring/discovery/spring-dspace-addon-discovery-solr-plugin-services.xml file & commenting out the bean & the alias shown below.
Code Block | ||
---|---|---|
| ||
<bean class="org.dspace.discovery.SolrServiceResourceRestrictionPlugin" id="solrServiceResourceIndexPlugin"/>
<alias name="solrServiceResourceIndexPlugin" alias="org.dspace.discovery.SolrServiceResourceRestrictionPlugin"/> |
The DSpaceObject class has an updateLastModified() method which will be triggered each time an authorization policy changes. This method is only implemented in the item class where the last_modified timestamp will be updated and a modify event will be fired. By doing this we ensure that the discovery consumer is called and the item is reindexed. Since this feature can be switched off a separate plugin has been created: the SolrServiceResourceRestrictionPlugin. Whenever we reindex a DSpace object all the read rights will be stored in the read field. We make a distinction between groups and users by adding a 'g' prefix for groups and the 'e' prefix for epersons.
When searching in discovery all the groups the user belongs to will be added as a filter query as well as the users identifier. If the user is an admin all items will be returned since an admin has read rights on everything.
...
Discovery is built as an application layer on top of the Open Source Enterprise Search Server SOLR. Therefor, 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".
Code Block |
---|
solr
├── search
│ ├── conf
│ │ ├── admin-extra.html
│ │ ├── elevate.xml
│ │ ├── protwords.txt
│ │ ├── schema.xml
│ │ ├── scripts.conf
│ │ ├── solrconfig.xml
│ │ ├── spellings.txt
│ │ ├── stopwords.txt
│ │ ├── synonyms.txt
│ │ └── xslt
│ │ ├── DRI.xsl
│ │ ├── example.xsl
│ │ ├── example_atom.xsl
│ │ ├── example_rss.xsl
│ │ └── luke.xsl
│ └── conf2
├── solr.xml
└── statistics
└── conf
├── admin-extra.html
├── elevate.xml
├── protwords.txt
├── schema.xml
├── scripts.conf
├── solrconfig.xml
├── spellings.txt
├── stopwords.txt
├── synonyms.txt
└── xslt
├── example.xsl
├── example_atom.xsl
├── example_rss.xsl
└── luke.xsl
|