We needed to populate some training course and class rosters into Sakai to let people play with site creation, roster attachment, and publishing tests to students. While we could have used webservices, we decided to leverage the built-in CmSyncJob and generate an XML file to dump out the data, and then sync it into the CMS (we wanted something easy to check into SVN for future usage).

The fun part was it let me use Ruby’s Builder (originally part of rails, but then extracted) to produce the XML, which was fun. Builder has a nice Ruby syntax that uses

to allow a nice language to XML mapping:

  puts "* Writing Academic Sessions..."

xml.tag!("academic-sessions") {
  2008.upto(2012) { |i|
    xml.tag!("academic-session") {
      xml.eid(i)
      xml.title("#{i-1}-#{i} School Year")
      xml.description("#{i-1}-#{i} School Year")
      xml.tag!("start-date","6/1/#{i-1}")
      xml.tag!("end-date", "8/31/#{i}")</pre>

And just run though a bunch of loops, and pretty clean method calls to spit out XML.

Thanks to http://blog.katipo.co.nz/?p=29 for the tips on Builder, especially the bit about using

to put in names which would translate to Ruby keywords (e.g.

where the - makes it

otherwise)

I started this entry while I was riding a train back from the Laguardia ePortfolio Conference I’m endeavoring to reflect upon and synthesize threads from various (enlightening) presentations I’ve seen, and discussions I’ve had the privilege of participating in. First a brief plug: the content from the conference was fantastic — many congratulations to the folks from Laguardia Community College for organizing such a wonderful event.

Sakai has amazingly broad potential. The energy and excitement in the community and among those who have been watching Sakai make it clear that we’re really realizing the benefit of contributor’s blood, sweat, and tears in the form of some exciting tools for teaching and learning. Sakai seems uniquely positioned to become the base of a whole ecosystem of tools supporting different facets of the academic experience ranging from instruction, to assessment, to facilitating interactions between learners. I think we may be at a crossroads in terms of positioning, particular as we evolve towards explaining the product, beyond the project & community. Laguardia’s conference and discussions, especially those related to “Sakai vs. OSP” really focused my thinking on various opportunities for Sakai to support different areas of teaching, and learning.

A statement: I think the the common usage of Sakai to discuss both a specific set of tools supporting course/learning management (Sakai CMS/LMS?) and a platform/environment upon which those tools can be built and deployed has resulted in some confusion. I have heard many questions recently in the vein of “do you have to use Sakai to use OSP?” or “we’re a Blackboard school, and aren’t going to switch, does that mean OSP is out?” The fact that OSP is a toolkit built on top of Sakai (the platform) seems to be a confusing point for many who don’t currently have plans to deploy Sakai as a CMS/LMS.

To clarify, yes: it is quite reasonable to deploy OSP as a system exclusively dedicated to portfolios, completely separate from the other tools. Inputting text, adding reflections, uploading evidences, and managing assessment are all perfectly capable of being performed in a stand-alone environment. In the same way that past releases of Sakai downloaded from sakaiproject.org “stealthed” (hid) the portfolio tools an institution could choose to leverage the OSP piece of the Sakai ecosystem without forcing your users to adopt the entire environment — one advantage of the platform’s open-ness and customization capabilities.

In fact, I think this scenario illustrates a very real way to explain Sakai. If Sakai is a platform upon which bundles of tools (courseware, OSP, etc.) can be built, then we have a product with many facets. Each facet (LMS, OSP, Collaboration) supports a different interaction scenario, part of a greater whole of learning. Going forward, perhaps explicitly separating that greater platform from its concrete manifestations (particularly as courseware) would help emphasize Sakai’s potential as a learning suite or system — with facets focused on all aspects of a learner’s experience: courses, co-curricular’s, career advising, libraries & research, collaboration, and personal expression for a start. This thinking was really influenced by listening to many people talk about OSP — as a toolkit for building concrete artifacts: resumes, co-curricular transcripts, certification documents, personal expressions — all leveraging the same tools, but in many respects separate endeavors linked only by

I think there’s a danger that we could allow ourselves to slot Sakai into a box defined by the products that came before. though that’s where many adoptors initial exposure came from. The example of OSP illustrates the clear potential of Sakai’s modular architecture to enable assemblage of higher-level environments supporting particular styles of teaching or interaction. A common environment lets us both build on previous work, and also focus on integrating the experiences for out students and teachers, participants and leaders. My programmer’s mind sees this as being much the same potential as is now playing out in the Eclipse eco-system.

So the question I think this brings up is: if we focus on this broader picture, and think about these “bundles” as being the real deliverable, could we better frame this relationship by rebranding (consistent with recent thoughts about relaunching) the Sakai courseware tools as a separate entity within the Sakai umbrella — “Sakai Classrooms” maybe? Leaving room for thinking of the ecosystem as bundles, which you can mix and match: “Sakai Portfolios”, “Sakai Communities”, “Sakai Social Networking”. Different bundles of functionality built on the same platform, possibly using the same individual tools, but illustrating some of the broader possibilities.

John Lewis from Unicon talked about open-source in Universities. Higher Ed has an extremely complex, dynamic, organizational structures. uPortal has grouping and other mechanisms which are more sophisticated than other projects, battle tested for large and sophisticated higher-ed deployments. CAS was one of the first systems, has features like Proxy Auth that no one else has, and is widely adopted — integrated into commercial and other frameworks like ACEGI. Hypercontent – why another CMS? Hypercontent separates content management from presentation, CAS enabled, reuses uPortal GAP, portlet content & management tools. Continue Reading »