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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
