Add supporting repositories to documentation on reader/README.md

[molikd]

It turns out that the 'reader' github repo is not the only repository that Distant Reader relies on, there are other, connected repos (like https://github.com/ericleasemorgan/reader-carrels ) that need to be documented in reader (the main github project)

Please add any in-house repositories were are using to README.md.

[molikd]

https://github.com/ericleasemorgan/reader-extras

[ericleasemorgan]

Ah, read-extras. This repository includes a whole bucket of desktop tools.

Remember, a study carrel is really an elaborate data structure. Different types of data can always be found in the same places from carrel to carrel to carrel. Also, it is not possible to build every cool widget into stand-alone Web interface. With these two things in mind, the reader-extras repository includes all sort of cool thing use at a student's, researchers, or scholar's desktop. For example, there is a script to using Solr (on a person's desktop machine) to create and search a study carrel. Given the short name of a carrel, there is a tool to download the carrel fro carrels.distantreader.org and add it to ones library. There is an interactive tool for creating network diagrams rooted in different types of nouns. There is a fledgling tool for geo-locating places extracted from the named-entities process. There is a tool for creating and searching a semantic index using word2vec. There are tools to cluster documents in a couple of different ways.

Again, study carrels are data sets. These tools are used to "read" the data sets. It is possible to incorporate some of these tools into the Web interface, then then the Web interface would: 1) no longer be stand alone, and 2) require a WHOLE LOT of interface design.

[nkmeyers]

The assumption that the stand alone(downloadable & runnable) web interface should be the necessarily limiting factor of the connected users' UX is potentially a false choice with negative consequences? We need to examine why it should be a priority to privilege the Distant Reader CORD19 downloadable UI feature set over a connected Distant Reader CORD19 users' defacto [potentially richer] feature set ?

The downloadable standalone UI does have limiting factors, but those do not, in and of themselves, need to determine how we limit the connected UX?

Next Tasks: to break the false assumption: update the code contributor's instructions and add some documentation about the values behind the [sometimes limiting] downloadble UI feature set, and document any co-dependencies between the repos so code contributors know where it is ticketed, okay, and welcome to extend and enhance each of the:

1. Distant Reader Classic UI connected feature set and which repos are involved
2. where it is ticketed, okay and encouraged to extend and enhance Distant Reader CORD19 project connected UI and which repos are invooled especially where they are different than Classic
3. where it is ticketed, okay, and welcome to extend and enhance the downloadable UI feature set and whether the downloadable UI feature set is the same or different between Distant Reader Classic and Distant Reader CORD19 and which repos are involved?

Let's discuss at Friday meeting and if above is agreed we can ticketify this approach to documentation so it is easier for code contributors to understand repository co-depndences and purposes, and easier for code contributors to take action on UI feature enhancement tickets.