Kategorie: Gastbeitrag

Tools

Open Access Publishing at TUHH: Exemplary Step-by-step guide for a toolchain with TORE, GitLab, Sherpa Romeo and Zenodo

The following step-by-step guide is updated regularly and should be seen as a kind of living document. A more recent version, if available, can be viewed via the repository linked in the license note at the end of the post.

Publishing a paper as preprint would work as described in the following steps:

  1. You have to get an overview on possibilities to publish and open access sharing rights (further information on the websites of the TU library)
  2. Check the permissions of your journal or publisher where you would like to publish via Sherpa Romeo. Example for IEEE proceeding is:
Example for aggregated permissions of IEEE proceedings via Sherpa Romeo

Here you can see that preprints (research papers that are shared before peer review) are possible and which rules you have to follow. For example for CDC (Conference on Decision and Control) you can upload the preprint with a notice that this paper is submitted for review and afterwards you have to place a copyright notice and a DOI link of the IEEE finally published version. You are not allowed to publish the final version, just an author version with the copyright terms. See IEEE policy, section 3 for that.

  1. Create a repository for your publication in our gitlab instance: TUHH – Gitlab (private repo, a public repo can be seen here). In general you create

    • a repository for your paper
    • a repository for your software code (See Code Section)

Use the following scheme: Year-paper-conference-FirstSixWordsOfTitleOfYourPublication (e.g. 2021-paper-ECC-A-Gradient-Descent-Method-for-Finite) while the code is in the corresponding Year-code-TitleOfYourContribution repository.

  1. Have in mind to add references to supplimentary material in the readme.
  2. Add submission or copyright terms to your paper and create a prefinal pdf. You might keep some space (Where??) to place the preprint DOI for references.
  3. Open tore submission page with your personal account (more details via tore help).
  4. Select Publications with fulltext and click on manual submission
  5. The next pages collect metadata:
    • Title
    • Authors (Add an ORCID if possible, Add Prof Werner, for example). Clicking on the magnifier allows searching for entries. Validated entries are marked with a green arrow.
    • Select Language: English
    • Type: Preprint
    • Enter Abstract in English
    • Select TUHH Institute: Type E14 and by using the magnifier select the validated entry.
    • Go next
A click on the magnifier allows searching for entries
  1. Next page collects publisher metadata:
    • These information will be updated with the final version to be submitted for publication
    • Enter Date of issue: Todays date
    • Go next
  2. License details
    • License: Copyright should be selected
    • Supplemented by: Here you can add your Code DOI
    • Project: If you are working for a DFG program, you should reference it here
    • Funder: Here you should add DFG or BMWI as Funder
  3. Now you get your DOI.
    • Copy this DOI into your paper and compile it with this DOI. The DOI is booked but not finally registered. This will be done in the next steps
  4. Now, upload the pdf of your preprint
    • upload pdf
    • check filename (should be meaningful)
    • Set embargo date if neccessary
    • next
  5. Verfiy your submission and accept the license of TORE
  6. Your submission is nearly done. TUHH Library will check your submission. Either they accept it or ask you to change things. You will be emailed. Your entry is so to say, peer review on metadata level
  7. For now you are done. Further version have to be uploaded when the paper got accepted and you can upload the final author version to TORE. Please make sure that you reference the publisher DOI and add the correct credits to the paper.

Publish your software files related to your paper publication

You want to publish files like your source code, your data or videos in a save manner and cite them using a DOI?

The code you publish should be able to reproduce all figures you show in your publication by running one or multiple files which are than related to your figure. If your code uses special software or libraries to run, you should note them down in a dependancies and software section in a readme file of the repository. You should not include these files to your repository. Installation steps should be explained.

