2. Module objectives By the end of this module you will: Know about the EasyDeposit SWORD client creation toolkit Have seen some example configurations of EasyDeposit Understand how to construct a custom SWORD client Have had the opportunity to construct your own custom EasyDeposit SWORD client
3. Background to EasyDeposit Created at the University of Auckland Library Digital Development and Media Services team Already created several custom SWORD clients Thesis deposit Computer Science technical report archive Wanted an easy way to create more clients
4. EasyDeposit Benefits Written in PHP (a skill often found in general web teams rather than specialised repository development teams) Web-based (user + admin) Stand-alone (doesn’t require extra systems such as a database) Comes with more than 20 ‘steps’ out-of-the-box Open-source: you are free to modify or extend it
6. Anatomy of EasyDeposit Home page Customisable Deposit screens Made up of a series of ‘steps’ Steps can be added or removed Steps can be configured Extra steps can be added Look and feel Customisable CSS / header / footer
7. Steps Different types of step Login (must come first) Repository credentials Repository related Data collection Verification Deposit Post-processing
8. Visible / Invisible steps Some steps are visible: Collect metadata Upload files Verify inputs Some steps are invisible: Deposit
9. Login steps Must come first Sets the user ID (used to store uploaded files on disk, and optionally for deposit credentials) Different options: LDAP login – allows local credentials to be used Service Document login – checks username and password with the repository No login – Used when you want anonymous deposit
10. Repository credentials Must set repository credentials Repository username / password / on-behalf-of Use users’ credentials Deposit performed as that user Use single set of credentials Minimises number of user accounts in the repository if users only deposit a few items (e.g. theses)
11. Repository related steps Allow user to interact with the Service Document Select from collections they are allowed to deposit to Only useful if they understand the choice Select a repository to use from a pre-defined list or enter a Service Document URL Too complex for most users
12. Data collection steps Collect metadata Allow files to be uploaded Can have automated steps E.g.: Crossref DOI lookup
13. Verification step Allows user to verify their submission Allows the user to return to the step to edit the details if required
14. Deposit step Performs the deposit Usually also performs the packaging An invisible step Multiple repository deposit step to deposit to multiple repositories
15. Post-processing steps Performs tasks after the deposit has taken place Examples: Email confirmation to the user Thank you message with the URL of the deposited item Email sent to administrator to alert them
16. An example Deposit a journal article with a DOI Steps: Nologin Crossrefdoilookup Crossrefdoimetadata Uploadfiles Verify Deposit Thankyou
17. Another example Deposit of a PhD thesis Steps: Ldaplogin Title Uploadfiles UOACreativecommonsembargo Verify Deposit Email Thankyou
18. The administrative interface Protected with a username and password Edit and configure the steps Edit the welcome screen Edit the commons header, footer, and CSS Set some global settings
22. Extending EasyDeposit Based on CodeIgniter MVC-based architecture Create a controller and a view Look at the current controllers and views to see how they work Feel free to contribute them back to the project
23. Conclusion If you have any questions or suggestions about EasyDeposit, please get in touch! stuart@stuartlewis.com
24. Credits This course has been produced by: Stuart Lewis The SWORD project http://swordapp.org/ Funded by JISC http://www.jisc.ac.uk/ Licence Creative commons