On Aggregation, and Crow
4 min read
A mildly edited version of my response to Jim Groom's post over on the bava --
D'Arcy mentioned the need for this to scale, and he's right. With that said, I don't think we need to have scalability to 100K students as a first goal. The beauty of the small pieces loosely joined is that it's easier, and that it's a step away from the monolithic LMS's so beloved by so many --
Toward that end, it's good to consider what we'd need to carry from the blog to the aggregator in order to connect a student work with an institutional SIS/LMS. To start, I see two factors as essential: first, mapping a feed to a student, and second, mapping individual posts from within a feed to a course.
The first piece is relatively straightforward: within the institutional aggregator, map each feed to a userid within the school's system. This way, institutional IDs are not exposed via any type of feed, and the connection of student feed to institutional record occurs where it needs to: within the institutional aggregator.
The next piece gets trickier: embedding course info into the feed. I actually think the easiest way to do this would be to use the Atom feed, as the Atom feed is designed to carry additional info (as an xml payload within the feed). Google is using Atom feeds this way on Open Social (although for a far more complex implementation, carrying friend data), and given that WP already generates Atom feeds, it makes sense to leverage what's already there.
So, on the WP side: some new code that creates a drop down list of course names keyed to course IDs. When a person is creating a blog post, they have an additional field containing a list filtered to their own courses. If we want to get really tricky, we could include whether the poster is a student, instructor, ta, etc, for a specific course. This would involve querying/syching data out of the school's Course Management System and exposing it via the WP UI.
On the Drupal side, this data would need to be mapped into taxonomy terms (and this code already exists/is working on the feeds site). This mapped taxonomy term would automatically generate a feed from within Drupal of every post in the course, and these posts could also be displayed on a course by course basis -- so we could filter by author, course, keyword, date, etc. Then, within Drupal, OPML feeds per course would need to be exposed to privileged users -- these OPML feeds would be exportable, and would allow someone to subscribe to all the feeds in a single course in one step. Creating these OPML feeds would require new code. Alternately, it would be possible to create a page view of all the posts within each course using the views module, date filters, etc.
While there would still be more work to do after this, coding solutions for these two items (add course data to the atom feed from within WP, and generate the OPML feeds from within Drupal) would allow feeds from WPMU to be aggregated and sorted by student and course.
The advantage of creating the drop down list for courses is that the process of selecting/typing the correct tag is simplified. The disadvantage, though, is that any user not on a school-offered blog is out of luck. In order to support a wider variety of platforms basic keywords could be used on a course by course basis. Then, within Drupal, keywords that have been reserved for a specific course could be handled differently than other keywords. This system would be far more prone to user error (and would subsequently have issues scaling) but it has the additional advantage of working with any blogging platform that supports tags on posts. WP does that, right?
:)
Also, re the title of your post, I make a habit of eating crow, but I like to do it in style.
Bon Appetit,
Bill
