Scott's Workblog

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

We had a pretty broad group of people, including Alex Bilbie from Lincoln, who was doing all kinds of fun things with iCal, RSS and mashing up university services, the Open University's Tony Hirst who can do some quite amazing mashups, Martin Hamilton who is trying out innovative things within the area of CRM and services to businesses, and of course Brian Kelly.

Rather than just a free for all we collected our ideas and put them on a public wiki, so you can add your own thoughts.

At the end of the session, Brian took us through University API: WTF? to get us to question ourselves. I think overall the whole API thing is a no-brainer for the digerati, but persuading management is a problem. As Andy Powell pointed out - its easy to confuse the concrete examples of what you might use an open service for (and its value proposition), with the point of providing open services because you don't know what they might be useful for!

As is usual at these events I had to produce a summary slide, which this year was inspired by the work of Dan Hilliers:

The OWFa establishes copyright and patent rights for a specification, and clarifies the intellectual property and usage rights for a specification where there is no single organisation publishing a specification. This has been an issue for a number of specifications developed informally among a community online rather than through an established standards organisation, where there is no clear "owner" of the specification.

The OWFa is one part of the answer to this problem; the license names the individuals who have contributed to the specification rather than a single entity. In the near future OWF will also release a model Contributor License Agreement (CLA) for participants in open specification development based on similar documents used by the Apache Software Foundation. A CLA provides a statement that an individual has granted a license to use their contributions, and furthermore asserts that they have the permission of their employer to do so. This provides an "audit trail" to help resolve any issues that emerge, for example in settling claims of copyright or patent violations. While it doesn't prevent problems emerging, it helps to establish the process and reduce risks for all parties - including the contributors themselves.

This announcement marks a major step forward for community-based approaches to developing specifications, and will help with the commercial adoption of community specifications, as well as help smooth the path for contributing community specifications into more formal processes.

For more information, see Introducing the Open Web Foundation Agreement

The workshop offered several different perspectives on Open Source projects - from an OSS project, from a project consuming libraries and other outputs of OSS projects, and from a developer submitting their first patch. This was a nice mix, and it was good to see the process from different viewpoints.

My presentation was primarily from the OSS project end, and focussed on Wookie:

I think the main thing I was trying to convey is how from a project perspective you're (usually) keen to get external contributions, no matter how small, and how willing project team members are to help get people involved. My "being nice is a survival strategy in OSS" seemed to go down well as a takeaway message!

Ian Boston was next up and talked about how Sakai works with Open Source projects - I think the point he makes about "good code - bad community vs. bad code - good community" is an excellent one. Perhaps one of the reasons why Moodle is so successful with its community are the wide range of issues that users can readily tackle themselves - whereas something very mature and well designed like Apache Commons makes developers averse to touching anything!

The last talk was by Mark Johnson, and was all about submitting a one-line patch to Moodle. This was a really nice walk-through from identifying a problem, engaging with the community, to getting the fix accepted, and with a clear case as to why the college would want to support this activity.

The discussions around the workshop also threw up some interesting issues. One of the big ones would seem to be that the core processes that developers have to engage in - particularly in Open Source projects, but in commercial development, too - are often also not taught in programming courses, namely source control and issue trackers. This is one of the hurdles for bringing on relatively new developers into a mature project. On the other hand it could be argued that Open Source projects provides a very useful training ground for developing the skills of using these systems, which translates well into other developer roles.

Another issue that comes up a lot is sustainability, especially in relation to funded programmes, I think we're making a lot of progress on this one, and at least now sustainability is something that projects funded by JISC have to consider. However its still not quite right, and there are probably things we can do to try to keep a good balance of innovation and sustainability where there is central funding for software development.

OSS Watch are a JISC innovation support centre; and they are focussed on Open Source in education. Find out more at http://www.oss-watch.ac.uk/.

Bondi

The Bondi project of the Open Mobile Terminal Platform (OMTP) has produced a set of APIs and reference model for common device features; these currently include SMS messaging, local files, media gallery, location, camera, and communication log (missed calls).

These APIs build upon the W3C Widgets specification, which I've posted quite a bit about on this blog previously, and are accessed quite handily from JavaScript; I'll show an example in the next post.

