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
p: 740-599-5005 x809
On Thu, Oct 9, 2014 at 3:27 PM, Mark H. Wood <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
> 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
https://lists.sourceforge.net/lists/listinfo/dspace-devel
