Caveat Lector

Tables. Bloody tables. Manakin isn’t quite as table-infested as the JSP URI, but it’s still got plenty of bloody tables where they shouldn’t be.

A comment I left in the code today:

<!-- NO CAPES! -Edna Mode. NO TABLES! -DS -->

I also notice that the summary-view table allows blank metadata items (abstract, description). This is stupid. I believe I have fixed it. Once I’m sure, I’ll let you know.

Also, argh, VERBOSITY. Less noise on the pages, please! Turning the bitstream table into a list allows me to get rid of the table headers. This is a good thing.

Also, double-argh, thumbnails at the end of the file listing, when they’re the first thing anyone wants to consider! Fixed that one too.

And inflicting MIME types on users sucks. I gotta find a way around that one; I don’t care what METS allows.

Edited to add: I have a notion for that last. Get the Bitstream Format Registry to export itself to something XMLish, then call it via the MIME type in METS. Kludge, if I can even get it to work, but way better than inflicting MIME types on users.

Hm… there is also input-forms.xml, which might be pressed into service in a pinch…

Apparently it’s not possible to Creative-Commons-license a DSpace submission via the UI after the ingest process is complete. This is brain-dead stupid, but so much is.

There appears to be a technical way around this, though it is somewhat cumbersome. Use it with all due care; I refuse to be responsible if you CC-license something you shouldn’t and an angry faculty member comes after you with long knives. Also, I’m in the middle of testing this myself; I’m not 100% sure it works yet.

The way CC licensing works in DSpace is that various files (”license_rdf”, “license_text”, and “license_url”) get added to an item in a CC-LICENSE bundle when a depositor clicks the appropriate buttons to add a CC license. So if you add those files to that bundle for an existing item, as far as I can tell, it’s CC-licensed.

If you’re going to try this hazardous little trick (did I mention it was hazardous?), the first thing you need to do is collect those three files for the various available CC licenses. There is probably an easy way to do this, but the hard way is to hop onto your test server (you do have a test server, right?) and put in a few faux items with CC licenses, then use the command-line ItemExport tool to export them. The license files will be in the exported directory.

Now use the ItemExport tool to export the item you want to license. Add the three files pertaining to the appropriate license to the exported item directory. Then add these three lines to its “contents” file:

license_rdf	bundle:CC-LICENSE
license_text	bundle:CC-LICENSE
license_url	bundle:CC-LICENSE

Make sure that the separator between filename and bundle is a tab character.

Stick the new improved item directory back on your server (if it’s not already there), and (this is important!) run ds_migrate on it, because if you don’t you’ll have even more junky useless format and date metadata than DSpace usually keeps. Then use the regular item importer on it, remembering to add the –replace flag.

Should do the trick. I hope. We’ll see.

Edited to add: Works as advertised. I have a whole CC-licensed collection now!

So one of the problems with DSpace in both its JSP and Manakin incarnations is that authors get lumped together with editors, translators, advisors, and many other sorts of contributors in a number of the displays. This is confusing at best and outright wrong at worst. I promised several of my colleagues that I’d fix that in Manakin.

I’m trying to start slowly here, with the simple display of titles and authors found in (for example) the Recent Submissions section on community and collection pages. Found that bit (and let me congratulate the Manakin devs on the nice, sensible display choices here):

        <div class="artifact-title">
            <a>
                <xsl:attribute name="href"><xsl:value-of select="@url"/></xsl:attribute>
                <xsl:choose>
                    <xsl:when test="$data/dc:title">
                        <xsl:copy-of select="$data/dc:title[1]/child::node()”/>
                    </xsl:when>
                    <xsl:otherwise>
                        <i18n:text>xmlui.dri2xhtml.METS-1.0.no-title</i18n:text>
                    </xsl:otherwise>
                </xsl:choose>
            </a>
        </div>
        <div class=”artifact-info”>
            <xsl:choose>
                <xsl:when test=”$data/dc:contributor”>
                    <xsl:copy-of select=”$data/dc:contributor[1]/child::node()”/>
                </xsl:when>
                <xsl:otherwise>
                    <i18n:text>xmlui.dri2xhtml.METS-1.0.no-author</i18n:text>
                </xsl:otherwise>
            </xsl:choose>
            <xsl:text> </xsl:text>
            <span class=”date”>(<xsl:copy-of select=”substring($data/dcterms:issued/child::node(),1,10)”/>)</span>
        </div>

So, okay, for title we’re grabbing the first dc:title element, and for author we’re grabbing the first contributor element regardless of its qualifier (which is the problem that I want to fix), and for date we’re going straight to something (element unimportant, as I read it) with a qualifier of “issued”.

Huh. So if I read this right, we’re assuming that no two DC elements happen to have the same qualifier for any reason. I suspect that works out fine in practice (though what about dc.contributor and dc.creator?), but it seems, well, brittle. Hacky. Kludgy.

What I don’t quite see how to do is create an XPath that takes both element and qualifier into account, since they’re in different namespaces and may not have any structural relationship to each other. (Where’s the documentation on this particular METS profile, anyway?) Anybody got a brilliant answer?

We recently moved our DSpace to a shiny new server, which mostly made things much faster, but also caused some funky email glitches. Once the glitches were resolved, we discovered we had a problem with DSpace email subscriptions going to no-longer-usable email addresses. As far as I can tell, DSpace doesn’t have any UI for getting rid of those subscriptions.

The fix is to go into the database and perform the following query:

delete from subscription where eperson_id = (select eperson_id from eperson where email='bouncing email here');

