Caveat Lector

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.)

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.

In no particular order:

• Monochrome cats, including scrawny gray kittens who appear on doorsteps out of nowhere and turn into sleek little cuddlebugs.
• Homegrown basil.
• Coming home, to a place that’s just as great as I remembered it.
• Good work, and the skills and the drive to do it.
• Living a half-hour walk from work, and a stone’s-throw from almost everything I need.
• Friends who hear me, and understand, and manage not to condemn even when I deserve it.
• This marvelous Internet.
• Professional respect, earned and not.
• Reasonable health, and freedom from pain.
• Enough, and then some.

Wishing the same for everyone.

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.)

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!

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!

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.)