Than this is one way to go:

  1. Create a repository for your publication in our gitlab instance: TUHH – Gitlab. In general you create
    • a repository for your paper (See Paper Section)
    • a repository for your software code in https://collaborating.tuhh.de/ICS/ics-private/phd-students/papers (private repo) by using the following scheme: Year-code-conference-FirstSixWordsOfTitleOfYourPublication (e.g. 2021-code-ECC-A-Gradient-Descent-Method-for-Finite) while the paper is in the corresponding Year-paper-conference-TitleOfYourContribution repository.
  2. Upload your code by using git (You can use this repo already when starting to work on an idea: Repositories can be renamed and moved in the gitlab structure). Code should be cleaned up and except for dependancies and libraries selfcontaining. (Be careful on which branch to push, master gets automatically pushed to github, others not)
  3. Add a License file to the repo using templates: GPLv3 (Software) and CC-BY-SA (for all other media) and remove all lines after End of Terms and Conditions around line 625
  4. Add the following header lines to the beginning of each of your files. In references your refere to papers, software or tools you base on to cite them. Make sure that our license in compatible with the build on software/library/code.
```
%------
% Project: Name and Link
% Copyright: 
% License: 
% References:
% Authors:
%------

%---------------------------------------------------------------------------------------------
% For Paper, 
% "A Gradient Descent Method for Finite Horizon Distributed Control of Discrete Time Systems"
% by Simon Heinke and Herbert Werner
% Copyright (c) Institute of Control Systems, Hamburg University of Technology. All rights reserved.
% Licensed under the GPLv3. See LICENSE in the project root for license information.
% Uses an own implementation of the work of 
% "A. Vamsi and N. Elia, Design of distributed controllers realizable over arbitrary directed networks,
% IEEE Conference on Decision and Control, 2010."
% Author(s): Simon Heinke
%--------------------------------------------------------------------------------------------
```
  1. You also might want to enter a section in the Readme file on how to cite your work. Therefore you should include bibtex code for citing authors to reference your work in their publication. E.g.:
``` 
@misc{1606.01540,
    Author = {Greg Brockman and Vicki Cheung and Ludwig Pettersson and Jonas Schneider and John Schulman and Jie Tang and Wojciech Zaremba},   Title = {OpenAI Gym},
    Year = {2016},
    Eprint = {arXiv:1606.01540},
}
 ```

Example for Readme.md from Christian Hespe:

Example for a Readme.md file
  1. Create a repository at github.com/TUHH-ICS
    • with the same name as in gitlab
    • Give a short meaningful description
    • Select public
    • Click on create repository
    • Ask Lennart Heeren or Patrick Göttsch to grant you maintainer rights in that particular repository
    • Copy the SSH url from github
  2. Enable mirroring in gitlab
    • Switch to your private gitlab repository
    • Left menu -> Settings -> Repository -> Expand Mirroring repositories
    • Paste your github url in Input the remote repository URL
    • Modify it this way: ssh:// at the beginning and replace the colon after github.com with a slash. It should look like this now: ssh://git@github.com/TUHH-ICS/REPO_NAME
    • Klick on Detect host keys button
    • Select (although it does not seam to be clickable) in authentification method SSH Public Key
    • And select Mirror only protected branches. By default only the master branch will be pushed as it is.
    • Click on mirror repository to setup the mirror.
    • Now you have to click on the Copy ssh public key
Copy the ssh public key via mousclick on the copy item
  • After a click on the key…
    • go back to GitHub;, click on Settings > Deploy Keys > Add deploy key
    • Give it some title, paste the copied key in the key field and check Allow write access abd than click on Add key
    • Now you can trigger the mirroring by pushing or merging into the master branch in gitlab or manually in the gitlab repo mirroring settings page
  1. Uploading to Zenodo
    • Login to Zenodo using ** Log in with this credentials **
      • user: ics@tuhh.de
      • passwd: JJ^Q?…
    • Click on setting->github (1),
    • Click on Sync now button (2),
    • and enable the repository (3, located at the end of the list),
    • Then we go back to github and create a new release (4):
  • 1. Click on setting->github
  • 2. Click on Sync now button
  • 3. Enable the repository (located at the end of the list)
  • 4. Then go back to github and create a new release
  • give a version tag like v1.0
  • give a meaningful title
  • and some description (will also be published by zenodo)
  • click on Publish Release
