Learning Registry 2.0 ideas

[Steve Midgley]

Hi,

I wrote up a list of Learning Registry 2.0 features that I've been thinking about - in relation to how they work in the 1.0 system. Since many people at the GoOpen event expressed interest in understanding where we're trying to go with the new system, I thought I should share my thinking here.. You can also see the roadmap for features that we're working on here: https://github.com/learningtapestry/learningregistry/issues (you can also browse the codebase at the location, but it's very preliminary and not readme yet).

Here are the issues that I think LR 1.0 has that we should fix, and how I think the work we're doing for a proposed 2.0 project will address them:

• LR is not "hackable" - The architecture is not good (CouchDB and Python mixed up unhappily). Authentication is not great. Search is virtually impossible to expand upon without massive disk space problems.
• We are rebuilding LR core in a very simple Ruby/Grape API DSL. 
• We are using Postgres on the bottom end
• We are adding an ElasticSearch engine as an optional search component
• These actions should fix all the programming and architecture issues that make it hard to create new features for the project.
• LR APIs are sprawling, confusing and not useful for primary use cases
• We are greatly simplifying the API set, to use a basic set of RESTful verbs
• We are making the API supportive of parallel queries, to make access easier
• The archive/federation system is not effective
• We are going to disable the master-master replication API. We are going to enable a "backup/restore with archive.org" facility to make it *much* easier for everyone to get a copy of the whole LR database.
• The digital signing of envelopes is custom, confusing and hard to implement against
• We are redesigning the envelopes in several ways:
• JSON Web Tokens for signing (jwt.io)
• Use json-ld and/or xml/xsd namespace extensions to make LR more compatible with schema.org/dublin core and the web in general (I just wrote an email about this proposal to the group)
• Update/delete is hard to use
• We are adjusting update/delete to make it easier to use. We want a concept of "delete my metadata envelope" to be distinct from "delete this resource"
• Deletes will be "suggestions" rather than database operations. Search engines can honor deletes or ignore them. You can use/eval deletes, even if you are using the resource metadata as well.
• Envelopes are hard to use, resources are unavailable
• LR doesn't provide access to resources - only envelopes of metadata. It might have 5 envelopes that all refer to one resource.
• We plan to provide a "merged view" of envelopes so you can see every envelope in one data structure, making it appear much more like a single resource.
• We are NOT building a search engine that ranks/weights resources - other orgs are providing this already.

More soon but that's the feature set as I see it! Please send your feedback and ideas. And participating in our bi-weekly call is a great way to get engaged in collaborating on the work going forward. We had a great call today.

Best,

Steve