Scott's Workblog

While the previous FIS event was focussed on areas such as governance and in particular the role of informal standardisation processes, this event is going to focus on technical aspects - how we model, develop, document, test and handle conformance for specifications and standards.

As before, we're inviting position papers, so if you have a view on how standards should be developed, or how the documentation should be written, or any other topic related to the area then you can either send us a paper by email, or blog it and send us a link, and we'll circulate it ahead of the meeting and make sure delegates have access to it during the event.

The papers from the previous event are still available, and are a great resource for people interested in this area.

I gave two talks at the event, and these were based around our experience at moving the outcomes of an EU-funded research project into the Apache Software Foundation, and in engaging with commercial partners.

The first was on barriers to community and focussed on areas such as governance, diversity and personal barriers to engaging in an Open Source development community, and how as a member of such a community you can make a contribution. Noirin Shirley, who gave another talk on a similar topic, made the useful suggestion of being a "greeter" for a project so that everyone who posts on a project mailing list gets a friendly response straight away.

The second talk was on dissemination beyond academic circles. This was a case study of the transfer of our work from a closed research project into an open project in the ASF incubator (Apache Wookie (Incubating)), looking at the process and business case. For us this move has proven to be extremely successful, and the value generated through adopting a fully-open development approach rather than the"open source, closed community" more typical of research projects has been far greater than the sum of our investment. While not every project can be as successful as this, hopefully it will at least help making the case easier for others.

Of course I didn't just go to do some talks! There were lots of sessions and two very interesting keynotes. I don't normally enjoy keynotes, but these were sufficiently different to be of interest. Steven Pemberton provided a historical perspective on open innovation before delving into what he sees as the key challenge facing open source: usability. Roland Harwood's keynote provided some very interesting case studies of open innovation, with examples including applying F1 logistics technology to hospital waiting lists, and Virgin Atlantic sourcing innovations from an online community of frequent flyers.

Other sessions I attended look at open innovation between business and academic teams, FOSS business models, the CodePlex Foundation (not .com!), open source innovation, community, knowledge transfer partnerships... its going to take me quite a while to let it all settle and figure out which of the things I learned about I can apply next.

Overall the "Open Innovation" message came through loud and clear, as did the clear willingness of both academic and commercial organisations to work together on this basis.

In my own mind I'm seeing "Open Innovation" as a methodology that can both support and be supported by the other "Open" agendas that the CETIS, OSSWatch and UKOLN innovation support centres have been pushing for some years now - Open Source, Open Standards, Open Content, Open Data - each of which also build upon and sustain each other.

The combination of these factors enables companies and universities to unlock innovation that generates far greater value than could be created by any one of them alone, or even by a more traditional "closed" partnership. The challenge ahead is to remove any remaining barriers to openness and collaboration, and to unlock the potential for open innovation involving universities and innovative companies; I think the event last week was an excellent start.

This meant persuading our Institute to actively commit to supporting our staff engaging in an open community process with no promise of future funding, rather than dumping some code in a repository at the end of the project and hoping somehow that something magical will happen. I had to draft and redraft a business case, all the time making the arguments about risks and opportunities for our management team. However, looking back I can safely say the actual results - in income alone - far exceeded my most optimistic projections.

An OSS strategy has proven for to be extremely successful for our small research unit, in terms of funding, reputation, partnerships, and academic opportunities, and this event is an opportunity for me to tell that story to a wider audience - so do come along if you're interested to find out more.

For more details and to register see http://www.transfersummit.com

Durand comments that "The main idea behind SLD 2.0 was to keep the essence of learning design in a voluntary simplistic specification easily usable as an add-on for IMS-CC 1.0. Several documents are already available."

I think this is a reasonable position to take; the IMS LD specification is extremely complex, hard to implement, and perhaps most problematic, hard for authors and users to understand. Most of the effort in recent years to improve adoption has focussed on improvements to tools supporting the specification, for example with ReCourse and Astro.

However there is only so far you can go with building tools and doing odd spec tweaks (like bolting on support for Widgets into the LD Services element) and so a re-think of IMS LD from the ground up is something worth thinking about.

Looking at Durand's proposal my immediate thought is that his idea of the "essence" of Learning Design is rather different from my own - and in fact he keeps what I would have thrown out, and he throws out some of what I would have kept.