Click on „Publish release“ after assigning a tag, a title and a description

This automatically generates a zip of the code and this zip gets uploaded to zenodo, also automatically.

  1. Creating a DOI/Publishing
  • Back in Zenodo click on upload at the top of the page
Upload-Button
  • Here you find your software code already published
Published software code
  • Since not all metadata is available on github, you have to edit your entry
    • Click on the title opens the entry and shows a view as readers would see it.
    • You can click on edit to add or change metadata. The next view is organised in multiple sections:
      • Files: Here you can upload a new version manually. But normmaly you would choose a github release as the way to go.
      • Communities: Please select Hamburg University of Technology to reference this contribution to TUHH
      • Upload Type: Should already be Software
      • Basic Information:
        • Adjust the Title because the github repo name has been used. E.g.: Code for paper: Name of my marvellous paper
        • Authors: Clean up authors list; Lastname, Firstname – Hamburg University of Technology – Institute of Control Systems – ORCID
        • Add Prof Werner to this list: Werner, Herbert Hamburg University of Technology – Institute of Control Systems – 0000-0003-3456-5539
        • Add a meaningful Description
        • Version tag got automatically set
        • Language: Choose English
        • Give similar Keyword as you choose for your paper
      • License: All should be okay. The License is provided in the repository. Zenodo so far does not support GPLv3.
      • Funding: Select nothing
      • Save the changes. And when you think they can be published, hit the publish button.
  1. Cite code
    • use Zenodo Bibtex generator to get a bibtex entry of your code for your latex literature file – Export section (bottom right)
BibTeX code export via Zenodo

Put a DOI patch into the readme -> Use latest version DOI by clicking on the DOI entry (1) and copying the markdown code (2) from the window. You can add a badge to your gitlab repo as well, either in the readme (2) or by adding a batch using (3a) and (3b)

Zendodo DOI Badge

You might want to change the DOI to the DOI for the latest version:

Adjust the DOI
  1. Updating
    • Create new release on github
    • update Description on zenodo

Publish your video files / data related to your publication

Use only Zenodo.

References

CC BY 4.0
Weiternutzung als OER ausdrücklich erlaubt: Dieses Werk und dessen Inhalte sind – sofern nicht anders angegeben – lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: Open Access Publishing at TUHH: Exemplary Step-by-step guide for a toolchain with TORE, GitLab, Sherpa Romeo and Zenodo von Patrick Göttsch, Christian Hespe, Adwait Datar, Simon Heinke und Lennart Heeren Lizenz: CC BY 4.0. Eine ggf. aktualisierte Version des Workflows kann über dieses GitLab-Repositorium abgerufen werden.
Allgemein, Anwendungen und Tools, Arbeitswelt, Digitale Welt, Featured, Gastbeitrag, Open Access, Open Science, Open Source, Publizieren, Workflows , , , ,
Wand mit Notiztipps

Geschichte und Gegenwart meiner Notizen (Gastbeitrag von Benjamin Roers) #Notizschreibwochen2020

Luft nach oben

Wenn ich mich richtig erinnere, dann habe ich mir den größten Teil meines Studiums keine großartigen Gedanken darüber gemacht, wie ich Informationen nachhaltig, d. h. strukturiert, wiederauffind- und verwertbar dokumentiere. Nur selten habe ich Exzerpte zu einzelnen Texten angefertigt, um sie dann am Semesterende doch bloß irgendwo abzuheften.

Für Hausarbeiten sammelte ich meine Literaturnotizen zunächst in einem einzelnen Dokument. Wenn ich dann zu schreiben begonnen hatte, sortierte und kopierte ich mir relevante Angaben einfach dort in meine Textdatei, wo ich sie brauchte. Welche absurden Relationen das annehmen konnte, war mir gar nicht mehr bewusst, bis ich mich an einen Tweet von mir erinnerte (siehe Abb. 1).

Tweet zu Notizen einer Hausarbeit.

