We will use the dspace.cfg as our example for input conventions used through out the system. It is a basic Java properties file, where lines are either comments, starting with a '#', blank lines, or property/value pairs of the form:

property.name = property value

Some property defaults are "commented out". That is, they have a "#" proceeding them, and the DSpace software ignores the config property. This may cause the feature not to be enabled, or, cause a default property to be used when the software is compiled and updated.

The property value may contain references to other configuration properties, in the form ${property.name}. This follows the ant convention of allowing references in property files. A property may not refer to itself. Examples:

property.name = word1 ${other.property.name} more words
property2.name = ${dspace.dir}/rest/of/path

	Property values can include other, previously defined values, by enclosing the property name in ${...}. For example, if your dspace.cfg contains: dspace.dir = /dspace dspace.history = ${dspace.dir}/history Then the value of dspace.history property is expanded to be /dspace/history. This method is especially useful for handling commonly used file paths.

It is important to rememeber that there are two dspace.cfg files after an installation of DSpace.

The runtime file is supposed to be the copy of the source file, which is considered the master version. However, the DSpace server and command programs only look at the runtime configuration file, so when you are revising your configuration values, it is tempting to only edit the runtime file. DO NOT do this. Always make the same changes to the source version of dspace.cfg in addition to the runtime file. The two files should always be identical, since the source dspace.cfg will be the basis of your next upgrade.

To keep the two files in synchronization, you can edit your files in [dspace-source]/dspace/config/ and then you would run the following commands:

cd /[dspace-source]/dspace/target/dspace-<version>-build.dir
ant update_configs

This will copy the source dspace.cfg (along with other configuration files) into the runtime (/[dspace]/config) directory.

	You should remember that after editing your configuration file(s), and you are done and wish to implement the changes, you will need to:

Below is a brief "Properties" table for the dspace.cfg file and the documented details are referenced. Please refer to those sections for the complete details of the parameter

dspace.dir
dspace.url
dspace.baseUrl
dspace.oai.url
dspace.hostname
dspace.name

db.name
db.url
db.driver
db.username
db.password

db.schema
db.maxconnection
db.maxwait
db.maxidle
db.statementpool
db.poolname

mail.server
mail.server.username
mail.server.password
mail.server.port
mail.from.address
feedback.recipient
mail.admin
alert.recipient
registration.notify
mail.charset
mail.allowed.referrers
mail.extraproperties
mail.server.disabled

assetstore.dir
[assetstore.dir.1
assetstore.dir.2
assetstore.incoming]

srb.hosts.1
srb.port.1
srb.mcatzone.1
srb.mdasdomainname.1
srb.defaultstorageresource.1
srb.username.1
srb.password.1
srb.homedirectory.1
srb.parentdir.1

handle.prefix
handle.dir

core.authorization.community-admin.create-subelement
core.authorization.community-admin.delete-subelement
core.authorization.community-admin.policies
core.authorization.community-admin.admin-group
core.authorization.community-admin.collection.policies
core.authorization.community-admin.collection.template-item
core.authorization.community-admin.collection.submitters
core.authorization.community-admin.collection.workflows
core.authorization.community-admin.collection.admin-group
core.authorization.community-admin.item.delete
core.authorization.community-admin.item.withdraw
core.authorization.community-admin.item.reinstatiate
core.authorization.community-admin.item.policies
core.authorization.community-admin.item.create-bitstream
core.authorization.community-admin.item.delete-bitstream
core.authorization.community-admin.item-admin.cc-license
core.authorization.collection-admin.policies
core.authorization.collection-admin.template-item
core.authorization.collection-admin.submitters
core.authorization.collection-admin.workflows
core.authorization.collection-admin.admin-group
core.authorization.collection-admin.item.delete
core.authorization.collection-admin.item.withdraw
core.authorization.collection-admin.item.reinstatiate
core.authorization.collection-admin.item.policies
core.authorization.collection-admin.item.create-bitstream
core.authorization.collection-admin.item.delete-bitstream
core.authorization.collection-admin.item-admin.cc-license
core.authorization.item-admin.policies
core.authorization.item-admin.create-bitstream
core.authorization.item-admin.delete-bitstream
core.authorization.item-admin.cc-license

plugin.sequence.org.dspace.authenticate.AuthenticationMethod

ldap.enable
ldap.provider_url
ldap.id_field
ldap.object_context
ldap.search_context
ldap.email_field
ldap.surname_field
ldap.givenname_field
ldap.phone_field
webui.ldap.autoregister
ldap.login.specialgroup

ldap.search_scope
ldap.search.user
ldap.netid_email_domain

authentication.shib.email-header
authentication.shib.firstname-header
authentication.shib.lastname-header
authentication.shib.email-use-tomcat-remote-user
authentication.shib.autoregister
authentication.shib.role-header
authentication.shib.default-roles

search.dir
search.max-clauses
search.analyzer
search.operator
search.maxfieldlengthsearch.index.n

http.proxy.host
http.proxy.port

plugin.named.org.dspace.app.mediafilter.FormatFilter
     filter.org.dspace.app.mediafilter.PDFFilter.inputFormats
     filter.org.dspace.app.mediafilter.HTMLFilter.inputFormats
     filter.org.dspace.app.mediafilter.WordFilter.inputFormats
     filter.org.dspace.app.mediafilter.JPEGFilter.inputFormats
  filter.org.dspace.app.mediafilter.BrandedPreviewJPEGFilter.inputFormats

pdffilter.largepdfs
pdffilter.skiponmemoryexception

crosswalk.mods.properties.MODS
crosswalk.submission.MODS.stylesheet
crosswalk.qdc.namespace.QDC.dc
crosswalk.qdc.namespace.QDC.dcterms
crosswalk.qdc.schemaLocation.QDC
plugin.named.org.dspace.content.crosswalk.IngestionCrosswalk
plugin.named.org.dspace.content.crosswalk.DisseminationCrosswalk

