oregondigital / od2 Goto Github PK

Next generation of Oregon Digital ( https://oregondigital.org ) digital collections platform, built on Samvera Hyrax ( https://github.com/samvera/hyrax/ )

Ruby 34.35% JavaScript 1.69% HTML 61.31% Dockerfile 0.17% Shell 0.26% Haml 0.09% SCSS 1.97% Python 0.16%

linked-data rdf digital-collections rails solr fedora blazegraph samvera hyrax blacklight

od2's Introduction

OregonDigital

Overview

Current production Oregon Digital running Fedora 3 and Hydra 6.

New development is focused on Oregon Digital 2: http://github.com/OregonDigital/OD2

Connected projects:

csv2bag - bulk ingest from CSV
cdm2bag - bulk ingest from CONTENTdm
ControlledVocabularyManager - Rails app with Blazegraph powering OpaqueNamespace.org

Local Development Setup

Using Docker

Grab everything you need

# Grab the repository
git clone [email protected]:OregonDigital/oregondigital.git

# Start the whole stack - on your first run, this can take a while to download
# all the necessary images
docker-compose up -d

Making zoomable images work

Create config/app.yml with information about how to reach your local system's RAIS container; e.g.:

iip_server:
  location: http://localhost:12415/images/dzi

You may need to choose something other than localhost if you're doing a demo or running docker inside a virtual machine. The rest of the settings (port and path) should remain untouched.

Generate filler data

First, run the rake task:

docker-compose exec workers bundle exec rake filler_data

Next, log into the main application by browsing to http://localhost:3000/users/sign_in. Docker sets up the admin user as "[email protected]" with the password "admin123". Once you're signed in, visit http://localhost:3000/resque/overview and watch the queue slowly get processed. This can take a while, but once it's done you should have 3 collections of dummy data.

Testing

Easy as ./docker/test.sh! Except....

Want to focus tests? Just pass in a path: ./docker/test.sh spec/models.
If you need to ensure your environment is pristine, use the --destroy flag, which will destroy and rebuild all containers.

Updating Gems

The safest way to update gems is to destroy and rebuild the dev image, otherwise you're only updating gems within a container, and containers do not necessarily persist very long.

docker-compose stop
docker-compose rm
docker rmi oregondigital/od1-dev
docker-compose build workers

You can also run "bundle install" inside a particular container, but this should only be done if you know what you're doing. It can get really confusing when you accidentally use docker-compose run when you meant docker-compose exec. Or if you choose the wrong container name.

Various other docker stuff

This list of commands should get you moving forward with most typical development tasks:

# When you change code, if you start getting odd errors, you may have to
# restart the OD containers:
docker-compose restart web workers resquehead

# If things are still "weird", rebuild the OD containers:
docker-compose stop web workers resquehead
docker-compose rm web workers resquehead
docker-compose build web workers resquehead
docker-compose up -d

# If you need a "hard reset", nuke it!  WARNING: THIS WILL REMOVE ALL YOUR
# DEVELOPMENT-INGESTED ASSETS!
./docker/nuke.sh

# When nukes just don't destroy enough, try out a SUPERNOVA!  This will remove
# every Docker entity related to OD, which will mean re-downloading the images:
./docker/supernova.sh

# Watch the logs for everything
docker-compose logs -f

# Just watch the Rails web app logs
docker-compose logs -f web

Manual

Requires Ruby 2.0

(Mongo needs to be running, 2.4 is known to work: https://docs.mongodb.com/v2.4/tutorial/install-mongodb-on-ubuntu/ )

git clone [email protected]:OregonDigital/oregondigital.git
cd oregondigital
bundle install
rake db:migrate
git submodule init
git submodule update
rake hydra:jetty:config

On a newer install, may have to pin

Symlink media directories:

ln -s /path/to/rails/media public/media
ln -s /path/to/rails/media/thumbnails public/thumbnails

Install memcached if needed, or make sure it's running (needed for login sessions):

Ubuntu: sudo apt-get install memcached
Mac/Homebrew: brew install memcached
Other: http://memcached.org/downloads

Start the servers:

rake jetty:start
rails server

Vagrant Setup

Requires Git, VirtualBox, and Vagrant. Also requires 3 gigs of RAM to be available for the VM which vagrant creates.

Option 1: manual submodule setup:

git clone [email protected]:OregonDigital/oregondigital.git
cd oregondigital
git submodule init
git submodule update

Option 2: automatic submodule setup:

git clone [email protected]:OregonDigital/oregondigital.git --recursive
cd oregondigital

Either way, you then tell vagrant to download and start the virtual machine:

vagrant up
vagrant ssh

After vagrant ssh you'll be logged into the VM. From there, you'll want to start the Rails server:

cd /vagrant
rails server

You can browse the app via http://localhost:3000, and check on the jetty container (which houses solr and fedora) at http://localhost:8983.

od2's People

Contributors

Stargazers

Watchers

Forkers

notch8

od2's Issues

IIIF Configuration

Descriptive summary

RIIIF Needs to be configured early on to verify that derivatives are being processed properly.

https://github.com/curationexperts/riiif

A Ruby IIIF image server as a rails engine

This is a good solution early on, while the systems team configures and sets up the servers and configurations needed to get this working with Amazon S3 and a bunch of other different file systems and servers.

To configure RIIIF in OD2 Follow these steps.

Add RIIIF gem to gemfile and bundle install and rebuild docker:

gem 'riiif', '~> 1.1'

Configure RIIIF in hyrax.rb initializer file

config.iiif_image_server = true
   # Returns a URL that resolves to an image provided by a IIIF image server
  config.iiif_image_url_builder = lambda do |file_id, base_url, size|
    "#{base_url}/downloads/#{file_id.split('/').first}"
  end
   # Returns a URL that resolves to an info.json file provided by a IIIF image server
  config.iiif_info_url_builder = lambda do |_, _|
    ""
  end
   # Returns a URL that indicates your IIIF image server compliance level
  config.iiif_image_compliance_level_uri = 'http://iiif.io/api/image/2/level2.json'
   # Returns a IIIF image size default
  config.iiif_image_size_default = '600,'
   # Fields to display in the IIIF metadata section; default is the required fields
  config.iiif_metadata_fields = Hyrax::Forms::WorkForm.required_fields

Add RIIIF initializer file with proper configurations

Riiif::Image.file_resolver = Riiif::HTTPFileResolver.new
Riiif::Image.info_service = lambda do |id, _file|
  # id will look like a path to a pcdm:file
  # (e.g. rv042t299%2Ffiles%2F6d71677a-4f80-42f1-ae58-ed1063fd79c7)
  # but we just want the id for the FileSet it's attached to.

  # Capture everything before the first slash
  fs_id = id.sub(/\A([^\/]*)\/.*/, '\1')
  resp = ActiveFedora::SolrService.get("id:#{fs_id}")
  doc = resp['response']['docs'].first
  raise "Unable to find solr document with id:#{fs_id}" unless doc
  { height: doc['height_is'], width: doc['width_is'] }
end

Riiif::Image.file_resolver.id_to_uri = lambda do |id|
  ActiveFedora::Base.id_to_uri(CGI.unescape(id)).tap do |url|
    Rails.logger.info "Riiif resolved #{id} to #{url}"
  end
end

Riiif::Image.authorization_service = Hyrax::IIIFAuthorizationService

Riiif.not_found_image = Rails.root.join('app', 'assets', 'images', 'us_404.svg')
Riiif.unauthorized_image = Rails.root.join('app', 'assets', 'images', 'us_404.svg')

Riiif::Engine.config.cache_duration_in_days = 365

Mount the engine in routes.rb file:

mount Riiif::Engine => 'images', as: :riiif if Hyrax.config.iiif_image_server?

Configure users with proper roles within admin sets

Descriptive summary

This will be a bunch of busy work that requires someone to go in and setup workflow roles for specific users. You can add users to workflow roles from the workflow roles tab.

Dependent on #24

Based on what was said in ticket 24, the base could work with the possible addition of a 4th, which is called "Curating" A discussion about this role will be found here "INSERT LINK HERE!!!!!!!!!!!!!!!!!".

Configuring a new role can be quite an extensive process, and should be discussed amongst the developers. Some key files however, are as follows.
https://github.com/samvera/hyrax/blob/5a9d1be16ee1a9150646384471992b03aab527a5/lib/hyrax/role_registry.rb

It may be as simple as adding the role to this file to register it, but some more work may be involved. We have not added extra roles to SA so we are unfamiliar with this process for the most part.

Break apart characterization blob into separate fields

Descriptive summary

This ticket lays out the need for more granularized information about files. Currently hyrax monitors file information gathered from fitz (which is a file characterization library which gathers information about a file) in a giant blob of text in "characterization" field on a fileset. It would be worth while to break that blob of text up into their own fields to make them facetable or searchable for more descriptive and useful information about files ingested into OD2.

File size, mime type, checksum, etc.

#356

Bulk load testing data

Descriptive summary

Generate a simple (throwaway-able) script that can process a CSV of metadata to create/recreate works and upload related files to OD2 Staging.

Expected behavior

This will, initially, work with ActiveFedora worktypes and be capable of reloading a bunch of test metadata and files for the sake of testing staging.

create basic worktypes for Generic and Image models

Descriptive summary

@vantuyls asks to have these basic work types built initially for demonstration purpose and built upon as we complete the metadata application profile

Admin Dashboard view of oEmbed enabled items

Descriptive summary

Admins and staff should be able to easily see only all works that have an oEmbed URL included.

Expected behavior

An Admin Dashboard view can show which works have an oEmbed URL included.

Related work

#75 Initial configuration of oEmbed

[10] Alternative rendering of relationships on the show page

Descriptive summary

Currently, we are rendering a simple link on the show page to a parent or a child. This is rendered pretty far down on the page, and may not be as apparent to someone who is viewing the page right away. We need to work on making this more noticeable. Do we want to render the relationships higher on the page? Do we want to add a badge on the work if it is in a relationship? Another badge if it is in a collection? We need to figure out how to render these pieces of information on a work show page to better highlight the relationships of the work. This would allow users to have an easier time discovering other works within the system.

Furthermore, This work may have siblings. Works that have the same parent. If this work is a sibling to another work, it would be great if a user could go to the previous or next work in the list. This builds off of the ordering of works within a collection, but can also stand alone based on the current order in a returns list of sibling IDs. Whichever it may be, being able to go sideways in the graph would also enhance discoverability in the system.

Expected behavior

When a user views a work that is part of a collection or has a parent or child, it is easily noticeable and easy to see what collection or parents or children this work has. A user must be able to go to said collection, parent, or child for ease of discoverability.

Related work

This work may be done by another team at the time of arriving at this ticket. We may need to re-discuss this and figure out our needs at that time.

Also discussed having some of this relationship info in the Universal Viewer.

Ordered metadata on works

Descriptive summary

Ordered metadata has a lot of moving parts. There has been a lot of work done in SA surrounding this, but here is the gist. There are some fields thats data is ordered. Like for instance creator. There could be a creator that is considered the primary creator, and all the other creators show up behind that in order of contribution date. This order is very important to the work and to the metadata and folks using that work. It is important that we allow for that order to be established and maintained.

Like previously said, there has been done in SA by the team and there are several PRs that are associated with it. This work is going to be most likely the bulk of work in this stage of OD and time needs to be taken to thoroughly and fully implement this feature.

We need to or may have already identified which fields are ordered. We need to refer to the MAP about that. Also, we need to make sure that we pay careful attention to the predicates associated with these nested ordered terms. The data associated with this is indeed nested and Fedora has a hard time with that, so there are some heavy customizations around being able to support nested data.

Expected behavior

A user can duplicate an ordered field and rearrange those pieces of data in the proper order. An order is assigned to each field and on save, the order is persisted on the nested ordered objects associated with that work. When the show page is visited, the data is displayed in the proper order. Editing needs to work the same.

This is the PR that implements Ordering on one field. This will supply some of the barebones work that can get ordering to work. There are also some bug fixes and changes that have occurred over time so make sure to check the most up to date files in SA when porting this work over. There are also heavy JS customizations done and close attention will need to be paid to that.

Dependency on Valkyrie/Hyrax 3 for this work - might also depend on Postgres for backend.

[10] Design for Collections Landing Pages

Descriptive summary

This may or may not be work done in hyrax. There should be the ability to express a collection landing page per collection. This landing page would contain information about the collection. Whats in it? Where did it come from? What is its significance? Some sort of description of the collection. It should also have representative images associated with the collection. ~~These should be displayed on the landing page in a carousel like rotation.~~ These should be displayed in a single row of thumbnails, 4 across.

These have already been implemented in OD and are a very important piece of displaying a collection for users to see. This collection landing page needs to be accessible from a list of collections somewhere in OD2.

Expected behavior

When the collection is visited, all the information associated with the collection will be displayed on its landing page.

Latest MAC design:
https://projects.invisionapp.com/share/47X400SV3BM#/screens/415938473

###Related Issues
#42

Discoverable Compound Objects

Descriptive summary

Compound Objects exist in Hyrax by virtue of the work done with PCDM. Then Hyrax was extended to be able to track these compound objects. These compound objects come in many forms. One way it manifests is through a work and its image associated with it. That image is a FileSet object which is nested under the work. FileSets are discoverable by themselves but also from a work with a related FileSet. This was extended even further to be able to support Parent/Child relationships within the system. A parent work could be an article, but a child work associated with that article could be an existing dataset used in the article. That dataset could be a work itself with many different pieces of metadata associated with it.

We need to make this relationship more visible to people trying to discover works. Currently, when a search is fired off, works show up in a list format. These works do not show users whether or not that work has children works, filesets, or anything else. It would be useful for users to see maybe if this work was contained in a collection or many collections. Whether or not it is a parent or has a parent. And many other different ways.

Some questions that arise are, how far "up" or "down" do we want to display in the hierarchy. We dont want to go too bananas on it, but we also want to provide enough information to help users who are trying to discover and research.

This spills into the idea, that maybe we need to overhaul the search result interface, to display many different types of results in different sections. This is definitely an epic ticket that needs more discussion but should serve as a good starting point to figure out the work involved and needed.

Expected behavior

When a user searches for a work, you get contextual information about its relationship to other objects. Parents? Children? In a collection?

One example, if it's possible to do this (Duke's new ArcLight): https://archives.lib.duke.edu/?utf8=%E2%9C%93&group=true&search_field=all_fields&q=duke

Related work

Some work may be done in collection extensions that would serve to help support this idea and could be done by others at the point of working on this ticket.

Configure, setup, install, and code for OAI endpoint

Descriptive summary

OD provides its works and metadata to other groups that harvest the data using an OAI-PMH Harvester.

Current OD OAI endpoint is: https://oregondigital.org/oai
Example result for a set/collection is: https://oregondigital.org/oai?verb=ListRecords&metadataPrefix=oai_qdc&set=oregondigital:illustrated-booklets

OD Wiki page, more details and known harvesters: https://github.com/OregonDigital/oregondigital/wiki/OAI-Documentation

https://github.com/projectblacklight/blacklight_oai_provider

Expected behavior

OAI endpoint works
oai_dc and oai_qdc formats are supported
OAI sets are configured, likely corresponding to AdminSets

Related work

Link to related tickets or prior related work here.

Initial configuration of oEmbed

Descriptive summary

EDIT:
@CGillen Attempted the above and it doesnt work due to the fact that hyrax uses its own routes instead of using blacklight routes. The gem requires blacklight routes to work. Instead we plan on using https://github.com/ruby-oembed/ruby-oembed Which can manually grab the oembed stuff. We want to get data in the front end using AJAX and parse it out and display the html in order to prevent the app from hanging.

ORIGINAL TICKET:
First what will need to happen is the installation of the oembed gem. You can follow their step by step guide on how to do this found here. https://github.com/sul-dlss/blacklight-oembed

One you have installed the gem and run the bundle install command, the code should now be available to you.

Next what needs to happen is the base configuration of oembed. That can also be found https://github.com/sul-dlss/blacklight-oembed

Youll have to run the install rake task, which will generate all the files needed by the application to get oembed working.

The catalog controller will have to be configured to know what field is configured to be the oembed field.

The initializer will need to be configured to know which endpoints to accept. This may need some thought, because you may be able to configure it to use any endpoint.

After this is all completed, then you will have to setup the oembed field in the application. The field can be named anything but will follow this format.

property :abstract, predicate: ::RDF::Vocab::DC.abstract do |index|
    index.as :stored_searchable
end

After this field is setup, youll have to add that named field to the configuration in the catalog controller for the oembed stuff.

Now, you should be able to ingest a new work, fill out all its required field, add an oembed url to the proper field (using the link pulled from say any youtube video as long as its the actual oembed url)

The work should save and on the show page the video should be displaying.

Requirements

for an item, we want to be able to add an oEmbed URL to a field (exact field TBD, can create new 'oembed' property for now) and then on the showpage it will show the player for the video

Bulk Work (Ingest, Review, Edit, Export, Task Control)

Descriptive summary

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

THIS WORK MAY BE CONTRACTED OUT AND NEEDS MAJOR DISCUSSION ON WHAT THE NEEDS OF THIS FEATURE ARE!!!!!!

-Bulk Edit
-Bulk Review
-Bulk Ingest
-Bulk Export
-Bulk Task Control

Expected behavior

Actual behavior

Steps to reproduce the behavior

Do this
Then do this...

Related work

Link to related tickets or prior related work here.

Complete 'Work Type Where Defined' column in MAP

Ryan will take the first pass. Sarah S. and Julia will review ASAP.

What is MVP for user groups and grouping in OD2?

Descriptive summary

Groupify found here: https://github.com/dwbutler/groupify

The groupify gem would be used in place of the abilities in hyrax. This would replace the abilities that are in hyrax. You can express relationships between rails models. There is some research that we would have to do to see if this meets our needs and there would have to be some discussion about how we want to configure this gem to work differently for each user. This is also dependent on whether or not the roles currently in hyrax get the job done or not. This would be based on ticket #24.

IIIF Configuration/Linking for Thumbnails

Descriptive summary

Each work within OD should have a supporting image or FileSet associated with it. This image will be stored elsewhere and will need to be linked into Hyrax from where it is stored. One of the ways it will be linked in is on the search results page. If a work shows up in the search results and has an accompanying image, it will need to be displayed as a thumbnail here. It needs to be formatted to a specific size based on derivatives being generated.

This work is highly dependent on what the Systems Team decides to do for creating derivatives. It will also need to be decided what we want to display if the accompanying FileSet is an audio or video file. Do we want to display a specific frame in the video file? Do we want a default images?

RIIIF Will have to be configured. This will allow the image viewer work, This is a part of IIIF within OD2 and can be found here:

https://github.com/curationexperts/riiif

RIIIF can be a little confusing, but is useful when working with other forms of viewers within hyrax.

Expected behavior

Thumbnails show up in places around the system Featured Works, Search Results, etc.

Related work

This work is heavily dictated by whether or not the systems team has the derivative generation infrastructure into place and derivatives are being generated properly.

#54

[1] Build and ingest workflows

Descriptive summary

Each worktype will have its own workflow based on specific needs of either an institution or process needed to accept a type of work in the application. These workflows are expressed in a configuration file found here. https://github.com/osulp/Scholars-Archive/tree/master/config/workflows or in /config/workflows/*.json. These workflows will be generated based on a state machine type flow. For information about state machines see here. https://en.wikipedia.org/wiki/Finite-state_machine#Classification. There is also a wiki that has been written about hyrax workflows found https://github.com/osulp/Scholars-Archive/wiki/Workflows and https://github.com/samvera/hyrax/wiki/Defining-a-Workflow . The workflows will then need to be heavily tested as their layout, states, to and from actions, can tend to get quite complicated.

The workflows are built using a system called Sipity. This library can be found here: https://github.com/ndlib/sipity

This is a library that can arbitrarily build a set of rules based on a state machine. These rules define the state machine. How to get from one state to the next, what are any processes that need to be ran when you transition to a certain state, and many other different things. These workflows will have to be verified heavily, but progress needs to be made on them over time. @vantuyls Is the one who worked heavily on the workflows in ScholarsArchive, and would be a good consultant for this work.

These will be committed to the repository, but make sure that when these PRs are being pushed up, to add a GIF of it working. We use LICEcap as our capture software, but any file in gif format should work.

https://licecap.en.softonic.com/

Checking and setting a workflow looks like this:

Using a workflow is found in this dropdown:

Expected behavior

After a workflow is created per the layout expressed in the previous links, and put in the proper place in the application, a rake task will need to be ran in order to generate the necessary workflow within the application. The system will express that an error exists in the workflow json file and fail to ingest, if it does not work. If it does, no error will be reported out. You can then check that the workflows exist in the dashboard > collections (under the all collections tab). When you edit a collection, you can express what workflows each work within that collection gets. Each work type will have its own admin set or collection.

Related work

The related work associated with this ticket is the Completion of the MAP. The map will have to be completed to know what types of workflows are associated with each work type

Related Tickets

Verification of Features Already in Hyrax/OD

Descriptive summary

This ticket represents the need to go through hyrax and verify that some of the features assumed to be working in hyrax, are actually working as expected. This ticket can be updated overtime when we discover that hyrax has a feature that we need and we need to verify that they are working. Some different features that exist that need to be verified are as follows.

Expected behavior

Verify that User editing works.
* Updating user info
* Is the user info correct?
* Can you delete and create other users in the UI?

A user can update their own information which includes ORCID, facebook, twitter, G+.
A user can update their password if logged in.
An admin cannot remove users from the application.
An admin cannot update information about a user.
An admin cannot create other users unless through the devise interface or using their university credentials.
A user cannot delete their account.

Verify that the review queue is sufficient
* Can you review a work from the UI
* Can you see all works under review
* Can you filter out works to see your works that you want to review?

A work can be reviewed from two places. The review queue located at /admin/workflows
An admin can see all the works under review at /admin/workflows
Under review works can be sorted via the columns at /admin/workflows. They can also be searched for. No other methods of filtering are available at this time.

Verify the Parent Child relationship information is displayed properly on the show page
* Is this how we want it?
* Does it need to be moved anywhere?

Currently, the parent child info is shown quite far down on the page. Its not readily visible when a user first visits the show page. Do we want to move it up? @mccallum Might have some good ideas.

Verify Zoomable image viewer is working properly
* Is it working as expected?
* Does it cover all our needs for different image types?

Images: The viewer works well for images. They can pan, zoom, rotate, display information about the item.

Audio: Not working

Video: Not working

PDF: Available for downloading. No viewer used

Document: Gets loaded into the system and is downloadable. No viewer used.

Verify PDF viewer fulfills all requirements
* OCR reading for searching
* Next/Previous page
* Table of Contents
* Zoomable

PDF VIEWER NOT FUNCTIONAL

Versioning

Versioning not working. Says it uploads a new file, but dont have access to file and doesnt replace old file.

Install blazegraph and copy over configuration files for blazegraph

Descriptive summary

This ticket describes the need for installing blazegraph for OD2. Blazegraph is handled mostly by the gem found here. https://github.com/osulp/triplestore-adapter

This gem is an interface gem which allows a user to connect to any triplestore backend like marmotta or in our case, blazegraph. By installing this gem, it gives you access to rake tasks which allow for the controlling of said backend triplestore.

After the installation of this gem run the task rake triplestore_adapter:blazegraph:setup and this should setup any necessary configuration for the triplestore.

You will know this is all working when you run rake triplestore_adapter:blazegraph:start and it works.

One note is that in order for blazegraph to work, it needs a namespace. Im not entirely sure whether or not the namespace is built on configuration but you can also run rake triplestore_adapter:blazegraph:build_namespace

Set up Controlled Vocabulary Objects in OD

Descriptive summary

This work may or may not need to be done based on how our implementation of triple powered properties goes. In hyrax, there are controlled vocabulary objects, such as this: https://github.com/samvera/hyrax/blob/5a9d1be16ee1a9150646384471992b03aab527a5/lib/hyrax/controlled_vocabularies/location.rb This is a controlled vocabulary object that manages the location based uri handling and retrieval of labels. We could do this for all or some of our controlled vocabulary fields. This will just need to be discussed.

-Pros

Follows the Hyrax way of doing controlled vocabularies
Inherently organized based on hyrax ways of doing things
Flows nicely through the form and other pieces of hyrax

-Cons

We havent fully utilized this and we dont know the inner workings of it all too well
We did another way of dealing with controlled vocabularies in SA.

Discussion can be had here.

PREMIS Data indexed and accessible in exports and show pages

Descriptive summary

We need to begin logging PREMIS Data. PREMIS data is the "who" "what" "when" of changes being made to works in the system. If a user goes in and edits a work, we would like to know things like, what fields were changed, who changed them, when was the change made, what was it changed from? This are all important questions and can help with tracking within the system. We need to figure out which pieces of data are already being logged, what pieces of metadata need to be added to the work metadata to help with tracking, indexing this data, and being able to display this data to those who need it. We would also have to work on working this data into exports of data at some point down the road.

Expected behavior

When a work is created, edited, and possibly reviewed, it logs premis data that can be viewed by specific users on the show page of a work.

Related Work

The related work associated with this ticket includes the ability to create metadata for a default work, review being possible. We would have some logic behind the scenes that accumulates all the necessary PREMIS data and ties it to a work and indexes it and exposes it on the show page.

Setup Triplestore adapter objects in OD2 to connect to the triplestore adapter interface and test.

Descriptive summary

Now that the triplestore is configured and working, an implementation will need to be set up using what the triplestore-adapter gem provides. There are a few objects to go over that are necessary for interfacing with the triplestore-adapter gem and OD2. This is as follows.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-bb09ca9f30a2b172310eccb148cc9305
This file is an object that allows for error reporting when it comes to a triplestore error. We can add any number of objects here which relate to a given error. In this example, we have a triplestore error and a uri error.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-3060a384590884beda894babeef0d38d
This object is a validator that ensures that a uri was provided in the form. This is to make sure that we can report both on the backend and frontend whether improper data is being entered and report that to the user. This object can implement the previous file by using that error class and handling the error properly.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-a844811c81255eafffe8ac2675fcf679
This next file is a large file which essentially overrides a lot of what simple_form is doing to create a specific type of input. SimpleForm is a gem that allows for the easy generation of forms in rails. It is what generates the HTML behind the scenes and builds out the form fields so you dont have to. We need a type of form field that isnt provided by SimpleForm so we have to override some of its internals to generate our own.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-4f7e4485def77b80f9ac52e01751c8a6
This next file is essentially an adherence to a pattern used quite a lot in hyrax. We have extracted out the TriplePoweredForm "behavior" which enables a form object to become "TriplePowered" meaning it can interface with the triplestore backend.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-0873f7ce9796373e62c89c5bd909211b
This is the file that actually uses the triplestore code to make the calls to store data into the backend.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-9210982b7fa445e3d7ec8ac5077f1aa4
This file is the same as the other file that adheres to the pattern used a lot in hyrax. We have extracted this code into a "behavior" which allows a work to know that it is triple powered. It knows that it has a specific field that should be expecting a uri. It knows how to grab uris from the backend, it knows how to translate a uri to a label and many other different things. This needs to be included on a work if that work has a controlled vocabulary field.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-77a5be6b83ee75a4553eed5e0f781748
This file is an indexer. Indexers know how to take the data and translate it into a format that can be indexed. Here it is looking at which field is controlled and indexing its labels and other data.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-e11bdaf9116be3911e9557b69e242370
We need to make sure to include the triplestore-adapter code in our app.

Expected behavior

The tests pass.

[1] Configure GenericWork to have a triple powered field.

Descriptive summary

Here, we need to make sure to include all the objects in the proper places around the app and actually test if labels are being fetched, indexed, and viewable from the show page.

https://github.com/osulp/Scholars-Archive/pull/564/files#diff-e11bdaf9116be3911e9557b69e242370
The objects that need files included can be found here and found by a simple ctrl-f look for include

Then after all the proper files have been included in the proper places, then you can ingest a work, input a uri such as http://id.loc.gov/authorities/subjects/sh85145447 in the form and it should display "water" as the label.

This will conclude the triplestore configuration and show that triple powered properties and the backend are all working properly.

Expected behavior

Generate a work with a uri in the proper field and it should display its label.

application version file

Descriptive summary

Including a version file for the application would assist in our deployment process, discussion/troubleshooting, and give us the ability to surface this information in a meaningful way to the end user.

Expected behavior

Include a VERSION file in the repository that is managed during milestone releases.

Expectations:

the file must be a single line of text
the version text must only include a-z,0-9, low dash (_), dash (-), and period (.)

Example:
MS1-0.10.1

Ordering of works within a collection, supporting structure of archival material

Descriptive summary

Per a discussion with Chris Petersen, that there is a need to be able to order works within a collection. There are some collections that are a list of letters that are in a chronological order. This has just been brought up and we havent nailed down the specifics. But this will be discussed more at a future date.

Do we need more roles than Managing, Depositing, and Approving?

Descriptive summary

This may need less work than previously expected. Roles exist by default in hyrax. These roles are Managing, Depositing, Approving. Managers have all the rights associated with an admin set. Depositing have access to be able to deposit into that admin set. Approving have the ability to review the works in a workflow within an admin set.

Do we need anymore roles? If so, where do we put these roles, what are their privileges? Do we need to identify them? This is more of a question

Once we answer these answers, the role generation could be already complete. After that, we would need someone to go in and manage the admin sets and set up the proper users who have access to these admin sets.

Date terms that adhere to the EDTF Format

Descriptive summary

There is a format for dates that is compliant with LOC and ISO 8601 called the extended date time format. This format helps format specific date formats, be easier to search for and keeps them consistent. This helps with dates such as circa 1991 or something along those lines. To read more about EDTF dates, read here https://www.loc.gov/standards/datetime/

We made SA EDTF compliant, in a large PR found here osulp/Scholars-Archive#523 Most of this work will get date fields EDTF compliant. One thing that needs to be decided is which dates out of all the different date types need to be edtf compliant. Do all of them? Some of them? Who knows.

Porting the work will be quite a process and @luisgreg99 Was the one who championed this.

Expected behavior

Dates that are set to follow the edtf format for dates save edit and show pages all show the dates in the proper format.

Related work

osulp/Scholars-Archive#523

Rights based restrictions

Descriptive summary

There are some works that should respect the copyrights of a work. For instance. If a work has copyrights that imply that a user should not have the full resolution image, then we shouldnt allow users to download the full resolution image. If there is a work and it is older than a specific day, then we should allow for folks to have access to all the information and full rez image due to it being in public domain.

EDIT: As noted below, there are some extra concepts that need to be looked at based on licensing even though they are public domain works. Or works that are shared with an institution that need to allow full rez downloads but are restricted via IP.

We should lay out all possible permutations we can think of, so that we dont implement this feature inappropriately. We we want to layout these permutations in a spreadsheet here is fine.

Labeled this as a question now as well, to further emphasize an not entirely fleshed out concept.

Expected behavior

When you visit a work, and its copyrights suggest folks shouldn't have the full resolution images, then it shouldn't provide a link to download that image. Instead it should provide a link to download the proper image based on the rights.

If a work is public domain or just became a public domain work, we should allow full unaltered access to that work.

Related work

Some related work may include metadata logic work surrounding mechanisms that check a works age and makes decisions based on that age.

Move local_env.yml to encrypted secrets

Descriptive summary

Application would benefit from using Rails 5.x encrypted secrets instead of local_env.yml functionality. Encrypted secrets should have rails environment as the top-level key for all related configurations (database credentials, urls for services, etc)

remove https://github.com/OregonDigital/OD2/blob/master/config/application.rb#L19-L22
remove local_env.example.yml
remove the local_env set in CCI
update CCI (online) to include the key for the credentials as an ENV variable for the containers to run in
Work with Ryan O. to get production/staging k8s service URLs into the encrypted secrets
Update all configurations in the application to use Rails encrypted secrets instead of ENV

Configure metadata based on worktypes

Descriptive summary

This work will be to configure the metadata for each worktype in the system. Each work type will have its own metadata which will be laid out im the MAP by the metadata group. >>>>>>>>>>>>>>> INSERT LINK TO MAP HERE >>>>>>>>>>>> After the metadata is laid out in the map, it will need to be translated over to each work type based on work done here. https://github.com/osulp/Scholars-Archive/tree/master/app/models/concerns/scholars_archive. Each model has *_metadata.rb where * is the work type name in the system. (I.E article_metadata default_metadata etc.) Each piece of metadata will have to be taken care, to make sure the controlled vocabulary fields are configured as controlled vocabulary metadata fields and ordered fields are configured as ordered fields with the proper predicates.

This work will have to be translated over to make sure that the forms all have the proper metadata as well as well as having the metadata in the proper order. Alpha sort the fields in the metadata files.

Here are a few examples of configured metadata and supporting configurations in the metadata file that are needed.

property :abstract, predicate: ::RDF::Vocab::DC.abstract do |index|
    index.as :stored_searchable
end

The property command comes from a supporting library already in hyrax. Followed is the name of the field to be configured. The next is the definition of the predicate which should come from the map. Next comes the description of how the field will be indexed in solr. The main configurations are :stored_searchable and :facetable. This will allow the metadata in the field to be searched and used as a facet.

Another potential configuration will be for linked data.

property :based_near, predicate: ::RDF::Vocab::DC.spatial, class_name: Hyrax::ControlledVocabularies::Location do |index|
    index.as :stored_searchable, :facetable
end

The only difference to note in this one is the defined class name. This class is a linked data class and will be discussed later. If research would like to be done now, check this file.
https://github.com/samvera/hyrax/blob/5a9d1be16ee1a9150646384471992b03aab527a5/lib/hyrax/controlled_vocabularies.rb

and

https://github.com/samvera/hyrax/blob/5a9d1be16ee1a9150646384471992b03aab527a5/lib/hyrax/controlled_vocabularies/location.rb

Keep in mind the bottom of the metadata file

accepts_nested_attributes_for :based_near, :allow_destroy => true, :reject_if => proc { |a| a[:id].blank? }

This configures the models to accept nested attributes for an object. Since there are extra fields associated with controlled vocabularies, this is what helps with that.

Lastly there is this configuration

property :nested_ordered_abstract, predicate: ::RDF::Vocab::BIBO.abstract, :class_name => NestedOrderedAbstract do |index|
    index.as :stored_searchable
end

This looks similar to the controlled vocabulary but is denoted as an ordered field. This will come into play later.

We may be able to skip over these configurations early on and configure them simply, until we focus more on metadata logic.

Expected behavior

This should configure the work types in the system to have the proper metadata fields in the system with the proper predicates.

Actual behavior

No change may actually be seen however, it can be tested by inspecting the objects in the console on creation.

Requirements/ToDo

create separate ticket for metadata fields for each work type
~~create ticket for Configure Ordered Metadata~~

Related work

#21

Consider mirroring authorities to facilitate typeahead

Descriptive summary

We ought to consider mirroring LC, Getty, and other authorities locally to facilitate typeahead and other functionality.

Broader and narrower terms / alternate titles and names

Descriptive summary

Whichever way is decided, we would need to think about caching extra information pulled from endpoints. These pieces of information that would get indexed could help with searching and discovery within OD. For example, we could index alternate titles of subjects, like scientific names of the mandarine orange (Citrus reticulata) so if someone searches for its scientific name, they would be able to find the works that have mandarine orange as its subject.

Indexing Broader and Narrower terms could be useful as well depending on how broad and narrow someone went. If someone wanted to search for a mandarine orange, but just searched for orange, or if someone wanted to find the play "Cats" they could search for Play, or Musical, and still find cats.

This is all about expanding the discoverability in OD by ten fold. If there are any other ideas that folks have, it could be put here as well.

Expected behavior

When alternate titles, scientific names, broader or narrower terms are searched for, they bring up the proper works in the search terms. These terms pulled from an endpoint, will be indexed into the proper solr fields and configured for being searched for.

Related work

Indexing set up, controlled vocabularies set up, end points being hit and pulling proper info, info being indexed. Once all this work is all done and being worked on, this can be done.

All Information Based on Derivative Generation Here

Descriptive summary

This ticket is a nexus for information about the derivative generation process. Fill out as descriptive of information as possible about the decisions made about how this will be working. It can be an epic ticket that we can breakdown in the future.

Expected behavior

Actual behavior

Steps to reproduce the behavior

Do this
Then do this...

Related work

Link to related tickets or prior related work here.

Error handling for oEmbed viewers

Descriptive summary

If a work has an oEmbed URL, and the viewer fails to load on the show page, that should be recorded and logged for troubleshooting. Possible reasons are that the source site is down, permissions changed on the media, or it was removed.

Expected behavior

Admin Dashboard shows all oEmbed errors, sorted by most recent, and what those errors were.
Provide a way to mark errors as resolved.
Send email to depositor of work with oEmbed URL notifying about error.

Related work

#75
#76

Configure the catalog controller for searching, faceting, and other base config

Descriptive summary

This ticket expressed the need of configuration of the catalog controller. This is a large request as there are many configurations that need to be set along with quite a bit of testing to make sure these configurations are set properly. A lot of configuration is already expressed here, and can be translated over based on metadata needs expressed in the MAP. >>>>>>>>>>>>> LINK TO MAP HERE >>>>>>>>>>>>>

Facet Field Configuration:

Facets have to be configured from the catalog controller. https://github.com/osulp/Scholars-Archive/blob/master/app/controllers/catalog_controller.rb#L72 This means translating the MAP information over into the catalog controller based on what is faceted or not. Some of the fields may be faceted, but are also ordered, or controlled and more work may need to be done with those. That information will be expressed in another ticket however and for starters, getting the basic metadata fields that need to be faceted set up first.

    config.add_facet_field solr_name('contributor_committeemember', :facetable), limit: 5, label: 'Committee Member'

This configuration takes the name of a field and the facetable symbol, a limit to how many values show up on the initial view of the facet, and the label to be displayed on the facet tab on the search page.

Index Field Configuration(Search result metadata displayed per search result):

The Index Fields are the fields that appear in the search result list for each work. https://github.com/osulp/Scholars-Archive/blob/master/app/controllers/catalog_controller.rb#L122
For instance, title, creator, subject, may be pieces of metadata that we need to show up per item in the search results. This information should be expressed in the map and will need to be configured here.

config.add_index_field solr_name("title", :stored_searchable), label: "Title", itemprop: 'name', if: false

This configuration takes the field name, and stored searchable as the symbol. The label of the search field, the itemprop, and sometimes a helper method. The helper method is used to process a certain chain of methods to change or render specific fields depending on the results.

Show field Configuration

The show page or the single item page will need to be configured here https://github.com/osulp/Scholars-Archive/blob/master/app/controllers/catalog_controller.rb#L150
This configures the show page to display the proper information within the system. There may be some extra customization that we need to do to show proper information per work type, but initially this is a good place to start to get the right data showing up on the show page.

config.add_show_field solr_name("publisher", :stored_searchable), label: "Publisher"

This configuration takes the field name and the stored searchable symbol and a label.

This configuration is the same every time and replace the label and solr name with the proper label and field name.

Search Fields

The search field configuration is done in two parts. The first part is the "all fields" search which is a simple search in the search bar. The main spot to pay attention to is here: https://github.com/osulp/Scholars-Archive/blob/master/app/controllers/catalog_controller.rb#L200 This is a list of the fields that will be searched when someone enters a search in the search bar. Each field that is required for searching will have to be input here.

Second, there is https://github.com/osulp/Scholars-Archive/blob/master/app/controllers/catalog_controller.rb#L244-L251 this configuration. This allows the field to actually be searched if it is a faceted search. The facet may show up if it has been configured as a facet, but the system wont know how to search for that specific field unless it is also configured as a search field here.

Expected behavior

The show page, searching, facets, search result metadata all should appear correctly throughout the system

Related work

#27

Combined Facets

Descriptive summary

This is another doozy of a ticket. There is a need in the system to collapse some pieces of metadata into an "umbrella facet" An umbrella facet would be a facet that contains many different pieces of metadata and combines it into one. For instance, Lyricist would be contained under the Creator facet. We would have to devise some way that the system knows how to aggregate a list of solr fields into a single search result to display the proper values associated with all the different facet terms under a single umbrella term.

This also begs the question of disambiguation. We will have to pay close attention to multiple results found, when to combine them under one term or whether they are two separate terms. Several results with the same value could be returned from different facet searches. Are they the same term? Different terms? We have no way of disambiguating them so do we keep them separate? Careful attention would be needed in this part of development.

We will have to decide which piece of metadata is the proper umbrella facet and which other facets go under that one. This may be described in the MAP or somewhere else, but that info should be linked here at some point. Should we be able to configure them from a UI?

Expected behavior

When a user looks at the facet for creator or any other facets that are aggregates of many facets, they should be able to see all the information from the many different facets associated with it.

Audio/Video Enhancement for Universal Viewer

Descriptive summary

Currently, audio and video files arent set up to run through universal viewer. We would need to do some work on learning more about universal viewer to run the audio and video files through that. There has also been some talks of work being done in hyrax to render different viewers depending on what the format of the file is. This would be a smart mechanism that would make a decision about what to render based on the extension of the file it receives.

If we want to use UV, we will have to do some work, but by the time we get here, audio and video might be working by default. We will have to track this and make a decision once we get here.

Expected behavior

Audio and Video works on the show page of a work with an audio or video file.

Related work

Audio and video configuration or different viewer based on the file associated with the work.

Come up with scripts for JP2 derivative generation

Descriptive summary

When we have test assets, we're going to want to see them working pretty quickly. This means having the necessary derivatives. I know how to handle image derivatives, so that's what I'll tackle here.

Expected behavior

Running a script against a static image should result in a JP2 file
Running a script against a PDF should result in a JP2 per page
The JP2s are pan-and-zoom-friendly: tiled (1024x1024), and the "right" number of resolution levels are created (this can depend on image dimensions, so we need a semi-smart script)

Related work

issue #73 (closed) kicked off this ticket
This is sort of a child of issue #30

Configurable Facets

Descriptive summary

We need to have a lot of work done around Configurable Facets. This is a multi-faceted (see what I did there?) bit of work that spans across many different pieces. We need to be able to configure facets per collection. Each collection will have different metadata that is important to that collection. We need to not only configure the facets per collection, but order them as well. Since different collections will highlight different pieces of metadata, we need to be able to push the most important metadata to the top. We need to be able to turn on and off, these facets per collection in a UI of some sort and that leads to the second point.

We need to have some sort of way to track whether or not to render a specific facet depending on what is being viewed. Therefore, we need a way to toggle facets on and off, or assign it to specific collections or both. This could be a drop down or check box either in the collections pages somewhere, or its own UI element. A admin user, need to be able to go in and add or remove facets per collection at any time.

There will be a lot of different pieces in the code that surround this. Maybe we need more database driven configuration, maybe we can use flip flop. There will have to be a lot of discussion around this ticket, but the basics should be lain out here.

Expected behavior

A user can go to a collection and see a specific set of configured facets, in a specific order, to further enhance the discoverability within that collection.

An administrative user should be able to go in and turn on and off and reorder facet fields based on a collection or within the system as a whole.

Related work

Collections work will need to be extended and there will be a lot of work needed behind the scenes to make facets a much more useable piece of the system.

Analytics

Descriptive summary

Analytics is a big topic of discussion. Hyrax has some analytics and we will need to set up a google account and configure it in the system. Also, we may need to talk about porting over any analytics from the old system to the new system.

Furthermore, we will need to work on enhancing the analytics. This ticket is for discussion about the analytics. Are we going to work on analytics? Is someone else? What are the requirements?

PDF Viewer

Descriptive summary

We haven't seen whether or not UV completely fulfills the requirements of functionality of a PDF viewer. In OD, we have in text search dependent on OCR provided. This allows for a user to search for terms in the document. It also needs to provide the ability to zoom in on the page, flip between pages, highlighting in the text, etc.

In OD, OpenSeaDragon was used which is a library is included within UV, so it may already be taken care of.

Expected behavior

Read through a PDF document in the proper order, search functionality within the PDF, page through, table of contents, metadata.

Model the work migration process

Descriptive summary

Establish a model of the processing steps for migrating a work from OD to OD2
Should this be a separate Ruby gem, something that can be included to OD2 only while the migration is occurring.. and this gives the gem the ability to use models and hyrax functionality directly

Metadata Validations

Descriptive summary

This may not actually need an epic ticket, but this ticket describes the need to validate all metadata. We need to make sure that if we are expecting a string, that the form only accepts strings. If it is a controlled vocabulary field, that it accepts uris from specific endpoints. If we are expecting dates in a specific format, that we are getting those dates in those formats.

We need to go through and make sure every piece of metadata is validated

Expected behavior

The front end rejects a value if it isnt correct. The backend rejects a value if it isnt correct.

Generate seed data for OD2

Descriptive summary

We need to generate a seed dataset for OD2. This will allow us to better QA UI changes and allow for building catalog controller etc.

@jsimic @petersec @wickr can you define a seed dataset for us to start with?

URIs show up next to labels

Descriptive summary

After we have the triplestore and all supporting libraries, we should be able to input a uri in the form field of a triple powered property, and have it go to that uri, pull down the labels, and cache the label and uri both in the triplestore as well as index it in solr. when looking at the form during the editing of a work, you should be able to see the label next to the uri. In the show page, maybe we can link out to the uri as well as supply the label for searching in hyrax.

Expected behavior

A user who is ingesting a work that has triple powered fields, can input a uri and have it cache the label and uri. When viewing this on the show page, you should be able to see the label and possibly link out to the uri. When editing that work, you should be able to see the uri next to the label, with the uri only being editable.

Related work

This work has already been done in Scholars Archive, and will most likely be based on the "Related URI" Field in SA. This already provides the functionality of accepting a uri and a label and displaying it to the user. We would just have to hit the URI and grab the label and cache it which should already work based on the setting up of the triplestore and making active triples work in OD.

Configuration of work types in the application

Descriptive summary

There are going to be very many work types that will be defined over the next several weeks (September 21st - November 14th). These work types will become objects in the application that users will pick from to create their works within Oregon Digital 2. These work types are defined here >>>>>>> INSERT LINK TO MAP HERE . We need to generate these work types in the application using a rake task provided by hyrax. This rake task can be found here https://github.com/samvera/hyrax#generate-a-work-type.

You can run rails generate hyrax:work work_type_name_found_in_map which will generate all the files needed for the work type generated to function properly in the system. Some of the files mentioned are as such.

      create  app/actors/hyrax/actors/work_actor.rb
      create  app/controllers/hyrax/works_controller.rb
      create  app/indexers/work_indexer.rb
      create  app/forms/hyrax/work_form.rb
      create  app/presenters/hyrax/work_presenter.rb
      create  app/models/work.rb
      create  app/views/hyrax/works/_work.html.erb
      insert  config/initializers/hyrax.rb
      create  config/locales/work.en.yml
      create  config/locales/work.es.yml
      create  config/locales/work.zh.yml
      create  config/locales/work.de.yml
      create  config/locales/work.fr.yml
      create  config/locales/work.it.yml
      create  config/locales/work.pt-BR.yml
      create  spec/actors/hyrax/actors/work_actor_spec.rb
      create  spec/controllers/hyrax/works_controller_spec.rb
      create  spec/features/create_work_spec.rb
      create  spec/forms/hyrax/work_form_spec.rb
      create  spec/presenters/hyrax/work_presenter_spec.rb
      create  spec/models/work_spec.rb

The only file that we wont need, unless heavy customizations are involved are the app/views/hyrax/works/_work.html.erb

This file should be removed to make sure that the application doesnt have too many extra files.

There could potentially be heavy alterations of some files such as the presenters, models, and eventually, some of the indexers. Keep these in mind for future work.

As changes are made to these files, please make sure to update their specs as well.

The config/local files are used for language translation and it might be worth it to check in with these files toward the end to make sure they are sufficient for accessibility purposes.

Expected behavior

The expected behavior will be quite simple. You plug in the rake task in the command line and it pops out the necessary files needed to generate a work type.

Related work

The related work associated with this ticket will be the MAP. The MAP will need to be completed in order to generate all the necessary work types needed by the application. If it is only partially completed

Related tickets

--------------------List related tickets here-------------------------

Steps

Generate MAP
Link MAP here
create a ticket for each work type
create ticket to configure metadata fields
Complete generation of each work type
configure specs for metadata fields
Verify they are configured to be generated in the application and that metadata looks and behaves
QA
Merged

Start processing original files to JP2

Descriptive summary

@jechols suggests that we begin a process that will transcode original files (at least TIFFs) to JP2

Expected behavior

Setup AWS S3 storage
Generate a catalog of the original OD location, transcode_status, and the final S3 location of each file
Write a script to process and log each TIFF?
As a TIFF is transcoded, record in the catalog that it had been completed and where it was stored

Metadata Viewing

Descriptive summary

This is a large ticket that encompasses many different pieces of functionality. As we are working on creating the logic behind the scenes that manages and formats the metadata, we will have to be conscious about how it is displayed to the users. There are a lot of different types of metadata views that we will have to be conscious of.

Show Page: The show page is a where a majority of the metadata is displayed. There are many different types of metadata
- Metadata Searchable Via Facets/Quick Link Searches
- Basic non linked metadata
- Metadata with supporting URIs
- Metadata that is a URI and label
- Text Fields
- Date Fields
- Ordered Fields
- More

Each one of these will be displayed differently on the show page and we need to make sure that all of them work properly. Searchable, external links link out properly, popups look right, labels for the fields, Etc.

We need to also take care of what is displayed on the search results. What pieces of metadata do we want there? How big do we want the search results to be? Images. We need to make sure this all looks right.

There are also featured works that need to be formatted properly.

This is a ticket that outlines the need to break down all the places where the metadata is displayed and make sure it is all displayed properly.

IP Based Restrictions

Descriptive summary

This work includes the possible whitelisting of specific IP addresses for specific works and collections. Some collections are only accessible from the OSU or UO campuses. We would need some way of looking at a users IP address and checking to see whether they were within the proper IP range to look at specific works and collections. This has been implemented in OD but may need to be looked at again for new or alternative ways of accomplishing this.

There are several different ways we can restrict IPs depending on how much work/engineering we want or feel is necessary. This feature is in Oregon Digital and can be found here:

OregonDigital/oregondigital@cca646d

This expresses a more engineered version of doing IP addresses and should at least match the needs of the IP based restrictions. This may, however, be overkill, or slightly different depending on how much hyrax already supports and the changes to roles and users. If further discussion about this method is needed, then we can log that discussion in this ticket.

Otherwise, if we simply need to reject users from specific routes, there is work that you can do in the routes based on this stackoverflow page.

https://stackoverflow.com/questions/5553874/rails-3-whitelisting-list-of-ips-via-routes

We need to talk about requirements of IP restrictions.

Expected behavior

When there is a work or collection that has been restricted to "UO Only" or "OSU only" And you are on campus, you should be able to view that work. Otherwise that work should not be able to be looked at.

Requirements

Admin Dashboard area to create/edit/update/delete groups of ranges for IP Restriction (UO Only, OSU Only), restricted to Admins
Work show page should have very clear indication of IP Restriction group, such as banner or badge
More than 1 IP Restriction group should be able to be applied to a work (both OSU and UO)
Restricted works are not viewable in search results for those who couldn't see the work
Can bulk assign works an IP Restriction

Related work

Research may need to be done on technologies or gems that exist or work done in hyrax that allows for the easy whitelisting (or black listing) of IP addresses.

install triplestore

Descriptive summary

We have chosen blazegraph

How To Install Blazegraph and triplestore-adapter

This PR in scholars archive configures blazegraph and uses the triplestore-adapter, which allows the ability to access triplestores like blazegraph. A bit of work will have to be done early on the get this functioning.

https://github.com/osulp/Scholars-Archive/pull/564/files

This will get OD most of the way there, with a little wiggling of files into place to get it all flowing naturally. A good way to test this is enable a field to be controlled and add it to the supporting files for the triplestore. Then use a uri from id.loc.gov and put that into the form. If the form accepts it and displays a label, it is working properly. Otherwise exceptions will be raised and more work will have to be done on this.

Expected behavior

Install blazegraph and copy over configuration files for blazegraph
* We know this is working, because you should be able to run the triplestore adapters rake task
and it works.
Setup Triplestore adapter objects in OD2 to connect to the triplestore adapter interface and test.
* We know this is working because the tests pass
Configure GenericWork to have a triple powered field.
* You can input a URI and it can grab the label and index it, displays the label on the show page.