sul-dlss / vt-arclight Goto Github PK

An Arclight-based discovery application for materials from the Virtual Tribunals project

Ruby 64.04% JavaScript 1.95% HTML 12.81% SCSS 3.81% XSLT 11.63% Shell 0.41% Dockerfile 0.30% Python 5.05%

vt-arclight's Introduction

Virtual Tribunals

An Arclight-based discovery application for materials from the Virtual Tribunals project

Install

bundle
yarn

Start solr

First start solr.

bundle exec solr_wrapper

Index seed data

You can seed the index with rake vt:seed. This loads data from our spec/fixtures directory. It is a vastly reduced (200K vs 1K lines of XML) version of the collection EAD file, which should be representative of different media types, series, subseries, date formats, etc. The fulltext transcript files associated with the items in seed.xml are also stored in our fixtures; these files will be indexed for fulltext search.

We also added a video.xml file in fixtures that only contains the records/druids for the 37 items with video. This was useful for example in testing whether transcript harvesting worked on the videos, rather than harvesting from the entire collection.

You can always delete the current index with rake arclight:destroy_index_docs.

Data from ArchivesSpace

We store EAD XML generated from ArchivesSpace in public/data/mt839rq8746.xml. mt839rq8746 is the druid associated with the Nuremberg collection, and we use it as a permanent identifier in ArchivesSpace. mt839rq8746.xml contains all the records in the Nuremberg Trial collection, around 9,000 records. We pull the file from SUL's production instance of ArchivesSpace (http://spec-as-prod.stanford.edu:8080/). A staging instance (http://spec-as-stage.stanford.edu:8080/) also exists; you can use this to experiment, but the files we commit to this repository should be downloaded from production.

How to download mt839rq8746.xml

Making requests to the ArchivesSpace endpoints via rake task requires certain environment variables be set. Locally you can pass them on the command line or set them up another way. On our vt-stage and vt-prod servers running this application, these env vars are stored and accessible. Both vt-stage and vt-prod are set in Vault to point to http://spec-as-prod.stanford.edu (production ArchivesSpace) as the source for their EAD. The following variables are needed to perform the download:

ASPACE_URL
ASPACE_USER
ASPACE_PASSWORD

You can get these values from Vault by running the following (stage example):

vault kv get puppet/application/vt/<stage or prod>/aspace_url
vault kv get puppet/application/vt/<stage or prod>/aspace_user
vault kv get puppet/application/vt/<stage or prod>/aspace_password

If you want to download the latest data and overwrite the file in public/data follow these steps:

Find out the ID of the Resource and its Resository that you want in ArchivesSpace. Repository refers to internal SUL organization. On the production ArchivesSpace server, the Repository ID is 18, for Virtual Tribunals. "Resource" is the name for top level containers in ArchivesSpace. The Resource ID is the permanent identifier we use for the collection. It's the same as the druid and won't change: mt839rq8746
Run the download task -- it takes resource and repository as arguments. When trying to pass arguments to a rake task in the form of [arg1,arg2], it seems my zsh shell requires escaping the brackets:
```
rake vt:download_resource\[18,mt839rq8746\]           
```
Locally with passing env variables, the command should look like this:
```
 ASPACE_URL=http://spec-as-prod.stanford.edu:8089 ASPACE_USER=<xxx> ASPACE_PASSWORD=<xxx> rake vt:download_resource\[18,mt839rq8746\]  
```

How to index mt839rq8746.xml

Now that the new copy of mt839rq8746 is downloaded, we can index it.

Index the file.
```
 rake vt:index 
```

If indexing on a remote server, we need to clear the caches:

 cap prod remote_execute["cd vt/current; RAILS_ENV=production bin/rails r 'Rails.cache.clear'"]

Here is an example of indexing new data onto a remote server. Make sure the SOLR_URL in the last step actually matches your index.

cap stage deploy # put latest EAD file onto the server
cap stage ssh
SOLR_URL=http://sul-solr.stanford.edu/solr/nta-arclight-stage/ RAILS_ENV=production bin/rails arclight:destroy_index_docs vt:index
RAILS_ENV=production bin/rails r 'Rails.cache.clear'