event.dispatcher.default.class
event.dispatcher.default.consumers
event.dispatcher.noindex.class
event.dispatcher.noindex.consumers
event.consumer.search.class
event.consumer.search.filters
event.consumer.browse.class
event.consumer.browse.filters
event.consumer.eperson.class
event.consumer.eperson.filters
event.consumer.test.class
event.consumer.test.filters
testConsumer.verbose

plugin.single.org.dspace.checker.BitsreamDispatcher
checker.retention.default
checker.retention.CHECKSUM-MATCH

org.dspace.app.itemexport.work.dir
org.dspace.app.itemexport.download.dir
org.dspace.app.itemexport.life.span.hours
org.dspace.app.itemexport.max.size

bulkedit.valueseparator
bulkedit.fieldseparator
bulkedit.gui-item-limit
bulkedit.ignore-on-export

webui.browse.thumbnail.max.height
webui.browse.thumbnail.max.width

thumbnail.maxwidth
thumbnail.maxheight

webui.preview.maxwidth
webui.preview.maxheight

webui.preview.brand
webui.preview.brand.abbrev

webui.preview.brand.font
webui.preview.brank.fontpoint

webui.strengths.show
webui.strengths.cache

webui.browse.value_columns.max
webui.browse.sort_columns.max
webui.browse.value_columns.omission_mark
plugin.named.org.dspace.sort.OrderFormatDelegate

recent.submission.sort-option
recent.submissions.count

webui.feed.enable
webui.feed.items
webui.feed.cache.size 
webui.cache.age
webui.feed.formats
webui.feed.localresolve
webui.feed.item.title
webui.feed.item.date
webui.feed.item.description

webui.content_disposition_threshold
xmlui.content_disposition_threshold

webui.html.max-depth-guess
xmlui.html.max-depth-guess

webui.suggest.enable
webui.suggest.loggedinusers.only

webui.licence_bundle.show
webui.itemdisplay.default
webui.resolver.1.urn
webui.resolver.1.baseurl
webui.resolver.2.urn
webui.resolver.2.baseurl
plugin.single.org.dspace.app.webui.util.StyleSelection
webui.itemdisplay.thesis.collections
webui.itemdisplay.metadata-style
webui.itemlist.column
webui.itemlist.width
webui.itemlist.browse.<index name>.sort.<sort name>.columns
webui.itemlist.sort<sort name>.columns
webui.itemlist.browse.<browse name>.columns
webui.itemlist.*lt;sort or index name>.columns
webui.itemlist.dateaccessioned.columns
webui.itemlist.dateaccessioned.widths
webui.itemlist.tablewidth

xmlui.supported.locales
xmlui.force.ssl
xmlui.user.registration
xmlui.user.assumelogon
xmlui.user.logindirect
xmlui.theme.allowoverrides
xmlui.bundle.upload
xmlui.community-list.render.full
xmlui.community-list.cache
xmlui.bitstream.mods
xmlui.bitstream.mets
xmlui.google.analytics.key
xmlui.controlpanel.activity.max
xmlui.controlpanel.activity.ipheader

Many of the database configurations are software-dependent. That is, it will be based on the choice of database software being used. Documentation is below shows PostgreSQL and Oracle examples.

The configuration of email is simple and provides a mechanism to alert the person(s) responsible for different features of the DSpace software.

mail.server.username
mail.server.password

mail.server.username = myusername
mypassword

mail.extraproperties = mail.smtp.socketFactory.port=465, \
	                   mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory, \
	                   mail.smtp.socketFactory.fallback=false

This is the default "technique" that is used by DSpace to store the bitstreams. DSpace can also use SRB (Storage Resource Brokerage) as an alternative. See section 5.2.6 for details regarding SRB.

assetstore.dir.1
assetstore.dir.2

assetstore.dir.1 = /second/assetstore
assetstore.dir.2 = /third/assetstore

	In the examples above, you can see that your storage does not have to be under the /dspace directory. For the default installation it needs to reside on the same server (unless you plan to configure SRB (cf. below)). So, if you added storage space to your server, and it has a different logical volume/name/directory, you could have the following as an example:

Please Note: When adding additional storage configuration, you will then need to uncomment and declare assestore.incoming = 1

An alternate to using the default storage framework is to use Storage Resource Brokerage (SRB). This can provide a different level of storage and disaster recovery. (Storage can take place on storage that is off-site.) Refer to http://www.sdsc.edu/srb/index.php/Main_Page for complete details regarding SRB.

The same framework is used to configure SRB storage. That is, the asset store number (0..n) can reference a file system directory as above or it can reference a set of SRB account parameters. But any particular asset store number can reference one or the other but not both. This way traditional and SRB storage can both be used but with different asset store numbers. The same cautions mentioned above apply to SRB asset stores as well. The particular asset store a bitstream is stored in is held in the database, so don't move bitstreams between asset stores, and do not renumber them.

srb.homedirectory.1 = /mysrbzone/home/mysrbuser.mysrbdomain
 

The 'assetstore.incoming' property is an integer that references where new bitstreams will be stored. The default (say the starting reference) is zero. The value will be used to identify the storage where all new bitstreams will be stored until this number is changed. This number is stored in the Bitstream table (store_number column) in the DSpace database, so older bitstreams that may have been stored when 'asset.incoming' had a different value can be found.

In the simple case in which DSpace uses local (or mounted) storage the number can refer to different directories (or partitions). This gives DSpace some level of scalability. The number links to another set of properties 'assetstore.dir', 'assetstore.dir.1' (remember zero is default), assetstore.dir.2', etc., where the values are directories.

To support the use of SRB DSpace uses the same scheme but broaden to support:

in this broadened use of the 'asset.incoming' integer will refer to one of the following storage locations:

Should the be any conflict, like '2' referring to a local directory and to a set of SRB parameters, the program will select the local directory.

If SRB is chosen from the first install of DSpace, it is suggested that 'assetstore.dir' (no integer appended) be retained to reference a local directory (as above under File Storage) because build.xml uses this value to do a mkdir. In this case, 'assetstore.incoming' can be set to 1 (i.e. uncomment the line in File Storage above) and the 'assetstore.dir' will not be used.

For complete information regarding the Handle server, the user should consult 3.3.4. The Handle Server section of Installing DSpace.

Since many institutions and organizations have existing authentication systems, DSpace has been designed to allow these to be easily integrated into an existing authentication infrastructure. It keeps a series, or "stack", of authentication methods, so each one can be tried in turn. This makes it easy to add new authentication methods or rearrange the order without changing any existing code. You can also share authentication code with other sites.

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \ 
          org.dspace.authenticate.PasswordAuthentication

The configuration property plugin.sequence.org.dspace.authenticate.AuthenticationMethod defines the authentication stack. It is a comma-separated list of class names. Each of these classes implements a different authentication method, or way of determining the identity of the user. They are invoked in the order specified until one succeeds.

An authentication method is a class that implements the interface org.dspace.authenticate.AuthenticationMethod. It authenticates a user by evaluating the credentials (e.g. username and password) he or she presents and checking that they are valid.

The basic authentication procedure in the DSpace Web UI is this:

Please see the source files AuthenticationManager.java and AuthenticationMethod.java for more details about this mechanism.

 plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
                              org.dspace.authenticate.IPAuthentication 

 authentication.ip.MY_UNIVERSITY = 10.1.2.3, \            # Full IP
                                   13.5, \                # Partial IP
                                   11.3.4.5/24, \         # with CIDR
                                   12.7.8.9/255.255.128.0 # with netmask
 

                plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
                     org.dspace.authenticate.LDAPAuthentication
                          

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
       org.dspace.authenticate.LDAPHierarchicalAuthentication

object scope : 0
one level scope : 1
subtree scope : 2

ldap.search.user
ldap.search.password

ldap.search.user = cn=admin,ou=people,o=myu.edu
ldap.search.password = password

Detailed instructions for installing Shibboleth on DSpace may be found athttps://mams.melcoe.mq.edu.au/zope/mams/pub/Installation/dspace15.

DSpace requires email as the user's credentials. There are two ways of providing email to DSpace:

The first option takes Precedence when specified. both options can be enabled to allow for fallback.

authentication.shib.role-header
authentication.shib-role.header.ignore-scope

authentication.shib.role-header = Shib-EP-ScopedAffiliation
authentication.shib-role.header.ignore-scope = true

authentication.shib.role-header = Shib-EP-UnscopedAffiliation
 authentication.shib-role.header.ignore-scope = false

authentication.shib.role.Senior\ Researcher
authentication.shib.role.Librarian

authentication.shib.role.Senior\ Researcher = Researcher, Staff
authentication.shib.role.Librarian = Administrator

The following settings are currently not used by XMLUI. XMLUI writes its logs to [dspace-xmlui]/WEB-INF-logs/ in the actual XMLUI web application.

log.init.config = ${dspace.dir}/config/log4j.xml
log.init.config = ${dspace.dir}/config/log4j-console.properties

Search indexes can be configured and customized easily in the dspace.cfg file. This allows institutions to choose which DSpace metadata fields are indexed by Lucene.

search.analyzer = \
     org.apache.lucene.analysis.cn.ChineseAnalyzer

For example, the following entries appear in the default DSpace installation:

search.index.1 = author:dc.contributor.*
search.index.2 = author:dc.creator.*
search.index.3 = title:dc.title.*
search.index.4 = keyword:dc.subject.*
search.index.5 = abstract:dc.description.abstract
search.index.6 = author:dc.description.statementofresponsibility
search.index.7 = series:dc.relation.ispartofseries
search.index.8 = abstract:dc.description.tableofcontents
search.index.9 = mime:dc.format.mimetype
search.index.10 = sponsor:dc.description.sponsorship
search.index.11 = id:dc.identifier.*
search.index.11 = language:dc.language.iso

The format of each entry is search.index.<id> = <search label> : <schema> . <metadata field> where:

In the example above, search.index.1 and search.index.2 and search.index.3 are configured as the author search field. The author index is created by Lucene indexing all dc.contributor.*, dc.creator.* and description.statementofresponsibility metadata fields.

After changing the configuration run /[dspace]/bin/index-init to regenerate the indexes.

	While the indexes are created, this only affects the search results and has no effect on the search components of the user interface. One will need to customize the user interface to reflect the changes, for example, to add the a new search category to the Advanced Search.

In the above examples, notice the asterisk (*). The metadata field (at least for Dublin Core) is made up of the "element" and the "qualifier". The asterisk is used as the "wildcard". So, for example, keyword.dc.subject.* will index all subjects regardless if the term resides in a qualified field. (subject versus subject.lcsh). One could customize the search and only index LCSH (Library of Congress Subject Headings) with the following entry keyword:dc.subject.lcsh instead of keyword:dc.subject.*

These settings for proxy are commented out by default. Uncomment and specify both properties if proxy server is required for external http requests. Use regular host name without port number.

Media or Format Filters are classes used to generate derivative or alternative versions of content or bitstreams within DSpace. For example, the PDF Media Filter will extract textual content from PDF bitstreams, the JPEG Media Filter can create thumbnails from image bitstreams.

Media Filters are configured as Named Plugins, with each filter also having a separate configuration setting (in dspace.cfg) indicating which formats it can process. The default configuration is shown below.

filter.plugins = PDF Text Extractor, Html Text Extractor, \
                         Word Text Extractor, JPEG Thumbnail