This doesn’t affect the eperson record in the slightest, so if your eperson was responsible for item submissions, you haven’t destroyed any provenance information. You may, however, want to check the eperson out in the dspace-admin UI to be sure you’ve removed any submission privileges they shouldn’t have any longer.

Remember way back when, when I was a wee baby librarian trying to figure out how to rewrite DSpace URLs without breaking everything?

This is how I shoulda done it.

I couldn’t have figured that one out on my own without a hell of a lot more Apache-fu than I have. I feel stupid, but not too stupid.

And hey, now everybody else stuck in my baby-librarian booties doesn’t have to go through hell and back trying to get that done.

So now we all know.

Just reading through the messages.xml file, I see some things that Manakin has streamlined compared to the JSP interface, and I entirely approve.

They haven’t, however, gotten rid of the unnecessary task-choice workflow step, which makes me mutter various things not safe for a PG-13 weblog. I’m hoping I can go in and fix this, but I suspect it’s going to be a Java problem, and that may be tougher than I can deal with.

Sigh. Back to fixing language.

Anyone using Manakin: Do not—DO NOT—send it live without a thorough read of the messages.xml file in the i18n folder in the config folder. Just in a quick read, I’ve found misspellings, incorrect apostrophe use, and similar things that send a librarian’s spine shivering as though nails had run down a nearby chalkboard.

I’m fixing them on my end, and when I’ve time, I’ll shoot a corrected version at the developers. In the meantime? Don’t embarrass yourself or your institution. Read the file and fix it!

Edited to add: Also, verbosity and redundancy. Argh. Librarian thing. Sometimes we need to be beaten with copies of Strunk and White. Avoid needless words, dammit, especially on the web! (Expostulations are never needless.) I just changed “If that is the case” to “If so.”

Edited to add (again): Even better. “The following represent ways in which you can log in. Choose the appropriate method by following the link.” changed to “Log in via:”.

We should totally hold a contest. Whoever can reduce the wordcount in DSpace’s message file most while retaining appropriate clarity wins.

So this is the design I’m supposed to imitate in the new Manakin-based repository design. Except for the Arial (ugh), it’s not bad, passing over lightly that the CSS code looks like what I might have written when I was new to the spec—that is, disorganized and messy.

But I have a design problem. Well, several. One is that I don’t have a reverse-video repository logo. That could be gotten around; I can just make one. But if I do, I may cause brand confusion between the repository and the larger organization, and I can’t think of anything calculated to cause me more grief. If I don’t, then I have the problem of trying to fit a multi-colored logo into that nice red border. Yucko.

Okay, so we get rid of the red border at the top and make it white, demarcating it with the thin red line. The nav sidebar can stay more or less as it is, white-on-red. That will also let me move the breadcrumbs into the header, which is a feature of the default Manakin design that I quite approve.

Now there’s the two-logo problem. Two logos? Yes, two logos: one for the repository, and one (optional) for the community or collection. How do you put two logos on a page such that they don’t clash? And why is the real page title living in the body of the page and not the header?

Okay, so let’s be clever about this. If there’s a logo, we put it in the logo spot in the header. If not, we use the default repository logo. Either way, proper title goes in the header. Yes! I like this. (Others may not, if they are concerned about the repository “branding” itself. Me, I’m pragmatic. The repository “brand” isn’t worth diddly-squat. Letting campus communities brand their own collections is worth a lot.)

Now to figure out how to make it happen… title shouldn’t be hard, but I’m not sure about that logo…

One of the things my students don’t know yet, because it completely slipped my mind to tell them last week, is that I will in fact be doing their final project with them.

I asked them to investigate and then either implement or plan for a technology that is unfamiliar to them. And timing worked out such that I now have a Manakin-enabled DSpace test server to mess with.

The Manakin theme tutorial is pretty good so far, though it’s mildly frustrating that the xmlui.xconf file (like the dspace.cfg file) is the Special File that has to be changed in the running directory, rather than in source. If you’re working with a fresh copy of the code in Eclipse as I am, that makes the tutorial look wrong, because there’s a config directory inside Manakin with the xmlui.xconf file in it.

Ugh, complicated goofiness. But I believe I have created space for a new theme, and so on I go.

Oh, and I made a new category for Manakin grumblings and squees. I expect to emit many of both.

So, yeah, DSpace RSS feeds. They don’t work like RSS feeds anywhere else in the universe.

The blog feeds I follow send me whatever’s been posted since the last time I polled them, when I poll them. No fixed number, just whatever’s there that I haven’t seen. This is the behavior I expect; I don’t want to miss posts just because it’s been a while since I polled, and one particular blog has gone on a posting spree for whatever reason.

DSpace RSS feeds give me the last five items. (I can change “five” to something else, so it’s really “the last n items,” but stick with me here.) It doesn’t matter if five, fifty, or five hundred items have been deposited since I last polled—I get the last five, no more.

This is not the behavior I want. I want to keep an eye on what’s going into the repository! That’s what the RSS feed is for, in my small beady repository-rat brain.

For once, I don’t think this is the DSpace developers’ fault; they’re relying on somebody else’s RSS library. Be nice if that library would fix itself, though. (And I could be wrong; I don’t know whether DSpace or the external library decides what goes into a feed at polling time.)

Edited to add: It’s my fault, as usual. RSS feeds are limited by number; all I can do about it is raise the number. Thanks to John Mark Ockerbloom, Aristotle Pagaltzis, and Jim Downing for setting me straight. (Though I still think the behavior is broken! Sometimes what one needs is a protocol, not a file format.)