add functionality to "collect" plays into a temporary but referencable custom corpus

[ingoboerner]

At the last JF we discussed implementing a functionality to the dracor-api and frontend that would allow a user to "collect" (star/bookmark/add to shopping cart/...) individual plays and aggregate a custom corpus.

The functionality to collect the plays could be implemented in the frontend maybe as a button on the individual play-page. If a user clicks it the dracor-id of the play must be stored, e.g. in the local storage of the browser. Currently we don't use any cookies on dracor and we should refrain from using cookies because otherwise this would have implications on legal requirements (cookie consent). We also don't want to store any user data, which means also the custom corpora on the server.

The frontend could have a functionality to display the custom corpus, e.g. https://dracor.org/custom and display it similar to other corpora, e.g. https://dracor.org/cal with the exception that it need a control element to flush the local storage to remove the custom corpus; optionally there could be an additional functionality to delete individual play items from the list.

There should be also a functionality to load such a custom corpus by evaluating an URL parameter, e.g. "custom".
If, for example, a user had selected certain plays to be assembled to such a custom corpus, the frontend should be able to parse the individual play-ids from the url parameter and store it in the local storage/display the custom corpus, e.g.

https://dracor.org?custom=gersh000014,shake000032 should be handled in such a way that a temporary custom corpus is set up that contains two Hamlet plays identified by the ids.

On the API side there should be a functionality that allows for generating information about the custom corpus, e.g. if a certain API endpoint is called with an URL parameter containing ids of plays it should return data similar to /corpora/{corpusname} – https://staging.dracor.org/doc/api#/public/list-corpus-content. The metadata on the custom corpus would be relatively sparse. Currently the schema of the endpoints contains the following fields:

name*	[...]
title*	[...]
acronym*	[...]
description	[...]
commit	[...]
repository	[...]
licence	[...]
licenceUrl	[...]
plays	[...]

The attributes commit,repository,licence,licenceUrl are probably not applicable and could be removed, it would make sense to still include the datetime of the request to the API to have some indicator when the custom corpus was assembled to allow for ways to later reconstruct the state of the data (see also the report on versioning living and programmable corpora: https://zenodo.org/records/11081934).

Maybe it would also be an option not to implement a designated endpoint for this but just add this functionality to the /corpora/{corpusname} endpoint (by adding the reserved keyword custom and/or the URL parameter custom={ids}).

or:
/corpora/custom as a route + URL param "ids" would also be an option:

  /corpora/custom:
    get:
      summary: List contents of a custom corpus
      parameters:
        - name: ids
          in: query
          description: A list of DraCor IDs
          required: true
          schema:
            type: array
            items:
              description: dracor-id
      responses:
        '200':
          description: Successful

The idea behind this all is

• allow users to quickly assemble a custom corpus and share it with other by providing a link that includes the dracor-ids of the included plays; this link can be shorted using a link shortening service and included in publications for example
• add limited functionality that has been implemented in an external tool/docker setup to the dracor core services (frontend, api). This has been already done for another thing, the GitHub hash as an attribute in the APIs response; examples of custom corpora and the rationale behind this is in the Report on Versioning Programmable Corpora here: https://versioning-living-corpora.clsinfra.io/4_dockerizing_dracor.html#practical-examples
• We don't have a possibility at the moment to do faceting on a list of plays (apart from filtering the list for search terms (e.g. https://dracor.org/eng, search for author's name, e.g. "Marlow"). If we had the functionality to display a custom corpus based on a list of ids the filtering could be done externally (e.g. by querying a triple store with SPARQL) and still having a way to display the result of such a custom corpus within the DraCor frontend.
  In a later stage the DraCor system could have a URL parameter that contained an encoded SPARQL query (or a query in another query language) and use an external service to generate the list of ids that are needed for the frontend to display this custom corpus.