Abb. 1: Tweet zu Notizen einer Hausarbeit.

In Sachen Schreibpragmatik war also noch Luft nach oben.

Keine Lust mehr, alles manuell zu tippen

Zumindest hatte ich mich zu dieser Zeit schon mit Literaturverwaltungssoftware beschäftigt. Ich hatte keine Lust mehr, meine Literaturrecherchen in Word-Dateien zu dokumentieren, Fußnoten und Verzeichnisse manuell zu tippen und am Ende jeder Hausarbeit mindestens einen halben Tag für die formale Kontrolle einzuplanen. Meine Idee war: Wenn ich mir einmal die Zeit nehme, um mich konzentriert in eine Literaturverwaltungssoftware einzuarbeiten, werden die kommenden Schreibprojekte sehr viel einfacher sein. Ich entschied mich damals konkret für die Software Zotero, weil es eine Freie und Open Source Software ist und mir die Idee dahinter sehr gefiel (tut sie heute noch).1

Mein Plan, durch die Nutzung eines Literaturverwaltungsprogramms komfortabler arbeiten zu können, ging jedenfalls auf. Mit Zotero war ich schnell vertraut und zum Schluss hatte ich mir in ein paar Tagen (und Nächten) im CSL-Editor auch noch einen eigenen Zitierstil zurecht gebaut. Für mich als Laien war das mitunter nervenaufreibend, weil furchtbar kompliziert. Aber es hat sich gelohnt: Meinen damals individualisierten Zitierstil benutzen ich und ein paar Kommiliton:innen heute noch.

Von da an war Zitieren eigentlich kein großer Aufwand mehr. In Word hatte ich mir entsprechende Tastenkürzel eingerichtet mit denen sich Fußnoten mit ein paar Handgriffen setzen ließen. Abschließend dann noch mit einem Click ein Literaturverzeichnis erstellen und das Referenzsystem der Arbeit war im Wesentlichen korrekt. Wichtig ist dafür nur, dass die Angaben in der Zotero-Datenbank korrekt, d.h. einheitlich und vollständig sind.

Trial & Error

In Zotero begann ich dann auch bald, meine Literaturnotizen und Exzerpte zentral zu sammeln. Im Gegensatz zu meiner früheren Technik, bei der alle Notzien in einer Datei untereinander aufgelistet waren, hatte ich nun alles dem jeweiligen Literatur-Datensatz zugeordnet. Bei der Vorbereitung für Hausarbeiten war das hilfreich, weil strukturierter und übersichtlicher.

Am Schreibprozess selbst änderte das allerdings nichts. Denn sobald ich damit begann, zog ich alles wieder in eine Textdatei und baute davon ausgehend meinen eigenen Text. Eine Masterarbeit von etwa 100 Seiten ließ sich auf diese Weise noch erfolgreich produzieren. Aber spätestens beim nächsten Schritt, einer Dissertation mit 250 bis 300 Seiten, würde dieses System an seine Grenzen stoßen, dachte ich.

Womit wir im Grunde in der Gegenwart angekommen wären. Denn seit ca. einem Jahr bin ich jetzt in einem Trial & Error-Prozess dabei, ein für mich angenehmes, praktikables und zielführendes Wissensmanagement zu entwickeln. Dieses besteht derzeit aus einem digital-analogen Mix aus handschriftlichen bzw. getippten Notizen, dem Markdown-Editor Zettlr und Zotero. Das dazugehörige Konzept sieht drei Schritte vor, die ich nun kurz skizzieren möchte.

Let’s get concrete

Schritt 1: Lesen und Notieren

Texte lese ich in entweder analog (Buch/gedruckter Scan) oder digital (auf dem Tablett). Dabei habe ich immer einen Stift in der Hand, um Markierungen und Randnotizen zu machen. 2 Diese Randnotizen haben sich im Laufe der Jahre standardisiert und entsprechen den gängigen wissenschaftlichen Strukturkategorien. 3