Word Text Extractor, JPEG Thumbnail,\
     Branded Preview JPEG

plugin.named.org.dspace.app.mediafilter.FormatFilter = \
         org.dspace.app.mediafilter.PDFFilter = PDF Text Extractor, \
         org.dspace.app.mediafilter.HTMLFilter = HTML Text Extractor, \
         org.dspace.app.mediafilter.WordFilter = Word Text Extractor, \
         org.dspace.app.mediafilter.JPEGFilter = JPEG Thumbnail, \
         org.dspace.app.mediafilter.BrandedPreviewJPEGFilter = Branded Preview JPEG

filter.org.dspace.app.mediafilter.PDFFilter.inputFormats
filter.org.dspace.app.mediafilter.HTMLFilter.inputFormats
filter.org.dspace.app.mediafilter.WordFilter.inputFormats
filter.org.dspace.app.mediafilter.JPEGFilter.inputFormats
filter.org.dspace.app.mediafilter.BrandedPreviewJPEGFilter.inputFormats

filter.org.dspace.app.mediafilter.PDFFilter.inputFormats = Adobe PDF
filter.org.dspace.app.mediafilter.HTMLFilter.inputFormats = HTML, Text
filter.org.dspace.app.mediafilter.WordFilter.inputFormats = Microsoft Word
filter.org.dspace.app.mediafilter.JPEGFilter.inputFormats = BMP, GIF, JPEG, \ 
                                                            image/png
filter.org.dspace.app.mediafilter.BrandedPreviewJPEGFilter.inputFormats = BMP, \
                                                   GIF, JPEG, image/png

