Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The #GoOpen Initiative was spearheaded by the US Department of Education Office of Educational Technology in the fall of 2015 as a way to support States and districts choosing to transition to the use of openly licensed educational resources to transform teaching and learning. As part of that program, state and district educational agencies were motivated to share their open educational resources (OER) using the Learning Registry.
To support the GoOpen program, a separate branch (goopen branch) of the Learning Registry node software was started, with an emphasis on making it easier to control the publishers to the node, and to enforce data format and quality restrictions on the resources published to the node. The goopen branch was eventually merged into the 0.52.0 branch, where configuration options were added so that the nodes could be standardized across one codebase, with these new features as options.
The GoOpen Node was launched in March 2016, with details provided to the developer community.
The main features that distinguished the GoOpen node from the public LR nodes (node01 and node02):
- moderated registration process for publisher accounts
- resource metadata only, using payload schema of LRMI/schema.org/JSON-LD format.
- Metadata validation on publish
- initial seeded with approximately 96,000 resources, culled from the best metadata on the public nodes, plus some new additions
As part of the launch of this node, we’re also pleased to announce resource contributions from the following organizations: TES Global - approximately 1000 records, sample Khan Academy - approximately 3000 records, sample the National Archives’ DocsTeach - approximately 100 records, sample
Although updating the authentication mechanism was not integral the GoOpen program, the requirement to add a gatekeeping mechanism for new publisher accounts on a node offered a chance to switch from the legacy Mozilla Persona identity verification system to using the industry standard OpenID Connect (OIDC) authentication layer. Using OIDC, new LR publishers are given multiple options during the publisher registration process for verifying their identity, while keeping the existing the existing infrastructure of publisher accounts in CouchDB meant that the minimal updates would need to be made to the overall core features of the system.
The authentication app between the OIDC providers and the CouchDB user account storage was written as a Ruby on Rails app. On the LR nodes it runs from the /auth-server path, served via the Passenger Phusion app server.
When registering for a new publisher account, the RoR app presents the user with a form to provide information for their account request, with the following fields:
- Name of Organization
- Point of contact (person responsible for metadata)
- E-mail address for point of contact
- Estimated number of records to publish
- A sample of a record to be published
To simplify the gatekeeping functionality and provide maximum flexibility for publisher account approvals, the RoR app sends an email with account request information to a configurable address. If multiple people are responsible for account approvals, a Google group or similar distribution method can be used for this address. The email sent includes a link to approve the account. Once an account is approved, the new publisher receives notification that their account has been approved.
Switch from Mozilla Persona to OIDC
Shortly after the GoOpen nodes were launched, Mozilla announced that they would shutdown their Persona services in fall of 2016. At that time the other OIDC changes were integrated into the main LR codebase (as part of 0.52.0) and all LR public nodes were updated to use OIDC as their authentication method. The RoR app server has a configuration parameter,
approval_enabled in secrets.yml, which is set to false on the non-GoOpen nodes, so that publisher accounts are created immediately with no gatekeeping.
LRMI Schema Validation
To ease the process of consuming records from the GoOpen node, an additional schema validation option was added to the LR codebase. When enabled in the config, records published to the node must validate against a more strict set of standards. Node admins can make adjustments to the schema requirements internally by updating the resource_lrmi_open.json file.
At the launch of the GoOpen nodes, the schema validation required:
- all records must be resource metadata (no paradata)
- payload schema must be in LRMI, schema.org, or JSON-LD format
- Required fields: url, name, description, accessRights, and publisher
These schema requirements were enacted to provide some assurance to consumers of the GoOpen node records that the metadata they were consuming would be high quality. The validation mechanism could be adjusted to ease, or to further restrict the metadata on a node by node basis.