STRUKTURKATEGORIE VERBUNDENE FRAGE / ERLÄUTERUNG NOTIZ AM TEXTRAND
Thema/Gegenstand Worum geht es allgemein? Thema
Fokus Worum geht es im Speziellen? Fok.
Fragestellung Was soll herausgefunden werden? F
Defintion Wie genau werden zentrale Begriffe verstanden? Def.
Ziel Was ist das Ziel des Textes? Was möchte er herausfinden, zeigen, infragestellen o.ä.? Ziel
These/n Was ist/sind die Antwort/en auf die Fragestellung? T bzw. T1, T2, …
(Histroische) Quellenbasis Mit welchem Material wird gearbeitet? An welches Material richtet sich die Fragestellung und werden Thesen abgeleitet? Q
Methode/Theorie Mit welcher Perspektive und welchem „Werkzeug“ nähert sich der Text dem Thema? Wie und auf welcher gedanklichen Grundlage wird die Fragestellung beantwortet? M/T
Forschungsstand Was wurde zum Thema bzw. zum speziellen Fokus bislang an wissenschaftlicher Literatur veröffentlicht, auf die der Text aufbaut? Fs
Angekündigtes Vorgehen Wie geht der Text im Einzelnen vor? Welche Schritte unternimmt der Text in seinem Verlauf? Vorgehen
Kernaussagen Was sind die zentralen Aussagen des Textes? •
Für mich besonders relevant Was ist darüber hinaus für mich, mein Projekt, meine eigene Fragestellung bzw. mein persönliches Interesse von Bedeutung? ! bzw. Diss.

Tab. 1: Strukturkategorien für Randnotizen.

Sobald ich einen Text auf diese Weise gelesen und erschlossen habe,4 schreibe ich mir zumindest alles heraus, was für meine Dissertation oder meine jeweilige Frage(n) an den Text wichtig ist.5 Das tue ich meist in Form einer Liste, an deren Anfang die Literaturangabe des Textes steht. Hinter den einzelnen Punkten stehen dann auch immer Textverweise. Falls mir später etwas unklar ist oder ich den Punkt nochmal vertiefen will, weiß ich, wo genau ich gucken muss. Wenn ich einen Text nicht nur in Bezug auf mein eigenes Interesse, sondern darüber hinaus auch in seiner Grundargumentation genau dokumentieren will, schreibe ich ein Exposé. Dabei orientiere ich mich an den oben aufgeführten Strukturkategorien.

Nahezu alle meine Aufzeichnungen speichere ich digital und hefte sie darüber hinaus als analoge Ausdrucke in einem Ordner ab. Denn obwohl ich viel digital mache, bin ich ein eher haptischer Mensch. Tatsächlich kann ich auch auf Papier gedruckte Texte immer noch besser lesen als digitale.

Schritt 2: Verzetteln

Als nächstes werden die Notizen in Zettlr „verzettelt“, d.h. dass ich jeden relevanten Gedanken aus seinem ursprünglichem Textzusammenhang herauslöse und für jeden in eigenen Worten eine Einzelnotiz schreibe.6 Um die Notizen zu sammeln und zu organisieren, habe ich mir in Zettlr einen Zettelkasten angelegt.

Dort lassen sich die einzelnen Notizen auch verschlagworten und über IDs individuell miteinander verknüpfen. Auf diese Weise entsteht ein großes, sich stets erweiterndes und dynamisch aufeinander beziehendes Netz an Informationen. In meinem Zettelkasten sammele ich nicht nur meine Literaturnotizen, sondern grundsätzlich alle interessanten Gedanken, Ideen und Überlegungen. Der Einfachheit halber habe ich mir eine Zettel-Vorlage gebaut7 auf der jede Notiz beruht (siehe Abb. 2).

Zettelvorlage für Notizen.

Abb. 2: Zettelvorlage für Notizen.

Schritt 3: Pflegen der Zotero-Datenbank

