Personal APIs and Academic Libraries

Roger Schonfeld’s “Improving Privacy by Rethinking Architecture” post on The Scholarly Kitchen blog does an excellent job of exploring the question of privacy and third-party data collection for researchers and academic libraries:

By having comparatively little user activity data on their own hands, and fragmenting those data they do keep, libraries may feel they have sidestepped an ethical dilemma [researching anonymously]. But they surely have missed the opportunity to build the personalized discovery and research information management tools that scientists and other academics need. In doing so, libraries have underserved researchers and other users, putting themselves at a competitive disadvantage relative to other providers. But at the same time, they have not placed limits on the data gathering and usage of content providers and other vendors nearly as strictly as they often claim for themselves.

It’s a tricky issue, and Schonfeld adriotly underscores the irony of outsourcing research services as a means of exonerating your library, while at the same time forcing the community you serve into much more precarious conditions. And while steps need to be taken to manage the sharing of data with these third-party services, the deeper issue he gets is that our thinking assuming the current state of IT infrastructure. What if that infrastructure was designed in such a way that academics had control over the data they shared while doing their research. Not only as a means of privacy protection—though definitely that—but also as a means to extend such a “decentralized architecture” to serve as individualized research archives (a personal cyberinfrastructure).

I was excited Schonfeld highlighted the Personal API project Reclaim Hosting is working on with Brigham Young University presently, and I really liked the way in which he extrapolates the vision of providing students more control over their data to researchers controlling access to their own scholarly work, and changing some of the basic ways we understand sharing and publishing one’s work.

If successful, it is possible to imagine such a decentralized architecture being extended to serve the needs of a researcher account in terms of library resources and content platforms. Indeed, I have argued that a cross-platform user account controlled by the researchers themselves would bring vast improvements in the processes of authorizing access to an appropriate copy of an information resource, while dramatically improving one’s control of one’s own data. Such an architecture represents a sea-change compared with today’s systems and it is no small thing to imagine the costs and logistical complexities of a transition.

The logical and political complexities of such a transition are no small thing to say the least. And while organizations like BYU that have visionary folks like Kelly Flanagan and Phil Windley leading the charge are rare, Schonfeld’s final note suggests quite hopefully that alternatives are both possible and important:

Even so, the work that Reclaim Hosting and BYU are undertaking is more than just experimental. It suggests that, when the political and organizational stars align, an entirely different architecture for the control of user data is possible.

That is so awesome, and why not? The time has come, and I know for certain that numerous other institutions are keen on what the folks at BYU are doing, and are prepared to double down on giving people more power over the online identities, personal data, and digital domains. Reclaim is in the air!

Domains as Ground Zero for the Struggle over Agency

BYU’s Bold Plan to Give Students Control of Their Data

BYU’s Bold Plan to Give Students Control of Their Data

I was really pleased with Marguerite McNeal‘s article in edSurge on Brigham Young University’s Personal API experiment. It can be hard to explain (at least for me), but she does an excellent job providing an accessible frame for the project by looking at it in terms of students finally being able to manage and control their own data. I think the following paragraph summarizes the idea behind a personal API as clearly as anything else I’ve seen:

A personal API builds on the domain concept—students store information on their site, whether it’s class assignments, financial aid information or personal blogs, and then decide how they want to share that data with other applications and services. The idea is to give students autonomy in how they develop and manage their digital identities at the university and well into their professional lives

The idea of autonomy in relationship to our personal data puts the discussion in a far broader context, and its immediacy is anything but academic. That said, I think it’s telling that a number of universities have been pushing hard to bring the importance of controlling your data to their academic communities. BYU’s work around the personal API is a really exciting early attempt at what this might look like. I could listen to Phil Windley talk about what he calls “sovereign source identity,” an idea he credits to Long islander and UMW grad Devon Loffreto:

“We want to teach students that this isn’t the only way identity happens online. They can create their own,” Windley says. This fall BYU introduced its Domain of One’s Own pilot to 1,000 student and faculty participants. But offering personal Web spaces is just the beginning, Windley says. “Domains help students understand their personal identity. The next step is understanding your personal data and how you control that.”

Absolutely right! And Adam Croom, who has been going gang busters with University of Oklahoma’s Domain of One’s Own project OU Create, frames this argument along the lines of a negotiation that should be taking place but isn’t:

“It’s the idea that tapping into one’s data should be a negotiation that the student gets to make,” says Adam Croom, director of digital learning at the Center for Teaching Excellence at the University of Oklahoma (OU). “Why can’t I manage what apps tap into my data, whether that’s the learning management system or the bursar’s office? Why aren’t there terms and conditions for students to understand who has access to their data?”

Another article I found alongside this one, thanks to the Cassandra of Ed-Tech*, was the article in Education Week proclaiming 2016 will be “The Year of Agency.” If that’s right—and I hope it is—that means more an more universities will need to start rethinking their infrastructure, and APIs have helped BYU and University of Oklahoma do just that. And so much of that work has been make possible thanks to the tireless evangelism of Kin Lane who has provided a vision of what APIs can be for Higher Ed. One we desperately needed.

