Forum .LRN Q&A: Re: SLN Evaluates options for next generation learning platform

Let me see if I can clarify a few points.

The integration will not be trivial and will require significant investment and coordination.

Absolutely true. In fact, I would say that it would have been impractical even for an organization of SUNY's size to attempt this sort of an integration challenge even two or three years ago. Recent progress in technical standards make this project possible for us, but it's certainly not the path of least resistance. One of the technical goals of the SLN2.0 project and it's sister LMOS Open Source project will be to further lower the barriers to tool integration by a significant margin.

They hope to draw on best-of-breed tools or applications from a diversity of sources, which could include .LRN. But I suspect that because of Java the integration with Sakai tools will be easier.

Correct on both counts, though less so with Sakai than you might think. The Sakai people haven't quite decided yet if Sakai is an enterprise bundle or a framework with applications. Right now it functions as more of the former than the latter. For example, proper Java-native integration with uPortal has turned out to be much harder than they anticipated and is probably still a year or two away. We will most likely cherry-pick from the small collection of Sakai tools that were developed as stand-alones and integrated later--the SAMigo test engine, the grade book, the Melete course content manager, and the enhanced version of JForum--while steering clear of the applications that are more deeply enmeshed in the Sakai bundle unless and until the Sakai folks make more progress toward a framework approach.

For a variety of reasons, the SUNY core application stack is proposed to be all Java. But one of our goals is to enable inclusion of heterogenous tools in a distributed environment. In addition to SUNY's centralized SLN (which hosts an LMS, among other services), each of our 64 campuses has its own IT department. And there is a movement toward portal standards university-wide. So the "LMS" that a given SUNY campus uses (if our proposal is implemented) could be, in reality a mix of locally and remotely hosted services. They may be running uPortal locally and pulling in the LMS portlets remotely from SLN, while also pulling in, say the Horizon Wimba voice discussion board from a vendor-hosted external site. We would love to see campuses also be able to run applications from dotLRN, Moodle, Blackboard, Angel, or whatever as well. We have a long road to travel before we can get there, including the establishment of some further standards, but that's our long-term vision.

The functional set is very much LMS-oriented and is intended to support learning design and learning environments. I think one of the principal virtues of .LRN derives from a community-centric model and paradigm. I think this is right way to go, but I am prejudiced. A course is just one type of community.

Actually, the portal-centric approach we are taking takes us in a direction that is quite dotLRN-like in this regard. We will be able to create spaces that are defined by permissions and groups. Those spaces will undoubtedly have generic groupware portlets in them, such as file-sharing, calendar, and discussion board. They may also have education-centric portlets, such as a test engine, a grade book, and so on. Much of our document is necessarily focused on the teaching and learning stuff because that is the primary need that SLN2.0 needs to satisfy. But really, the portal framework, together with a couple of other infrastructure pieces, functions quite analogously to the OpenACS base of dotLRN in some ways.

There seems to be huge layer missing in the architecture. Which component is responsible for the managing permissions, groups,content objects, etc? LAMS doesn't handle that. uPortal doesn't as far as i know. And individual tools don't either. So what layer will manage things like group permissions or do the work of oacs content object repository or lors?

There are at least two pieces to address here. First, uPortal does have permissions and groups in the form of something called Person Attributes Group Store, or PAGS. You can read about it here, here, and here. PAGS, together with LDAP and CAS, will provide SLN2.0 with groups, roles, and all that tasty goodness.

The content management piece is something else, and we are not as far along and thinking through that piece of it yet. I mentioned Sakai's Melete before, which could serve as something somewhat LORS-like (though not CR-like). That would be one quick and dirty way for us to support IMS Content Packaging and so on. Bigger picture, we'll probably go with a CR that is compliant with the JSR-170 Java Content Repository standard. There are a currently a couple of interesting Open Source implementations out there, including Alfresco, Magnolia, and eXo; I suspect that we'll be seeing others as well in this rapidly evolving space.

Anyway, I hope I've made clear that we'd be pleased to collaborate with projects like dotLRN on interoperability. We're still a bit away yet from even having enough publicly available technical information to have a concrete conversation in this regard, but we hope to get to that point within the next several months. In the meantime, we'd be delighted to discuss the vision and hear your thoughts on our approach.

To the degree that I have been helpful to the SUNY team in thinking through this proposal, I owe much of my skill and knowledge to the patience and teaching skills of this community. If Don hadn't offered to set up an OpenACS box for me for the price of a sandwich and a beer way-back-when, and if Janine and Ben and many others not patiently answered my non-techie questions and invited me into the conversation, I wouldn't be where I am today. I would be personally delighted if the folks working on the LMOS project could continue to benefit from the expertise and perspective of the OpenACS community.