Welcome to the PESC EdUnify Task Force collaboration space! If you are not already on the e-mail announcement and discussion list please contact Michael Sessa, PESC Executive Director, at michael dot sessa at pesc dot org for access to participate in the list and the wiki. Much of the content on this wiki is public for viewing, but to create content or view draft content, please contact Michael Sessa about participating in the project to obtain an user account.
Presently it is hard to access data across higher education. Data interchange standards are not widely implemented by vendors, academic institutions, and government agencies. Where standards are implemented they are not registered or documented in an infrastructure that allows them to be readily used by people building integrations and looking for data. EdUnify infrastructure will allow vendors, academic institutions, and government agencies to register their data interchange specifications and implementations and map them to standard terminology for interoperability. Users of EdUnify will be able to use these registry and annotation services to build integrations, inventory services, and access data across higher education. PESC is the right organization to undertake this effort, because it is a neutral party with a track record of success in developing and implementing standards.
For a list of Task Force members and contact information, see the PESC EdUnify Task Force Participants page. To enroll other participants contact Michael Sessa, PESC Executive Director, at michael dot sessa at pesc dot org.
We are presently gathering requirements and considering candidate technical architectures and design. To facilitate this process, the task force has implemented a fully functional EdUnify demonstration registry based on the open source BioCatalogue web service registry. EdUnify will be:
This is a summary of some killer apps that anyone (application vendors, academic institutions, people in their garage, Facebook, Google, Microsoft) could develop when EdUnify exists. EdUnify is the infrastructure that enables these composite applications. It is not the intention for EdUnify to build killer applications, but rather lay the groundwork and provide the infrastructure to promote the development of these new applications that reach across higher education. Building these killer applications without infrastructure like EdUnify is cost prohibitive and, in fact, many applications won't even be conceived until we can see the landscape of web service across higher education and other sectors.
These are the top ten. If you have more or better apps you can think of, please add them to the Killer Apps page. The applications we can envision help provide motivation for building the EdUnify infrastructure. Like the Web itself, the real killer apps will likely follow the infrastructure.
We often view external challenges outside the boundaries of our organizations as out of scope, out of reach and not something we can or should focus on. Assumptions are drawn and acceptance of the current state of affairs continues.
Innovation and progress is the push to do better, improve things over the status quo. Innovation does not happen in a vacuum. It takes effort. First, we need people to step up and challenge the status quo, question the methods and look to see if there are ways to overcome the challenges and assumptions. Second, we need to explore how our community can work together through our differences, to compromise and set the stage for progress. Third, we need to realize progress is incremental. Not everything has to be addressed all at once. And finally, we need to apply our efforts to a vision that we can share, that will address our individual circumstances and how the potential effort can help us achieve great things together.
Before going too deep into EdUnify, think about your use of email today and how easy it is for you to send and receive email. It does not matter which email program you utilize, the interchange works the same. Who, how and when did we establish the convention of email@example.com? How do we register domain names like academyone.com or emory.edu? How does the computer program I use, reference and send my email and how does my email get to my destinations without someone lifting a hand? And, how did the @ sign become the separator? These 'standards' reflect solutions and decisions made just few short years ago that has made email computing services simpler to use and transparent. Adoption and compromise are voluntary decisions. There was no law passed. There was no decree from government.
We can learn a lot by understanding the evolutionary path of email. What came first, the demand? Or, the innovation? How did a community come together to face the challenges of exchanging electronic messages? There were plenty of vendor products routing messages. How can we learn from the path taken by early ventures to bridge email systems? As they came together to address their differences, with similar set of challenges, how did they compromise? How did they adapt? Moving or accessing electronic data, in what ever form it is in, from program to program, place to place, across computers is complex. How did they reduce the complexity, obstacles and legacy of doing it my way?
Then, ponder how easy it is to travel by car north and south or east and west across state lines and towns across America. We have a system of roads we mostly take for granted today. Imagine what it would be like getting in your car and driving to the store five miles down a dirt path? Or, that we had roads, but their were no standards on how to travel on them, like which side do you drive on, or what do the signs mean along the way? On many toll roads, we now have Ezpass, a device put on your windshield that can be read from toll booths while traveling 35 MPH. It eliminates stopping, wasting gas and time. It consolidates monthly billing for tolls. It works on many highways and even parking garages. It is simple to establish one account that works across many States. And, it does not add costs to the trip.
In our recent memories, events often collapse and we forget about how difficult it was prior to let's say Google or the Cell Phone. How did we search for information in the 50's, 60's, 70's and 80's? What happened to card catalog files and the augmentation of libraries sharing their repositories that began in the 70's indexing holdings? Or, what was life like before Amazon or Facebook for many younger today. Do you recall Gopher, Compuserve or BackRub? Collaborative efforts can realize great results. Read more about three major technology innovations and collaborations born by a few people who came together to change our world for the better. They decided to overcome the challenges and invest in developing ideas that could bridge frontiers thought overwhelming. Not only did they change the face of America, they improved how we live and work reducing the distances and times we spend moving from place to place, either physically or virtually. Revolutionary Ideas
We are glad you have come to this wiki site. We have come together to face one of our toughest challenges haunting higher education and education efforts in general. That is, how can we overcome the inhibitors and obstacles of data access and movement, the huge costs layered within the movement and exchange of data across computer applications to foster new tools and methods to address the challenges of research, teaching and learning in the 21st century, which is not bound by border, physical or otherwise.
Across education, the utilization and effectiveness of data and information technologies is severely inhibited by access methods, differing protocols, non-standard payloads, varying data definitions, and inability to trust disparate applications stove piped by proprietary design. Billions of dollars are spent annually trying to move data across components employed by stakeholder computer systems. The current state of automation, with all its redundancy, unnecessary aggregation and inaccuracy render a tremendous burden on the educational investment society as a whole is making.
Policy, governance, research, teaching, administration, funding, and learning are all impacted. The unintended consequence of metered design without considering the external interchanges which contribute to additional obstacles and costs is avoidable. The accurate, authoritative and secure transmission of data spanning components and stakeholders would respect and reinforce autonomy and roles, by connection, rather than push the work around mentality that has been fostered by the industry fearful of data access, use and security.
The education industry spends approximately 4% of operating expenses on IT which approximates $50 Billion annually. Of that, approximately 50% or $25 Billion is spent supporting connections and movement of data across disparate applications inside and outside the institution poorly. Even with that much money spent to keep things band-aided together where funding has been applied, the ineffective use of technology is wasting away the capacity of tools and the investment in automation. Without addressing the challenge to bridge systems and components, we will be continually haunted by what could be, rather than what is. Automation can empower and serve the industry with innovation and unity in purpose. Thus, the call for EdUnify, to create a registry, lookup, and supporting services to enable applications and computer systems to seek and connect through a common abstract pipe following community developed methods, protocols, payloads and services promoted on a voluntary basis.
The following are examples of potential high-level functional goals.
The following are examples of enumerated types of services:
The Task Force is preparing very specific, structured use cases that the EdUnify frameworks will support to help identify specifications and technology it will develop or apply. The Task Force is preparing a set of use cases in a common format to help identify the constituents served and processes addressed in each use case. There is a template which can be used to start each new use case. For more details visit the Use Case page.