Names are assigned to each filter using the plugin.named.org.dspace.app.mediafilter.FormatFilter field (e.g. by default the PDFilter is named "PDF Text Extractor".

Finally, the appropriate filter.<class path>.inputFormats defines the valid input formats which each filter can be applied. These format names must match the short description field of the Bitstream Format Registry.

You can also implement more dynamic or configurable Media/Format Filters which extend SelfNamedPlugin

The MODS crosswalk is a self-named plugin. To configure an instance of the MODS crosswalk, add a property to the DSpace configuration starting with "crosswalk.mods.properties."; the final word of the property name becomes the plugin's name. For example, a property name crosswalk.mods.properties.MODS defines a crosswalk plugin named "MODS".

The value of this property is a path to a separate properties file containing the configuration for this crosswalk. The pathname is relative to the DSpace configuration directory, i.e. the config subdirectory of the DSpace install directory. Example from the dspace.cfgfile:

crosswalk.mods.properties.MODS
crosswalk.mods.properties.mods

crosswalk.mods.properties.MODS = crosswalks/mods.properties
crosswalk.mods.properties.mods = crosswalks/mods.properties

The MODS crosswalk properties file is a list of properties describing how DSpace metadata elements are to be turned into elements of the MODS XML output document. The property name is a concatenation of the metadata schema, element name, and optionally the qualifier. For example, the contributor.author element in the native Dublin Core schema would be: dc.contributor.author. The value of the property is a line containing two segments separated by the vertical bar ("|"): The first part is an XML fragment which is copied into the output document. The second is an XPath expression describing where in that fragment to put the value of the metadata element. For example, in this property:

dc.contributor.author = <mods:name><mods:role><mods:roleTerm
	                    type="text">author</mods:roleTerm>
                        </mods:role><mods:namePart>%s</mods:;
                        <mods:namePart>%s</mods:namePart></mods:name> |
                        mods:namePart/text() 

Some of the examples include the string "%s" in the prototype XML where the text value is to be inserted, but don't pay any attention to it, it is an artifact that the crosswalk ignores. For example, given an author named Jack Florey, the crosswalk will insert

<mods:name>
   <mods:role>
     <mods:roleTerm type="text">author</mods:roleTerm>
   </mods:role>
   <mods:namePart>  Jack Florey</mods:namePart>
</mods:name>

into the output document. Read the example configuration file for more details.

The XSLT crosswalks use XSL stylesheet transformation (XSLT) to transform an XML-based external metadata format to or from DSpace's internal metadata. XSLT crosswalks are much more powerful and flexible than the configurable MODS and QDC crosswalks, but they demand some esoteric knowledge (XSL stylesheets). Given that, you can create all the crosswalks you need just by adding stylesheets and configuration lines, without touching any of the Java code.

The default settings in the dspace.cfg file for submission crosswalk:

As shown above, there are three (3) parts that make up the properties "key":

     crosswalk.submissionPluginName.stylesheet =
          1        2        3               4 

Here is an example that configures a crosswalk named "LOM" using a stylesheet in [dspace]/config/crosswalks/d-lom.xsl:

 crosswalk.submission.LOM.stylesheet = crosswalks/d-lom.xsl

A dissemination crosswalk can be configured by starting with the property key crosswalk.dissemination. Example:

     crosswalk.dissemination.PluginName.stylesheet = path

The PluginName is the name of the plugin (!). The path value is the path to the file containing the crosswalk stylesheet (relative to /[dspace]/config).

You can make two different plugin names point to the same crosswalk, by adding two configuration entries with the same path:

     crosswalk.submission.MyFormat.stylesheet = crosswalks/myformat.xslt
     crosswalk.submission.almost_DC.stylesheet = crosswalks/myformat.xslt

The dissemination crosswalk must also be configured with an XML Namespace (including prefix and URI) and an XML schema for its output format. This is configured on additional properties in the DSpace configuration:

     crosswalk.dissemination.PluginName.namespace.Prefix = namespace-URI
     crosswalk.dissemination.PluginName.schemaLocation = schemaLocation value 

For example:

     crosswalk.dissemination.qdc.namespace.dc = http://purl.org/dc/elements/1.1/
     crosswalk.dissemination.qdc.namespace.dcterms = http://purl.org/dc/terms/
     crosswalk.dissemination.qdc.schemalocation = http://purl.org/dc/elements/1.1/ \
     http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.xsd

[dspace]/bin/dsrun
     org.dspace.content.crosswalk.XSLTIngestionCrosswalk [-l] plugin input-file

The QDC crosswalk is a self-named plugin. To configure an instance of the QDC crosswalk, add a property to the DSpace configuration starting with "crosswalk.qdc.properties."; the final word of the property name becomes the plugin's name. For example, a property name crosswalk.qdc.properties.QDC defines a crosswalk plugin named "QDC".

The following is from dspace.cfg file:

crosswalk.qdc.schemaLocation.QDC = http://www.purl.org/dc/terms \
      http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd \
      http://purl.org/dc/elements/1.1 \
      http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd

In the property key "crosswalk.qdc.properties.QDC" the value of this property is a path to a separate properties file containing the configuration for this crosswalk. The pathname is relative to the DSpace configuration directory /[dspace]/config . Referring back to the "Example Value" for this property key, one has crosswalks/qdc.properties which defines a crosswalk named QDC whose configuration comes from the file [dspace]/config/crosswalks/qdc.properties.

You will also need to configure the namespaces and schema location strings for the XML output generated by this crosswalk. The namespaces properties names are formatted:

crosswalk.qdc.namespace.prefix = uri

where prefix is the namespace prefix and uri is the namespace URI. See the above Property and Example Value keys as the default dspace.cfg has been configured.

The QDC crosswalk properties file is a list of properties describing how DSpace metadata elements are to be turned into elements of the Qualified DC XML output document. The property name is a concatenation of the metadata schema, element name, and optionally the qualifier. For example, the contributor.author element in the native Dublin Core schema would be: dc.contributor.author. The value of the property is an XML fragment, the element whose value will be set to the value of the metadata field in the property key.

For example, in this property:

     dc.coverage.temporal = <dcterms:temporal />

the generated XML in the output document would look like, e.g.:

     <dcterms:temporal>Fall, 2005</dcterms:temporal>

Ingestion crosswalk plugins are configured as named or self-named plugins for the interface org.dspace.content.crosswalk.IngestionCrosswalk. Dissemination crosswalk plugins are configured as named or self-named plugins for the interface org.dspace.content.crosswalk.DisseminationCrosswalk.

You can add names for existing crosswalks, add new plugin classes, and add new configurations for the configurable crosswalks as noted below.

Package ingester plugins are configured as named or self-named plugins for the interface org.dspace.content.packager.PackageIngester. Package disseminator plugins are configured as named or self-named plugins for the interface org.dspace.content.packager.PackageDisseminator.

You can add names for the existing plugins, and add new plugins, by altering these configuration properties. See the Plugin Manager architecture for more information about plugins.

DSpace now comes with a Checksum Checker script ([dspace]/bin/checker) which can be scheduled to verify the checksum of every item within DSpace. Since DSpace calculates and records the checksum of every file submitted to it, this script is able to determine whether or not a file has been changed (either manually or by some sort of corruption or virus). The idea being that the earlier you can identify a file has changed, the more likely you'd be able to recover it (assuming it was not a wanted change).

It is possible for an authorized user to request a complete export and download of a DSpace item in a compressed zip file. This zip file may contain the following:

The configuration settings control several aspects of this feature:

DSpace, through some advanced installation and setup, is able to send out an email to collections that a user has subscribed. The user who is subscribed to a collection is emailed each time an item id added or modified. The following property key controls whether or not a user should be notified of a modification.

These settings control two aspects of the submission process: thesis submission permission and whether or not a bitstream file is required when submitting to a collection.

This enables the Creative Commons license step in the submission process of the JSP User Interface (JSPUI). Submitters are given an opportunity to select a Creative Common license to accompany the item. Creative Commons license govern the use of the content. For further details, refer to the Creative Commons website at http://creativecommons.org .

In this section of Configuration, we address the agnostic WEB User Interface that is used for JSP UI and XML UI. Some of the configurations will give information towards customization or refer you to the appropriate documentation.

webui.browse.thumbnail.maxheight
webui.browse.thumbnail.maxwidth

webui.browse.thumbnail.maxheight = 80
webui.browse.thumbnail.maxwidth = 80

thumbnail.maxwidth
thumbnail.maxheight

thumbnail.maxwidth 80
thumbnail.maxheight 80

webui.preview.maxwidth
webui.preview.maxheight

webui.preview.maxwidth = 600
webui.preview.maxheight = 600

webui.preview.brand.font
webui.preview.brand.fontpoint

webui.preview.brand.font = SanSerif
webui.preview.brand.fontpoint = 12

The browse indexes for DSpace can be extensively configured. This section of the configuration allows you to take control of the indexes you wish to browse, and how you wish to present the results. The configuration is broken into several parts: defining the indexes, defining the fields upon which users can sort results, defining truncation for potentially long fields (e.g. authors), setting cross-links between different browse contexts (e.g. from an author's name to a complete list of their items), how many recent submissions to display, and configuration for item mapping browse.

webui.browse.index.1 = dateissued:metadata:dc.date.issued:date:full
webui.browse.index.2 = author:metadata:dc.contributor.*:text
webui.browse.index.3 = title:metadata:dc.title:title:full
webui.browse.index.4 = subject:metadata:dc.subject.*:text
#webui.browse.index.5 = dateaccessioned:item:dateaccessioned

     browse.type.<index name>

webui.itemlist.sort-option.1 = title:dc.title:title
webui.itemlist.sort-option.2 = dateissued:dc.date.issued:date
webui.itemlist.sort-option.3 = dateaccessioned:dc.date.accessioned:date

plugin.named.org.dspace.sort.OrderFormatDelegate = \
org.dspace.sort.OrderFormatTitleMarc21=title

author = org.dspace.sort.OrderFormatAuthor
title  = org.dspace.sort.OrderFormatTitle
text   = org.dspace.sort.OrderFormatText

	This section actually applies to any field with multiple values, but authors are the define case and example here.

Replace dc.contributor.* with another field if appropriate. The field should be listed in the configuration for webui.itemlist.columns, otherwise you will not see its effect. It must also be defined in webui.itemlist.columns as being of the datatype text otherwise the functionality will be overridden by the specific data type feature. (This setting is not used by the XMLUI as it is controlled by your theme).

Now that we know which field is our author or other multiple metadata value field we can provide the option to truncate the number of values displayed by default. We replace the remaining list of values with "et al" or the language pack specific alternative. Note that this is just for the default, and users will have the option of changing the number displayed when they browse the results. See the following table:

We can define which fields link to other browse listings. This is useful, for example, to link an author's name to a list of just that author's items. The effect this has is to create links to browse views for the item clicked on. If it is a "single" type, it will link to a view of all the items which share that metadata element in common (i.e. all the papers by a single author). If it is a "full" type, it will link to a view of the standard full browse page, starting with the value of the link clicked on.

The format of the property key is webui.browse.link.<n> = <index name>:<display column metadata> Please notice the punctuation used between the elements.

Examples of some browse links used in a real DSpace installation instance:

This allows us to define which index to base Recent Submission display on, and how many we should show at any one time. This uses the PluginManager to automatically load the relevant plugin for the Community and Collection home pages. Values given in examples are the defaults supplied in dspace.cfg

There will be the need to set up the processors that the PluginManager will load to actually perform the recent submissions query on the relevant pages. This is already configured by default dspace.cfg so there should be no need for the administrator/programmer to worry about this.

plugin.sequence.org.dspace.plugin.CommunityHomeProcessor = \
        org.dspace.app.webui.components.RecentCommunitySubmissions

plugin.sequence.org.dspace.plugin.CollectionHomeProcessor = \
        org.dspace.app.webui.components.RecentCollectionSubmissions

This will enable syndication feeds—links display on community and collection home pages. This setting is not used by the XMLUI, as you enable feeds in your theme.

webui.feed.item.title
webui.feed.item.date

webui.feed.item.title = dc.title
webui.feed.item.date = dc.date.issued

webui.feed.item.description = dc.title, dc.contributor.author, \
           dc.contributor.editor, dc.description.abstract, \
           dc.description

webui.feed.item.dc.creator
webui.feed.item.dc.date
webui.feed.item.dc.description
						

webui.feed.item.dc.creator = dc.contributor.author
webui.feed.item.dc.date = dc.date.issued
webui.feed.item.dc.description = dc.description.abstract

The following configuration is used to change the disposition behavior of the browser. That is, when the browser will attempt to open the file or download it to the user's specified location. For example, the default size is 8Mb. When an item being viewed is larger than 8MB, the browser will download the file to the desktop (or wherever you have it set to download) and the user will have to open it manually.

Other values are possible:

The setting is used to configure the "depth" of request for html documents bearing the same name.

webui.html.max-depth-guess
xmlui.html.max-depth-guess

webui.html.max-depth-guess = 3
xmlui.html.max-depth-guess = 3

To aid web crawlers index the content within your repository, you can make use of sitemaps.

The following section is limited to JSPUI. If the user wishes to use XMLUI settings, please refer to Chapter 7: XMLUI Configuration and Customization.

webui.itemdisplay.default = dc.title, dc.title.alternative, \
           dc.contributor.*, dc.subject, dc.data.issued(date), \
           dc.publisher, dc.identifier.citation, \
           dc.relation.ispartofseries, dc.description.abstract, \
           dc.description, dc.identifier.govdoc, \
           dc.identifier.uri(link), dc.identifier.isbn, \
           dc.identifier.issn, dc.identifier.ismn, dc.identifier

metadata.dc.contributor.other       = Authors
metadata.dc.contributor.author      = Authors
metadata.dc.title.*                 = Title

webui.resolver.1.urn
webui.resolver.1.baseurl
webui.resolver.2.urn
webui.resolver.2.baseurl

webui.resolver.1.urn = doi
webui.resolver.1.baseurl = http://dx.doi.org/
webui.resolver.2.urn = hdl
webui.resolver.2.baseurl = http://hdl.handle.net/

plugin.single.org.dspace.app.webui.util.StyleSelection = \
  org.dspace.app.web.util.CollectionStyleSelection
  #org.dspace.app.web.util.MetadataStyleSelection

webui.itemdisplay.metadata-style
webui.itemdisplay.metadata-syle

webui.itemdisplay.metadata-style = schema.element[.qualifier|.*]
webui.itemdisplay.metadata-syle = dc.type

webui.itemlist.columns = thumbnail, dc.date.issued(date), dc.title, \
          dc.contributor.*

webui.itemlist.browse.<index name>.sort.<sort name>.columns
webui.itemlist.sort.<sort name>.columns
webui.itemlist.browse.<browse name>.columns
webui.itemlist.<sort or index name>.columns

Because the item mapper requires a primitive implementation of the browse system to be present, we simply need to tell that system which of our indexes defines the author browse (or equivalent) so that the mapper can list authors' items for mapping

Define the index name (from webui.browse.index) to use for displaying items by author.

SFX Server is an OpenURL Resolver.

DSpace now supports controlled vocabularies to confine the set of keywords that users can use while describing items.

The need for a limited set of keywords is important since it eliminates the ambiguity of a free description system, consequently simplifying the task of finding specific items of information.

The controlled vocabulary add-on allows the user to choose from a defined set of keywords organized in an tree (taxonomy) and then use these keywords to describe items while they are being submitted.

We have also developed a small search engine that displays the classification tree (or taxonomy) allowing the user to select the branches that best describe the information that he/she seeks.

The taxonomies are described in XML following this (very simple) structure:

<node id="acmccs98" label="ACMCCS98">
    <isComposedBy> 
        <node id="A." label="General Literature">
            <isComposedBy>
                <node id="A.0" label="GENERAL"/>
                <node id="A.1" label="INTRODUCTORY AND SURVEY"/>
            </isComposedBy>
        </node>
    </isComposedBy>
</node>

Your are free to use any application you want to create your controlled vocabularies. A simple text editor should be enough for small projects. Bigger projects will require more complex tools. You may use Protegé to create your taxonomies, save them as OWL and then use a XML Stylesheet (XSLT) to transform your documents to the appropriate format. Future enhancements to this add-on should make it compatible with standard schemas such as OWL or RDF.

In order to make DSpace compatible with WAI 2.0, the add-on is turned off by default (the add-on relies strongly on Javascript to function). It can be activated by setting the following property in dspace.cfg:

webui.controlledvocabulary.enable = true

New vocabularies should be placed in [dspace]/config/controlled-vocabularies/ and must be according to the structure described. A validation XML Schema can be downloaded here.

Vocabularies need to be associated with the correspondent DC metadata fields. Edit the file [dspace]/config/input-forms.xml and place a "vocabulary" tag under the "field" element that you want to control. Set value of the "vocabulary" element to the name of the file that contains the vocabulary, leaving out the extension (the add-on will only load files with extension "*.xml"). For example:

<field>
    <dc-schema>dc</dc-schema>
    <dc-element>subject</dc-element>
    <dc-qualifier></dc-qualifier>
    <!-- An input-type of twobox MUST be marked as repeatable -->
    <repeatable>true</repeatable>
    <label>Subject Keywords</label>
    <input-type>twobox</input-type>
    <hint> Enter appropriate subject keywords or phrases below. </hint>
    <required></required>
    <vocabulary [closed="false"]>nsi</vocabulary>
</field>

The vocabulary element has an optional boolean attribute closed that can be used to force input only with the javascript of controlled-vocabulary add-on. The default behavior (i.e. without this attribute) is as set closed="false". This allow the user also to enter the value in free way.

The following vocabularies are currently available by default:

The DSpace digital repository supports two user interfaces: one based upon JSP technologies and the other based upon the Apache Cocoon framework. This section describes those configurations settings which are specific to the XMLUI interface based upon the Cocoon framework. (Prior to DSpace Release 1.5.1 XMLUI was referred to Manakin. You may still see references to "Manakin")

In the following sections, you will learn how to configure OAI-PMH and activate additional OAI-PMH crosswalks. The user is also referred to 9.2OAI-PMH Data Provider for greater depth details of the program.

The following configurations allow the adminstrator extract from the DSpace database a set of records for editing by a metadata export. It provides an easier way of editing large collections.

bulkedit.fieldseparator = tab

bulkedit.ignore-on-export = dc.date.accessioned, \
                            dc.date.available, \
                            dc.date.updated, dc.description.provenance

It is now possible to hide metadata from public consumption that is only avaialable to the Administrator.

The [dspace]/config/registries directory contains three XML files. These are used to load the initial contents of the Dublin Core Metadata registry and Bitstream Format registry and SWORD metadata registry. After the initial loading (performed by ant fresh_install above), the registries reside in the database; the XML files are not updated.

In order to change the registries, you may adjust the XML files before the first installation of DSpace. On an already running instance it is recommended to change bitstream registries via DSpace admin UI, but the metadata registries can be loaded again at any time from the XML files without difficult. The changes made via admin UI are not reflected in the XML files.

[dspace]/bin/dsrun org.dspace.administer.MetadataImporter -f [xml file]

<dspace-dc-types>
    <dc-type>
        <schema>dc</schema>
        <element>contributor</element>
        <qualifier>advisor</qualifier>
        <scope_note>Use primarily for thesis advisor.</scope_note>
    </dc-type>
</dspace-dc-types>

These filters handle PDF resources with more sophisticated tools that can produce thumbnail images of PDF and 3D PDF files, and do much faster (and more complete) text extraction as well.

5.3.2.3. Installation within DSpace

The user will be using Java™ Advanced Imaging Image I/O Tools.

	For AIX, Sun support has the following: "JAI has native acceleration for the above but it also works in pure Java mode. So as long as you have an appropriate JDK for AIX (1.3 or later, I believe), you should be able to use it. You can download any of them, extract just the jars, and put those in your $CLASSPATH."

Fetch and install jai_imageio JAR

Download the jai_imageio library version 1.0_01 or 1.1 found athttps://jai-imageio.dev.java.net/binary-builds.html#Stable_builds .

Install it in your local Maven repository with the command (assuming the library is installed locally at /opt/facade/lib/jai_imageio.jar):

        mvn install:install-file  \
         -Dfile=/opt/facade/lib/jai_imageio.jar               \
         -DgroupId=com.sun.media                              \
         -DartifactId=jai_imageio                             \
         -Dversion=1.0_01                                     \
         -Dpackaging=jar                                      \
         -DgeneratePom=true
	

Edit DSpace Configuration

First, be sure there is a value for thumbnail.maxwidth and that it corresponds to the size you want for preview images for the UI, e.g.: (NOTE: this code doesn't pay any attention to thumbnail.maxheight but it's best to set it too so the other thumbnail filters make square images.)

        # maximum width and height of generated thumbnails
        thumbnail.maxwidth  300
        thumbnail.maxheight 300
        

Now, add the absolute paths of the XPDF tools you installed:

        xpdf.path.pdftotext = /var/local/bin/pdftotext
        xpdf.path.pdftoppm = /var/local/bin/pdftoppm
        xpdf.path.pdfinfo = /var/local/bin/pdfinfo
	

Also be sure the mediafilter configuration includes the new filters, e.g: (New sections are in bold)

        filter.plugins = \
         PDF Text Extractor, \
         PDF Thumbnail, \
         HTML Text Extractor, \
         Word Text Extractor, \
         JPEG Thumbnail
         plugin.named.org.dspace.app.mediafilter.FormatFilter = \
         org.dspace.app.mediafilter.XPDF2Text = PDF Text Extractor, \
         org.dspace.app.mediafilter.XPDF2Thumbnail = PDF Thumbnail, \
         org.dspace.app.mediafilter.HTMLFilter = HTML Text Extractor, \
         org.dspace.app.mediafilter.WordFilter = Word Text Extractor, \
         org.dspace.app.mediafilter.JPEGFilter = JPEG Thumbnail, \
         org.dspace.app.mediafilter.BrandedPreviewJPEGFilter = Branded Preview JPEG
	

#Configure each filter's input format(s)

          filter.org.dspace.app.mediafilter.XPDF2Thumbnail.inputFormats = Adobe PDF
          filter.org.dspace.app.mediafilter.XPDF2Text.inputFormats = Adobe PDF
          Add -Pxpdf-mediafilter-support to maven build
        

Edit the POM for the dspace-api module. Within the <dependencies> element, add this new element:

	%mvn -Pxpdf-mediafilter-support package
	

Build and Install

Follow the usual DSpace installation/update procedure (mvn package and then ant -Dconfig=etc. ...)

These instructions were retrieved from "http://libstaff.mit.edu/facade/index.php/DSpace_PDF_Media_Filters"

To ease the hassle of keeping configuration files for other applications involved in running a DSpace site, for example Apache, in sync, the DSpace system can automatically update them for you when the main DSpace configuration is changed. This feature of the DSpace system is entirely optional, but we found it useful.

The way this is done is by placing the configuration files for those applications in [dspace]/config/templates, and inserting special values in the configuration file that will be filled out with appropriate DSpace configuration properties. Then, tell DSpace where to put filled-out, 'live' version of the configuration by adding an appropriate property to dspace.cfg, and run [dspace]/bin/install-configs.

Take the apache13.conf file as an example. This contains plenty of Apache-specific stuff, but where it uses a value that should be kept in sync across DSpace and associated applications, a 'placeholder' value is written. For example, the host name:

ServerName @@dspace.hostname@@

The text @@dspace.hostname@@ will be filled out with the value of the dspace.hostname property in dspace.cfg. Then we decide where we want the 'live' version, that is, the version actually read in by Apache when it starts up, will go.

Let's say we want the live version to be located at /opt/apache/conf/dspace-httpd.conf. To do this, we add the following property to dspace.cfg so DSpace knows where to put it:

config.template.apache13.conf = /opt/apache/conf/dspace-httpd.conf

Now, we run [dspace]/bin/install-configs. This reads in [dspace]/config/templates/apache13.conf, and places a copy at /opt/apache/conf/dspace-httpd.conf with the placeholders filled out.

So, in /opt/apache/conf/dspace-httpd.conf, there will be a line like:

ServerName dspace.myu.edu

The advantage of this approach is that if a property like the hostname changes, you can just change it in dspace.cfg and run install-configs, and all of your tools' configuration files will be updated.

However, take care to make all your edits to the versions in [dspace]/config/templates! It's a wise idea to put a big reminder at the top of each file, since someone might unwittingly edit a 'live' configuration file which would later be overwritten.

A usage instrumentation plugin is configured as a singleton plugin for the abstract class org.dspace.app.statistics.AbstractUsageEvent.

SWORD (Simple Web-service Offering Repository Deposit) is a protocol that allows the remote deposit of items into repositories. DSpace implements the SWORD protocol via the 'sword' web application. The version of SWORD currently supported by DSpace is 1.3. The specification and further information can be downloaded fromhttp://swordapp.org.

SWORD is based on the Atom Publish Protocol and allows service documents to be requested which describe the structure of the repository, and packages to be deposited.

                        plugin.named.org.dspace.content.packager.PackageIngester

sword.accept-packaging.METSDSpaceSIP.identifier
sword.accept-packaging.METSDSpaceSIP.q

sword.accept-packaging.METSDSpaceSIP.identifier = http://purl.org/net/sword-types/METSDSpaceSIP
sword.accept-packaging.METSDSpaceSIP.q = 1.0

sword.accept-packaging.[handle].METSDSpaceSIP.identifier
sword.accept-packaging.[handle].METSDSpaceSIP.q

sword.accept-packaging.[handle].METSDSpaceSIP.identifier = http://purl.org/net/sword-types/METSDSpaceSIP
sword.accept-packaging.[handle].METSDSpaceSIP.q = 1.0

plugin.named.org.dspace.sword.SWORDingester

plugin.named.org.dspace.sword.SWORDIngester = \
  org.dspace.sword.SWORDMETSIngester = http://purl.org/net/sword-types/METSDSpaceSIP \
  org.dspace.sword.SimpleFileIngester = SimpleFileIngester

OpenSearch is a small set of conventions and documents for describing and using "serach enginges", meaning any service that returns a set of results for a query. See extensive description in the Business Layer section of the documentation.

Please note that for result data formatting, OpenSearch uses Syndication Feed Settings (RSS). So, even if Syndication Feeds are not enable, they must be configured to enable OpenSearch. OpenSearch uses all the configuration properties for DSpace RSS to determine the mapping of metadata fields to feed fields. Note that a new field for authors has been added (used in Atom format only).

It is possible now to configure a DSpace instance to have an "Embargo" feature uses for thesis and dissertations.

Remember that you need to replace SCHEMA.ELEMENT.QUALIFIER with a real metadata field. Additionally, you need to replace the CLASSNAME with a properly impleented plugin.