PLE
It was a great week for course advertising in Europe last week as CEN (Comite Europeen de Normalisation - European Committee for Standardization) endorsed both a Workshop Agreement and a commitment to develop it into a European Norm (EN) for Metadata for Learning Opportunities (MLO). MLO defines a common model for expressing information about learning opportunities such as the courses available at a university such that they can be aggregated by other services such as advice centres, search engines, or brokerages.
An EN is a formal European Standard, whereas the CEN Workshop Agreement (CWA) agreed on 13th October represents an interim specification that can be referenced immediately by implementers while the formal standardisation process - which may take up to two years - goes ahead. Once a European Norm (EN) is agreed, it becomes a de jure standard throughout the community, replacing any similar standards in place in member states.
So what is MLO? MLO is a standard model and vocabulary that represents the common subset of several existing specifications used for advertising courses. This includes XCRI from the UK, CDM from Norway, CDM-FR from France, EMIL from Sweden, and PAS1068 from Germany. The common subset consists of four classes and 13 properties that are common to all or most of these existing specifications, plus references to other properties commonly used from Dublin Core (see below).
Rather than replacing the existing specifications, MLO standardises a common model that is then implemented by specifications as a conformant binding. This means that, in practice, each specification has to be slightly modified to conform to the same common core, but retains its local extended properties and implementation architecture. So developers already using these specifications can become MLO-conformant very easily by adopting the updated version when it becomes available, which should itself be a very minor update as the standard is based on the existing commonalities. It also opens the door to other communities or consortia developing their own bindings for different applications or markets - for example using a different base technology specification such as RDF, JSON or Atom Syndication Format. Any specifications, though they may have a very different technical implementation, will still share common concepts and properties that developers can use to make transforms between them.
Why did MLO take this approach rather than standardise a binding? Well, one of the key considerations is the lifetime of standards. A standard has to stand for a much longer period of time than a specification, enough time for new technologies to come into play and become the preferred implementation approach.
Another consideration is the need for different kinds of implementations in different situations - for example, mobile applications, distributed applications, centralized systems, REST, SOAP and so on. Again, architectures also have trends that evolve over time, and can easily overtake a standard.
Finally, there is the need for communities to define their own vocabularies, extensions, and conventions. One approach to this is to define a very large standard of what is hoped to be all possible properties and classes and to then constrain this model in application profiles. Another approach is to define a common core and then allow communities to extend this common core in any way they wish. This largely maps to the difference between the approaches taken by Learning Object Metadata and Dublin Core; MLO takes the latter approach.
So what impact will MLO have? The initial impact is to some extent psychological - implementers can go ahead and commit to using specifications that are going to conform to MLO with greater confidence, as they are based on a standard that is going to be around for a long time. We will also see transforms and crosswalks becoming available between the existing course advertising specifications, and this may lead to new opportunities for services that operate across European countries such as Ploteus. As more learning opportunities are advertised in MLO-conformant formats new services that aggregate this information for different purposes become viable.
In the longer term there is a commitment from all the specification communities involved in MLO to continue to work together and seek further opportunities to adopt common models. However the preferred approach is to see what emerges as common use in implementation communities rather than to design new models from first principles.
The MLO document is still awaiting editorial comments before being prepared for formal publication by CEN; however a draft is currently also available here.
Yesterday I gave a presentation for the Sakai working group on authoring about the work we've been doing on Widgets. I'm including it here as its got some more of the technical details.
I think a major implication of widgets is that it challenges the idea of writing tools as plugins just for one platform (e.g. Moodle, or Sakai) rather than as generic widgets usable in any "container", which can include personal as well as institutionally-offered web spaces. For example, a Moodle course can include things like a chat, voting, and forum widget - which you can then drag off into your personal site.
Perhaps make your own personal "dashboard" out of the widgets you've taken from several different courses you are participating in, originally offered in different LMS's by different organisations.
Yesterday I presented at an online seminar on Personal Learning Environments. The organisers - the Evolve project - also made a recording of the session so you can see how it went.
Thanks to everyone who took part and asked lots of difficult questions!
To download the recording, you need to click this link and let the Java weirdness happen. I guess a regular movie wouldn't have captured the chat backchannel, which is nice as I missed some of the comments while busy talking.
I'm off to Maastricht next week to take part in a workshop on mashup personal learning environments (MUPPLE) as part of the EC-TEL conference. I'll be presenting a demo of some work we've been doing on integrating widgets into various platforms.
I'll post a link to the paper when I get back, but in the meantime, here is a screenshot to give you an idea of what I'll be showing: spot the Apple Dashboard widgets in this Elgg 1.0 installation!
This is all possible at least partly through the efforts of W3C in coming up with a common Widget specification, but also through many modern platforms such as Elgg, Wordpress and Moodle having a "Widget" concept in their plugin architecture that makes embedding of other bits of web far easier. The combination of these factors made building a generic widget server technology that can serve widgets from existing platforms such as Dashboard, Sidebar, Konfabulator (etc.) into web environments feasible.
We've also extended the widget spec, and enabled stateful collaborative widgets, like the "Natter" synchronous chat widget you see in the image. With no special server-side coding whatsoever - its all Javascript and AJAX calls to standard widget service methods and events.
After MUPPLE I'll be at IMS in Birmingham, quite possibly for a repeat performance, but this time showing this technology being combined with learning design sequences.
I think this one has been brewing for quite some time - the Open Web Foundation is pulling together a number of specifications under the umbrella of a single foundation.
The Open Web Foundation was announced by David Recordon of SixApart at OSCON yesterday.
The new foundation is to "create a home for community-driven specifications" such as oAuth and OpenID as well -if the slides are anything to go by - as the currently very proprietary Google Gadgets.
On the one hand I think this is certainly a step in the right direction for getting these specifications onto a stable footing. On the other hand, what about IETF? What about W3C? What about ISO? What about UN/CEFACT? I'd like to see a good rationale for why none of these existing organisations are unsuitable for the kind of work being discussed. Do they take too long? Are they full of your competitors? Are they too undemocratic? Too democratic? This is a very serious issue, especially as in the Google case, W3C have been working on non-proprietary open specifications in the same areas.
One argument is that the new body should purely focus on IPR management. This is certainly one area of concern with community specifications, and tackling it would be very useful. However, this would then require a very hands-off approach by the organisation, which is maintained without the urge to control the direction of the specifications themselves. Already discussions are taking place about what criteria the organisation would set up as to what projects it would accept, and what processes it will have to develop.
For example, would the OWF incubate a competitor to oAuth? If not, why not, and how would it make that decision?
If the OWF really can pull off a lightweight approach to IPR management for specifications then this could be a useful initiative, but the relationship with, in particular, the W3C and IETF needs to be explained much more clearly, and the role corporate interests are playing (Google, Yahoo!) in its development made explicit, before we know if the OWF is a good place to work on interoperability issues.
If Atom (or Pie as it used to be called) was being developed now, would it now join OWF, or would it still offer its spec to IETF to become an open standard? What would be the difference?
More coverage over at TechCrunch
Its been quite a while since my last blog post, for which I place them blame largely on Twitter, so here is a brief roundup of what I've been up to lately.
XCRI
I've been really busy with XCRI recently as part of the efforts to harmonize the different specifications for course advertising and syndication across the EU. There is no a draft model out for consultation that we intend to submit for a European standard. There's a lot of enthusiasm for this (see my post on the XCRI blog about the Athens Declaration) and so I'm pretty hopeful that not only will we see a new lightweight EU standard for course advertising, but we'll also see all national initiatives adapting to it in a relatively short period of time. Certainly as soon as the standard is agreed we're planning to make the changes to the XCRI spec needed to conform to it.
ARGOSI
This is an Alternate Reality Game project I've been working on. The first rule of ARGOSI is you don't talk about ARGOSI.
On The Horizon
If you haven't already done so, check out the series of blog posts on Mark Feldstein's blog. These are all about the papers we're writing for a special issue of OTH, and I'm writing one of these with Kamala here at Bolton. I think this is going to be a really good journal issue and well worth getting hold of - I'm just worried about making sure our contribution is as thought-provoking as some of the other papers.
Widgets & Wookies
We've been working on using the W3C Widgets spec as the basis for making and delivering collaborative widgets that can be distributed across lots of platforms, both personal and institutional, using a piece of OSS we've developed called Wookie. Some more info in this interview. I'm really excited about this work, and we hope to have some really good stuff about it online soon.
FeedForward
My partner on the project, Kris, had to take some extra leave so we had to put back the release of the next version of the application. We're still planning to get out a new version before the Autumn. Thanks to erveryone whose got in touch asking about how we've been doing!
Conferences, unconferences and so on
I've recently attended EUNIS 2008 in Denmark, and the JISC Innovation Forum at Keele. I've also been along to the CRIG barcamp. However other people have written far more timely and informative posts about all of these things! Next up I've got:
There has been a lot more going on, but those are the headlines for now...
No really, its a technorati claims thing
I'm not sure what I'd use this for, but its certainly cool and very cybernetic. Pachube is a service for tagging objects that share data from their sensors.
Services like Pachube could be useful for some kinds of very high-level business intelligence, particularly analyses that cross organisational or national boundaries.
At the moment, however, it does have the feel of a webcams site with graphs and XML, but as more objects, places and devices get wired (or wireless) then something like Pachube becomes an inevitable evolution.
Perhaps someone will find some interesting way of using some of these sensors in one of the many mashup competitions making the rounds currently.
I've been talking about oAuth a lot to colleagues recently; I'd had it vaguely on my radar for a while, but a conversation with David Recordon from SixApart at EduServ last year convinced me to take a more serious interest in the specification. oAuth is essentially a user-centric authorization mechanism for enabling services to talk to each other.
Currently some services enable interoperability by getting the user to delegate authority to the service to interact with another, essentially by enabling it to impersonate the user. For example, you give Flickr your LiveJournal account details so it can cross-post your photos.
With oAuth, the same functionality is enabled without the security, trust and privacy compromises: the user talks to both services and explicitly grants permission for the services to talk, but without revealing any account details.
There are a great many service-to-service contracts that could benefit from this user-centric approach: employers and universities, for example. Or between employers and applicant's portfolio services.
But is oAuth actually being adopted? Well, the evidence suggests it is, with Google announcing adoption, and discussing integration with its OpenSocial and Google Gadgets technology. For Google this replaces its proprietary AuthSub mechanism with one that can be shared across providers.
For eLearning, the oAuth spec is an important building block in developing distributed as well as federated elearning architecture. With oAuth, users can choose to connect together services that have no existing relationships using a common authorization method.
Even better, oAuth is completely agnostic with regard to identity and authentication protocols and models - it doesn't need single sign-on or any kind of shared identity or authentication model between service providers.
The bottom line - if you are developing an application that needs to talk to an external service API on behalf of the user, then you may need to start looking into oAuth.