Specifically, Durand has kept the aspects of Learning Design that are concerned with conditional branching. This has always been my least-favourite part of LD for a number of reasons; one of which is that I don't like putting programming logic into XML (<if>x<then>y<else>z<endif>). If you're going to use this sort of logic in an XML document, I think its better to use a scripting language like JavaScript or a functional programming language like Erlang. However, that's a pretty technical reason. The main reasons I would give for this being something to leave out of a simplified Learning Design language are that (a) SCORM already does this and is widely implemented and (b) most examples of simple learning designs don't use this feature, and are fairly linear flows.

This is brought home I think by what Durand has left out, which is grouping. In SLD 2.0, the only "groups" you can have for activities are everyone, and individuals. So as far as I can tell, no small-group activities are supported.

This positions SLD 2.0 much more closely to SCORM than to something like LAMS, which is probably the most popular LD platform. Which makes me wonder whether SLD 2.0 would have been better positioned as additional requirements for SCORM 2.0 rather than a simplification of LD?

So what would I do differently? Well, I think I'd start from somewhere else. I'd recognise that for individual, self-paced, adaptive content the only game in town is SCORM. And I'd take a look at existing implementations, like LAMS. And I'd focus on the things which make LD different from SCORM, which is around group and collaborative activities. And what I'd come up with would be something like this:

• <sequence> a set of activities that have to be completed one after another
• <choice> a set of activities that users can complete in any order they want
• <dissolve> split the participants up to work as individuals
• <merge> merge all the participants into one group
• <group> split the participants into groups; this can be specified as dynamic, using some heuristics like preferred numbers per group, or with pre-defined groups. The design could specify whether the runtime should assign users randomly, let users select which group to join for themselves, or prompt the moderator to assign the users.
• <synchronize> stop progress until everyone has completed the previous sequence or choice.
• <wait> stop progress until the moderator decides to go on
• <schedule> stop progress until a specified time.

Each of these concepts should seem pretty familiar to LAMS users, although the LAMS file format doesn't really look like this. It also looks an awful lot like a group workflow pattern language.

I think this specification is simpler than IMS LD, but at the same time it has almost no overlap with Durand's proposal. Which just goes to show that IMS LD is not only complex, but you can carve up the space it occupies in many different ways.