Most likely you will be reindexing the EAD XML, and not the full text files, as those are fairly static. You can skip the slow processing involved with re-indexing fulltext by commenting out the to_field 'full_text_tesimv' block in lib/traject/vt_component_config.rb.

Note on the data in ArchivesSpace

The data we upload to ArchivesSpace is generated from a custom pipeline. See /source_data/README.md. Edits can be made to individual records manually, or on a larger scale by rerunning the steps in our data pipeline, and reuploading files to ArchivesSpace. When chanages are made to the collection in production ArchiveSpace, you should download the new file as described aboce, and save it in public/data, overwriting the existing file. Commit this new file and submit a PR. Once merged and deployed, you can reindex on vt-stage and vt-prod, as described above.

Start the app

Locally

Then in another terminal, start the app:

bin/dev

A server will start with the application on port 3000.

OR with Docker

You can start the application by running:

docker compose up

Then point your browser at http://localhost:3000/

vt-arclight's People

Contributors

Stargazers

Watchers

Forkers

marlo-longley

vt-arclight's Issues

Landing page and URL question

Earlier this week, Hannah messaged me that "nta.stanford.edu" won't work if we want to add collections later on down the line to Arclight. As a result, we had a conversation in our demo/retro (the part with stakeholders there) where we suggested the following:

Use virtualtribunals.stanford.edu as the URL
Have that URL go to a landing page which in some manner points to Spotlight collections and Arclight collection (perhaps with other contextual information about the whole VT project).
virtualtribunals.stanford.edu/nuremberg would be the URL for NTA

Penelope (runs CHRIJ) and Regina (SUL bibliographer) were good with this proposal, but I told them we would need to check with @ggeisler once he's back from vacation to see if it's possible within the scope of time we have.

Hannah suggested that I put together a formal proposal after @ggeisler takes a look and we get the ok to move forward from dev team. The proposal should go to Hannah, Tom, Penelope, David. I wonder though if this is needed since we got Penelope's OK. I will find out if it seems like something we should move forward with.

Create rake tasks that get and process EAD via the ASpace API

The idea behind this ticket is proof of concept for a data pipeline proposed by @corylown for our application.
Since our data will change infrequently, demanding it manually in a task, rather than some kind of regular/dynamic updating, is acceptable. Also, because this application is showcasing a single collection, it could make sense to store the data in the same repository.

This approach could consist of 2 rake tasks:

Task 1:

Connect to ASpace to grab EAD
Save the EAD into the codebase (to be committed to the Github repository)

Task 2:

Run traject to index the EAD into solr

The EAD format is NOT finalized yet. But we can still start developing this. Here is how to connect to the staging ASpace
(ask Marlo for credentials to plug in here):

Authenticate/login to get a session token. The JSON response will have a "session" key you can copy.
curl -s -F password="<pass>" "http://spec-as-stage.stanford.edu:8089/users/<username>/login"
Request specific EAD Resource. Paste in the session token you got above to the curl header. 10208 is current NTA data but this ID will change as we iterate.

curl -H "X-ArchivesSpace-Session: xxxxxxxxx7957dcfd333b99e55cf0" \
"http://spec-as-stage.stanford.edu:8089/repositories/2/resource_descriptions/10208.xml"

You should get an XML document returned that you can work with experimentally.

Ingest NTA EAD generated from ASpace into Arclight

This can be draft/sketch EAD, but we should test ingesting with the outcome of #27

Blocked by #27

Implement devise-guests and a cleanup method

We want to install this gem and also have a strategy for cleaning up temp users from the DB
This will enable us to build the bookmarks interface

Decide on parent container naming and grouping strategy

Related to #3 but I think it would be helpful to have a ticket that explicitly requires a decision to be made about our content inventory strategy. Specifically, we need to decide:

Will we group all of the boxes and all of the electrical transcription content into two distinct parent containers?
If not, will we use another parent container grouping strategy, or go with a completely flat organization (i.e., a single list of 28 boxes followed by N number of days of electrical transcription content)?
If so, what do we want to name the two parent containers? As shown below my suggestion is to use "Series 1: Paper material" (though we can try to come up with a better label than "Paper material") and "Series 2: Electronic media".
If we use "Series" for these parent container labels, is it okay that we're using this archival term in this way? And can we generate minimal metadata necessary to support it (perhaps just a brief description to say it contains the 28 boxes, or the electrical transcriptions organized by day)?

Example of how the content inventory using this suggestion would look:

A secondary question is the exact format of the display labels for the child components. I the examples above, I used "Box X:" plus the range of item numbers in that box, which will be more informative for users than simply "Box X". But if that is problematic for some reason we could simply use the Box number and the date like so (ignore the colon after the box labels in this example):

Decide if/how we will display repository information

Currently we are test cataloging under the SPECCOLL repository in ASpace.
Obviously they don't hold the NTA collection. Can we create a new repository for NTA? We should ask Michael or someone who has that authority.

If not, we may have to write code that edits the repository data in the EAD once it's returned from the API.

Implications for #28

Decide how we want to handle the ead_ssi field

either:

use ead_ssi even though we don't have ead and we would need to make up a value
create our own field key such as collection_identifier_ssi and patch Arclight to use our new key and override default behavior

pros/cons about simpler vs confusing

dockerize nta-arclight

BL docker-compose

BL rake task for server

Decide on application/site title

In my initial mockups I used "Nuremberg Trial Archives" as the site title, but that was just a quick placeholder (the visual design and layout of the masthead are still TBD so those aspects won't necessarily look like they do in the example below):

What do we want the actual title to be?

Below is a version with what might be the more formal title of the project. Is this what we want to use in the application? Or something else?

Add deployment setup with capistrano

Decide on our About page strategy

A basic question that has implications for development is: do we want the NTA site to have one or more About-type pages, or will it be sufficient to just have a link that points to information that otherwise would be part of one or more about pages?

Because Arclight doesn't include about pages, if we want the NTA site to have one or more of them it will require additional development work. It might not be super complicated, but is definitely additional work. The potential benefit of that additional work, from an end-user perspective, is that any information we want to provide about how NTA was funded, details about future project plans, or how to contact appropriate people is more immediately available (the user doesn't have to leave the site to view it). Something like this (either as a single about page or spread across several -- though several about pages might be a bit more development work than a single one, because of the need for the sidebar, etc.):

