...
Architectural Comparison Between DSpace 1.x REST/Fedora and DSpace 2.x REST/Fedora
Recommendations:
For the DSpace Storage Service and Semantic Storage Projects, a recommendation that the DSpace Storage Service be re-factored.
MRD: I would propose that we need to continue to clean up the Storage Services API. I recommend two alterations to the API as a means to better mediate the separation between a DSpace Storage Entity as an "Identifier" and its Storage Properties as attributes that may be stored in one or more storage systems. This means that a couple things need to happen int he existing Storage API
- That "StoragePropertyDSPACE" parameters should be dropped fromt he StorageEntity object all together.
- That "StorageProperty service methods for performing CRUD operations on Storage properties be maintained on a separate mixin interface.
- That StorageRelation be removed from the object model and relations be captured only by attaching StorageEntities as "values" of StorageProperties.
Links to Projects:
- GSOC10 - Backport of DSpace 2 Storage Services API for DSpace 1.x: I for DSpace 1.x: DSpace 2.0 storage mechanism provides convenient way to store DSpace contents in various storage solutions. It is based on set of interfaces for which various implementations are possible and some beta releases already exist (Jackrabbit, Fedora, etc). DSpace 2.0 is in its early stages of development and DSpace 1.x releases yet can not take advantage of this new mechanism. To fix this, it is necessary to port DSpace 2.0 storage interfaces to 1.x. I propose implementing this backport. – Andrius Blažinskas
- GSOC10 - DSpace REST API: Integration, testing, documentation and further development of DSpace REST services for 1.x and 2.0 versions. - Bojan Suzic
- GSOC10 - Storage Service Implementations Based on Semantic Content Repository: Develop DSpace storage service implementations based on semantic content repositories (TripleStore). - Yigang Zhou