Liverpool Learning Registry Node Installed

Cartoon of character having a good ideaAt long last, when all hope seemed to be fading, we have managed to get our Learning Registry node at Liverpool up and running. Thanks to the LR people (especially Jim Klo) for helping identify the problem, but especially to John Gilbertson in our Computing Services Department for his perseverence. Many would have thrown in the towel long ago.

We’ve re-published all the records that our students collated over the summer (32,000 in all – records, not students) and have verified that we can retrieve these data by the various means required.

As it’s a Friday afternoon, we’re not going to try and change the Kritikos website to point to the local node today; better wait and do it properly next week.

UPDATE 4 Mar 17:00

The Kritikos website has now been successfully changed to read all Learning Registry data from the local Liverpool node.

The next step is to change the code to write to the local node. This will require some careful testing, but we confident it can be completed quite quickly.

Design and User Interface – final look

We are getting ready to “soft launch” Kritikos for all our Engineering students at the University of Liverpool. This demonstrates how they will access Kritikos via the student portal at University of Liverpool. All engineering student at University of Liverpool will have eventually have the Kritikos ‘widget’ pre-installed, so they’ll have access to it as soon as they log in.

Kritikos widget on student portal at UoL

Kritikos widget on the student portal at the University of Liverpool

When an user types a search term into the search box in the widget they will be taken to the main Kritikos search page, shown below, with all the results relevant to the particular search term. A user can select the resource type, and the page will display Any resource which already has data associated with it in the Learning Registry is clearly marked by the LR icon at the top-right.

Kritikos search results for Flash movies on tensile testing

Clicking on a thumbnail takes the user to the resource detail page. This provides a mini representation of the resource, and if it is interactive, the user can enjoy the full functionality of it without going to the host page. This is the page where all data associated with an individual resource is displayed. The user can also interact with the resourse, e.g. leave a comment, reccommend it, or assign it as relevant/not relevant to a particular module of study. A user can also add the resource to his/her favourites list. They can also ‘vote’ on the activity of other users by clicking on the thumbs up/thumbs down icons.

Kritikos resource details page

Paul Hagan and Simon Hatton from our Computing Services Department have been a huge help in finalizing the current view of the Kritikos widget and the site itself. Thank you guys!

Liverpool Learning Registry Node

Silhouette of cartoon character scratching headA frustrating week as we try – so far without success – to reinstall our Learning Registry node here at Liverpool. It was actually working okay until we wiped the test data in readiness for publishing the main set of documents.

Thanks due to John Gilbertson from our Computing Services Department, and also especially to Nick Syrotiuk from Mimas, for their patience in trying to resolve the issue.

We aim to roll out Kritikos to all the students in the Engineering Dpartment as soon as we can resolve the problems with the node. Some of the front-end web application code will need changing to reflect the new paradata document structures, but believe this can be done quickly.

UPDATE 28 Feb 10:00

