The document summarizes work done as part of the CLIF (Content Lifecycle Integration Framework) project to integrate the Fedora digital repository with content management systems like Sakai and SharePoint. It discusses how content can flow between these systems as part of the digital content lifecycle. The project developed technology integrations between Fedora and Sakai/SharePoint as examples of how a repository can support lifecycle management across systems. It evaluates these integrations and concludes that diverse systems can be effectively integrated to allow cross-system lifecycle management if standard interfaces and content structures are used.

1. Enabling the digital content lifecycle: content flow between Sakai and Fedora Chris Awre Library and Learning Innovation EuroSakai Amsterdam, 27th September 2011 1

2. CLIF Project CLIF - Content Lifecycle Integration Framework Funded by JISC 01 July 2009 – 31 March 2011 Project partners University of Hull King’s College London Centre for e-Research (CeRch) 2

4. In particular, REMAP explored how a repository could support records management and digital preservation as part of a lifecycle management approach for digital content

5. Previous work had sought to push the repository upstream in the workflow

6. Dilemma was that the repository risked becoming another content silo alongside other content management systems on campus (in our case, Sakai and SharePoint)

7. How can the repository become more integrated in the institutional environment?3

9. Adopted at University of Hull in 2005

10. Live institutional repository since 2008

11. Developed and managed through DuraSpace

12. Strong community model, akin to Sakai

13. Features we like (the advert!)

14. Powerful digital object model

15. Extensible metadata management

16. Expressive inter-object relationships

17. Version management

18. Configurable security architecture4

20. Digital content is only going to grow

21. Standards-based (open standards where possible)

22. To provide a future-proof exit strategy

23. Content agnosticism

24. We don’t know what types of content may come along

25. Content semantics

26. Recording the relationships between different pieces of content supports future use and preservation 5

28. Other repository options were not actively considered

29. Following on from work looking at integration of DSpace and Sakai through CTREP project

30. Aimed to achieve the same end goal of seamless integration for Fedora

31. Regardless of the system, it is important to understand what you are trying to achieve in the management of content through integration

32. Repository choice driven by external factors of how repository management is carried out6

34. Aimed to increase repository usage through integration within the LMS, using Sakai as the platform

35. Cambridge examined integration with DSpace

36. University of Highlands & Islands (UHI) examined integration with Fedora

37. Work focused on use of Sakai ContentHostingHandler

38. DSpace work successful, albeit that information being sent between the two was limited

39. Fedora work halted as it became clear that the version of Sakai CHH at the time was not able to deal with rich Fedora objects

40. Re-visiting this has been possible through Sakai developments

41. We are grateful to CTREP for pioneering this approach7

42. Lifecycle Lifecycle management within a repository 8 Can this be enabled across systems?

43. Lifecycle integration 9 Sakai SharePoint Repository Content flows between systems according to need in lifecycle

45. Some imaginative ways used for how content from here is used by other tools within the system

46. Content is also shared between sites, and staff are encouraged to make their content shareable

47. Focus of content management is to support use within Sakai

48. Focus is on Sakai, not the content

49. A content silo?

50. How could integration with a content store – a repository – enhance how Sakai manages and uses content?10

52. Recognising that individual systems cannot always support the whole lifecycle from creation to preservation or deletion

53. Specifically investigate the role of repositories in the digital content lifecycle

54. Where is the repository best positioned within the lifecycle?

55. What roles can digital repositories play?

56. Understand how content will flow in and out of a repository as part of the lifecycle

57. CLIF has been agnostic about this11

59. Based on interviews with staff at partner institutions

60. Academic staff (Head of Department / Senior Lecturer)

61. Records Manager

62. Research active staff

63. Interviews highlighted that staff were managing as best they could within single systems they were familiar with

64. Potential to exploit additional functionality in other systems welcomed12

66. Capturing data produced through experimental equipment and archiving this for use in future work in the repository

67. Preparation of research outputs and archiving of these for dissemination

68. Teaching

69. Teaching materials accessed from within a repository to inform current courses

70. Exam papers created in one system and archived for future reference in the repository (marks could be archived for private access as well)

71. Administration

72. Committee papers circulated to committee members before a meeting are moved to the repository for wider access post-meeting13

74. Technology integrations as exemplars of how a repository can support lifecycle management across systems

75. Fedora – Sakai integration

76. Fedora – SharePoint integration

77. Software available on GitHub

78. Technical appendix to final report describing architecture and implementation 14

79. A digital content lifecycle 15 There are many variations and versions of lifecycle models - another is not required Each has a number of stages CLIF sought to capture use cases that encompassed a number of these stages and tested how they could be managed across systems © Digital Curation Centre

81. Work was focused within a system or was more architecture-based without addressing specific systems

82. Possibly due to flux in technology development

83. Terminology is key to addressing lifecycle management

84. There are many different lifecycles (knowledge, digitisation, metadata, etc.) that may overlap

