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.
DSpace Architectural Review
Notes from Thursday, 26 Oct 2006 (JSE)
I. Review of Agenda
1. Data Model Revisit (aggregation, etc)
2. Concrete data model and storage
3. Larry Stone: History, Provenance, Audit
4. Etc...
II. Abstract Data Model Revisit (Rob)
- summary: fixing the "bundle" system
- See RJ notes
See diagrams of Rob's draft proposals
- version 1
- version 2 (typed)
- version 3 (typed)
Richard Rogers proposal
- "strawman 2"
(MS) Observation: Rob's makes more explicit how maps to FRBR
- whereas RR's more RDF- (or Fedora)-like
Need to test proposals against concrete examples
- See wiki, Data Model Use Cases
- See wiki, Asset Store Use Cases (older)
Problem with "Museum"-like repositories
- e.g. in which there are many representations of a "work"
- like many photos of a physical object
- (ms) FRBR vs VRA
(jse) Separate data abstraction from application
- (md) jsr-170 node/property model
- (rj) let's be clear on what we need to worry about; this talk og nodes/properties is implementation...
RECOMMENDATION: (draft) Adopt Rob's Item/Representation/File (with Metadata for each)
- ...and publish application note/"best practices" on meanings
- change: Bundle to Representation...
- change: Bitstream to File...
Example: "submitting a pdf with some metadata and a license"
*item is an article + descriptive metadata
*manifestation is a pdf
*file is a pdf
problem in linking-in files as metadata
LUNCH
III. History, Provenance, Audit
Overview of Larry Stone's stuff by RR
- See Larry Stone's Event System prototype
- ...and DSpace Event Mechanism
1. Event Mechanism
2. History needs to be based on logical events (transactions) not DB events
3.