May I just say that the results of this search are freaking me right the hell out?
Somebody needs to revise the Worldcat relevancy algorithm. STAT.
(And no, I didn’t intentionally go do a Worldcat ego search. I just needed some results so I could see how they’d designed their results and item-metadata pages, so I typed the first name that came to mind.)
One of the (sadly few) nice things that DSpace’s JSP interface did was call out the link for the page you happened to be on in the navigation sidebar. The magic was a class attribute on the current page’s link, plus a bit of CSS.
Manakin doesn’t do that out of the box. But it can, and I just spent entirely too much time making it do so. Y’all get the benefit of my cussing streak.
The first trick is to figure out just what the address of the current page is. Go up to the top level of your theme’s XSLT stylesheet and add this:
<xsl:variable name="currentpage"> <xsl:value-of select="$context-path"/> <xsl:text>/</xsl:text> <xsl:value-of select="/dri:document/dri:meta/dri:pageMeta/dri:metadata[@element='request' and @qualifier='URI']“/> </xsl:variable>
(Incidentally, could somebody with more XSLT-fu than I have kindly explain what the difference is between dri:metadata[@element='request' and @qualifier='URI'] and dri:metadata[@element='request'][@qualifier='URI']? I know there is one, because it keeps tripping me up.)
Now you need your <dri:xref> transformation to take notice. Here’s how it works:
<xsl:template match="dri:xref">
<a>
<xsl:attribute name="href"><xsl:value-of select="@target"/></xsl:attribute>
<xsl:if test="($currentpage)=(@target)">
<xsl:attribute name="class">
<xsl:text>current</xsl:text>
</xsl:attribute>
</xsl:if>
<xsl:apply-templates />
</a>
</xsl:template>
And then you may style at will.
This only works for side navbar links. It doesn’t currently work for the alphabet links at the top of browse-by pages, because they’ve got parameters attached. (If I recall correctly, there may be some URL-space rearrangements in current Manakin versions that might fix this.) Happy designing!
The default Manakin install, just so you know, doesn’t put subject terms on the short item-display page. It’s not hard to add them back, and I recommend it; you’ll see what I did with them in a moment.
Making authors and subjects clickable is a bit trickier. Up-front warning: what I’m about to show you is apparently not in line with the latest version of Manakin, but if you get the idea, making the necessary fixes won’t be hard.
The first problem is that the names need to be URL-encoded or browsers will break amusingly. This leads to the second problem, which is that XSLT 1 doesn’t have a built-in URL encoder. Fortunately, Cocoon does, and you can enable it for your Manakin themes. In your main sitemap.xmap file, add the following just below the root <sitemap:xmap> element:
<map:components>
<map:transformers>
<map:transformer name="encodeURL"
src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
</map:transformers>
</map:components>
Then, between Steps 4 and 5 of the <map:pipeline>, add:
<map:transform type="encodeURL"/>
URL encoding problem solved. (Note: if you mouse over links with this working, they don’t look encoded—that’s okay, everything still works.)
Now you need to go into your theme’s XSLT stylesheet and look for the <xsl:template> with the name “itemSummaryView_DS-METS-1.0-DIM”. If it’s not there, go into DS-METS-1.0-QDC.xsl, find it there, and copy it into your theme’s stylesheet.
After breaking things amusingly several times, I found out what works. Note carefully that I am not using Manakin-default table markup for metadata, because I despise table markup. I’m using definition lists instead, and I’ve made them look like tables with CSS. (Hell, my metadata display is prettier than WorldCat’s. Right-justify your labels, people! It helps the eye.)
<xsl:if test="$data/dim:field[@element='subject']“>
<dt><xsl:text>Subject(s):</xsl:text></dt>
<dd>
<xsl:for-each select=”$data/dim:field[@element='subject']“>
<a>
<xsl:attribute name=”href”>
<xsl:value-of select=”concat($context-path,’/browse-subjects?subject=’)”/>
<xsl:copy-of select=”text()”/>
</xsl:attribute>
<xsl:copy-of select=”text()”/>
</a>
<xsl:if test=”count(following-sibling::dim:field[@element='subject']) != 0″>
<xsl:text>; </xsl:text>
</xsl:if>
</xsl:for-each>
</dd>
</xsl:if>
Taking that a bit at a time… frankly, you should wrap all your metadata declarations in <xsl:if> statements as I just did, because otherwise they will show up in Manakin whether they actually have values or not! This is just silly.
I put the bare text “Subject(s)” in the code instead of doing something in messages.xml for it. This is bad, it will be fixed, and you should not do it. Use messages.xml instead.
The rest works out to “for each subject, put a link to the corresponding browse-by-subject page, and add a semicolon and space if it’s not the last subject in the list.” It doesn’t take a whole lot of XSLT-fu to see how it works.
This works just as nicely for authors, and I’ve got that enabled too. (I’ve also split out real authors from advisors, translators, editors, etc. in the code. This took a little doing, and may be worth a separate post.) You can do it too—have fun!
Busy. Dammit. I can’t escape teh busy. Not for five minutes.
I’ll be out of town Sunday through Tuesday at the NISO/PALINET thing. Slides are done, but I haven’t scripted them, so guess what I’ll be doing tomorrow? (That and next week’s class lecture.)
If that’s not enough, I’m up for fifteen minutes at a local teaching/learning tech thing on the 13th. I can cannibalize existing presentations to put that together, but I still have to do that (and we just won’t talk about the two hours I spent on a meeting yesterday over this, because I am rapidly forming a personal rule that anything on which I have to spend more meeting time than actual doing the thing time is not worthwhile).
And Roach Motel is due shortly, and while I think it’s quite done enough to give to an editor without cringing—I took a pass through and fixed a lot of structural problems that were causing unnecessary repetition, and have I mentioned that I’m really not a very fluid and polished writer?—I haven’t formatted it the way they want and I need to do that.
And I’m so overdue on a book review that let’s not even talk about how overdue I am on the book review. I’m taking the book with me to read on the plane.
And I’ve basically promised to make a stab at integrating some PREMIS into Manakin, because that is the officially-blessed way of solving my friendly file-format descriptions problem. Wish me luck with that.
If that’s not enough, toss in some fairly massive upheaval in both personal and professional lives, none of which I feel justified in blogging publicly. Suffice to say that while both situations are unsettled, both are improving and I am cautiously optimistic about both—but none of it does anything useful for my stress levels, right?
There may be blogging. There may not be blogging. I’m busy.
There is likely to be more Manakin blogging; the redesign proceedeth apace and I have some tidbits to share. I merely remark briefly that I do better relying on my own hacktastic CSS skills than using other people’s beautiful elegant solutions. I tried the Holy Grail. I spent days trying to get it to do what I needed, and that was just in Firefox—I looked at it for the first time in IE yesterday, and it was horrendously, unbelievably, irretrievably broken. I gave up shortly thereafter, and within 45 minutes had something that is working fine in Firefox, and probably won’t need more than a few box-model tweaks in IE.
In passing: I read this report (PDF) on the fate of social-science post-docs, and was struck by the sentence “Funders, policy makers, disciplinary associations, universities, and graduate faculty need to recognize that the PhD in the 21st century is preparation for employment.”
I… I… I got nothin’. I can’t think of a blessed thing to say to this. Except a loud and boisterous “BEWARE!” to anyone thinking of entrusting their lives to a doctorate in a social-science discipline. (Including LIS.)
In no particular order:
Wishing the same for everyone.
The Medical Library Association did what I thought was an impressive and effective webcast on open access today. No ’cast with Heather Joseph in it can be all bad, but I was impressed with how up-to-date, engaged, and persuasive the other participants were as well.
Except that—as usual—the repository-rats got left out to shiver in the cold.
I fired in a question that tried to address this, but I didn’t phrase it well and it got mangled by the facilitator. (Yep, that one.) My issue, in brief, is that the envisioned role for librarians in the brave new open access world is as educators, advocates, negotiators—everything but actual collection developers!
Look, the reality is that we can jawbone faculty until we turn blue in the face and it will accomplish nothing on the green-OA side. It disturbs me, profoundly, that nobody seems to be talking about active content harvest and collection. (The closest anybody got in the webcast was the suggestion of dual-mode deposit into PubMed Central and the local repository. Yes! This is what I’m talking about, people! But it’s not nearly enough.)
And until we start talking about beating the bushes for content, we’re still leaving our poor repository-rats twisting in the wind. I must say, my ratty little neck is getting sore.
The biblioblogosphere is all twittery about the new Kindle thing from Amazon.
I’m not. Looks like the same old, same old to me. I don’t see what’s changed about the gadget or the legal and social environment that’s going to make this thing a success.
Wake me if I turn out to be wrong.
(Also, four hundred smackers? Um, no.)
(I posted a lengthy polemic to the DSpace-Tech mailing list in response to a gentle question about projected DSpace support for electronic theses and dissertations. I think the content is relevant to more than just the DSpace community, so I reproduce it here, with an added link or two.)
With the understanding that I’m not a DSpace committer and not involved in any way with DSpace or the DSpace Foundation except as DSpace user and occasional bug or patch submitter…
My sense is that DSpace development has only vaguely and loosely been guided by real-world use cases not arising from its inner circle of contributing institutions. E.g., repeated emails to the tech and dev lists concerning metadata-only deposits (the use case there generally being institutional-bibliography development), ETD management, true dark archiving, etc. etc. have not been answered by development initiatives, or often by anything but “why would you even want that?” incomprehension or “just hack it in like everybody else!” condescension.
There are hacks for some of these uses, yes… but from a sysadmin’s perspective, hacks endanger smooth upgrade paths, and from the perspective of many librarians, hacks are entirely out of reach because IT rather than the librarian controls the box DSpace lives on.
When innovation has occurred around DSpace, it has generally died on the vine because of the aforementioned threat to smooth upgrade paths. TAPIR and Researcher Pages may serve as the requisite gruesome warnings here; they died not because the ideas underlying them were bad (they emphatically weren’t! if we still had TAPIR, Susan wouldn’t have had to ask the question she just did!), but because almost nobody dared adopt them. I see all kinds of nifty conference presentations involving DSpace mods — but they provide me no practical benefit whatsoever, because the code isn’t out there and I probably couldn’t use it if it were!
DSpace’s lack of a plugin/mod API, coupled with the amazing spaghetti dinner under its hood, has stifled service innovation in the repository space for years, and will continue to do so until the defect is rectified. Neither EPrints nor Fedora is in a much better position just now, but in all honesty, I predict that the first platform to have a half-decent mod API (especially one that welcomes mods written in friendlier languages than Java) will experience an explosion of innovations that will eat the other platforms’ lunch. Manakin assuredly helps, but not quite enough.
SWORD may also help, rather backhandedly, by providing an ingest path that doesn’t rely on the horrendous web UI or the awkward batch ingester. We’ll see; I’m hopeful. I’d far rather build an ETD app that used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs myself, much less try to push the committer group to do so.
It may be worth noting at this point that I put my votes where my mouth is; when the DSpace development survey came out, I put a mod API at the very top of my desiderata. I encourage other repository managers with unmet needs to speak up for this! It’s vastly more important for the long-term health of DSpace and the services we are building around it than are (for example) controlled vocabularies.
I am impressed by the RAND report on digital preservation and scholarly communication. It has been researched and written by smart people who know this field and understand all the angles. I would happily use it in a classroom, and that’s high commendation—a lot of these report things don’t make any sense to someone who doesn’t already have the background. Well done, RAND.
That said, I’m not as enthusiastic about emulation as they are. I reluctantly admit that for some things we’ll have to learn to do it. However, a lot of the perceived need for emulation is caused by a dearth of proper open data standards. Give me those, and “emulation” becomes “manipulate and use the data in the best way possible,” which goes far beyond mere aping of obsolete systems.
I’m currently wading through the scholarly-communication SPEC kit 299 from ARL, and shaking my head at the surveys we’re apparently supposed to be spraying hither and yon. If I tried to have the liaisons at MPOW do the Opportunity Assessment Instrument, I’d be lynched. Or lynched and then fired. Or fired and then lynched; I’m not sure what the protocols are around here.
Whose tail do I have to yank before the reality of “no resources, no help, no buy-in” sinks in? Please, tell me, whose?
To be fair, ARL/SPARC does better than most. (Cough, cough, ALA/ACRL.) Less happytalk, more substantive attempts to help. But even they are a bit distant from reality. I appreciated, though I don’t entirely agree with, the snarktastic interviewee in the SPEC kit talking about how open-access pitches are so violently out-of-touch that they alienate the very faculty we’re trying to win over.
That’s reality. The snark, I mean. If you’re a repo-rat and you’re not even a little snarky by now, you haven’t been around long or you’re just not paying attention.
I am the Annoyed Librarian. Come the heck on, people, didn’t you all suspect already? There ain’t nobody in this here biblioblogosphere more annoyed than I am.
Library school? All over it. The stupid job-shortage lies? Oh yeah. Technology uberhype? Annoys me past reason. Pointless ALA shenanigans? I’ve expended more verbiage on that than anybody, and I don’t even belong to ALA.
You knew. ’Fess up. You all knew all along (because hey, writing styles like mine aren’t a dime a dozen, you know?) and you’ve just been humoring me.
Jenica, Michelle, Rochelle, Laura, just give it up. Poseurs. You can’t out-annoyed me. I practically invented annoyance!