Hi Peter and Mark,
The DataONE project includes work we did to DSpace Item versioning that
might be of interest to you here. This was deployed as a solution to our
clients as well. Basically, we have augmented the Versioning system to
track "all" changes to DSpace Items.
In this prototype, the Event System is utilized to create a history of
version changes that happen to an item. Each database transaction that
generates a set of events, these are captured by the VersioningConsumer,
which creates a new immutable version record containing the new state of
the Item. The original state of the Item was already recorded in the Items
previous version record. This allows all changes done through the API to be
tracked and preserved.
The new Version records:
- The time the change happened
- The eperson account that caused the change
- A summary message and a log of all the EventManager events that caused
the change.
- A customized METS AIP XML manifest is stored in relation to the
version record
- Additionally, set of version2bitstream records records all the current
bitstreams associated with the Version (and METS manifest)
Through this mechanism the following is possible:
- Creation of an audit trail / version history that includes all changes
to an Item
- Ability to view the previous state of an Item in the UI, including
links to access bitstreams
- Ability to "restore" the current DSpace Item from any of the previous
revisions via admin UI.
- Ability to Search for and restore any Item that was deleted from
DSpace, but has an existing version history record in the version history
table.
We are using this in DataONE to track and report all versions and events
that cause changes to DSpace Items. Some of the code involved has been
published into DataONE on Github and can be easily viewed:
https://github.com/DataONEorg/DSpace/tree/dataone-4_x/dspace-dataone/dataone-api/src/main/java/org/dspace/versioning
An extrapolation from this could be to extend the capability to any
DSpaceObject and have version history on any DSpaceObject in general,
however, this will require creating Persistent representations of
non-content DSO (EPersons, Groups, so-on) that can be used for rendering,
serialization and deserialization.
Regards,
Mark
On Thu, Oct 9, 2014 at 12:38 PM, Peter Dietz <pe...@longsight.com
<javascript:_e(%7B%7D,'cvml','pe...@longsight.com');>> wrote:
> Not entirely related to dc.description.provenance, but I want to see a
> thorough validatable audit log from the system. i.e. Who changed
> what/when/why/how. i.e. This Group name used to be "ABC Staff", now it's
> just "Staff", who did that, when did they do that, what was the previous
> value. What changes have been made in the past 7 days.
>
> This shouldn't really show up in the metadata section (we could use
> metadata4all I guess though). But I think those events would need
> timestamps. (Maybe even a isCurrent flag, to hold on to previous version of
> metadata field).
>
>
>
> ________________
> Peter Dietz
> Longsight
> www.longsight.com
> pe...@longsight.com <javascript:_e(%7B%7D,'cvml','pe...@longsight.com');>
> p: 740-599-5005 x809
>
> On Thu, Oct 9, 2014 at 3:27 PM, Mark H. Wood <mw...@iupui.edu
> <javascript:_e(%7B%7D,'cvml','mw...@iupui.edu');>> wrote:
>
>> While reviewing DS-2082 I realized that the way bitstreams are handled
>> in the provenance doesn't make much sense to me. I'll admit that I
>> don't think people are adding and removing bitstreams within
>> particular items all that often, but still, I feel that this is simply
>> an awful format for recording how an item came to be as it is.
>>
>> Should we not append a *new* dc.description.provenance value every
>> time the item is changed, rather than endlessly extending a single
>> one? The single string is awfully hard to read, let alone
>> mechanically parse, and at some point one will surely overflow the
>> maximum size of a TEXT column. Listing all of the bitstreams' names
>> in a single line every time there is a change is also not so
>> scalable. That's one factor that led to DS-2028 in the first place.
>>
>> I recall that there have been proposals for more radically
>> reorganizing this information, and perhaps that's what we should do.
>> But at a bare minimum, shouldn't we break the history of an item down
>> into separate entries, instead of stringing them together?
>>
>> BTW the change I suggest would require some other work, as right now
>> we are lucky that the appending happens on the proper metadatavalue.
>> MetadataUtilities.appendMetadata clearly was supposed to index through
>> matching entries looking for the "right" one, but in fact it ignores
>> the index and always appends to the first value that that DBMS happens
>> to return. I'm filing an issue on that, as it seems wrong
>> regardless. OTOH I see that it's only used three places, all in the
>> item updater, and likely would have no purpose if we change the way
>> item updates are recorded.
>>
>> --
>> Mark H. Wood
>> Lead Technology Analyst
>>
>> University Library
>> Indiana University - Purdue University Indianapolis
>> 755 W. Michigan Street
>> Indianapolis, IN 46202
>> 317-274-0749
>> www.ulib.iupui.edu
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Dspace-devel mailing list
>> Dspace-devel@lists.sourceforge.net
>> <javascript:_e(%7B%7D,'cvml','Dspace-devel@lists.sourceforge.net');>
>> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> <javascript:_e(%7B%7D,'cvml','Dspace-devel@lists.sourceforge.net');>
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
--
[image: @mire Inc.]
*Mark Diggory*
*2888 Loker Avenue East, Suite 315, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
--
[image: @mire Inc.]
*Mark Diggory*
*2888 Loker Avenue East, Suite 315, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
