Regular readers will know that I’ve been posting about daily – or serialised – RSS feeds for several years now, so here’s a quick recap of what serialised feeds actually are, and then a bit of news about my latest attempt at OpenLearn Daily feeds.
If you’re reading this via an RSS feed, then I’m assuming you’re familiar with the idea of RSS (if not, check out the Common Craft video: RSS in Plain English). The important thing to take away from this understanding is that separate RSS feed items contain separate chunks of content.
Typically, RSS is used to syndicate content as it is published from a regularly updated source, such as a blog, news service, or saved search. In these cases, each feed item might correspond to a separate news item, blog post, or search result.
In contrast to syndication feeds from continually or regularly updated sources, a serialised feed is an RSS feed derived from an unchanging (or “static”) body of content, such as a book, or OpenLearn course unit, for example.
The original work is partitioned (serialised) into a set of separate component parts or chunks – in the case of a book, this might correspond to separate chapters, for example. Each chunk is then published as a separate RSS item. By scheduling the release of each feed item, a book or course can be released as a part-work over a period of time, with each part delivered as a separate feed item.
“Serialisation” should thus be understood in the sense of “serialised” books, such as might appear over several issues of a newspaper, or several episodes of a radio programme in the case of a book serialised for radio.
Daily feeds are a special case of serialised feed in which items are released according to a daily schedule.
Serialised feeds may be published according to a “global” schedule – starting on a particular day, and running for a fixed period of time – or a local “personal” schedule, in which case the serialisation starts at the time an individual subscribes to a personalised, serialised feed. That is, the serialisation is published according to when an individual subscribes to the feed. So if I subscribe to a daily, personalised feed today, I get the first item today, the second item tomorrow, and so on; whereas if you subscribe next Wednesday, you get the first item next Wednesday, the second item next Thursday, etc.
Two good examples of services that publish serialised feeds are DailyLit and Podiobooks. DailyLit produces books (some free, some for a fee) as serialised feeds (or via email installments) and Podiobooks serialises books as audio podcasts. Another example is RSS Response, an RSS “auto-responder” service in which a series of staged marketing or product support releases can be delivered to a potential customer over an open-ended period of time, but starting when they subscribe to the feed.
There are two main ways of handling personalised feeds at a server level: datestamping, and unique feed subscription identifiers.
The first, and simplest, way is simply to add a datestamp to a feed subscription URL whenever a page that contains a link to the feed is published. When a blog reader polls the feed server, the current time is sampled, compared to the timestamp in the subscription URL, and the appropriate number of items published to the feed. This approach is demonstrated on Openlearnigg, where a Yahoo pipe is used to provide daily serialised feeds for OpenLearn units (see Static RSS Feed Content, Delivered Daily for more on this); the “clockRSS” icon links to the daily feed:
[Note: the openlearnigg daily feeds appear to be broken at the moment:-(]
The second way is to add a unique subscription identifier (or set of identifiers, such as a user ID and a separate feed identifier) to the feed URL each time it is linked to. User settings can then be associated with each identifier in a small database, containing details such as the start date of the subscription, information relating to the schedule (such as how frequently items should be added to the feed), the provision of offsets and accelerators (for example, an offset might say that the user wants the first three items on the first day, item four on the next day, and so on; an accelerator might allow a subscriber to grab an additional item before the next scheduled release is due, accelerating the rate at which the serialisation is published to the subscriber). DailyLit uses unique subscription IDs to allow personalised scheduling:
In a commentary on Misconceptions about reuse of open educational resources, Juliette Culver rightly identifies “Misconception 1: The only type of reuse is wholesale reuse” (see also some of my own thoughts on this: So What Exactly Is An OpenLearn Content Remix?). However, that is not to say that wholesale reuse of opencourseware is not possible. For example, whilst I have not been engaged in remixing OpenLearn content, per se, I have dabbled in various ways of re-publishing course units in different formats (ebooks, for example, or via embeddable Grazr widgets on Openlearnigg, as shown in the screenshot below).
(For more examples, see Feeding from openencourseware.)
Republication is also possible in different contexts (such as an environment that provides alternative community, commenting or discussion tools).
Serialised feeds offer another possible context for re-publication, particularly for opencourseware, in which pacing is returned to mix, at least insofar as the subscriber to a serialised course is concerned. (There are loads of issues here with respect to serialisation discussion around serialised course content, but that is for another day and another post ;-) That is, by subscribing to a serialised version of a course, a learner can benefit from the paced delivery of the course materials, akin to the paced delivery that is achieved by attending a series of timetabled lectures over a term in a traditional institution.
For a long time, I’ve felt that serialised content on demand is an attractive offering, and I’ll be looking to explore this area far more aggressively than I have in the past over the next year or so…
As Stephen Downes noted in his essay “The Future of Online Learning 2008” whilst discussing Time Independence:
Being able to time the distribution of resources is a significant advantage. It allows for presentations, interactions and other activities to be encountered dynamically during the course of days or weeks. This space can be used to pedagogical advantage in addition to meeting the student’s scheduling needs, facilitating ongoing practice and recall. Dynamic scheduling does not guarantee success – students may simply delete the material as it arrives. But having this level of control makes it more likely students will be able to attend to the material when it arrives.
Self-pacing in online learning, therefore, isn’t simply the learner picking up the work from time to time whenever he or she feels like it. It is rather the employment of various mechanisms that will enable work to be scheduled. Pacing continues to be important, even in instances of self-pacing. Being free to set one’s own schedule does not mean setting no schedule at all. Nor does it mean that the release of learning activities and content is not scheduled at all. It is, rather, a meshing of schedules.
So to start the year, I’ve spent a little bit of time putting together a WordPress MU site that republishes OpenLearn content in a blog format, and additionally provides a daily feed for the republished courses: http://learningfeed.org.
The installation makes use of two WordPress plugins that were developed under the auspices of the OpenLearn project mid-way through last year: OpenLearn WordPress Plugins. The first plugin makes it easy to create WPMU blogs based on separate OpenLearn course units; the second provides the daily feed service.
The WordPress serialised feed plugin uses a timestamped subscription URL, and a relatively simple approach to scheduling (though I intend to develop this further).
You can find links to several examples of a republished courses – and their corresponding serialised RSS feeds – here: LearningFeeds Miscellany.
It is my intention for the first iteration of LearningFeeds to see just what sorts of thing “come to mind” when playing around with the syndication (republishing) of opencourseware in a WordPress environment, as well as the “issues” that will no doubt arise from using the first versions of the OpenLearn WordPress plugins in anger (I will document my exploration s in the LearningFeeds blog, and cross-link to them from OUseful.info).
In the meantime, please feel free to comment back here with any thoughts you might have with respect to the use of serialised RSS feeds in online education and training:-)
9 thoughts on “Serialised OpenLearn Daily RSS Feeds via WordPress”
An interesting post – my first concern was about the potential over-use of control of pacing which might conflict with a desire for individual needs to be met.
I was reassured by the thought that serialised RSS could offer a cohort of learners ‘shared experience’ so that the stimulus for discussion is based on a common rhythm of ‘newness’. This certainly seems to work for soaps!
Fantastic information. RSS is flexible enough to allow for many uses, and I applaud you for sharing some of those in this post. Our custom serialized feed generation process is rather complex in that we look for confirmation that prior episodes have been accessed before sending the next file. This is great if you go on vacation or are unexpectedly away from your computer for a time.
Happy to discuss that and more with you as necessary. And thanks for spreading the word of Podiobooks.com!
Your podiobooks “custom serialized feed generation process” ability to “look for confirmation that prior episodes have been accessed before sending the next file” sounds really useful, particularly where it’s important for the listener to hear every episode in sequence.
One of the issues with the WP daily feed plugin we commissioned is that if someone goes away then several unread posts will stack up. Using the date stamped feed url makes it tricky to “pause” the delivery of the feed, which is what your algorithm does natively and invisibly/in the background. (A less seemless/more clunky approach would be to use ID keyed feeds and have the use “pause” the delivery of the feed).
Just by the by, in podiobooks, is there also an ability for the user to “skip” chapters without listening to them?
And is there (or is there likely to be) a Podiobooks API available?
@richard re: your “first concern … about the potential over-use of control of pacing which might conflict with a desire for individual needs to be met”
– could you explain that concern in a little more detail, maybe with a use case?
re: “offer[ing] a cohort of learners ’shared experience’ so that the stimulus for discussion is based on a common rhythm of ‘newness’.” this is something I need to think about a lot more. The original intention was just to provide individual start date feeds, but being able to schedule “as if in realtime replays” across a group of learners acting as if they were a cohort, but following along at different points in time, is just such a beautifully quirrky to problem to think about.
NB it’s quite possible for a group of individuals to follow a single feed at the same pace and start date simply by sharing a feed URL, of course…
“Just by the by, in podiobooks, is there also an ability for the user to “skip” chapters without listening to them?”
We have a very basic user interface to allow them to add additional episodes to their custom feed. Very useful if someone is taking a long trip and knows that they have time to listen to an additional episode or two. I use this a lot when traveling for business, usually grabbing an extra episode of each book to which I’m subscribed.
In effect, you could use this to skip episodes, as most podcasters are set up to only retrieve the most recent episode. So if you just listened to #5 and wanted to skip 6, the last episode added to the feed, you’d need to manually say “release one more”, putting #7 at the top and most recent. Your podcatcher, upon sync, would then only grab #7. Kludgy, but doable.
“And is there (or is there likely to be) a Podiobooks API available?”
We’ve talked about it. The engine that powers the site was designed to be utilized by sites other than Podiobooks.com. So I’ll give you a qualified yes. If we had an interesting project to work towards… sure!
Comments are closed.