85. Can be easier to break down the lifecycle into stages, many of which are common16

87. cf. the use of the Hydra digital object approach

88. Policy is as important as technology in determining how different systems are used to manage a lifecycle

89. Digital preservation can be greatly supported if considered at the beginning of the lifecycle (as REMAP found)

90. There is a need to identify how people and roles fit into an overall lifecycle

91. It may be valuable to record information about the lifecycle itself as content moves, but this has resource implications

92. cf. the use of PREMIS events metadata recording what happens to an object17

93. System overview 18

95. Fedora v3.4

96. Extends and enhances the JISC CTREP Fedora ContentHostingHandlerplugin

97. CHH is a pluggable provider model for hosting content

98. Content displayed in standard Sakai Resources Tool

99. Enabled and Configured by uploading a mountpoint.properties text file

100. Resources Tree view shows a ‘live view’ of a specific Fedora collection

101. ‘Show other sites’ allows files and/or nested folders to be copied/moved between MyWorkspace site and Fedora mounted site19

102. .properties configuration file 20

103. Sakai to Fedora 21

104. Or… 22 Resources Tool CHS API BaseContentService DBContentService ContentHostingHandlerResolverImpl ContentHostingHandlerImplFedora

106. Sakai holds files

107. Fedora holds objects made up of a collection of datastreams, one of which is the file (others will contain metadata)

108. In linking Sakai and Fedora, three considerations needs to be addressed

110. Retrieving a file from Fedora for use in Sakai requires use of the search capability within Fedora23

112. Due to use of HTTPS

113. Switching to HTTP improved performance and allowed easier debugging

114. Other performance improvements enabled included,

115. Caching of resources and folder objects

116. Minimising web service calls by sing one call to retrieve multiple properties

117. No pre-fetching of datastreams

118. The CHH code is over-complicated at times

119. Impact of changes at high level can be extensive lower down24

121. The majority of menu functions work in the same manner as with standard resources, e.g., upload, copy, paste, move, delete, create

122. This applies to folders as well as individual objects

123. Folders represent collection objects in the repository

124. Metadata can be captured in Sakai for use in Fedora (though Sakai is not able to re-use this when retrieving an object from Fedora)

125. User can browse Fedora collection (though not yet search)

126. User does not need to know they are working with the repository25

128. Common approach to structuring digital objects is required

129. Systems interacting with Fedora can build objects using this common approach

130. CLIF adopted the approach developed through the Hydra project

131. http://projecthydra.org/26

134. Copy/move to/from Repository 28 Copy & move folders/files between Fedora and MyWorkspace is easy ! Copy…

135. Copy/move to/from Repository …paste! 29

136. It looks easy, but… © 2008 Richard Green … you don’t see what is going on underneath! 30

138. Some of the commands under the Edit functionality have no current effect on the object in Fedora

139. The metadata captured is minimal, and Sakai cannot make use of metadata added within Fedora

140. Folders with large numbers of resources have a noticeable impact on performance when browsing or carrying out actions upon them31

142. There needs to be clarity over why different systems are being used, to overcome concerns about having to work with multiple systems

143. There is a need for better preservation and a recognition that integrating the repository could support this, but also a need to be clear about what needs preserving

144. There is benefit in being able to access other content stores from within your current working environment in order to see what is available more broadly32

146. Having access to resources that could be used within Sakai was a valuable addition to being able to browse resources inside Sakai

147. Providing access to resources in context was considered very important, hence, linking to the files in the repository instead of copying them across may be preferred

148. Why create a copy if access is OK where the content is?

149. Reference or irregular content was considered to fit best into the model of access via repository

150. Bulk movement likely to be more useful than object by object movement33

152. This tallies with findings in CLIF

153. Focus on use of APIs where available

154. Institutional repository systems are not so good at this

155. A challenge for these systems

156. Capturing annotations alongside original content would enhance archival records

157. Exporting multiple resources, as IMS CP or other, also a route for managing content across systems34

159. Better adoption of interface standards would be helpful

160. Standardisation in the structure of the content being moved maximises how the content can be managed by the different systems

161. Where the repository is one of the systems involved its current primary role appears to be as a recipient of content (for preservation)

162. Perception that content in the repository can be used there without moving it into the other integrated systems 35

163. Demo 36 Copyright © copyright-free-photos.org.uk

164. Thank you Chris Awre – c.awre@hull.ac.uk Richard Green – r.green@hull.ac.uk Andrew Thompson – andrew.thompson@hull.ac.uk Simon Waddington – simon.waddington@kcl.ac.uk Project website - http://www2.hull.ac.uk/discover/clif.aspx Project GitHub - https://github.com/uohull/clif-sharepoint and https://github.com/uohull/clif-sakai Project final report - http://edocs.hull.ac.uk/splash.jsp?parentId=hull:1647%26pid=hull:4194 37