At the same time, giving students, faculty, and staff more control over their data will be without some serious struggle. A response to this article published today on EducationDive illustrates why giving students control over their data might be an issue for some:

Schools are tracking student movements around campuses, incorporating data about how many times they visit the library or the tutoring center into performance data, merging that with student information system and learning management system data, and then developing predictive models to help counselors and students themselves. Giving students access to their own data is one thing, but letting them block others from seeing it is a different beast that could derail retention efforts.

Derailing retention? It’s strange to see the idea of allowing students to decide who gets to see their data, for how long, and why as somehow antithetical to keeping them? There is a joke in there somewhere. Fact is, the realities behind the learning analytics applications that have been relentlessly tracking student’s personal data may very soon be coming to a head. I would bet there has been little to no transparency about what student data universities are tracking, and whom they are sharing it with. Hell, I’m sure a number of universities aren’t even aware themselves of what data these third party applications are collecting. The idea that someone empowering students to opt-out of these unilateral relationships with various technology vendors is somehow preventing them from doing their job is demonstrative of just how much of the job of teaching and learning they’re offshoring to third-party technology solutions. And I won’t even get into the insane idea that tracking a student’s movement around campus is a sound academic counseling strategy.

Reclaim Hosting was born out of a movement that is grounded in the principle of empowering students and faculty to take control of their teaching and learning. And as Phil Windley notes, understanding who has access to their data and how it is being used will be ground zero for that struggle if we are, indeed, entering the year of agency.

_______________________

*I found this article thanks to the all-knowing, all-seeing Audrey Watters, who linked to it in this week’s Newsletter. You’d think given I was quoted in this I might know about it, but Audrey actually reads the web—all of it—unlike me :)

Reclaiming Community at BYU with Known

Screenshot-2015-11-11-10.00.14-1024x553.png
BYU’s Community Portal

We’ve been really lucky at Reclaim Hosting over the last year two years to have had the good fortune of working with the good folks at Emory University, University of Oklahoma, CSU Channel Islands, and Davidson College. These four schools have believed in what we’re trying to do from the start, and they’ve been as much partners and collaborators as clients. What’s so cool is that it has not stopped with them. The work we have been doing with Brigham Young University’s IT department over the last 6 months represents an exciting continuation of Reclaim’s partnership with universities to help co-create and implement a vision of what’s possible. What’s more, Reclaim’s not working alone on this one, we have finally been able to get serious and work hand-in-hand with Ben Werdmuller and Erin Jo Richey at Known to make these visions a reality. But I’m getting ahead of myself here, let me back up a bit…

Last Winter BYU’s CIO Kelly Flanagan and Enterprise Architect Phil Windley came to UMW to find out more about Domain of One’s Own. They have been working on a broader project to define a University API across their campus, and they saw personal domains and web hosting as a way of providing students spaces to manage and control their data in a space of their own. Kelly Flanagan has recently written a post, “Personal Domains, APIs, and Portfolios,” that captures the spirit of their project, and pushes to the very limits of decentralized data ownership viz-a-viz a personal API:

Imagine a world where other sites on the web don’t hold your personal data, but instead request access to the data they need through your Personal API. Perhaps you grant them access to only the portions they actually need and restrict them from others. They use the resources they’ve been authorized to access, perform the business functions you desire, return results, and their access is revoked.

This is a perfect marriage with BYU’s University API project, and represents about as vast and ambitious a vision for fundamentally rethinking Higher Ed IT I’ve yet to come across in my 10 years of instructional technology. But actually creating such a vision starts in small, concrete ways. When we were showing Kelly and Phil Domain of One’s Own community site, that became a focus for BYU. They were very interested in building that for their pilot, and they signed on for it over the summer. The issue was the community site Martha Burtis and Tim built almost two years ago is beginning to show its age and neglect (less is not always more). Trying to reproduce what was created as a prototype at UMW for schools working with Reclaim didn’t make much sense. It wasn’t easily abstracted out; Martha has been promoted up to grander things, and we needed to come to terms with the fact that we aren’t software developers. We can help imagine and create the infrastructure, but we need to start brining folks into the equation who specialize in developing specific applications like this—particularly if BYU’s community hub is going to support the Personal API vision.

So, in late September Tim and I traveled out to BYU to have just this conversation around the Personal API, and how a re-imagined community hub might be the first piece of that puzzle. The trip was a great success for Tim and I because we made some real headway on the initial vision of an API-driven community site. What we came away with was not only BYU’s continued support  on this project—they rule!—, but also the go-ahead to bring in Ben and Erin of Known to start building BYU’s community hub on top of Known.

What does this mean exactly? Well, that’s the fun part. Known already has an API built-in, so if Domains at BYU “beings with the Known” (to quote the great Adam Croom) the entire experience changes. For example, what would it mean if when you signed up for BYU Domains the first thing you saw was not CPanel, but an on-boarding process that begins with the option of integrating your various social media services through Known.

