SPAWS: Initial code, hands-on with the Learning Registry

So, as I mentioned in an earlier post, I’m using the Learning Registry infrastructure as middleware for sharing usage data about widgets across widget stores (the SPAWS project). This week I’ve focussed on the basic technical infrastructure needed for the project.

So, as I’m working in Java I created a new Maven project to create a library (.jar) that encapsulates some basic “paradata” (usage data) handling functions. The code is up on Github and you can include it as a dependency from the Sonatype Snapshots Repo. I decided to create a standalone library project rather than code straight into Edukapp as I may want to reuse this library for Apache Rave – I also need it to be available to other widget store owners that may want to use it, e.g. IMC, SURFNet and SchoolNet.

After a bit of a struggle with the documentation I’ve got my project auto-building downloads in Github, and deploying snapshots to Sonatype. All good! However, I’m building on top of something called LRJavaLib, which has a dependency on a library (bee-encode) that isn’t available from any repository. I may end up submitting it to Sonatype as a third-party lib to make it easier to include SPAWS as a dependency without any other messing around.

(In the future, SPAWS may just end up part of LRJavaLib if its functionality is generic enough; however to begin with I wanted to have a bit of freedom to explore without messing up an existing library)

So, now I’ve got the library project set up, what can it do?

Well, so far I’ve got it working with JLern to publish, retrieve and filter ratings on resources. Learning Registry nodes don’t really have any concept of “updates” or “versions” so you have to do the filtering at your end.

For example, imagine in a widget store, Alice clicks 5-stars for the YouTube widget. We’d then send some JSON to the LR Node saying “In my store, Alice gave the YouTube Widget 5 stars”. We can then retrieve that from the LR node from another widget store to help calculate an overall rating for use in things like search results and detail pages.

However, if later on she changes her mind, you might publish “In my store, Alice gave the YouTube Widget 1 star”. However, when sending an “obtain” request to the LR Node, you’ll get BOTH ratings as separate records. So its important to be able to filter this kind of usage data to return only the latest version of a usage data record. To determine uniqueness in this case I use the combination of the submitter, the actor, and the resource. For other kinds of usage data I can see there may be a need for other kinds of filter.

Its also useful to be able to screen out any usage data you published yourself from the results, so I added an “omit submitter” filter.

So putting it all together, I have an initial entry point to SPAWS that looks like this.

So far, so good! However I’ve already come across my first Learning Registry issue: when I page through result sets, for some reason the “resumption token” ends up retrieving a load of spurious records unrelated to the original query 😦 Luckily my filters get rid of these, but it would be nice to be able to rely on the LR Node to sort that out.

Next up, I’ll see if I can get SPAWS as it stands integrated into Edukapp, and then extend the type of usage data beyond ratings into things like downloads, embeds and review comments.

This entry was posted in development, widgets and tagged . Bookmark the permalink.

1 Response to SPAWS: Initial code, hands-on with the Learning Registry

  1. Pingback: JISC OER Rapid Innovation: Technical roundup [start] #oerri – JISC CETIS MASHe

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