A Personal API

Personal API

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.

Suggested API Template

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:

Personal API Nuts & Bolts I

  • 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.

Personal API Nuts & Bolts III

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.

This entry was posted in reclaim and tagged , . Bookmark the permalink.

5 Responses to A Personal API

  1. Paul says:

    I’m not sure I understand much about APIs, how they work or what can be done with them, but I am intrigued by this personal API idea. One of the things I try to get across to students is that each of us is in charge of our own education, that it is our responsibility to make it work for us. It seems like a pAPI would make that more transparent or explicit, as well as empowering the individual in relation to the institution. Or institutions – if students owned their own learning space, maybe they wouldn’t need to be tied to a single school, but rather be free to build specialized degrees across institutions. “I am not a student ID number, I have an API!” or something like that.
    It also seems like an aspect of information literacy. Those library people talk about the value of information (http://www.ala.org/acrl/standards/ilframework#value), but mainly from the IP perspective. The value of personal info is in there as an afterthought, a minor issue, whereas with a pAPI it is right up front.

  2. Reverend says:

    PAPI, huh? You know I love that acronym 🙂

  3. tyelmene says:

    This reminds me of the discussion going on in the first days of what became micro formats about 15 years ago. It’s like hcard and fof all over again.

    • Reverend says:

      I hear you on that, and I really want to avoid any kind of spec in the end, I just want to see if some basic things work, and build a pragmatic approach to what this might be.

  4. I was digging through some old diagrams and came across the image on this post:


    Made me think of how much better this diagram would be with the whole Personal API idea you are blogging on. May need to update and revisit this idea once I can get some time to figure out APIs 🙂 It was a constantly changing/updating diagram anyways, so it needs another version of course.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.