Reclaiming Community at BYU with Known
Connect your Social Media through Known’s Convoy

What’s more, once you have done that, you default to a page that is a quick and easy publishing space to send your various work to your social media accounts (the personal API at work already).

Reclaiming Community at BYU with Known
The Known Dashboard in BYU Domains

So, as you can see this post in the default page for my BYU Domain becomes a means of pushing to my WordPress blog, Facebook, Twitter, Tumblr, etc. All this being handled by Known’s Convoy, which does the work of connecting your domain with these various social media sites automatically. Now, by extension, there is no reason this can’t integrate with BYU’s University API. There could be buttons underneath the various post types that allow students to send their work to a particular class using something like Canvas’s API.

Reclaiming Community at BYU with Known
Privacy matters

What’s more, built into each post are various privacy settings: Public, Members only (limited to the BYU community), and Private. [When talking to Tony Hirst about this, he recommended a fourth type called “off-campus” which allows students to post to their social media sites from Known, but not have it aggregated to the community site. I like that idea.] But where is this community site you speak of? Well, built into every students dashboard is a Community link.

Reclaiming Community at BYU with Known
Toggle to view community posts

And when I click on that I can see what is happening around the BYU Community within your stream. Not unlike Tumblr. You’ll notice my domain is now showing me Kelly’s post about Domains.

Reclaiming Community at BYU with Known
Posts from community read in my Domain

The reader is a view of the community, but ultimately much more once we get targeted data via APIs. it can be a view of all the posts from one course, all the post from your Facebook community,  all the public posts to Facebook from the BYU domains community, same goes for Instagram, Twitter, Tumblr, etc. (hence why the “off campus” feature in privacy setting could be OUseful). A targeted, community based reader of sorts that integrates course and distributed social media based on tags and data. A vision of aggregation heretofore only dreamed of in our edtech philosophy.

Reclaiming Community at BYU with Known
BYU Community Site Directory

What some of those tags and features might be is loosely framed in the site directory feature of the BYU Community site Ben and Erin have built, but that is only limited by how BYU wants to use their University API to integrate with the Personal API.

Reclaiming Community at BYU with Known
Elastic search in BYU’s community hub.

You can also search across specific content types, but this could easily be extended to search across social media sites, departments, courses, etc.

The work Erin and Ben have done on the Community Hub for BYU is phenomenal, and this is just the beginning. BYU’s community hub provides a model that we can now abstract and provide to other interested schools, and partnering with Known on this may very well changed the way we imagine Domains not only as personal empowerment online, but also community engagement.

Now, having Known as the default interface for BYU Domains in no way rules out the ability for users to install other applications, subdomains, etc. We are currently thinking through what’s the best way to provide a quick and easy way to create subdomains or install WordPress, as well as a simple means of toggle to CPanel to work from there. That said, the switch could be a major one for communities used to working in CPanel, so we to think intently about what this means for the community at large, and what works and what doesn’t. But thanks to BYU’s willingness to experiment, we have a partner that is helping us work through these questions currently, and we may have answers to some of these questions as soon as January.

These are very exciting times for Reclaim Hosting. It’s cool to see the visions we’ve been courting as a community for years and years start to take shape in an actual application built upon the values of an open and independent web.

A Domain Admin Dashoard with APIs

In my last post I tried to capture the work Tim and I did at BYU last week figuring out how an API-driven community site might work. The post is heavily narrative and as much notes for us and BYU as it is a peek into our thinking. The issue with that post is there isn’t really anything to help people visualize what this might look like. So, in this quick post I am going to share how we can use API calls to the web hosting interface CPanel and its client management software WHMCS. Peter Sentz, who is running the Domains pilot at BYU like a boss, requested (and I believe many other schools are interested in something similar) a quick dashboard/overview of how many users, accounts, and domains there are across the system. [The difference between users and accounts here is that users include all those who have also expressed interest, but may not have been given an account just yet.] So, on the heels of our work at BYU, Tim setup a page in the BYU Domains WordPress home to pull that information in from CPanel via API calls. It looks like this:

Screenshot 2015-10-06 19.14.28

That is the beauty of the API right there. Taking info from various systems and tying it together in a clean interface where an admin like Peter could use it. Another issue folks were having was finding a specific user’s domain and information. So based on a quick userid search form, Tim was also able to find a specified user’s domain and the date they created it. What’s more, it also includes links to that individual’s CPanel dashboard and their client info in WHMCS. Something like this:

Screenshot 2015-10-06 22.25.13

That’s about as solid an example of how we might start using these various API calls to create context specific interfaces for our Domains community as there could be. This is stuff Kristen Eshleman at Davidson College has been pushing for since the summer, and I think we are about to break it wide open with the work Tim is doing, not to mention the work Ben Werdmuller and Erin Jo Richey of Known fame will be doing to create integrated, personalized domains for these institutional communities. It’s exciting stuff!

Initial Notes on an API-Driven Community Site for BYU

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,  and 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.timelovesapis.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!