Bondi has been implemented by a number of operators, system and device manufacturers including Microsoft (Windows Mobile 6.0), LiMo (Linux for Mobile), O2, Vodafone BetaVine and LG; there are some SDKs available for developers, and even an emulator so you can test out your BONDI widget on a virtual phone. You can download it for the Eclipse IDE from the LiMo Foundation.

JIL (Joint Innovation Lab)

JIL is an initiative of Vodagine, Verizon Wireless, China Mobile, and Softbank Mobile, and like Bondi is also focussed on developing device APIs and related services that build upon the W3C Widgets specification.

One of the criticisms of JIL is that it "jumped the gun" somewhat on both W3C and Bondi in a rush to get to market quickly, and in the process has made the landscape more confusing for developers. However, at the recent Over The Air event I attended, Vodafone's Rick Fant explained that the group would be working with Bondi and W3C in future.

W3C Device APIs and Policy

The W3C DAP group was formed recently to develop a common device API specification, based on initial submissions from Bondi, JIL, Nokia, and Opera. Hopefully this will pull together all the different device APIs out there and come up with some common standards. Some pieces of the puzzle are already shaping up, such as the W3C GeoLocation API specification

Not Just For Mobile Phones

One of the interesting things about all the device APIs I've seen is how many of them can be applied outside of mobile devices: for example, most new computers have built-in webcams, and browsers can provide location services using technologies such as SkyHook. Web standards for accessing these capabilities gives developers an opportunity to create even richer applications and widgets without having to do much more than add a JavaScript library - in my next post I'll explain a demonstration I've produced of doing this using Apache Wookie (incubating).

This is a quick report on some experimental work I was trying out with Wookie, which is adding a Feature to support BONDI APIs. I added a feature based on the BONDI Camera API, which is used to gain access to the user's camera. Normally this is a camera in a mobile phone, however it can also work in the browser: for this I incorporated a Flash object that writes the content of the camera to a HTML 5 Canvas object, which can then be captured and used by a widget.

There is a reasonable amount of Feature code in the client side (Flash, JS, CSS...) but the widget author doesn't need to do very much at all. Here is my test Widget source code:

            <script>
                function takePicture(){
                        var camera = bondi.camera.getCameras()[0];
                        camera.takePicture(
                          function(img){document.getElementById("picture").src=img;},    // Got a picture!
                          function(){alert("nope");});           // User cancelled
                }
            </script>

The HTML is also simple:

          <body>
            <button onclick "takePicture()" >Take Picture</button>
            <img id="picture" src="" width="64" height="64"/>
          </body>

At runtime this gives the user a "take picture" button, which when clicked opens a lightbox showing the Flash "camera access" settings:

If the user allows access, they get the usual camera live preview with a "snap it" button. When this is clicked the user can choose to keep the image or take another (they can also click the close button, or press ESC, to cancel).

The captured image is converted into a data: uri and passed back to the Bondi script, which is what the widget javascript above inserts into the <src> element:

I think there is a lot of scope for adding these kinds of features into Wookie that would make for some interesting cases for incorporating mobile widgets into websites (and vice versa).

At the moment this is still an experimental feature and isn't part of the Wookie codebase, but I'll try and upload the source and some instructions in the near future.

We're now working on moving all the source code and sorting out the legal and licensing side of things, but this shouldn't take long; the incubator project page is now up, so you can keep an eye on our progress there.

Once this stage is completed, we'll be working to ensure that Wookie is sustainable with a broad group of committers from different organisations. We've already had quite a few people interested in contributing which is very encouraging. If you're interested, there is a mailing list set up for developers; to subscribe to the list, send a message to wookie-dev-subscribe@incubator.apache.org

So exciting times ahead for Paul, Kris and I working on Wookie in the Apache Incubator!

Thanks to everyone who has supported Wookie - especially the TenCompetence EU Project that funded the original development work, and also everyone who participated in the CETIS Widgets Working Group, which proved very helpful in informing the direction of the project, and to the folks at the Palette project (Alain, Stephane and Jerome) and the W3C Webapps group.

A special thanks to Ross at OSSWatch for helping out in many different ways, from helping us to develop the business case at the university to the actual Apache Incubator submission process. See also the post by Ross on the OSSWatch blog