e-Literate

Present is Prologue

Tag: interoperability

  • The Portal is the Platform, Part III

    This post is part of a series on the concept of a Learning Management Operating System.

    I have argued in this series that the heart of an LMOS should be a portal. The main reason I have given so far is that a modern portal is well suited to handle the long tail of specialized learning applications. But portals have many other virtues as well. For a good overview of the benefits it offers to a higher education environment, check out this report [PDF] put out by The Observatory on Borderless Higher Education. In the specific case of an LMOS, the second virtue that I want to highlight is flexible groups functionality. (more…)

  • Now, That's What I'm Talkin' 'bout!

    An excerpt from Sakai’s press release regarding a demonstration of the IMS Tool Interoperability (TI) standard:

    The demonstration included four LMS systems including BlackBoard, WebCT, Sakai, and Moodle. The demonstration included three applications: Concept Tutor, Samigo(Sakai), and QuestionMark. All LMS/Application combinations worked and were demonstrated at the meeting which validates the interoperability of the IMS TI specification.

    The demonstration was the culmination of nine months of significant co-design and engineering between all of the participants.

    Now that the interoperability demonstration is complete, the standard is expected to be published Fall 2005. As long as the standard is finalized in time, we expect that this feature will be present in the Sakai 2.1 release in the Fall 2005.

    (more…)

  • Doubts about OKI and Sakai

    I almost appended this as a comment to a previous post, but I decided it was important enough to elevate to the top level. I received this email from a person who wishes to remain anonymous but who has at least some first-hand knowledge of OKI:

    I didn’t want to publicly disparage the OKI project but privately I have severe doubts at its role in edu software development. I can’t think of any comparable edu project to OKI in terms of hype and funding.

    Sakai is using some of the OKI OSIDs but they also acknowledge that they need to go far and beyond OKI and have thus created their own set of Sakai APIs. Furthermore, as you alluded to in your post, this is not lightweight development at all. My biggest fear about all of these recent Mellon-funded edu tech projects is the immense barrier to entry because of the development difficulty. I fear that only the elite, the MITs, UMiches, Stanfords, will be able to contribute and play in this field.

    This strikes me as a very serious concern. In our quest for technical standards of interoperability, are we losing sight of loose coupling? Are we trying to over-engineer something that perhaps would work best through organic growth?

  • Groove, Sakai, and OKI

    Martin Terre Blanche has an interesting post (found via edu_rss) on why he won’t be using Groove and what he thinks will (and won’t) become a viable alternative. His strongest argument boils down to lock-in and data exchange problems. He believes this to be a fundamental problem that is common to the current crop of both desktop and web-based collaboration tools. Here’s a sample of his analysis:

    I doubt if there are other desktop products that do a better job than Groove and I don’t think web-based group collaboration systems such as yahoo groups are really the answer either. I think two things are now on the horizon that will make the sort of simple straight-forward collaboration so many people need possible:

    1. The development and wide acceptance of simple RSS-like standards for scenarios not currently properly catered for by RSS, such as identity, group membership, and events. This will hopefully make many more kinds of collaboration possible, patterned along the same lines as the open, distributed collaboration currently happening via blogs and RSS.
    2. The development of second-level tools that draw together granular collaboration services into coherent higher-order tools. There has recently been a flowering of wonderful new online collaboration tools (such as spurl, furl, flickr, bloglines and many others), and many of them (including Google itself) come with programmer interfaces that make it possible for developers to access some of their functionality and incorporate it into their own creations. Mostly the tools people have built so far have concentrated on creative ways of using the functionality provided by each separate service, but I think it is likely that soon tools that draw on several systems simultaneously will start to emerge.

    These two points sound roughly like what OKI and Sakai, respectively, are trying to do for world of course management systems. But are they going to be successful? How lightweight is OKI? (Certainly not as lightweight as RSS, is it?) Why is it necessary for OKI to be programming-language-specific (i.e., it requires Java)? How easy is it, really, to write a service that plugs into Sakai via OKI? Or is it really the uPortal standard rather than OKI where a lot of this plug-in-type work can happen?

    Honestly, I’m very confused. If anybody out there can clarify the situation, please post to the comments here. (Sam Ottenhoff, are you reading this?)