changed:
-
<p>Ed started by recapping the findings of the report. There were a few questions asked for clarification. Don Waters asked what exactly they meant by “interoperability” – ability to transfer data, link up systems…? (Answer given by Ed: it depends on the context of a given project.) Ira asked whether, when they said “OSIDs,” they meant 1) developing an OSID implementation, which takes a lot of effort, or 2) using an OSID by employing an implementation in a particular application. In reading the report, it wasn’t clear which of those they were talking about. Ed said that, again, it depended on the context, but that in general the lack of #1 was inhibiting the use described in #2.</p>
<p>No one said that they thought they had been misrepresented in the report. </p>
<p>Then each of the two nominated projects gave a brief description of what they do and how OSIDs fit in. Gerry Hanley from California State University (CSU) – he is the Senior Director for Academic Technology and also the ED of MERLOT – described their project, Digital Marketplace (DM). The use case he described was: a professor is preparing for the fall semester over the summer, and goes into DM to write a syllabus. As he writes it, DM is automatically calling up all the relevant content from zillions of publishers, the library, etc etc. Students can select the media in which they want their content, and administrators can relate learning outcomes to the content selection. OSIDs are useful because of all the interoperability necessary. DM has to interact with CSU’s 23 campuses, each with its own authentication system. It also has to be able to draw upon the content from hundreds of publishers.</p>
<p>Jens Haeusser from UBC described Kuali Student, which is in an even earlier phase than DM. This is an SOA-based student management system that needs to be able to interact with the full range of enterprise applications that are found on campuses. They are in a planning stage right now but the ultimate plan is to deliver a complete reference implementation, which they don’t expect to be adopted in any place in its entirety. Jens said that they are using OSIDs for the external interoperability, but that they are using web services within the system. A few people (from OKI) asked him to explain this decision. He said that OSIDs were too standard – they were too much of a constraint on what they wanted to do. Jeff Kahn (the other consultant) jumped in here and said that comparing web services vs. OSIDs was comparing apples to oranges because “OSID” is a specific standard, where “web services” have many instantiations. Everyone seemed to agree with this. One of the OKI people said that the benefit of using OSIDs internally as well is that it creates a clear “tear here” perforation for others who want to reuse parts of the project. Jens said it has been hard to get from the conceptual idea of the OSIDs to figuring out how to implement them, because there aren’t many prior implementations. (This is the chicken and egg problem that so many network markets face – who wants to buy the first fax machine? Except it’s worse because the fax machines have been on the market for 7 years and no one has bought one, which itself starts to seem like a signal.) This was obviously not resolved. Jens also said that one of the things they re already concerned with is how to build a “sustainability model,” by which he meant the community or commercial ventures that would support it after it was built.</p>
<p>MacKenzie Smith jumped in to ask a couple of questions during this period. Jens said that KS needed to be able to interoperate with repositories. She asked, “What is your mental map of a repository? What do you mean by that?” (The answer was, essentially: whatever our potential users want us to interoperate with that they call a repository.) MacKenzie asked the CSU people what they would do if a small university press didn’t have the resources to implement OSIDs, as the big publishers do (and are doing). CSU acknowledged that they might not be included, but that the hope was that there would be enough implementations of the relevant OSID by that point that it would be very easy for a small press to borrow one; it wouldn’t need to build from scratch. </p>
<p>After the discussion of KS and DM had run its course, Ed put up the “decision matrices” that were in the report – which projects seemed most promising for OSID development, and which OSIDs seemed most promising for implementation in those projects. At this point, Ed invited the group as a whole to take over and decide what to do next. Brad Wheeler asked, “What is the objective of this?” Ed turned to Chris.</p>
<p>Chris said “The reason we originally approached Jeff and Ed about this was that I wanted to know, how can I be more effective in encouraging grantees to think about implementing interoperability?” He said he wanted to hear from those present where it made sense to invest next. Ira chimed in, asking, “Is there anything missing in this report? Or, if I’ve read the report, do I know all I need to know about the way to move forward?”</p>
<p>Brad wanted to add an objective: “It’s like 2002 again, and we’re having the same conversation. I feel like I’m in “Groundhog Day.” Back then, we thought OSIDs were a great idea, but there weren’t enough implementations to make it practical for us to use, and we all talked about how there weren’t enough implementations. What I want to know is, are we someplace else now? Are OSIDs more ready to be used? Or have they been supplanted? Or have some of them taken off? I just want to come to an understanding of that so we can get out of “Groundhog Day.” (Heads nodding.)</p>
<p>Ira agreed with the Groundhog Day analogy. “I, too, have been hearing the same thing over and over. I’m experiencing a cognitive dissonance. Brad tells me that OSIDs are unusable, then CSU says that they fit their needs perfectly. When should we be insisting on adherence to a set of standards? When should we be telling grantees that they must use the OSIDs?”</p>
<p>Chuck: “I wasn’t going to take Ira’s bait, but…you have to want to use them. OSIDs are very attractive when you’re in the planning stages, but not when you are actually writing the application – then you need to do first what’s most necessary, and next what already has implementations. Abstractions are good – everyone agrees on this. But OSIDs are not good abstractions. Not unless you put a lot of energy into them. The exception is the repository OSID, which has benefited from having a champion in the middle who is fighting for them. (I wasn’t clear about who this was – I think CSU.) Now there are implementations of the repository OSID. And for DM, it’s mission critical. They are primarily a consumer/integrator, so they are going to make sure that it will work. For the other OSIDs, where are the implementations? Demos don’t count after 7 years. When you are actually doing a project and your survival counts on it, interoperability seems less important than just getting the thing done.”</p>
<p>Ira: “Sakai was sold on the basis of using the OSIDs, but it didn’t turn out that way…so are you saying that Kuali Student won’t work?”</p>
<p>Chuck: “I’m not saying that it won’t work. I’m saying that they’ll come to you in two years when it’s time to implement them and they’ll say that they have found something else.”</p>
<p>Discussion again about how it’s different for CSU because interoperability is core to what they do, and because of their position as a network of 23 campuses. They have to make interoperability work. </p>
<p>Aaron (from OKI, I think) suggested that if the repository OSID was a success, then maybe it would be a good idea to develop a model together on the basis of that. What does an OSID need in order to become a mature OSID? </p>
<p>Chris: “I’m surprised by what I’m hearing. If you’re telling me that the only way to make collaboration work is to have a middle man, that means I should only be funding state systems, assuming that they will work out all the interoperability kinks internally because they have to, and then others can benefit from their work. If I were to listen to this, then I wouldn’t fund collaborations any more. But I don’t think that’s in the interest of the people in this room.”</p>
<p>Chuck replied that he was just saying that interoperability would take a back seat when survivability is an issue. When you have to get Sakai done because 60,000 students will be using it in the fall, all the interoperability stuff, even though it sounded great in the planning, will fall by the wayside. </p>
<p>Ira: And CSU?</p>
<p>Chuck: That’s different. Their survivability depends on it. I think you ought to encourage planning for interoperability, but know that the application, the thing itself, actually has to be built next, and only then, when it’s mature, can you begin to think about interoperability.</p>
<p>Chris: I need it to be measurable. How do I structure a Mellon grant along those lines? I can’t just have some vague promise.</p>
<p>There was then some discussion about one of the OSIDs that hasn’t taken off (authentication/identity management). Chuck: Has it changed at all during the last 7 years? </p>
<p>Jeff (OKI/MIT): We were expecting to hear back from all of you about what you needed. We incorporated what we heard. It was all up on the website, ready for comment. </p>
<p>Someone from Indiana: I appreciate what you’re saying, but you didn’t incorporate our feedback. </p>
<p>Chuck: It’s like Groundhog Day all over again. </p>
<p>OKI person: Chuck, there isn’t a shred of documentation from you on the website…</p>
<p>Jens (being conciliatory): What I’m taking from this is that if OSIDs are going to remain relevant, the process for evolving them is important, more important than where they start out.</p>
<p>Chris: This seems like a good time to break for lunch. Hopefully when we come back everyone will be ready to engage in a productive conversation.</p>
<p>After lunch…</p>
<ul>
<li>At this point, my notes are more sketchy. The conversation got more technical. A few random notes from the discussion:<br />
</li>
<li>No one could really have this conversation without making reference to the other interoperability options. The premise of the paper was that this wasn’t about whether OSIDs were the best way to do it, only if they applied to these particular projects.<br />
</li>
<li>I had the impression that people were playing along at this point, not really engaging – much as they might have done during the interviews. <br />
</li>
<li>Brad said that he met with 5-6 CIOs this week and they talked about technology “grand challenges” for IT in higher ed. ID management is at the top of his list. (Would be interesting to know what else is up there.)<br />
</li>
<li>Brad also pointed out that three of the four OSIDs under consideration are not specific to higher ed (workflow, id management, repository). Only the gradebook is specific to higher ed. Should they be taking into account the fact that lots of other entities outside of higher ed are also trying to solve these problems? (There was no real answer to this.)</li>
</ul>
<p>I had to leave right at 3:00pm. Ed had just wrapped up, summarizing what was heard about each of the four OSIDs. Brad stepped in and asked what action should he be taking that is different now. Otherwise, it’s “Groundhog Day.” He advocated just deciding on something, whether it’s establishing a workgroup for each of the OSIDs to report back in 30 days, or deciding to forget 1 or 2 OSIDs altogether (“the problem in higher ed is that we never stop anything…”) <br />
</p>