Literatur sammele ich in Zotero – meistens schon im Rahmen der Recherche. Zunächst sortiere ich alle Einträge einem Projekt- und darin einem bestimmten thematischen Unterordner zu. Sobald ein Text für den weiteren Arbeitsverlauf relevant wird, schaue ich, dass der Eintrag einheitlich und vollständig ist. Wie gesagt, ist das die Voraussetzung dafür, dass auch die späteren Verweise im Text korrekt sind.

Anschließend versehe ich jeden Zotero-Eintrag mit Hashtags, die den jeweiligen Bearbeitungsstatus anzeigen und in Form eines farbigen Kästchens auch in den Einträgen auftauchen (siehe Abb. 3).

Farben Bearbeitungsstatus

Abb. 3: Farben zeigen in Zotero den jeweiligen Bearbeitungsstatus.

HASHTAG BEDEUTUNG
#liegt vor Der Text liegt in analoger oder digitaler Form zum Lesen bereit
#gelesen Ich habe den Text gelesen und durch Markierungen erschlossen
#exzerpiert Ich habe alles relevante aus dem Text herausgeschrieben
#verzettelt Ich habe mein Exzerpt in Zettl „verzettelt“
#eingepflegt Inhalte/Bezüge auf den Text finden sich in meinem Fließtext

Tab. 2: Bedeutung des jeweiligen Bearbeitungsstatus.

Im besten Falle habe ich einen Text dann also gelesen, alle für mich wichtigen Dinge herausgeschrieben und daraus verschlagwortete Einzelnotizen generiert. Zusätzlich habe ich in Zotero den Überblick darüber, welcher Text in welchem Stadium der Bearbeitung ist. Wofür ich bislang noch keine wirklich praktische Lösung gefunden habe: Meine Zettel übersichtlich und trotzdem flexibel in einen Fließtext zu übersetzen.

Fließtext: Theorie und Praxis

In Bezug auf Zettelkästen wird üblicherweise empfohlen, Gedanken und Argumente „inside the box“8, also entlang der bestehenden Zettel zu entwickeln. Indem immer mehr einzelne Zettel inhaltlich miteinander in Beziehung gesetzt werden, entsteht ein wachsendes Netzwerk an Informationen: Gewissermaßen ein großer, auf der Verknüpfung von Einzelgedanken basierender , Gedankenkomplex.

Soll aus diesem netzartigen Wissensspeicher nun ein linearer Fließtext zu einem bestimmten Aspekt entstehen, wird zunächst eine passende Gliederung entworfen. Anschließend werden alle für den Text relevanten Zettel identifiziert und entlang der Gliederung in eine sinnvolle Reihenfolge gebracht. Zum Schluss sind die Gedanken auf den einzelnen Zetteln dann nur noch durch kurze Übergangstexte miteinander zu verbinden und fertig ist der Fließtext. Soviel zur Theorie.

In der Praxis fehlt mir bislang noch die Übung, meine Texte auf diese Weise „inside the box“ zu entwickeln und zu schreiben. In Sachen Fließtextproduktion fühle ich mich gerade in Microsoft Word noch immer am wohlsten. Ich benutze die Anwendung schon lange und habe mich einfach an die klar umgrenzen Seiten und hübsch vorformatierten Texte gewöhnt. Am Ende des Tages habe ich dann auch einen besseren Eindruck davon, was ich geschafft habe.

Außerdem ist es in der Geschichtswissenschaft üblich, Referenzen in Fußnoten anzugeben. Und das bekomme ich mit meinen Zotero-Kurzbefehlen in Word immer noch einfacher hin, als in Markdown. Hier empfinde ich das Setzen von Fußnoten als sehr umständlich. Hinzu kommt, dass ich als Historiker neben wissenschaftlichen Texten ja auch mit historischen Primärquellen, also z.B. Zeitungsartikeln aus den 1950er Jahren, arbeite. Ob, und wenn ja, wie ich die in meinen Zettelkasten mitberücksichtigen kann bzw. möchte, weiß ich noch nicht.

Cowabunga!

