Skip to content

1.1 Definition of the project goals

Unlike humanities research, which is at least ideally open-ended, DSE must be conceived from the point of view of the end product. Planning must be based on a model of the finished edition and its intended use, and the necessary workflow steps must be traced back from the desired result - admittedly not without continuously adapting this result in the planning process.

In the following, we outline questions and challenges that a project should clarify for itself in the planning phase in the sense of a requirement check. The provisional answers to this check can be concretised in the planning phase with the help of further chapters of this handbook.

1. Initial situation: project framework and resources

Before detailed planning of the end product can begin, the following factors should be evaluated:

  • Nature and quantity of the media to be edited (see constituting texts)

  • Team size and skills

  • Project duration

The extent to which these factors can be adapted depends on the institutional and financial starting position, in particular possible funding. In the case of Switzerland, for example, as of summer 2024, public funding for larger DSEs is only possible as part of a 4-year project application to the Swiss National Science Foundation. This case only serves for illustration, of course, as funding possibilities might change fast and require thorough investigation.

2. Interaction of the technical components

A technical principle of DSE is the modular logic of organising the operation and backup of the various DSE components independently of each other. In particular, image data, the edition database (TEI/XML data) and the edition front end should be kept separate from each other so that they can be transferred to other institutions or replaced or supplemented with new technical solutions as required.

Before tools and platforms are defined, DSE projects should think about the interaction of the technical components.

  • Is there a technical lead who is familiar with all components?

    • If not, how is the interaction coordinated?

  • Are all available technical components really needed?

    • Small projects can, for example, dispense with metadata databases and curate their metadata in Excel or CSV files.

3. Forms of publication

  • Must a digital publication of the interface that is as easy to maintain as possible be available at the end (see our chapter about static presentation)?
  • Is a printed edition planned that is based on a reading version?
  • Is the frontend an intermediate stage that will be replaced by other forms of publication after a certain period of time (e.g. on a larger platform)?

4. Different forms of data utilisation

  • How should the data of the edition be used?

    • For qualitative analysis (e.g. historical source evaluation, philological text-genetic or hermeneutic methods)? Then it is worth focussing on the digital presentation and designing the texts on the human-readable interface, i.e. preparing them (also) for human use. In particular, the greatest possible accessibility should be aimed for.
    • For quantitative analysis (e.g. corpus linguistic analyses, philological distant readings, statistical questions)? Then long-term preservation in databases is (also) in the foreground. It makes the data (also) machine-readable via technical interfaces, so-called APIs, i.e. the data can be read automatically by programmes and tools.

    -> Of course, the two options are not mutually exclusive; a project can enable both qualitative and quantitative utilisation scenarios; in many cases it is even advisable to enable both.

5. Where is automation worthwhile for the project?

Repetitive work is predestined for automation, but not all repetitive work is worth automating (specifically: what takes longer: adapting/rewriting a python script or the repetitive work of a research assistant?) Appropriate technical knowledge must be recruited for the project.