John has now tried reinstalling the Learning Registry node onto a clean virtual machine and it still doesn’t work. He suspects that some library file required by the software has been updated and is no longer compatible. Running out of options and ideas :-(

UPDATE 1 Mar 17:00

Problem now resolved – see new posting.

Preventing duplicate paradata

We’re currently developing the code designed to prevent users from, accidentally or otherwise:

  • recording the same activity more than once
  • liking (or upvoting) their own activities

For example, if a student recommends a resource (URL) for a particular module, we should prevent them from doing it a second time. Likewise, we want to avoid the possibility of users voting for the same activity more than once (presumably with the intent of increasing the ranking of a resource or of another user). Similarly, we want to prevent users from upvoting any of their own activities (again with the intent of raising their own user ranking)

Unique User Identification

We need to make a final decision as to how individual students will be uniquely identifiable in our Learning Registry node. At present (01 Jan 2013), we record:

  • students’ full name (given and family name)
  • their degree programme (course)
  • degree title (BEng, MEng, etc)
  • current year of study.

In the short term, this is likely to provide ‘unique’ enough, but since we are now able to retrieve the students’ (or staff’s) University ID, we propose saving this in an encrypted form.

Having a unique identifier will make it easier to develop the code to prevent (i) users from voting for their own interactions (recommendations, comments, etc.) and (ii) users from sending duplicate paradata.

PHP code for publishing paradata to LR

We’re busy this week combining the various bits of code that we have written to date into one PHP class which will handle publishing paradata into our Learning Registry node. The paradata that accompanies different types of action (view, comment, align, recommend, not-align, share, upvote and downvote) and different users (students, teachers) are quite heterogeneous, so it’s all a bit fiddly.

Upvote/downvote actions in Learning Registry

We’ve been looking at the best way to implement upvote/downvote functionality in our website. The purpose of this is to enable users to endorse or disagree with other users’ activities, thereby introducing a level of self-regulation or democratisation. It also allows users to earn credibility or trustworthiness, which can then be used in the algorithm used to rank search results, and also incentivise students to interact positively with the ENGrich service.

Although some social media sites such as Facebook only support the positive like, our initial position is that we should allow (identifiable) users to give negative votes for activities they do not agree with. We shall review this position with our student group once we have gathered and analysed sufficient activity data.

The paradata statement we propose publishing into Learning Registry will take the following form. Note that the object of the paradata statement is the URL of a page describing the first user’s activity (e.g. comment, recommendation), not the URL of the actual resource itself.

{
"doc_type": "resource_data",
"doc_version": "0.50.0",
"resource_data_type": "paradata",
"active": true,
"identity": {
"owner": "AN Other",
"curator": "",
"submitter_type": "agent",
"submitter": "ENGrich",
"signer": ""
},
"digital_signature": "",
"resource_locator": "http://engrich.liv.ac.uk/rd3/?doc_id=78396f82b6984512ab5c3d5dab8e0b17",
"payload_placement": "inline",
"payload_schema": "LR Paradata 1.0",
"resource_data": {
"activity": {
"actor": {
"objectType": "student",
"displayName": " Student Name",
"description": [
"University",
"Engineering",
"University of Liverpool",
"3rd year",
"Aerospace Engineering with Pilot Studies",
"MEng(Hons)"
]
},
"verb": {
"action": "upvote",
"context": "ENGrich website",
"date": "2012-06-28"
},
"object": {
"id": "http://engrich.liv.ac.uk/rd3/?doc_id=78396f82b6984512ab5c3d5dab8e0b17"
},
"content": "This resource was upvoted on the ENGrich website by a 3rd year student reading Aerospace Engineering with Pilot Studies MEng (Hons) at the University of Liverpool on June28, 2012."
}
}
}

Checks:

  • prevent individual user from making more than one upvote/downvote on a particular activity
  • prevent users from upvoting (or downvoting) their own activities

Paradata published to Learning Registry

Today we have published two large batches of data into the JLeRN Learning Registry node:

  • 643 comments by the students on individual resources (URLs)
  • 5,400+ ‘assertions’ by students that individual resources are not relevant to engineering and/or education. Such data will eventually help to make future search results more relevant by demoting those resources that relate to other subjects (medicine is a common one) or target audiences (commercial, sales, marketing resources with little/no educational content).

We have also started work on the user interface to display these new paradata ‘types’.

Update and Delete: Learning Registry Tech Spec Amendment

Learning Registry logoThe imminent addition of federated update and delete solutions for Learning Registry is a very welcome development for the ENGrich project. This is the first NoSQL/CouchDB-based project that we’ve worked on and we’re still getting used to the paradigm shift away from regular SQL programming techniques and methodology. While we understand in principle the ideas set out in the LR Quick Reference Guide of ‘updating’ by publishing new documents and then as a data consumer, identifying the most recent (with the same type, submitter and resource locator), in practice we find it’s not always quite so simple. Publishing data can sometimes feel like hitting a very large red button, knowing that what’s done cannot easily be undone. We therefore look forward to seeing the outcomes of the review period, and wish the core LR team the best in its future implementation.

Ranking algorithm for search results

We have spent much of today working on the ranking algorithm to use for search results.

Each time a student interacts with a resource, the event will be captured and published into Learning Registry. Examples of such events include:

  • matching a resource with a particular study module (alignment, in LR Paradata parlance)
  • recommending a resource for a particular study module
  • commenting on a resource
  • sharing a resource (e.g. on Facebook, Twitter or LinkedIn)

We are calling these primary interactions, each of which can carry different ‘points’ for weighting subsequent searches.

In addition to these events, we will provide a mechanism for users to like/dislike (or agree/disagree with) other students’ primary interactions, thereby introducing a system of self-moderation or ‘democratisation’. Each user will therefore build up a trustworthiness index, based on how helpful or otherwise their peers judge them to be.

The ranking of the resource will therefore depend on the number of interactions found in LR, the relative importance of these interactions and the trustworthiness of the contributors.