c4l13_scholarsphere.md

ARCHITECTing ScholarSphere

ScholarSphere is a web application that allows the Penn State research community to deposit, share, and manage its scholarly works. It is also, as some of our users and our peers have observed, a repository app that feels much more like Google Docs or GitHub than earlier-generation repository applications. ScholarSphere is built upon the Hydra framework (Fedora Commons, Solr, Blacklight, Ruby on Rails), MySQL, Redis, Resque, FITS, ImageMagick, jQuery, Bootstrap, and FontAwesome. We'll talk about techniques we used to:

• eliminate Fedora-isms in the application
  1. no objects
  2. no datastreams
  3. no namespaces in URLs
• model and expose RDF metadata in ways that users find unobtrusive
  1. tradeoffs for using RDF instead of XML to serialize metadata
  2. limit of our authority control (essentially size, surfacing strings and not the URIs)
• manage permissions via a UI widget that doesn't stab you in the face
• harvest and connect controlled vocabularies (such as LCSH) to forms
• make URIs cool
• keep the app snappy without venturing into the architectural labyrinth of YAGNI
• build and queue background jobs
  1. moved from MySQL to Redis
  2. jobs include: characterization, thumbnail creation, batch metadata, activity streams
• expose social features and populate activity streams
• tie checksum verification, characterization, and version control to the UI
• let users upload and edit multiple files at once
• current environment set up (jenkins, github, redmine)
• future environment set up

The emerging 4 S's of #ScholarSphere's design philosophy:

• Semantic data;
• Social experience;
• Simple UI;
• Scholarly content

Screen casts:

• file upload
• permissions widget
• vocal authority