Having just blogged about the overall experience of the University API conference I spent the last two days at, and I wanted to get down some of the more focused discussions and thoughts around how the University API might intersect with some of the work we’ve been doing around Domain of One’s Own. First and foremost, what is a University API? Well Phil Windley breaks it down brilliantly in this post on the topic, and this is the pull quote for me.
We’re…designing and implementing a University API. The idea is simple: identify the fundamental resources that make up the business of the university and design a single, consistent API around them. A facade layer will sit between the University API and the underlying systems to do the translation and deal with format, identifier, and other issues.
BYU’s Doug Walker provided an excellent overview of how they’re designing their University API template in terms of URL structures and JSON. I came in and out of the conversation based on my limited understanding (though it’s getting better), but the discussion followed the concepts discussed in this tutorial—a work in progress.
This was an important session because it connected with the conversation I had with BYU’s Troy Martin about the idea of a Personal API after the session I convened around Domain of One’s Own on Wednesday. We got to discussing how domains can be understood within the context of the University API—and this is where things started getting kind of interesting because BYU is running a Domain of One’s Own pilot starting this fall. As Troy said, what if one’s personal domain becomes the space where students can make their own calls to the University API? What if they have a personal API that enables them to decide what they share, with whom, and for how long. For example, what if you had a Portfolio site with a robust API (which was the use case we were discussing) that was installed on student’s personal domain at portfolio.mydomain.com, and enabled them to do a few basic things via API:
- It called the University API and populated the students classes for that semester.
- It enabled them to pull in their assignments from a variety of sources (and even version them).
- it also let them “submit” those assignment to the campus LMS.
- This would effectively be enabling the instructor to access and provide feedback that the student would now have as metadata on that assignment in their portfolio.
- It can also track course events, discussions, etc.
The Personal API, through a very focused use-case of the personal portfolio, provides the means for students to have greater control over their data. A de-coupled application running on their own server yet seamlessly connecting to the University’s various services. A scenario wherein students can manage their learning in relationship to a broader University API. And the portfolio is just one use case, you can imagine a blog, resume, financial aid, transcripts, university applications and forms, etc.
The idea of controlling one’s personal data as well as providing a platform for literacy became the prevailing “why” of a personal API during the conversations, and that was very cool. The how is to start small with a simple portfolio program that connects to some of BYU’s APIs to see how it works. Doug Walker noted it might be a bit hairy because the idea of personal API in some ways resists any set structure imposed on a student’s domain. I agree with that, and I think that’s why you wrap some of that structure and basic framework for the API in a single application, like a portfolio, before trying to map out some kind of Personal API spec that every student must adhere to.
In some ways I am blurring two sessions we had on Thursday around the Personal API. The first was a broad discussion of what it means, it was focused around questions of how we control the permissions of our data, rather than hand that power over to others. There’s a pretty free range set of notes from the session, but I think this was the groundwork for the session in the afternoon when a handful of us sat down and tried to imagine the basics of this portfolio. We pulled Tim Owens into that discussion, and I think we have a rough idea of what a very small piece of a Personal API might look like.
What’s more, Kelly, Phil, Troy, hopefully Kin, and any other interested party are going to form a loose working group to hammer on this before the next University API conference in January 2016. I’m really looking forward to this idea. Not only does it deal with questions of student empowerment when it comes to their data, but it could also mean a whole knew way of allowing us, and anyone else with access to the data via the API, to imagine new ways of aggregating, visualizing, and mashing up the data.