SPAWS: Paradata recipes, identifiers, and starting integration

We just had our first advisory group meeting for SPAWS with Fridolin (OU), Sten (KUL) and Daniel (IMC) which has left us with plenty of things to think about.

Models for Paradata

We had a look at the paradata models from The Learning Registry and how they compare with things like Project Tin Can. I think the main difference is that Tin Can is concerned with interaction data between the resource and the player for a particular user, whereas the LR is more concerned with information about the resource. The main similarity is they both use JSON and take inspiration from Activity Streams. The Learning Registry “Paradata Cookbook” has a recipe for “Ratings” which has been implemented in SPAWS, however we also need to identify recipes for Comments, Tagging, Affordances, Statistics, and Related/Similar. I must admit I hadn’t though of sharing the Related/Similar information as paradata but that could be a useful addition.

Fridolin came up with an interesting suggestion which is rather than post paradata records containing the data, to instead publish links to the pages on the actual store where the widget is displayed, and extract the paradata using microdata or RDFa. This could be an interesting approach as you can potentially also grab more contextual information from the page too. However, we don’t have to do an either/or for SPAWS as we can extend the recipes for paradata to also point back to the original store page where the information was collected. That way, the web app stores consuming paradata using SPAWS can optionally follow the links and conduct additional analysis of the page.

We briefly explored the idea of including paradata in the widget manifest itself, however this way we encounter problems like having multiple versions of the package and manifest so we dropped that line of inquiry.

Our next action on the data models is to document our paradata “recipes” so we can check them against the data models being used in Edukapp and IMC’s store software, and to experiment with including links to the original context.

Identifying widgets and gadgets

W3C Widgets come with an identifier defined in the manifest itself – the @id attribute for <widget> in config.xml contains a IRI for the widget irrespective of where its currently installed. So this can be used to identify the widget – although the @id attribute is also optional, which could cause a problem. For OpenSocial gadgets, the situation is even worse as their doesn’t seem to even be any kind of identifier for a Gadget; one workaround is to use its original hosting location, or its title link href, however we need to investigate further.

This issue is important to resolve as we need to know the subject of the statements users make about web apps – which means we need to be able to identify the app globally and not just by an id used in an individual store.

(I guess we need to invoke Barker’s Law here – based on Phil’s tweet: “you cld make a kinda serious version of Mornington Crescent: start with any tech issue and trace it to identifiers” – which I’d reformulate as “Any technology issue can be ultimately traced to an issue with identifiers”.)

So the action here is I need to get my head around the identifiers issue and propose some solutions and workarounds.

Integrating SPAWS, Learning Registry and Web App Stores

The next issue is how we integrate all the pieces. For SPAWS and Edukapp its pretty easy as we can add the SPAWS jar as a Maven dependency in Edukapp and call it directly. However, the ROLE Widget Store is a Drupal PHP application, and so we need a different approach. One possible solution is to deploy SPAWS as a “Broker” service in front of the Learning Registry Node; or at least make it available as a service. So we need to create a very basic REST/JSON service for SPAWS as well as a library. That way IMC can start to experiment with it too.

In the original bid we also were looking at harvesting paradata from stores, however it seems a better fit to both the Learning Registry and Web App Store architecture to allow the stores to push and pull on their own schedule rather than harvest. It also makes it easier to include permission steps for users who haven’t indicated previously that they were willing to have their comments syndicated.

So our next steps here are to integrate SPAWS as a library in Edukapp, and create a SPAWS web API and host it somewhere, so everyone can start playing with it.

So plenty of jobs here to keep me occupied!


This entry was posted in apps, open education, widgets and tagged , , . Bookmark the permalink.

2 Responses to SPAWS: Paradata recipes, identifiers, and starting integration

  1. Pingback: SPAWS: Paradata Recipes | Scott's Workblog

  2. Pingback: SPAWS: Its all started coming together… | Scott's Workblog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s