by Scott Phillips
Main issue is Life-cycle management including epeople, authorization, and policies
- Current life-cycle:**
(ms) What level should we investigate DSpace history mechanism, most people are working on interface issues but few are working on preservation issues.
(ms) should the ingest workflow be worked on
(JD and JE) will review larry stone's event mechanism.
Conciseness: There should be an improvements to the event/history system.
(RT) The event mechanism will need to be tied to the new transaction model where logical changes are grouped together.
(ms) Proposal to use another third party workflow system.
Use a third-party system?
How would adopting a framework effect using third party workflow systems?
Recommendation: Adopt a third party API to implement a generic workflow system in the backend, then support a serious of tailored XML UI aspects to leverage the generic API for specific workflow needs.
- Identity Management:**
Current use of epeople:
(ms) problem using persistent identifiers (URI) inside the event mechanism. The URI's may not need to be actionable, but the ability to attach attributes to them.
(hj) needs to leave for his flight, but would like to know what CNRI can do to make handles more DSpace friendly.
(jd, je) more documentation for how to install handles, i.e. over port 80.
Recommendation: CNRI submit a presentation to OR07 about the handle system.
Recommendation: CNRI maintain a subset of the DSpace wiki about handles.
Recommendation: We assign a persistent id, (probably handle), that is not actionable (i.e. the handle does not actually work).
(je) DSpace's current implementation has problems, one trend in the industry is to adopt generic authorization languages.
(rt) problems: no definition what permissions / roles actually mean.
(rt) problems: some roles require extra implied permissions.
(rt) problems: undocumented 'features' for inheritance of permissions.
(rj) we should define a set of permissions, i.e. the seven base ones, look, add, remove, etc....
(rt) presents a proposed model with people, groups, role, and permissions.
Tomorrow: Data model, concrete data model, history