Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

  • Created by Unknown User (wiki_transfer), last modified on Apr 02, 2010

Wednesday Notes:

by Scott Phillips

Main issue is Life-cycle management including epeople, authorization, and policies

    • Current life-cycle:**
      • Ingest
      • submission
      • workflow
      • Event Mechanism (new from LS)
      • History
      • abc ontology (triplestore)
      • Preservation

(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?

Current proposal:

  • Use the limited workflow.
  • Or use XML UI aspects to replace.
  • Or use a third-party system to provide workflow.

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:

  • Permission control (object)
  • Role (i.e. responsibility to do something) (object)
  • Auditing (string)
  • Authority control (i.e. authors in metadata) (object)
  • notification services (object)
  • creator metadata (string)
  • Agent information (i.e. items were submitted onbehalf of someone else) (string)

Problems:

  • identity numbers, email addresses, change over time. Once these unique identifiers change there is no mechanism for the user to be able to update their information.
  • Use case, if a user places an item in the repository then later moves on from the institution, how is a later user able to contact the original author.

(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).

'''

  • Authorization*'''

(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

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.