Reading
Tags: books, reading, indieweb, publishing
Published: 2020-04-27 11:19:30

---
title: Reading
published: true
date: 2020-04-25 11:10:41 UTC
tags: books,reading,indieweb,publishing
canonical_url: https://adactio.com/journal/16803
---

At the beginning of the year, Remy wrote about [extracting Goodreads metadata](https://remysharp.com/2020/01/06/extracting-goodreads-metadata) so he could create his [end-of-year reading list](https://remysharp.com/2020/01/02/books-i-read-in-2019). More recently, Mark Llobrera wrote about [how he created a visualisation of his reading history](http://dirtystylus.com/2020/04/17/visualizing-my-reading-with-semiotic/). In his case, he’s using JSON to store the information.

This kind of JSON storage is exactly what Tom Critchlow proposes in his post, [Library JSON - A Proposal for a Decentralized Goodreads](https://tomcritchlow.com/2020/04/15/library-json/):

> Thinking through building some kind of “web of books” I realized that we could use something similar to RSS to build a kind of decentralized GoodReads powered by indie sites and an underlying easy to parse format.

His proposal looks kind of similar to what Mark came up with. There’s a title, an author, an image, and some kind of date for when you started and/or finished reading the book.

Matt then points out that RSS gets close to the data format being suggested and asks [how about using RSS?](http://interconnected.org/home/2020/04/16/rss_for_books):

> Rather than inventing a new format, my suggestion is that this is RSS plus an extension to deal with books. This is analogous to how the podcast feeds are specified: they are RSS plus custom tags.

Like Matt, I’m in favour of re-using existing wheels rather than inventing new ones, mostly to avoid [a 927 situation](https://xkcd.com/927/).

But all of these proposals—whether JSON or RSS—involve the creation of a separate file, and yet the information is originally published in HTML. Along the lines of Matt’s idea, I could imagine extending the [`h-entry`](https://indieweb.org/h-entry) [collection of class names](http://microformats.org/wiki/h-entry#Core_Properties) to allow for books (or films, or other media). It already handles images (with `u-photo`). I think the missing fields are the date-related ones: when you start and finish reading. Those fields are present in a different microformat, [`h-event`](http://microformats.org/wiki/h-event) in the form of `dt-start` and `dt-end`. Maybe they could be combined:

```

<article class="h-entry h-event h-review">
<h1 class="p-name p-item">Book title</h1>
<img class="u-photo" src="image.jpg" alt="Book cover.">
<p class="p-summary h-card">Book author</p>
<time class="dt-start" datetime="YYYY-MM-DD">Start date</time>
<time class="dt-end" datetime="YYYY-MM-DD">End date</time>
<div class="e-content">Remarks</div>
<data class="p-rating" value="5">★★★★★</data>
<time class="dt-published" datetime="YYYY-MM-DDThh:mm">Date of this post</time>
</article>

```

That markup is simultaneously a post (`h-entry`) and an event (`h-event`) and you can even throw in `h-card` for the book author (as well as [`h-review`](http://microformats.org/wiki/h-review) if you like to rate the books you read). It can be converted to RSS and also converted to `.ics` for calendars—those parsers are already out there. It’s ready for aggregation and it’s ready for visualisation.

I publish very minimal [reading posts](https://adactio.com/notes/reading) here on adactio.com. What little data is there isn’t very structured—I don’t even separate the book title from the author. But maybe I’ll have a little play around with turning these h-entries into combined h-entry/event posts.