Last week Tim and I travelled to Brigham Young University to continue conversations started in June around how BYU’s University API initiative, Domain of One’s Own, and an emerging vision of personal APIs might converge. We spent the first part of this most excellent trip over dinner. I mention this because it just so happens David Wiley was in town, and Phil Windley was kind enough to invite him out to dinner with all of us. It was a surreal evening because we spent it talking about the parallel work Reclaim Hosting and Lumen Learning are doing, as well as hearing some fascinating stories from Phil about founding iMall, an early creator of e-commerce tools during the mid 1990s. It was one of those dinner conversations that will stick with me for a while, and it energized me thoroughly.
But the following morning it was time to get down to business. We spent most of it getting more insight into how BYU is defining their University API project. What is the University API? Phil Windley lays it out much better than I ever could in this post. But in short, it is the intentional defining, mapping and abstraction of the various relationships of data resources across an entire institution to enable the BYU community to easily access, share, and re-use information on campus and beyond. It draws to mind the Herculean task of building a subway system in an existing, living city like NYC at the turn of the last century. It’s arduous, painstaking work—but essential to modernize infrastructure. We spent a good part of the morning looking at how they defined a variety of resources, but in the end Tim and I are neither linguists, programmers, or information architects so remaining at the level of JSON bracketed abstraction for too long is always dangerous to productivity.
Luckily, we came with a specific plan, and BYU’s Chief Information Officer Kelly Flanagan is one of those rare gems that can take that abstraction and immediately refine it into a simple problem to solve, “how to we use our APIs to give students the ability to control the personal data in their own domain.” That’s where we come in (the we is kinda royal here, I’m just the blogger). Over lunch the discussion continued, and Phil, Kelly, and Troy Martin basically told us how excited they were about working with us to try and marry the abstract University API to the specific and personal domain. What’s more, they encouraged us. It’s amazing how generative some genuine interest and encouragement can be. After lunch I prepared for a talk I was giving to the campus community about “Digital Genealogies and Sovereign Source Identity” (more on that in a forthcoming post) and Tim caught some major inspiration.
Over the course of that afternoon and into the early evening Tim and I talked through, worked on, and even began to prototype an API-driven community site. Things fell into place for us. The UMW community site at UMW Domains is more than a year old, and Tim and Martha Burtis put that together in a couple of days with duct tape, FeedWordPress, and three Hail Marys. As we were showing it off to the BYU folks that morning several of the pages and many of the links just didn’t work. Even more of a reason for us to make sense of how we can start to bridge the data we collect and visualize for the community site using API calls. The community site prototype that Martha and Tim built accomplished everything it needed to: it recast web hosting as a fish tank rather than a black box. What we realized that afternoon was that our job now was to re-architect the community site for BYU so that it can provide all the data we get in the UMW Domains site now (recent posts, term, course, department, instructor, status, software, etc.) through API calls.
Tim started playing with the CPanel API immediately, and once he gets going it is a thing of beauty to behold. Upon creation of any new web hosting account on BYU Domains an api subdomain is created, such as api.timlovesapis.com. This will be the place where we start writing to the personal API. What’s more, Tim also figured out how to get Known installed by default in the root of every new account for BYU Domains using CPanel’s APIs (not live for everyone just yet). So, when creating a domain on BYU Domains, the first thing a student will see is not CPanel, but a customized interface of Known that will be their personal API of sorts. They can integrate their various social media using Known’s Convoy, quickly post files, but also make some basic calls to CPanel to create subdomains, install applications, etc.
Known becomes the interface for their initial domain experience, with the option of accessing CPanel at anytime. And when they install WordPress in Installatron it will automatically write course, term, software, status, etc. to their personal API file. What’s more, if they are installing WordPress (which a majority will) the JSON-API plugin will automatically activate (at least until it is core) and write information like their recent posts, tags, etc. to their personal API file. So, the student has an API that lists all posts, subdomains, software installed, term(s), instructor(s), department(s), etc. Structured data they can now use to organize their career as a student, and the community can call to frame the experience in aggregate.
The next morning we did a demo for Troy, and I think we realized that Known provides a crucial bridge for the personal API vision here. If Known is the default interface for BYU Domains, it already has an API baked in, and it integrates students’ various social media sites from around the web. Known is the layer we build the API calls to CPanel through a simplified dashboard, as well as double down on integrating a contextualized reader into Known that enables the community to start following other people’s work based on structured relationships. Think a Tumblr like interface for all posts for a certain course that can be organized into columns á la Tweetdeck. Or all posts across a department, faculty member, Twitter, Facebook, etc. The community site as imagined through Known with a contextualized reader that enables you to personalize the way you experience the flow of data.
How can we do this? Well, by partnering with Ben Werdmuller and Erin Jo Richey of Known who will be working with us to design the interface and API hooks for BYU’s community portal. I am hopeful that this will be the groundwork for establishing an entirely new interface for personal web hosting across all the institutional sites using Reclaim Hosting (as well as a long-term relationship between Known and Reclaim!). It is really exciting stuff, and if it pans out the way we’re imagining, it marks a pretty dramatic shift in making web hosting, managing your personal data, and structuring your online existence that much more integrated. I can’t even begin to tell you how lucky we are to have the good folks at BYU’s Office of Information Technology pushing us to innovate wildly. They are remarkably open and willing to help us experiment along these lines, without ever shutting down the conversation in regards to what could go wrong, or what might or might not be kosher. They are in fully exploratory mode right alongside of us, and they have swung the doors wide open for us to see what’s possible. It’s like a whole new level of access for making web hosting and personal name spaces part of the “integrated domain” of higher ed in all the augmented-human-intellect-beauty such an Engelbartian turn of phrase draws to mind!
Nice work y’all!! Excellent progress.
Hi, from the University of Southampton, UK. We have a project which might be of interest, as it’s possibly the other side of the coin to your work. We run an open data service (no APIs, no authentication) to provide access to key data about the organisation such as buildings, rooms, courses, events, organisation structure.
I love that, any good anecdotes/stories around how is it being used. I’m always in search for good examples of how this data can be a boon to the broader community.