I know the feeling of wanting to share one’s reading habits from using GoodReads and my own personal ebook library, Libra.re. So when Joi mentioned he’d like to share the scholarly works he reads, I understood completely. The things we read become part of our minds and having some way of sharing that is another way we share of ourselves and help others to understand where we’re coming from in our own words and works.
Joi already uses Zotero to track his scholarly reading, which we discovered can provide an RSS Atom feed (OMG!) and an “extra” field the user can fill. As limited as this is—why not provide unlimited user-customizable key=value pairs, Zotero?—it is good enough for now.
Most of the per-item metadata that Zotero’s RSS feed includes, however, is in an HTML <table> in the Atom <content> tag. Go figure.
Parsing the feed and the HTML DOM was easy enough of course. What took the better part of the day was the data itself. I needed to figure out what data we wanted to feature, which we could rely on being present (Title, Author, etc…), what other data was present that we’d like to display if it happens to be available, and what to do with the rest. Showing everything every time would have been easy but also very messy. I opted to limit what we show on our listing and widget, and for everything else, we link through to the Zotero record.
I mentioned the “extra” field. This is a good example of how sometimes Joi needs to do a bit of manual labor because something can’t be automated. We use the “extra” field for a “date read” date stamp. Joi needs t manually enter the date he wants to say he read—started or finished, doesn’t really matter—the work in question. This allows us to list the works in that true blogging reverse-chronological way.
This development uses some of the core infrastructure I’ve built over the years for Joi’s site, with all aggregating, parsing, munging and caching using 3rd party libraries and functions I’ve assembled and have ready for exactly these sorts of projects.