I just recently completed a presentation on the work @mire has done to backport DSpace Services to the 1.6.0 release that is planned for release sometime before the end of the year. As I haven't received any request for the slides, I've placed them on slide-share.
While one always cringes at viewing oneself in video, I'll post the video stream as well for those that are interested in working with the dspace services framework.
User Group Meeting Site: http://dsug09.ub.gu.se/index.php/dsug/dsug09
Crowdvine: http://dsug09.crowdvine.com/
Video Streaming: http://bambuser.com/channel/dsug09
Dsug09 Services
View more presentations from Mark Diggory.
While one always cringes at viewing oneself in video, I'll post the video stream as well for those that are interested in working with the dspace services framework.
User Group Meeting Site: http://dsug09.ub.gu.se/index.php/dsug/dsug09
Crowdvine: http://dsug09.crowdvine.com/
Video Streaming: http://bambuser.com/channel/dsug09
Michele Kimpton recently aggregated together this years Open Repositories DSpace User Group Presentations into one post for the community. These were posted on the Georgia Tech OR09 presentation website. Below is a reposting of those presentations. Congratulations to all the presenters on a fine conference.
May 20th, 2009
Session One
DuraSpace - Michele Kimpton and Sandy Payette
http://presentations.dlpe.
Session Two
DSpace Technology Overview - Bradley McLean
Repository Software Technical Update with Chris Wilper - Chris Wilper
http://presentations.dlpe.
Session Three
2.0 Demonstration - Ben Bosman
http://presentations.dlpe.
Session Four
XMLUI Modularity in DSpace 1.5 & 2.0 - Mark Diggory
DSpace 1.5 Modifications: A Technical Overview - Elliot Metsger
DSpace 2 Service Manager Framework - Aaron Zeckoski
http://presentations.dlpe.
Session Five
Designing and Implementing a Learning Object Repository - William E Moen
Using DSpace as a Disciplinary Data Repository - Ryan Scherle
Introducing Vireo - ETD Submittal and Management for DSpace - Adam
Mikeal, Scott Phillips, John Leggett, Mark McFarland
The Sustainability, Preservation, Accessibility of Internal and
External Communities by Universities - Jeffrey Trimble and Salvador
Barragan
http://presentations.dlpe.
May 21st, 2009
Session One
Depth Customization of DSpace - S.K. Vijaianand and V.D. Shrivastava
http://presentations.dlpe.
EIAH's Experience in Localization and Customization of DSpace - Emad
Khazraee, Saeed Moaddeli and Hamed Malek
http://presentations.dlpe.
The Myth of Federated Searching - OhioLINK Digital Resoursce Commons
Team
http://presentations.dlpe.
Session Two
Making DSpace 1.5 Your Own: Customizing Via Overlays - Tim Donohue
http://presentations.dlpe.
DSpace Global Outreach Committee Update - Valorie Hollister
http://presentations.dlpe.
May 20th, 2009
Session One
DuraSpace - Michele Kimpton and Sandy Payette
http://presentations.dlpe.
Session Two
DSpace Technology Overview - Bradley McLean
Repository Software Technical Update with Chris Wilper - Chris Wilper
http://presentations.dlpe.
Session Three
2.0 Demonstration - Ben Bosman
http://presentations.dlpe.
Session Four
XMLUI Modularity in DSpace 1.5 & 2.0 - Mark Diggory
DSpace 1.5 Modifications: A Technical Overview - Elliot Metsger
DSpace 2 Service Manager Framework - Aaron Zeckoski
http://presentations.dlpe.
Session Five
Designing and Implementing a Learning Object Repository - William E Moen
Using DSpace as a Disciplinary Data Repository - Ryan Scherle
Introducing Vireo - ETD Submittal and Management for DSpace - Adam
Mikeal, Scott Phillips, John Leggett, Mark McFarland
The Sustainability, Preservation, Accessibility of Internal and
External Communities by Universities - Jeffrey Trimble and Salvador
Barragan
http://presentations.dlpe.
May 21st, 2009
Session One
Depth Customization of DSpace - S.K. Vijaianand and V.D. Shrivastava
http://presentations.dlpe.
EIAH's Experience in Localization and Customization of DSpace - Emad
Khazraee, Saeed Moaddeli and Hamed Malek
http://presentations.dlpe.
The Myth of Federated Searching - OhioLINK Digital Resoursce Commons
Team
http://presentations.dlpe.
Session Two
Making DSpace 1.5 Your Own: Customizing Via Overlays - Tim Donohue
http://presentations.dlpe.
DSpace Global Outreach Committee Update - Valorie Hollister
http://presentations.dlpe.
This last weeks OR09 meeting unleashed a number of new epiphanies around DSpace 2.0. I feel these realizations should lead us to the next step in way we represent entities like DSpace Items.
One of these ideas has to do with the recognition that an Item is actually a "View" or a "Join" of properties from separate functional areas such as "content", "history", "policy", and "presentation". Here are a few examples of those areas.
1.) Content: An underlying store in DSpace might be JCR, Fedora, DSpace, and s3. Each of these maintain a separate model expressing content their domain. Fedora (Fedora Objects and Datastreams), JCR (JCR Nodes, JCR Properties, JCR References), DSpace (Collections, Communities, Items, Bundles, Bitstreams, etc).
2.) History: Each of these above storage systems presents Versioning, History or Provenance differently in its above ER (Entity Relationship) model. While the Content domain may provide a representation of that versioning history, there is still the requirement of a separate service layered (or not layered) on top of that to work with the at Versioning model.
3.) Policy: Certainly each of these expresses a set of policy information, which is generally managed in a separate service or layer on top of the Entities expressed therein.
4.) Presentation: Once you have these expressed, external tools will seek to have varying "expressions" of the previous 3 areas that are specific to a particular domain/tool (HTML, AJAX/Web 2.0, OAI-PMH, LOD, ATOM/APP) Some of these various communities seek to constrain what out of the previous 3 areas can be expressed within their transmissions.
I feel that being at the nexus of all these functional domains, DSpace 2.0 has an opportunity to be something very powerful. If we can recognize that the "presentation" of any DSpace 2.0 Entity is a JOIN of the data from each of these areas, and that we have different "Services" responsible for expressing, accessing and persisting that "domain specific" data, then its clear that for any one entity in the DSpace model that we actually have N possible domain specific representations of an Entity expressed.
Content: Content in an underlying stores model on a per Entity basis.
History: Provenance, Versioning, and Change History Trail in Harmony per Entity.
Policy: Access Control and other Policy rules per Entity.
Presentation: Rendering details specific to a serialization of the Entity.
For much of the week I had been battling if we would want to provide Access Control configurability on a per property basis in DSpace 2.0, such that one would set explicit access rights on each property (regardless of its "functional use") in an Entity, it seemed that it could get very unwieldy, bloated and slow as the store grew. As an alternative, I was exploring mediating access control for only Entities on a per Service basis. Given the above analysis, I'm beginning to think this is the more reasonable approach.
To give an example, an Item might have a set of System properties, Descriptive properties, Provenance properties, and Policy controls; all stored in separate services. In DSpace 1.x provenance was stored directly in the metadata table (I.E. the Content Domain). Capturing changes on the "Content Domain" of the Item becomes difficult to mediate rights on because the changes themselves get encoded as changes in the "Content Domain" of the Item.
Work was ongoing at MIT by Mackenzie Smith to separate out that change history into an independent service based on a "history" triple-store. This is actually the right direction we should be going in for DSpace 2.0 and I think we may now see the correct path to integrate not just the work completed in the Pledge project into DSpace 2.0, But also possibly some of the significant work completed in last years Google Summer of Code on Fedora integration and Versioning of DSpace Items.
One of these ideas has to do with the recognition that an Item is actually a "View" or a "Join" of properties from separate functional areas such as "content", "history", "policy", and "presentation". Here are a few examples of those areas.
1.) Content: An underlying store in DSpace might be JCR, Fedora, DSpace, and s3. Each of these maintain a separate model expressing content their domain. Fedora (Fedora Objects and Datastreams), JCR (JCR Nodes, JCR Properties, JCR References), DSpace (Collections, Communities, Items, Bundles, Bitstreams, etc).
2.) History: Each of these above storage systems presents Versioning, History or Provenance differently in its above ER (Entity Relationship) model. While the Content domain may provide a representation of that versioning history, there is still the requirement of a separate service layered (or not layered) on top of that to work with the at Versioning model.
3.) Policy: Certainly each of these expresses a set of policy information, which is generally managed in a separate service or layer on top of the Entities expressed therein.
4.) Presentation: Once you have these expressed, external tools will seek to have varying "expressions" of the previous 3 areas that are specific to a particular domain/tool (HTML, AJAX/Web 2.0, OAI-PMH, LOD, ATOM/APP) Some of these various communities seek to constrain what out of the previous 3 areas can be expressed within their transmissions.
I feel that being at the nexus of all these functional domains, DSpace 2.0 has an opportunity to be something very powerful. If we can recognize that the "presentation" of any DSpace 2.0 Entity is a JOIN of the data from each of these areas, and that we have different "Services" responsible for expressing, accessing and persisting that "domain specific" data, then its clear that for any one entity in the DSpace model that we actually have N possible domain specific representations of an Entity expressed.
Content: Content in an underlying stores model on a per Entity basis.
History: Provenance, Versioning, and Change History Trail in Harmony per Entity.
Policy: Access Control and other Policy rules per Entity.
Presentation: Rendering details specific to a serialization of the Entity.
For much of the week I had been battling if we would want to provide Access Control configurability on a per property basis in DSpace 2.0, such that one would set explicit access rights on each property (regardless of its "functional use") in an Entity, it seemed that it could get very unwieldy, bloated and slow as the store grew. As an alternative, I was exploring mediating access control for only Entities on a per Service basis. Given the above analysis, I'm beginning to think this is the more reasonable approach.
To give an example, an Item might have a set of System properties, Descriptive properties, Provenance properties, and Policy controls; all stored in separate services. In DSpace 1.x provenance was stored directly in the metadata table (I.E. the Content Domain). Capturing changes on the "Content Domain" of the Item becomes difficult to mediate rights on because the changes themselves get encoded as changes in the "Content Domain" of the Item.
Work was ongoing at MIT by Mackenzie Smith to separate out that change history into an independent service based on a "history" triple-store. This is actually the right direction we should be going in for DSpace 2.0 and I think we may now see the correct path to integrate not just the work completed in the Pledge project into DSpace 2.0, But also possibly some of the significant work completed in last years Google Summer of Code on Fedora integration and Versioning of DSpace Items.
Subscribe to:
Posts (Atom)
