At DASER I was caught by Stevan Harnad’s idea of an email link to the author on a repository page for embargoed content. I buttonholed him briefly to confirm my understanding of the idea. He told me that the author’s email address was available as part of the item’s metadata.
“Well, the submitter’s name,” I corrected (respectfully, I hope). “We get some third-party submissions.” Like every other repository on the face of the earth.
I had to repeat myself before he quite understood me. An annoyed look crossed his face. “Well, that won’t work, then!”
It won’t work the easy way, true. It’ll still work, though, and I think I know how (at least for DSpace). Make a ticky-box on the first page to select the embargo, and then add a couple of inputs if that ticky-box is ticked: one for the appropriate email address, and (possibly) one for the length of the embargo. (Me, I’d rather see only one embargo length, but the rest of the world may see matters differently: the NIH embargo looks to end up at six months of length, whereas the typical thesis/dissertation embargo is one year long.)
As with most e-business websites, the best way to handle the email address is probably a “Use mine!” ticky-box with an input box for backup. And embargoing should probably not be available to everybody; best to activate it on a per-collection basis.
The neat thing about this system is that it handles multiply-authored material where the submitting author is not necessarily the one who ought to get requests. Not to mention, of course, the third-party-submission use case that got me thinking about this in the first place.
(I did discover yesterday that the license I’ve been using actually has language to cover third-party submissions. I’m thrilled; that cuts down amazingly on my paperwork hassles.)
Once DSpace has a plugin architecture, I daresay I’ll take a whack at coding this up. Shouldn’t be too hard; the hard part (well, the part I don’t know how to do, anyway) is baking in the embargo release automatically.
The image gallery, now… that is giving me fits, and I’m not even sure I can come up with something usable. The problem is the unpredictable relationship between an item and its image bitstreams. In some of the image collections my repository’s got, a typical item has two image bitstreams, where Image 1 is in a different (usually higher-resolution and lossless) format, but is otherwise identical to Image 2. An image gallery would pick one bitstream to display and forget about the other one, or have some UI widget to pick out the other one for closer examination. If it displays them all (and especially if it’s smart enough to use DSpace’s media-filter to step down high-res images), the user will (rather annoyingly) have to click past several versions of the same image.
In other collections, an item will have several image bitstreams that form part of a whole: for example, scans of several pages of a single manuscript. The image gallery should grab out all of these and display them in the correct order. How?
And how the heck does the image gallery know which kind of an item it has?
The image gallery I’m meant to be imitating clearly works because of an unstated understanding about one-image-bitstream-per-item. I don’t have the luxury of making that assumption, so I may have to nix the idea altogether for now. There’d be a way to hack it if DSpace used the “bundle” construct to group different versions of the same image, but I’m not confident enough to go that deeply into core code.
(And y’all Fedora-ites can just hush up. I know it’d be easy to build this on top of Fedora.)
Eh, well. I’m backburnering the image gallery for now. We’ll see what develops.