Alternatively, we could save the additional development work (at least for the first workcycle) by not offering any about pages, and rely on some static text on the homepage and, optionally, a link in the main menu that points to an external page with more project info (a LibGuide in the future, as some of us discussed, or to a page like https://exhibits.stanford.edu/virtual-tribunals/about/about-the-project in the near-term). So something like this link that points to an external page:

If we want to go with the external link approach, we need to decide where that link points to.

Also, depending on how we want the homepage of the site to look, we could supplement the external main menu link with additional external links by including some static text on the homepage (if, for example, the links indicated here pointed to different external pages with project-related content):

Investigate how to relate in ASpace video transcripts to main druid

There will eventually be 3-4 transcripts accessioned that will be related to each of the 37 video "main" druids. Not sure how this relationship will be expressed in EAD. Investigate if DACS has guidance or if there's any info in the EAD2002 schema.

Add SUL and SU footers

I think we use these fairly consistently in our public-facing apps, with the exception of the SUL footer link colors. I could look into this more, but for now I think the Exhibits implementation of the footers is a fine model to use:

Get EAD for entire collection tree out of ASpace API

Based on the API documentation I'm able to get the single resource XML using an API call such as:

curl -H "X-ArchivesSpace-Session: xxxxxxxxx7957dcfd333b99e55cf0" \
"http://spec-as-stage.stanford.edu:8089/repositories/2/resource_descriptions/10206.xml"

Resource 10206 is the top level of the collection and contains children.

But requesting 10206 via API as above does not return any children in the tree. The documentation is hard to read through but we need to find the right API call / options to return the entire tree in one document. This is the returned XML from the above call:

<?xml version="1.0" encoding="utf-8"?>
<ead audience="internal" xmlns="urn:isbn:1-931666-22-9" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:isbn:1-931666-22-9 http://www.loc.gov/ead/ead.xsd">
  <eadheader countryencoding="iso3166-1" dateencoding="iso8601" langencoding="iso639-2b" repositoryencoding="iso15511">
    <eadid>mt839rq8746</eadid>
    <filedesc>
      <titlestmt>
        <titleproper>
          Guide to the Taube Archive of the International Military Tribunal (IMT) at Nuremberg (1945-1946)
          <num>mt839rq8746</num>
        </titleproper>
      </titlestmt>
      <publicationstmt>
        <publisher>Department of Special Collections and University Archives</publisher>
        <address>
          <addressline>Green Library</addressline>
          <addressline>557 Escondido Mall</addressline>
          <addressline>Stanford 94305-6064</addressline>
          <addressline>[email protected]</addressline>
          <addressline>
            URL:
            <extptr xlink:href="http://library.stanford.edu/spc" xlink:show="new" xlink:title="http://library.stanford.edu/spc" xlink:type="simple" />
          </addressline>
        </address>
      </publicationstmt>
    </filedesc>
    <profiledesc>
      <creation>
        This finding aid was produced using ArchivesSpace on
        <date>2022-10-14 14:53:24 -0700</date>
        .
      </creation>
      <langusage>English</langusage>
      <descrules>Describing Archives: A Content Standard</descrules>
    </profiledesc>
  </eadheader>
  <archdesc level="collection">
    <did>
      <langmaterial>
        <language langcode="eng">English</language>
      </langmaterial>
      <repository>
        <corpname>Department of Special Collections and University Archives</corpname>
      </repository>
      <unittitle>Taube Archive of the International Military Tribunal (IMT) at Nuremberg (1945-1946)</unittitle>
      <unitid>mt839rq8746</unitid>
      <physdesc altrender="whole">
        <extent altrender="materialtype spaceoccupied">46 item(s)</extent>
      </physdesc>
      <unitdate calendar="gregorian" era="ce" normal="1945/1946" type="inclusive">1945-1946</unitdate>
    </did>
    <controlaccess>
      <subject source="lcsh">Crimes against humanity</subject>
      <subject source="lcsh">International criminal courts</subject>
      <subject source="lcsh">Trials (Crimes against humanity)</subject>
      <geogname source="lcsh">Zeppelinfeld (Nuremberg, Germany)</geogname>
      <subject source="lcsh">Criminal procedure (International law)</subject>
      <subject source="lcsh">Nuremberg War Crime Trials, Nuremberg, Germany, 1946-1949</subject>
    </controlaccess>
    <dsc />
  </archdesc>
</ead>

Related to #28

Confirm <dao> EAD structure for digital objects from ASpace

A lot of Arclight UI for "online content" depends on detecting the dao XML element in EAD (Digital Archival Object) -- see here.
We need to test linking a digital object to our collection items in ASpace, and see if produces the EAD we expect.

Investigate assumptions about metadata that underly default box and item display

Support five facet fields

We might adjust the facet field labels but tentatively these are the fields we'd like to display as facets:

where the fields reference the following columns in the metadata spreadsheet:

Date range = dc:date (multi-valued)
Language = dc:language (multi-valued)
Media format = edm:type
Document type = dc:type
Document format = dc:format

Note that the edm:type values in the current spreadsheet need to be cleaned up before we can use them:

At least a few records have the value 3D, which doesn't seem correct
All values are currently in uppercase; we'll want to display them with init caps
See #10 for more about this one. I think @laurensorensen might be looking into this.

Upgrade to bootstrap 5

create VMs for stage, prod (sprint 0)

I think dev and prod should be sufficient, but this could use analysis or discussion.
We don't yet know how we will be deploying the app/product

Determine rails features that won't be used and shouldn't be generated

Set up CI

Remove/hide the search results type options

Because NTA only has one collection, we don't need to display the "Grouped by collection" option for viewing search results. And because the other option ("All results") will then be the only other option, we don't need to display it, either. So we want to hide from the user interface this "All results | Grouped by collection" button group entirely:

Ideally this results in the navigation elements sliding down to be inline with the other search result controls:

As with many of the NTA customizations, we want to do this in a way that doesn't preclude us from bringing back the "All results | Grouped by collection" button group in the future, if and when more collections are added to this application.

Remove/hide the "collections" search option in the search navbar

With only one collection, it's unnecessary (and potentially confusing) to offer the user an option to scope their search by collection, so we should remove/hide collection search elements from the search navbar:

After hiding this, center the remaining search elements in the navbar:

Create arclight-based rails application

LoadError: cannot load such file -- capistrano/sitemap_generator

 cap stage ssh
(Backtrace restricted to imported tasks)
cap aborted!
LoadError: cannot load such file -- capistrano/sitemap_generator
/Users/jcoyne85/workspace/sul-dlss/nta-arclight/Capfile:35:in `<top (required)>'
(See full trace by running task with --trace)

Investigate the data implications for only having 1 collection in NTA

Create a custom home/site index page

This is likely one of the biggest NTA-specific customizations we need to make to core ArcLight. I don't have all of the specific content details ready yet (I'll need to work with @laurensorensen and possibly others to finalize the content) but I think the technical work can be done now, and we can update the content relatively easily later.

Currently I believe core ArcLight routes the application #index page to the Repositories list page. We don't want this to happen for the NTA site, because with only one collection there's no need for users to navigate the repository> collection hierarchy -- we want to enable users that arrive at the site to immediately start working with the NTA collection:

Implications:

The NTA home/index page above would be the application #index page in the sense of it being the page the main menu "Home" link would resolve to, and the page the URL we use (e.g. virtualtribunals.stanford.edu/nuremberg) to advertise the site resolves to.
This NTA home/index page should be a new page that isn't part of core ArcLight; we want to override the site index/repositories page with a new custom page (conceptually; not suggesting how this should be done technically). (Or, it replaces/overrides the blank index page I think ArcLight #index previously resolved to?)
Ideally this new page uses the search results page layout; it would include the facet sidebar and a main content area, as shown in the mockup. Not sure how much that complicates things, and I suppose if it is really troublesome we can reevaluate the home page design, but this would be the ideal user experience for now, when the site only has one collection.
For now, the main content area can contain just a placeholder paragraph of text (see below). I can update that content with static text/images later in the workcycle.
However this work is technically done, ideally it is done in a way that doesn't preclude us from relatively easily shifting back to using the repositories list page as the #index page in the future (e.g., if and when one or more new collections are added and they belong to different repositories).

Placeholder text to copy and paste to main content area

Placeholder text. The Nuremberg Trial Archives is.... Lorem ipsum dolor sit amet tempor cras sapien pharetra sagittis do. Id fusce nibh praesent laoreet sodales sagittis neque duis convallis ornare justo platea. Pretium adipiscing senectus nisi eget feugiat netus pharetra massa nibh elit lobortis ac. Nibh pulvinar odio tincidunt eget nullam mi ullamcorper porttitor turpis eleifend sodales facilisi pharetra suspendisse. Imperdiet platea laoreet lacus dictum leo feugiat hac lacinia ultrices feugiat.

Update layout and styling to match SUL theme

The visual design goal for the NTA site is to follow the general SUL application look and feel. Below are the most fundamental tasks I can think of to update the basic Blacklight/ArcLight layout and styling to reflect a SUL-branded layout and styling.

In general, I'd recommend using Exhibits as a model, although for the topbar and footer, most public-facing SUL applications should be close to what we want for NTA.

A: #66
B: Customize the site header/masthead: Detailed ticket TBD. This might be the most customized element and I need to think about how to make it as visually interesting as possible. For now, using #f2f1eb for the background color is probably sufficient.
C: Update content and component styling: Detailed ticket TBD to recommend details for customizing the typography and colors to match SUL styles. Some of the details (link colors, facet element colors, font-sizing) vary among our public-facing apps, but I'd suggest that Exhibits might be the most appropriate model for these in NTA.
D: #67

Get app credentials for ASpace staging server

Ask Michael Olsen

Currently we are using Lauren's creds and should have some for the app that we can use in #39 and similar situations

Decide on asset pipeline strategy (does this have implications for generating the base app?)

Change title to Taube Archive of the International Military Tribunal (IMT) at Nuremberg, 1945-46

@laurensorensen Can you confirm or clarify what the official collection title is? When working on my mockups I assumed:

Project name: Taube Archive of the International Military Tribunal (IMT) at Nuremberg (1945-1946)
Collection name: Inventory of the International Military Tribunal Archives, Nuremberg, as transferred to International Court of Justice, The Hague

That was based on the purl record showing the title as "Inventory of the International Military Tribunal Archives, Nuremberg, as transferred to International Court of Justice, The Hague"

But in the current version of the app on -stage, while I see the site title matches the project name, as expected ("A" in my screenshot below), the collection name is "Taube Archive of the International Military Tribunal (IMT) at Nuremberg, 1945-46" ("B" in the screenshot). This is similar but not identical to the project name (no parens around the years).

So I'm concerned about where we're getting the collection name in the app and why it doesn't match the purl (and Searchworks) record.

To be clear, I don't have a strong preference (I mean, I'd really prefer a much shorter collection name), I just want to be consistent. And the version in the app seems very duplicative of the site title, whereas the "Inventory of ..." version used in the purl record seems more descriptive (but longer, unfortunately).

Relatedly, the "C" in the screenshot refers to the series title in the inventory, which also includes "International Military Tribunal (IMT) at Nuremberg". Again, since that is part of the site title and collection title, it seems redundant and makes the corresponding labels on the inventory tree, breadcrumbs, and title of the series show page longer than ideal. Since you're just making these labels up (if I understand correctly), couldn't we just go with something more like "Document Books" for the series label? EDIT: I see in the "Series - sub-series" spreadsheet that you used shorter labels in column B, so maybe that is your intention and it is just a work-in-progress with the AS -> indexing process. If so, that's great, I like the labels as shown in column B of the spreadsheet a lot, definitely what I had in mind.

My overall concern is the frequent use of "International Military Tribunal (IMT) at Nuremberg (1945-46)" at various levels makes the site visually busy and harder for the user to scan. The whole site is on that topic as conveyed by the site title. So I'm looking for ways we can reduce unnecessary redundancy and simplify our labeling to get a cleaner UI.

Customize content and styling of topbar

For NTA, we want to change the height and colors of default topbar and add a Feedback link to it:

Styling of the topbar

I suggest using the exact height (35px) and background color (#8c1515) currently used in Exhibits.
Font color (#fff) and size (0.9375rem) same as Exhibits.

Contents of the topbar

A: Replace the "ArcLight" logo text with the SUL logo image - same version used in Exhibits. This should be linked to go to https://library.stanford.edu/ (which is different than Exhibits).
B: Retain the Bookmarks, History, and locale select menu we get from the core version of ArcLight.
C: Add a "Feedback" link. I'll create a separate ticket for this because this might need some discussion and details about the form this link would trigger. EDIT: see #129.

Decide on process of moving ASpace records from staging to production

Once we have final data formatted in staging ASpace, we will need to ask Michael Olsen to migrate it into production. He indicated the process was to request him.
We will also want to request a set of credentials that our app can use in production to connect to the API.
For production app creds should we only need the following permission level
view_repository

Add locale translations

Add locale translations into UI
To understand how big a task this is, we need to know how the current templates in AL work, and if there are inline strings we'd need to swap out with locale YAML.

Check and release linked purls

It seems like all (?) of the digital objects in this Document Books series in ASpace are PURLs that have not yet been released in SDR, e.g.

https://purl.stanford.edu/rn542wb9520
https://purl.stanford.edu/kd320gs5547

Add ASpace credentials to vault

Spec out an example EAD format for NTA data

Let's get a basic example with a few boxes and items, and then see what it would take to script our CSV into that format.

Decide on repository display

Will we display the index and show pages for repositories?
Currently the landing page/route of this application is the repositories#index page: (note this is a sample index and we will only have NTA/VT data in reality)

The #repositories#show pages look like this:

And repository is also prominent in the breadcrumbs

If we chose to display the repository structure, what text/content will we use?
If we want to visually suppress repository, what are the technical implications?

Discover how to get data out of ArchivesSpace

Pick a non-NTA collection that's already in AS
Try to get EAD out -- do we download it as XML, is there an API endpoint? Which is preferable?

Decide how to display media in NTA

This was not addressed in core arclight because of the variety of ways end users may be working with media
Probably we will use sul-embed

Do the two different EAD hierarchies display differently in ArcLight?

For a few Series groupings, there is a Series > Sub-series > File > Item hierchay, while there is:
Series > Sub-series > File grouping for the res of the Series.

Currently there is only a Series > Sub-series > File example up in ArcLight.

This week, @laurensorensen will upload a fixture (sample data) for the Series > Sub-series > File > Item hierarchy and make sure with the team that it works / displays as expected in ArcLight from ASpace.

Create record in ArchivesSpace for NTA

Decide on datastore solution for source data

We should not be using Solr as a stable data store. What is the latest good version of our source data / where does it live?
As simple as a CSV in a repository?

Add CI testing

via GH actions?

Update application title

Replace the current placeholder title in the application with Taube Archive of the International Military Tribunal (IMT) at Nuremberg (1945-1946)

Resulting masthead (in terms of the title; this example includes other unimplemented updates) should look something like:

Investigate whether we can use edm:type

Thanks to @ggeisler for researching this as a possibility
Investigate whether we can use edm:type as a high level media format facet
Do we have enough data?
Can we map the specific types automatically to edm:type? For example, "Film in a box" to "Video" when we are generating our final data formats

Decide about URL and possible landing page

In LDCY meeting, VT stakeholders expressed interest in virtualtribunals.stanford.edu as the URL we would go with for having a landing page farther in the future.

10/20/22 during workcycle, devs and ops assigned nta.stanford.edu and Hannah and myself expressed that it would need to be something other than this given that Tom expressed that more collections could be added later on.

virtualtribunals.stanford.edu would be the natural choice but since Spotlight was used for the other exhibit, we would need links out via a landing page to VT in Spotlight and NTA in Arclight (which would be something like virtualtribunals.stanford.edu/nuremberg and then a redirect to VT exhibits in Spotlight)

Would it be out of the scope and impossible given timeline to change the URL to virtualtribunals.stanford.edu and create a landing page to go with it (same SUL branding, etc)? Idea is that there would be two images with text underneath explaining the different collections briefly and the overall project name in a header plus text below the header that explains the overall project.

Set up continuous deployment

This could also involve the task in #39 to make sure we get fresh data on each deploy.

create nta-arclight repository

Update masthead main menu navigation items

We're currently displaying the "Repositories" and "Collections" links in our main menu, inherited from core ArcLight:

However, neither of those links are relevant to the NTA site (we don't want to display either of the repository or collections list pages). Instead, we do want to display some NTA-specific links. So we can replace those two links with these three (the labels and links might change later in the workcycle as we refine things, but these seem useful for now):

Home - linked to the NTA homepage, as described in #77
Content inventory - linked to what I'm thinking of as the "collection home" (as opposed to the NTA site home), which seems to be https://nta-stage.stanford.edu/catalog/mt839rq8746
About - linked to https://exhibits.stanford.edu/virtual-tribunals/about/about-the-project for now. This might change as we discuss and decide on our About page strategy.