There are three layers in Sakai:
- JSR 168 (uPortal is one implementation of that spec)
- The OKI APIs
- The Sakai APIs
I'd say these are listed roughly in order of importance. JSR 168 is the most lightweight and the most ubiquitous. As a side point, I think it may be just as important for dotLRN to be able to take JSR 168-compliant inputs as it is to be able to output to it. Enabling dotLRN users to create portlets for externally developed JSR 168-compliant tools would be a win.
OKI would be next in line. OKI has gotten an enormous amount of hype but it remains to be seen whether the APIs are going to be too cumbersome for widespread adoption. I think it will be very important to have work done on OKI for marketing reasons but, realistically, I'm not that sure there will be a whole lot of practical applications for the next couple of years. You might want to pick a few OSIDs that look the most useful to implement first and then have a longer-term plan for full compliance.
The Sakai API's themselves are probably least important in the long-run, since they are specific to Sakai. Before you put too much energy into these (or cough up the $10K to read the forums), I'd have somebody play around with the public release first.
Are there reasonable use cases for making dotLRN interoperate with Sakai? None leap to mind for me, but that doesn't mean that there aren't any. I haven't spent too much time looking into Sakai yet, so I don't know for sure. Even if there isn't a good use case for Sakai in the real world, it could still be very useful as a testing tool for the dotLRN developer community, since it is both JSR 168- and OKI-compliant. Again, though, I don't think you'll need to get too highly involved with the Sakai community to do that.
In general, I've grown far more skeptical of online learning standards over the past few years. They're too heavy and programmer-oriented for educators to use directly, to rigid to handle a huge range of real-world uses, and too vague to have completely standardized implementations. Even SCORM, which is by far the most successful initiative from the IMS/IEEE/ADL groups, has some serious problems. I'm starting to think that this isn't the right way to g(r)o(w).
Actually, one of the most important standards for online learning (believe it or not) may turn out to be RSS. In addition to the blogging craze, learning object repositories like MERLOT and MLX are using RSS feeds to syndicate their content. You could do a lot to move dotLRN forward as a platform simply by making it dirt-simple for users to create RSS- and OPML-based portlets and by making RSS feeds out of modules ubiquitous.