(For the activities themselves, they need titles, instructions, resources, and tools, and there are various ways you could specify that which I won't elaborate here.)

Here's an example of how it might look:

<schedule time="2010-05-05:12:00:00Z"/>
<sequence>
	<activity>
		<title>Getting started</title>
		<instructions>Read the briefing</instructions>
		<resource>
			<title>Briefing </title>
			<url>briefing.html</url>
		</resource>
		<content src="briefing.html"/>
	</activity>
</sequence>
<synchronize/>
<dissolve/>
<choice>
	<activity>
		<title>Read the articles</title>
		<instructions>Read each of the resources in this activity</instructions>
		<resource>
			<title>Article 1</title>
			<url>article-1.html</url>
		</resource>
		<resource>
			<title>Article 2</title>
			<url>article-2.html</url>
		</resource>
	</activity>
	<activity>
		<title>Do a quiz</title>
		<assessment src="self-test.xml"/>
	</activity>
</choice>
<group maxGroups="4" selection=":random"/>
<sequence>
	<activity>
		<title>Discuss</title>
		<instructions>Now in your group discuss the articles ...</instructions>
		<tool type="chat"/>
	</activity>
</sequence>
<wait/>
<dissolve/>
<sequence>
	<activity>
		<title>write individual log entry on activity</title>
		<tool type="text editor"/>
	</activity>
</sequence>
<synchronize/>
<merge/>
<sequence>
	<activity>
		<title>Plenary</title>
		<resource>
			<title>Debrief notes</title>
			 <url>debriefing.html</url>
		</resource>
	</activity>
</sequence>

At the JISC-CETIS future of interoperability standards event delegates also ranked lack of transparency and IPR issues as being two of the things we most wanted to fix in the eLearning standardisation domain, so its clearly still important.

Ganslandt makes the point that widespread adoption of such policies might lead towards homogenisation of standards setting organisations - not necessarily a good thing, as organisations differ along a wide range of criteria, and are often adapted to a particular set of conditions; for example, he cites the Danish review of openness in standards organisations, which concluded that openness is a trade-off proposition rather than an absolute criteria. For example, consortia may provide openness at the "front end" through open membership but have tighter editorial control from its Board of Directors at the "back end", or more restrictive membership criteria but greater openness and equality among members in the actual work of the consortium.

However as we see with the OWF, even at the most informal end of the standards spectrum there is a desire for more standardisation when it comes to IPR in particular. So perhaps it is practical to push for common IPR practices, irrespective of other characteristics of openness, as this would seem to be a more "absolute" criteria than process openness, which may indeed follow the pattern of tradeoffs that the Danish study concluded. And even then, I think it would be silly to conclude that all consortia are equally but differently open; there are clearly those that haven't even reached a tradeoff position yet with lack of openness at both ends.

Overall I have quite a lot of sympathy for the IBM stance, as poor IP policy and lack of transparency cause a lot of unnecessary friction and barriers in developing standards. However, pragmatically, some consortia are going to be strategic enough that you just end up gritting your teeth and trying to work past it rather than take a principled position. It would be interesting to see how IBM have put their policy into practice - and where.

I gave the "intro" talk, with the slides below, which was really setting the scene for "HTML+JS+CSS+Device APIs" as the logical development platform for mobile, rather than Java SDKs or Objective-C etc.

Some good questions were things like how far we were with device API specs (answer: BONDI there already, W3C DAP will take longer), and handling different form factors (answer: CSS and SVG go some of the way, but its still no less of an issue than for native apps).

Later on Anselm from Aplix gave a very nice demo of the Aplix Web Runtime for W3C Widgets running on Android, which can add W3C Widgets to the home screen, run them in a widget manager app, and also wrap them up as regular android apps. This was great stuff, exactly what I wanted to see, but unfortunately there is still uncertainty over how it might be licensed and distributed - its quite possible there will be deals with networks to put this capability on their Android handsets, rather than make is open source; I can see the logic in that as there is clearly some very heavy stuff going on under the hood for the device API mapping that was probably very difficult to develop.

However, the main thing it said to me is "this is doable", so we may well see an open-source equivalent come out, not as speedy (Aplix has a core written in C) or as comprehensive (Aplix maps all the BONDI, JIL and DAP device APIs into widget features) but perhaps good enough to get developers started.

The challenge was to create the best learning tool/integration using IMS Basic LTI and Blackboard. For this I completed work on an IMS BasicLTI adapter forApache Wookie (incubating), Dan converted a Google Wave Gadget for collaborative molecule models into a W3C Widget running in Wookie, and Mark made a multi-user editor based on TinyMCE. Together these were added to a Moodle course on Chemistry - using both the Wookie API and also BasicLTI (they work a little differently, so its nice to see that).

Because the widgets were being made available through BasicLTI, they could also be added to Blackboard, WebCT, Desire2Learn and Sakai, which is nice!

You can find out more about the challenges and winners over on the Dev8D blog

There is no shortage of innovative ideas, either in the fields of creating new devices, new applications and tools, or in applying creative ideas for activities using them. The key battlegrounds are of access and control. The Internet is vulnerable to interventions from restrictive business practices, political repression, and economic inequality.

Anyware seeks to change this.

Anyware is available anywhere. Its pervasive, ubiquitous, and under the control of the user. It is practically impossible for any government or company to prevent access to Anyware for any reason, whether political censorship, DRM, or attempts at platform lock-in.

Anyware runs on anything. It doesn't matter if its a refurbished 10-yr old iPhone or the latest wearables, or a high-immersion ambient environment suite. (Or some gadget you knocked together yourself using some instructables and a makerbot.)

Anyware connects people anyhow. Anyware just adapts to the situation and give you the best experience it can with what you've got with you. Immersion, overlays, video, 3D, audio, text.

Anyware is available to anyone. Its built into almost everything. It doesn't require a subscription plan. It doesn't come with a contract. It doesn't have any lock-in to a platform or a system or a walled community.

Anyware is controllable by you. You can block someone you don't want to interact with using Anyware, but you can't stop other people interacting if they want to. You can control your own level of engagement and immersion in your interactions - anywhere from full-sensory 3D to txt.

Anyware is secure. No-one can eavesdrop on your activities or install malware on your devices, or steal your identity.

Anyware is smart. It sweeps aside legacy restrictions like DRM and proprietary formats and codecs in order to connect people. It evolves faster than any mechanism that is aimed at stopping it.

Anyware is fast. There is no lag. There are no bottlenecks. There are no maximum current connections. There are no dropped connections. It just works, and it works everywhere.

Anyware supports "Anytivities" involving anyone on any device learning and working together. Anyone in the world with a commitment to learning about learning will be able to join the 2020 Winterschool using Anyware, and engage as immersively as they wish to, restricted only by the capabilities of the devices they can get hold of.

Anyware may be a dream, but without it, every other dream of learning technology is compromised.

Note: This post is my position paper for a CETIS meeting on the future of interoperability specifications in education.

Open, informal specification development enables communities to rapidly prototype specification ideas without the overhead of more formal processes, and may become the method of choice for working on specifications that anticipate future requirements.

However, when it comes to working with specifications produced in this fashion, there are a number of legal and IP barriers both for adoption and for engagement in formal standardisation that need to be overcome. Broadly, these are [1] the issues of ownership of the specifications, [2] the rights and conditions of use of the specification, and [3] the status of patents related to the specifications. Without clarity on these issues it is difficult for large organisations and government agencies to adopt the specifications. Formal standards organisations also may find it difficult to build on or include informal specifications as a part of formal standards for similar reasons.

To overcome these issues the Open Web Foundation has been working on two major legal instruments to assist informal specification communities, based on the successful example of the Apache Software Foundation for enabling open source to be widely used in the commercial world.

The key instruments are the license agreement for specifications - the Open Web Foundation Agreement (OWFa) - and the license granted by individual contributors to specifications, the Contributor License Agreement (CLA). The first covers how others may take, implement and reuse the specification; the second clarifies the status of the engagement of community members in creating specifications.

The OWFa makes it clear to potential adopters of the specification - including standards organisations wanting to work with it - what the conditions of use are for the specification, who contributed to it, and who is granting the license. Unlike a traditional software or specification license, the OWFa is not granted by a single legal entity such as a company or foundation, but is instead signed by all the contributors to the specification. This is important as - unlike a formal standard (or consortium specification) - there is usually no single entity that can assert ownership of an informal specification such that it can grant licenses for its use. This is also where the CLA comes in.

The CLA provides an "audit trail" of contributions to informal specifications by having each contributor assert the status of the work they have put into it - it asserts both that the contribution they have made is their own work, and that they have the right to license their contributions to the specification. In some cases this is a simple personal assertion; in others it needs to assert that the person's employer has agreed that they can license their contributions to the specification.

This means that in the case of any disputes it is possible to follow the trail and find out where ownership of any IP has been asserted, and who is responsible for making the assertion. This is useful, for example, where a person engages in a specification community for one company and then moves to another, or where their employer is taken over by another company or goes bankrupt and its assets acquired by another - the CLA makes it clear that the individual had the right to grant license to their work.

Finally, there is wording in the OWFa on patent non-assertion and licensing conditions that may be useful for some standards organisations, and particularly for specification consortia. This provides a promise by the signatories not to assert Necessary Claims for implementation, and a statement granting a royalty-free license to any Necessary Claims for implementation.

The OWFa is already available for use; the CLA is still being worked on but will almost certainly be released in 2010. Even for specifications developed prior to these instruments being created it will be possible for informal specification communities to adopt them provided they have a reasonable trail of contributions.

For example, the XCRI community could offer its XCRI 1.1 specification under OWFa as all contributions to the spec are logged either in the form of event attendance lists, forum contributions, or wiki history; this means all contributors could be asked to sign a CLA, and if this is successful, an OWFa license could be offered for XCRI.

In conclusion, I believe that the OWF agreements will provide a solid basis on which to enable more formal standardisation processes to make use of informal specifications without compromising the IP and patent policies of either formal standards bodies or specification consortia. This provides an opportunity for formal standards to be created that build upon informal specifications. The terms of the OWFa may need to be looked at more carefully in cases where multiple informal specifications may be harmonized to create a standard; however by establishing, through the use of CLAs, a clear IP framework for informal specifications, the way forward in such cases is made much easier.

Two other applications - the Aplix Web Runtime engine and the BONDI reference implementation for Windows Mobile - have also been able to successfully pass all the conformance tests. Several others are also approaching a full pass rate, as can be seen on the W3C implementation report.

Not only is this good news for Wookie its also good news for W3C, as more successful implementation helps the progress of the specification. Also, open source implementations can also help other developers build interoperable applications by reusing code. I hope in future we'll be able to make the widget parser in Wookie distributable as a standalone library as well as part of the Wookie widget engine, to help with this process.

Useful links:

• W3C Widgets 1.0: Packaging and Configuration
• Apache Wookie (incubating)
• A good list of resources on W3C widgets development