Ganz ausgefeilt ist mein Konzept also nicht nicht. Ob es das jemals sein wird? Mal gucken. Ob ich bei der jetzigen Methode bleibe? Vermutlich nicht. Solange meine Inhalte nicht verloren gehen, ist alles in Ordnung. Vielleicht werden sie im Laufe des Prozesses unterschiedlich entstehen oder verschiedene Formate durchlaufen. Das ist okay. Letztlich habe ich Lust und finde es wichtig, meine Arbeitsmethoden – und damit die Art und Weise, wie ich Wissen produziere – fortlaufend zu reflektieren und neues auszuprobieren. In diesem Sinne: Cowabunga!

 

Endnoten

1 Zotero wurde am Roy Rosenzweig Centre for History and New Media an der George Mason University entwickelt. Von dort stammen auch andere tolle Tools wie Tropy, mit dem sich historisches Quellenmaterial organisieren und individuell erschließen lässt; sowie Omeka, eine Software zum Erstellen von Onlinearchiven. Auf Omeka läuft auch das coronarchiv, ein Projekt zum Sammeln von Erlebnissen und Eindrücken zur Corona-Pandemie. Tragt doch gerne etwas dazu bei!
2 Selbst beim nicht-wissenschaftlichen Lesen habe ich zumindest immer einen Stift griffbereit, falls ich z.B. ein gutes Zitat oder einen spannenden Gedanken finde.
3 Ein ganz ähnliches System schlagen auch Thieme und Weiß vor: Thieme/Weiß 2020, S. 44–47.
4 Das Thema wissenschaftliches Lesen ist vielschichtig und wäre mindestens einen eigenen Beitrag wert. Zum Glück haben andere Menschen aber schon sehr viel nützliches darüber geschrieben. Hilfreich finde ich z. B. Otto Kruse: Lesen und Schreiben. Der richtige Umgang mit Texten im Studium. Konstanz 2010, sowie Sarah Thieme/Jana Weiß: Lesen im Geschichtsstudium. Opladen/Toronto 2020.
5 Dafür macht es Sinn, sich zuvor über den jeweiligen Anlass des Lesens klar zu sein: Lese ich den Text z.B., um seine Gesamtargumentation im Seminar zu besprechen oder weil ich eine ganz bestimmte Information für meine Hausarbeit brauche? Siehe hierzu auch Thieme/Weiß (2020), S. 19 f.
6 Siehe Söhnke Arendts: Das Zettelkasten-Prinzip: Erfolgreich wissenschaftlich Schreiben und Studieren mit effektiven Notizen. Norderstedt 2017, S. 83–98. Das wesentlich an die Arbeitsmethode Niklas Luhmanns angelehnte „Zettelkasten-Prinzip“ finde ich in Sachen „effektive wissenschaftliche Notizen“ insgesamt sehr inspirierend.
7 Dabei habe ich mich wiederum an Ahrend (2017) orientiert.
8 Ahrend (2017), S. 115.

Über den Autor:

Benjamin Roers hat Geschichte und Philosophie an der Universität Hamburg studiert und war dort u. a. als studentische Hilfskraft im Arbeitsfeld Public History aktiv. Seit April 2019 ist er wissenschaftlicher Mitarbeiter am International Graduate Centre for the Study of Culture (GCSC) der Justus-Liebig-Universität Gießen. Die meisten Notizen sammelt er für seine Dissertation zu Mensch-Tier-Beziehungen im Zirkus im 20. Jahrhundert.

CC BY 4.0
Weiternutzung als OER ausdrücklich erlaubt: Dieses Werk und dessen Inhalte sind – sofern nicht anders angegeben – lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: „Geschichte und Gegenwart meiner Notizen (Gastbeitrag von Benjamin Roers) #Notizschreibwochen2020“ von Benjamin Roers, Lizenz: CC BY 4.0. Der Beitrag steht als Markdown-, DOCX- und PDF-Datei zur Verfügung.
Allgemein, Anwendungen und Tools, Arbeitswelt, Digitale Welt, Gastbeitrag , , , , ,
1 2 3 … 5