Nur in quarto/data-stories: Documentation for Data Stories.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/data-stories/ds_documentation.qmd quarto/data-stories/ds_documentation.qmd
2c2
< title: "Documentation for Data Stories (Data Stories)"
---
> title: "Data Stories / Documentation for Data Stories (Data Stories)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/data-stories/ds_documentation
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/data-stories/ds_documentation"
>       icon: "gitlab"
11c11
< # Documentation for Data Stories (Data Stories)
---
> # Data Stories / Documentation for Data Stories (Data Stories)
14,21c14,17
< > title: "Documentation for Data Stories"
< > author: Till Grallert
< > date: 2025-03-11 
< > lang: de
< > tags: 
< >     - NFDI4Memory
< >     - ClioGuides
< >     - DataStories
---
> > title: "Data Stories / Documentation for Data Stories"
> > author: "Data Stories"
> > date: "2025-03-13"
> > lang: "de"
23,44d18
< > 
< > In diesem Repo findet sich die Dokumentation zu unseren Überlegungen zu Data Stories, die im Rahmen der Clio Guides publiziert werden.
< > 
< > # Inhaltliche Ideen
< > 
< > Inhaltliche Ideen werden über Issues gesammelt, die mit dem Label [Themenvorschlag](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/issues/?label_name%5B%5D=Themenvorschlag) versehen werden.
< 
< ---
< 
< ## Issues
< 
< ### Themenvorschlag: Zeitschriftenforschung und Impresso
< 
< Status: opened
< 
< Ich habe im Rahmen der DHd2025 mit Marten Düring gesprochen, ob er nicht Lust hätte gemeinsam eine Data Story zu Periodika und (aber nicht notwendigerweise) Impresso zu machen.
< 
< ### Themenvorschlag: Quellcodekritik
< 
< Status: opened
< 
< Im Nachgang der DHd2025 habe ich Adrian Demleitner und Daniel Gammenthaler angefragt ob sie eine Data Story zu Quellcodekritik und Forensik schreiben wollen.
Nur in quarto/data-stories: Linked Open Data in den Geschichtswissenschaften.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/data-stories/pandoc-templates.qmd quarto/data-stories/pandoc-templates.qmd
2c2
< title: "Pandoc Templates (Data Stories)"
---
> title: "Data Stories / Pandoc Templates (Data Stories)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/data-stories/pandoc-templates
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/data-stories/pandoc-templates"
>       icon: "gitlab"
11c11
< # Pandoc Templates (Data Stories)
---
> # Data Stories / Pandoc Templates (Data Stories)
14,16c14,17
< > authors:
< >   - Nicole Dresselhaus
< > title: Pandoc-Templates Data Stories
---
> > title: "Data Stories / Pandoc Templates"
> > author: "Data Stories"
> > date: "2025-05-12"
> > lang: "de"
18,410d18
< > 
< > ## Was befindet sich in diesem Repository
< > 
< > Dieses Repository dient als Template-System für die Erstellung von Data Stories
< > mit Pandoc und Quarto.
< > 
< > Es besteht aus zwei Hauptkomponenten:
< > 
< > 1. **Pandoc-Templates** (im `converter`-Verzeichnis):
< > 
< >    - Umwandelt Markdown-Dateien in HTML-Dokumente
< >    - Verwendet Pandoc als Konverter
< >    - Ermöglicht die Erstellung von professionellen Publikationen
< > 
< > 2. **Quarto-Templates** (im `quarto`-Verzeichnis):
< >    - Bietet ein Template-System für Quarto-basierte Dokumente
< >    - Unterstützt Markdown mit Codezellen
< >    - Enthält vordefinierte Stile und Layouts
< >    - Ermöglicht die Erstellung von hochwertigen HTML-Publikationen
< > 
< > Das Projekt wurde im Rahmen des Methods Innovation Lab des
< > NFDI4Memory-Konsortiums entwickelt. Es zielt darauf ab, neue Publikationsformate
< > für datafizierte Geschichtswissenschaft zu ermöglichen, die neben traditionellen
< > historischen Narrativen auch Code und Visualisierungen integrieren.
< > 
< > Grundlage legte hier ein Werkauftrag, dessen Originaldateien unter
< > `Werkauftrag/` zu finden sind.
< > 
< > Die Templates folgen dabei bestimmten Anforderungen:
< > 
< > - Barrierefreiheit (ARIA-Standards)
< > - Endings Principles for Digital Longevity
< > - Themes
< >   - Verwendung der visuellen Sprache der Clio Guides
< >   - Verwendung der visuellen Sprache des NFDI4Memory-Konsortiums
< > 
< > Das System ist modular aufgebaut, wobei Quarto als technische Grundlage dient
< > und Pandoc für die Umwandlung verwendet wird.
< > 
< > ## Vorgehen
< > 
< > 1. **Neues Verzeichnis erstellen:**
< > 
< >    - Erstellen Sie ein neues Verzeichnis im `quarto`-Verzeichnis
< >    - Beispiel: `quarto/meine-publikation`
< > 
< > 2. **Dateien bereitstellen:**
< > 
< >    - Kopieren Sie Ihre Markdown-Datei in das neue Verzeichnis
< >    - Stellen Sie sicher, dass alle benötigten Assets (Bilder, Tabellen etc.) im
< >      gleichen Verzeichnis liegen
< > 
< > 3. **YAML-Frontmatter konfigurieren:**
< > 
< >    - Nutzen Sie die Beispiele aus diesem Dokument als Vorlage
< >    - Passen Sie die Konfiguration an Ihre Bedürfnisse an
< > 
< > 4. **Generierung der Publikation:**
< >    - Führen Sie `make` im Verzeichnis Ihrer Publikation aus
< >    - Die generierte HTML-Datei wird im gleichen Verzeichnis erstellt
< > 
< > ## Vorraussetzungen
< > 
< > - **Quarto:** [Installation](https://quarto.org/docs/get-started/)
< > 
< >   - Unterstützt Markdown mit Codezellen
< >   - Ermöglicht die Erstellung von hochwertigen HTML-Publikationen
< > 
< > - **Make:**
< > 
< >   - Installieren Sie Make auf Ihrem System
< >   - [Installation](https://www.gnu.org/software/make/)
< > 
< > - _**Alternativ**_: Nutzen sie diesen quarto-Aufruf im Verzeichnis ihrer
< >   Publikation:
< > 
< >   ```bash
< >   quarto render meine-publikation.md --to html -o meine-publikation.html \
< >    --toc=true --email-obfuscation=javascript --mathml
< >   ```
< > 
< > ## HTML-Formatierung
< > 
< > Die Konfiguration des HTML-Ausgabeformats erfolgt über das `format:`-Tag in der
< > YAML-Frontmatter. Hier sind die wichtigsten Optionen:
< > 
< > 1. **Link-Einstellungen:**
< > 
< >    - `link-external-icon`: Fügt externe Links ein Icon hinzu
< >    - `link-external-newwindow`: Öffnet externe Links in neuem Fenster
< > 
< > 2. **Layout und Navigation:**
< > 
< >    - `toc-location`: Position der Inhaltsverzeichnis (z.B. "left")
< >    - `reference-location`: Position der Referenzen (z.B. "margin")
< > 
< > 3. **Styling:**
< > 
< >    - `theme`: Anwendungs des benutzerdefinierten Themes
< > 
< >      ```yaml
< >      theme:
< >        - ../themes/nfdi.scss
< >      ```
< > 
< > 4. **Weitere Links und Ressourcen:**
< >    - `other-links`: Zusätzliche Links mit Text und URL
< >    - `code-links`: Links zu Code-Repositories
< > 
< > Beispiel für eine vollständige Format-Konfiguration:
< > 
< > ```yaml
< > format:
< >   html:
< >     link-external-icon: true
< >     link-external-newwindow: true
< >     toc-location: left
< >     reference-location: margin
< >     theme:
< >       - ../themes/nfdi.scss
< >     other-links:
< >       - text: Tool-Storage interface
< >         href: "https://furesh.github.io/tool-storage-interface/"
< >     code-links:
< >       - text: Archive-System
< >         icon: gitlab
< >         href: "https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata"
< >       - text: Frontend
< >         icon: github
< >         href: "https://github.com/FuReSH/tool-storage-interface"
< > ```
< > 
< > Diese Konfiguration ermöglicht eine konsistente und benutzerfreundliche
< > Darstellung der Publikation im HTML-Format.
< > 
< > ## Konfiguration
< > 
< > ### Titel
< > 
< > Der Titel der Publikation wird in der YAML-Frontmatter-Konfiguration über das
< > `title`-Tag festgelegt:
< > 
< > ```yaml
< > title: "Titel der Publikation"
< > ```
< > 
< > ### Autor
< > 
< > - **Simple Namensnennung:**
< > 
< > ```yaml
< > author:
< >   - "Autor 1"
< >   - "Autor 2"
< > ```
< > 
< > _Verwendet, wenn eine simple Namensnennung reicht._
< > 
< > - **Komplexes Objekt:**
< > 
< > ```yaml
< > author:
< >   - name: "Vorname Nachname"
< >     # Alternativ:
< >     # - name:
< >     #     given: "Vorname"
< >     #     family: "Nachname"
< >     #     non-dropping-particle: "von der"
< >     #
< >     # vvv    ab hier alles hier drunter optional  vvv
< >     email: "email@example.com"
< >     orcid: "0000-0002-1825-0097"
< >     corresponding: true # Autor kontaktierbar
< >     id: "autor-id" # falls woanders referenziert (z.b. funding)
< > ```
< > 
< > _Verwendet, wenn detaillierte Angaben zu Autor(n) erforderlich sind. Gut für
< > wissenschaftliche Publikationen._
< > 
< > ### Institution
< > 
< > - **Als Liste von Affiliations:**
< > 
< > ```yaml
< > author:
< >   - name: "Name"
< >     affiliation:
< >       - "inst1"
< >       - "inst2"
< > 
< > affiliation:
< >   - id: "inst1"
< >     name: "Forschungsprojekt XY"
< >   - id: "inst2"
< >     name: "Universität ABC"
< >     department: "Institut für Digitale Historiographie"
< >     ror: https://ror.org/123456789 # example RoR
< > ```
< > 
< > _Autoren und Institute sollten immer getrennt sein. Dies sorgt dafür, dass bei
< > "schnellen Korrekturen" nichts übersehen wird._
< > 
< > - **Im Autorenobjekt:**
< > 
< > ```yaml
< > author:
< >   - name: "Name"
< >     affiliation: "Universität XYZ"
< > ```
< > 
< > _Wenn nur 1 Autor bei einer Institution ist, kann diese Kurznotation verwendet
< > werden_
< > 
< > ### Abstract
< > 
< > Ein kurzer Zusammenfassung des Inhalts kann über das `abstract`-Tag hinzugefügt
< > werden:
< > 
< > ```yaml
< > abstract: |
< >   Dies ist ein Beispiel für einen Abstract.
< >   Mehrere Zeilen sind möglich, da die Tilde (`|`) verwendet wird.
< > ```
< > 
< > ### Keywords
< > 
< > Schlüsselwörter können über das `keywords`-Array definiert werden:
< > 
< > ```yaml
< > keywords:
< >   - Schlüsselwort1
< >   - Schlüsselwort2
< >   - Schlüsselwort3
< > ```
< > 
< > ### Bibliographie
< > 
< > Die Quellenverweise werden in einer separate Datei gespeichert (z.B.
< > `referenzen.json` oder `references.bib`). Diese wird über das `bibliography`-Tag
< > referenziert:
< > 
< > ```yaml
< > bibliography:
< >   - assets/referenzen.json
< >   - assets/references.bib
< > ```
< > 
< > ### Lizenz
< > 
< > Die Lizenz der Publikation kann über das `license`-Tag angegeben werden:
< > 
< > ```yaml
< > license: https://creativecommons.org/licenses/by/4.0/
< > ```
< > 
< > Reine Text-Angaben sind auch möglich. Wenn die Publikation nur zu HTML übersetzt
< > werden soll, kann hier auch HTML genutzt werden:
< > 
< > ```yaml
< > license: "Redaktion Clio-Online 2024. Alle Rechte vorbehalten."
< > ```
< > 
< > ### Weitere Infos
< > 
< > Viele Weitere Informationen und ausführliche Anleitungen im
< > [Quarto-Guide](https://quarto.org/docs/authoring/front-matter.html).
< > 
< > ## Anhang
< > 
< > ### Ausschreibung
< > 
< > > Zeitgenössische, datafizierte Geschichtswissenschaft bedarf neuer
< > > Publikationsformate für sogenannte _Data Stories_, die neben dem historischen
< > > Narrativ beispielsweise auch Code und Visualisierungen enthalten und die nicht
< > > mehr notwendig ausschließlich linear gelesen werden müssen. Als erste
< > > Beispiele der Implementation solcher Ideen seien hier das
< > > ["Journal of Digital History"](https://journalofdigitalhistory.org/en/articles),
< > > ["Distill"](https://distill.pub/) und Refqa Abu-Remailehs Buch _Country of
< > > Words: A Transnational Atlas for Palestinian Literature_ (Stanford: Stanford
< > > University Press, 2023, <https://doi.org/10.21627/2023cw>) erwähnt.  
< > > Im Rahmen des Methods Innovation Lab des Konsortiums NFDI4Memory wird am
< > > Lehrstuhl Digital History an der Humboldt-Universität zu Berlin ein
< > > Werkvertrag ausgeschrieben.
< > >
< > > ### Die erwarteten Leistungen beinhalten
< > >
< > > - Layout und UX für solche Data Stories.
< > > - Das Layout soll die vorhandene visuelle Sprache der Clio Guides
< > >   (<https://guides.clio-online.de>) aufgreifen.
< > > - Dabei sollen folgende Grundlagen beachtet werden:
< > >   1. Regeln zur Barrierefreiheit. Siehe dafür beispielsweise
< > >      [Accessible Rich Internet Applications (ARIA)](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA),
< > >      [Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA)](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics)
< > >   1. Die
< > >      "[Endings Principles for Digital Longevity](https://endings.uvic.ca/principles.html)".
< > > - Als technische Grundlage für die Umsetzung wird ein System aus Markdown
< > >   Dateien mit Codezellen (wie z.B. in RMarkdown oder Jupyter Notebooks) als
< > >   _single point of truth_ verwendet, die dann durch Pandoc in eine Kombination
< > >   von HTML, CSS, und JavaScript transformiert werden.  
< > >   Für diese müssen entsprechende Templates bereitgestellt werden.
< > >
< > > Die Umsetzung kann ab sofort beginnen und soll möglichst bis **Mitte Dezember
< > > 2024** (Datum der Rechnungslegung) abgeschlossen sein.
< > >
< > > Der Auftrag wird durch den Bereich Digital History an der Humboldt-Universität
< > > zu Berlin betreut und Ansprechpartner_innen stehen jederzeit zur Verfügung.
< > > Nach einer Einführung wird eigenständiges Arbeiten vertrauensvoll
< > > vorausgesetzt. Es gibt keine Präsenzpflicht, sondern die Tätigkeit kann
< > > ortsunabhängig durchgeführt werden.
< 
< ---
< 
< ## Issues
< 
< ### Clio-Template auf quarto portieren
< 
< Status: opened
< 
< Momentan ist das Clio-Template "nur" auf pandoc. Das muss auf quarto portiert werden - sprich die vorhandenen templates/javascript in die entsprechenden quarto-templates portieren.
< 
< ### Use of the Pandoc templates with a Quarto pipeline
< 
< Status: opened
< 
< We need to figure out ways how to use the Quarto pipeline with Pandoc templates. This is originally meant to accommodate (and thus salvage) the expensive Pandoc templates created by Uyen.
< 
< ### Aufräumen und Dokumentation
< 
< Status: opened
< 
< Alles in diesem Repo muss dokumentiert werden, wie wir es am 28. April besprochen haben.
< 
< ### Anzeigefehler bei Verlinkung in license
< 
< Status: opened
< 
< Bei der Verlinkung zur Clio-Redaktion ist irgendwo ein markdown-fehler. 
< Die Angaben im Yaml: 
< ``license: 'Redaktion: [clio.redaktion@geschichte.hu-berlin.de](mailto:clio.redaktion@geschichte.hu-berlin.de). Alle Rechte an Texten, Bildern und sonstigen Inhalten liegen bei Clio-online. (C) Clio-online 2002-2024``
< werden nicht richtig angezeigt.
< 
< ### Author - about
< 
< Status: opened
< 
< Beschreibungen der Autor:innen werden momentan nicht mit angezeigt
< 
< ### Abstract im HTML-Header
< 
< Status: opened
< 
< "abstract" im YAML gibt den Abstract. Der muss in den HTML-Header
< 
< ### Keywords im HTML-Header
< 
< Status: opened
< 
< Im YAML gibt es "keywords". Die müssen in den <header> in den korrekten TAG.
< 
< ### List Institutions
< 
< Status: opened
< 
< "institute"-Key im Yaml listet die Institutions auf. Muss dargestellt/linkbar sein.
< 
< ### Author - Institute
< 
< Status: opened
< 
< An author can have one or more "institute" ⇒ Links to list of institutions / Flyover
< 
< ### Correspondence-Author hervorheben / Korrespondenzmail verlinken
< 
< Status: opened
< 
< Ein Author kann die Eigenschaft 'correspondence: "yes"' haben und hat dann auch eine Email gesetzt.
< Dies soll dargestellt werden.
< 
< Test: ∃ Author mit 'correspondence: "yes"', ∃ Author ohne ⇒ Beides wird korrekt dargestellt
< 
< ### Mehrere Autoren richtig anzeigen
< 
< Status: opened
< 
< - Tool-Registry-Paper hat mehrere Autoren. Diese werden momentan nicht angezeigt, da von nur 1 Author ausgegangen wird.
< 
< ### Zitierungen im Popup analog zu Fußnoten öffnen
< 
< Status: opened
< 
< - Cites sind unten als "#ref-....# hinterlegt, die Cite-Stellen haben "data-cites" mit entsprechenden Einträgen
< - [ ] Bei klick via JS flyover oder Block-Element (mobile) hinzufügen.
< - [ ] CSS "hübsch" machen
Nur in quarto/data-stories: Pandoc Templates.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/data-stories/story_lod-geschichtswissenschaften.qmd quarto/data-stories/story_lod-geschichtswissenschaften.qmd
2c2
< title: "Linked Open Data in den Geschichtswissenschaften (Data Stories)"
---
> title: "Data Stories / Linked Open Data in den Geschichtswissenschaften (Data Stories)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften"
>       icon: "gitlab"
11c11
< # Linked Open Data in den Geschichtswissenschaften (Data Stories)
---
> # Data Stories / Linked Open Data in den Geschichtswissenschaften (Data Stories)
14,20c14,17
< > title: "Data Story LOD Heraldik"
< > author: Till Grallert
< > date: 2025-05-06 
< > lang: 
< >     - en
< >     - de
< > tags:
---
> > title: "Data Stories / Linked Open Data in den Geschichtswissenschaften"
> > author: "Data Stories"
> > date: "2025-06-20"
> > lang: "de"
22,268d18
< > 
< > This repository is used to develop a data story for Linked Open Data with a focus on the [Digital Heraldry](https://digitalheraldry.org/) project. The data story is being developed as part of [NFDI4Memory](https://4memory.de/).
< > 
< > # Workflow
< > 
< > 1. Entwurfsphase: Markdown und Jupter Notebooks werden mit den Editors / IDEs der individuellen Wahl bearbeitet und mit `.git` versioniert.
< > 2. Editing: 
< >     - da es weiterhin keinen guten Markdown-Editor mit Unterstützung für kollaboratives Kommentieren gibt, transformieren wir alle `.md` in `.docx`
< >     - die `.docx` liegen in der HU Box und können synchron und kollaborativ bearbeitet werden.
< >     - am Ende von Bearbeitungssessions werden `.md` Abzüge erstellt und in `.git` versioniert.
< > 3. Copy-editing
< >     - Die  `.md` Abzüge müssen noch mit scripten oder regex nachbearbeitet werden, bevor sie in eine Pandoc-Pipeline eingespeist werden können.
< > 
< > ## Literaturverwaltung
< > 
< > Wir verwalten Literatur mit Zotero in der gemeinsamen Lehrstuhlbibliothek. Zur Markierung on relevanten References wird der Tag `writing: 2024 LOD`. Die informationen können dann als BibLaTeX exportiert und in diesem Repository unter `data-story/references.bib` gespeichert werden.
< > 
< > # Supported features
< > 
< > We use a pipeline of Quarto -> knittr -> pandoc to generate output based on markdown and executable code (Jupyter, RMarkdown).
< > 
< > ## Accronyms
< > 
< > Zur Markierung von Abkürzungen, wie [SPARQL]{.smallcaps} verwenden wir die Syntax für die Zuweisung von CSS Klassen zu Spans.
< > 
< > ## asides, callouts, etc.
< > 
< > Diese Klassen von `<div>` können alle auch kombiniert werden.
< > 
< > ### asides
< > 
< > Glossen werden mit der Klasse `aside` auf `<div>`s gemacht.
< > 
< > ::: aside
< > 
< > ![Dieses Bild taucht im Rand (Margin) auf und zeigt ein mögliches Beispiel für ein Bild in einem *aside* im Tufte-Layout.](data-story/images/2.2_diagram-graph-model-triple-with-classes-rdf.png){#fig-marginal}
< > 
< > :::
< > 
< > ### [callouts](https://quarto.org/docs/authoring/callouts.html)
< > 
< > There are five different types of callouts available.
< > 
< > - note
< > - warning
< > - important
< > - tip
< > - caution
< > 
< > The color and icon will be different depending upon the type that you select. See the following example
< > 
< > ::: { .callout-warning }
< > 
< > Achtung: Dies ist ein kurzer Callout mitten in der Einleitung, der verdeutlicht, wie Pandoc-Markdown Callouts genutzt werden können.
< > 
< > :::
< > 
< > ## [cross-references](https://quarto.org/docs/authoring/cross-references.html n)
< > 
< > Quarto uses a slightly different syntax for cross-references. Note that cross reference identifiers must start with their type (e.g. fig- or tbl-): `{#fig-something}` can be referenced as `[@fig-something]`.
< > 
< > ## images
< > 
< > We use standard Markdown syntax for embedding images. For automated numbering and cross references, we rely on the `pandoc-crossref` filter [@fig-2f0f].
< > 
< > ![Ein Bild](data-story/images/2.2_diagram-graph-model-triple-with-classes-rdf.png){#fig-2f0f}
< > 
< > ## Includes
< > 
< > One can either directly write into a single `qmd` file or include other files through built-in [Quarto functionality](https://quarto.org/docs/authoring/includes.html "Quarto Manual: includes").
< > 
< > ::: aside
< > Please note that file includes will cause havoc with
< > 
< > -   multiple YAML headers: the last value for every key in order of inclusion will take precedence.
< > -   duplicate note references: see the section on notes
< > -   relative paths in the included files will be interpreted as relative to the current file.
< > :::
< > 
< > {{< include drafts/1_Einführung_LOD-Data-Story.md >}} 
< > {{< include drafts/2_Technische-Grundprinzipien.md >}} 
< > {{< include drafts/3_Kurzeinführung-in-LOD_LOD-Data-Story.md >}} 
< > <!-- {{< include drafts/4_Durchführen-der-Abfragen.ipynb >}} --> 
< > {{< include drafts/5_Ausblick-und-weitere-Schritte.md >}} 
< > {{< include drafts/6_Literatur-und-weiterführende-Ressourcen.md >}}
< > 
< > ## hyper links
< > 
< > Write one list of all hyperlinks in your data story which you plan reusing. You can then use them throughout the project with the following syntax `[some text][link]`. Do NOT use footnotes for hyper links.
< > 
< > ## named entities and technical terms
< > 
< > Named entities and technical terms should be introduced/referenced/explained on their first occurrence. This is particularly relevant for technical terms. Make use of the syntax for a local library of links (see above). For software, we link to first and foremost to Wikidata as an authority file.
< > 
< > ## [notes](https://quarto.org/docs/authoring/markdown-basics.html#footnotes)
< > 
< > If you do not plan on re-using notes, use inline notes[^1]. Otherwise make sure to deploy some unique note references across the entire project[^2]
< > 
< > [^1]: such as this one
< > 
< > [^2]: some note with a unique note reference, which can be generated in a terminal with `$ head -c 2 /dev/urandom | xxd -p`
< > 
< > ## references
< > 
< > Please use BibLaTeX or CSL-JSON for your reference file. This can be automatically generated with Zotero and the BetterBibTeX add-on. To reference some entry from the reference file, use `[@key]`, e.g. [@HiltmannEtAl2025NER4allContextAll]. For a documentation of the syntax etc. see the [Pandoc manual](https://pandoc.org/MANUAL.html#citations).
< > 
< > ::: {#refs}
< > :::
< > 
< > ## tables
< > 
< > | Disziplin | Typische Fragestellungen | Anzahl Forscher:innen | Schwerpunkt |
< > |:----------------|:--------------------:|----------------:|----------------:|
< > | Geschichtswissenschaft | Entwicklung über Zeiträume | 100 | Chronologie |
< > | Kommunikationswissenschaft | Medienwirkung, Mediennutzung | 200 | Theorienutzung |
< > | Soziologie | Gesellschaftliche Rahmenbedingungen | 150 | Soziale Strukturen |
< > 
< > : Vergleich verschiedener Disziplinen {#tbl-1}
< > 
< > # Code requirements
< > 
< > ## Conda Environment
< > 
< > For all tasks in this repository, the conda environment `4memory-data-story_env` is being used. This environment can be recreated with either `requirements.txt` or `environment.yml`.
< > 
< > - [ ] switch to standard python environment
< 
< ---
< 
< ## Issues
< 
< ### Review des ersten Entwurfs
< 
< Status: opened
< 
< Dieses Issue verfolgt den Stand des Reviews des ersten Drafts. Dieses findet in DOCX Dateien in der HU Box statt, da sich dieses besser für die Annotation nutzen lässt, als Markdowndateien.
< 
< 1. Einleitung
<     - [x] Review durch Till
<     - [ ] Überarbeitung durch Philipp
< 2. Konzeptualisierung von Wissen als Graph
<     - [x] Review durch Till
<     - [ ] Überarbeitung durch Philipp
< 2. Kurzeinführung in RDF
<     - [x] Review durch Till
<     - [x] Überarbeitung durch Philipp
<         - [ ] Bildbeschreibungen nochmal prüfen und ggbf. korrigieren (@schnephi)
< 3. Kurzeinführung in LOD
<     - [x] Review durch Till
<     - [x] Überarbeitung durch Philipp
< 4. Durchführen der Abfragen
<     - [ ] Review durch Till
<     - [x] Überarbeitung durch Philipp
< 6. Ausblick und weitere Schritte
<     - [x] Review durch Till
<     - [ ] Überarbeitung durch Philipp
< 
< ### Unify terminology
< 
< Status: opened
< 
< Dieses Issue soll den Gebrauch von Terminologie verfolgen
< 
< 
< - [-] Wissensgraph anstelle von Knowledge Graph
< - [x] "Heiliges Römisches Reich" anstelle von "Altes Reich"
< 
< ### tabbed display of code and results
< 
< Status: opened
< 
< We need to figure out how to set up the tabbed display of code and results in Quarto
< 
< ### Verweise auf Software: Links zu Wikidata
< 
< Status: opened
< 
< Auch um unsere Tool Registry zu nutzen und zu verbessern, möchten wir sämtliche Software mit Verweisen auf Wikidata verlinken. Zur Recherche bietet sich neben Wikidata selbst auch https://furesh.github.io/tool-storage-interface/ an.
< 
< ### Support für breite Tabellen
< 
< Status: opened
< 
< Philipps Text enthält sehr breite Tabellen (i.e. viele Spalten) und diese werden im Standardlayout von Quarto nicht richtig unterstüzt. Hier benötigen wir Ideen und eine Implementation.
< 
< ### Code highlighting für SPARQL
< 
< Status: opened
< 
< Wir benötigen einen funktionalen Codehighlighter für SPARQL.
< 
< ### Literaturverweise: fehlen durchgängig
< 
< Status: opened
< 
< Es gibt im gesamten Text, jenseits eine kurzen Bibliographie in Teil 6, keine Verweise auf Literatur.
< 
< ### Eindeutige Fußnoten Keys
< 
< Status: opened
< 
< Damit die Dateien sauber gerendert werden können, müssen Fußnoten einen eindeutigen Key haben. Dafür gibt es zwei Lösungen:
< 
< 1. If you do not plan on re-using notes, use inline notes^[such as this one]. 
< 2. Otherwise make sure to deploy some unique note references across the entire project[^8b70]
< 
< [^8b70]: some note with a unique note reference, which can be generated in a terminal with `$ head -c 2 /dev/urandom | xxd -p`
< 
< ### Keine Fußnoten für Hyperlinks
< 
< Status: opened
< 
< Hyperlinks werden mit der relevanten Syntax direkt in den Text geschrieben und nicht in Fußnoten. Literaturverweise für Software (die bevorzugte Art und Weise) erfolgen in der gängigen Syntax für solche Verweise.
< 
< ### IDs für Abbildungen, Tabellen etc.
< 
< Status: opened
< 
< Damit Abbildungen automatisch nummeriert und klick-bare Querverweise gemacht werden können, benötigen wir IDs. Diese folgen der Syntax von `pandoc-crossref`, die auch in Quarto implementiert ist:
< 
< ```md
< ![Bildbeschreibung](../images/5_screenshot-palladio-gallery-dataview.png){#fig:palladio-gallery}
< ```
< 
< der String nach `#fig:` ist ein alphanummerischer String deiner Wahl. Er muss nur eindeutig sein.
< 
< ### Abbildungen: Bildunterschriften hinzufügen
< 
< Status: opened
< 
< Bei den Abbildungen fehlen richtige Bildunterschriften. Diese sind momentan noch die Pfade der Dateien:
< 
< ```md
< ![../images/5_screenshot-palladio-gallery-dataview.png](../images/5_screenshot-palladio-gallery-dataview.png)
< ```
< 
< Dies sollte so geändert werden:
< 
< ```md
< ![Bildbeschreibung ...](../images/5_screenshot-palladio-gallery-dataview.png)
< ```
< 
< ### BibLaTeX Datei mit der Bibliographie fehlt
< 
< Status: closed
< 
< Damit die Literaturverweise auch gerendert werden können, benötigen wir eine BibLaTeX Datei, die aus Zotero heraus erzeugt werden kann.
Nur in quarto/: fullwidth.lua.
Nur in quarto/: .gitignore.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/index.qmd quarto/index.qmd
2c2
< title: "Gitlab-Übersicht"
---
> title: Gitlab-Übersicht
7,72c7
< ### Methodenlabor
< 
< | Repository | Typ | Wichtigkeit | Dringlichkeit | Letzte Aktivität | Betreuung/Autoren | Status | Todos |
< | --- | --- | --- | --- | --- | --- | --- | --- |
< | [data_field-survey](methodenlabor/data_field-survey.qmd) | data | ★★★★★ | ★★★☆☆ | 2025-06-18 | Till Grallert | in progress | ☑: 1; ☒: 2 |
< | [FS_documentation](methodenlabor/fs_documentation.qmd) | writing | ★★★★☆ | ★★★☆☆ | 2025-06-18 | Till Grallert | - | ☑: 1 |
< | [p_gitlab-overviewer](methodenlabor/p_gitlab-overviewer.qmd) | code | ★★★★☆ | ★☆☆☆☆ | 2025-06-19 | Till Grallert | in Development | ☑: 15; ☒: 1 |
< | [data_dfg-gepris](methodenlabor/data_dfg-gepris.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | done | from README: 2 lines |
< | [data_ZfDG](methodenlabor/data_zfdg.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | done | from README: 2 lines |
< | [fs_sparql](methodenlabor/fs_sparql.qmd) | code | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | - | ?⃞ |
< | [sources_sparql](methodenlabor/sources_sparql.qmd) | code | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | - | ☒: 1 |
< | [TR_data](methodenlabor/tr_data.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | draft | ☒: 1 |
< | [TR_sparql](methodenlabor/tr_sparql.qmd) | code | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | production | from README: 2 lines |
< | [Writing](methodenlabor/writing.qmd) | writing | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | in progress | from README: 2 lines |
< | [writing_dh-personae](methodenlabor/writing_dh-personae.qmd) | writing | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert; Jascha Merijn Schmitz | published | ☒: 1 |
< | [data_DHConferences](methodenlabor/data_dhconferences.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | done | ☒: 1 |
< | [data_DHd](methodenlabor/data_dhd.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | done | ☑: 2 |
< | [data_DHQ](methodenlabor/data_dhq.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | done | ☒: 1 |
< | [data_tool-registries](methodenlabor/data_tool-registries.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-18 | Till Grallert | done | ☑: 7; ☒: 1 |
< | [Podcast](methodenlabor/podcast.qmd) | - | — | — | 2025-06-18 | Till Grallert | initial planning... | ☑: 2; ☒: 7 |
< | [Documentation](methodenlabor/doc_documentation.qmd) | - | — | — | 2025-06-17 | Till Grallert | - | ☑: 2; ☒: 10 |
< | [p_publish2wikidata](methodenlabor/p_publish2wikidata.qmd) | - | — | — | 2025-06-17 | Authors: Till Grallert; Isabell Trilling | draft | ☑: 1; ☒: 4 |
< | [![Avatar](https://scm.cms.hu-berlin.de/uploads/-/system/project/avatar/9154/Logo.jpg){width=16px} data_tool-registry](methodenlabor/data_tool-registry.qmd) | - | — | — | 2025-06-16 | Authors: Till Grallert; Nicole Dresselhaus | in Production | from README: 2 lines |
< | [podcast_digital-hist…](methodenlabor/podcast_digital-history-deleted-10146.qmd) | - | — | — | 2025-06-13 | - | - | ?⃞ |
< | [![Avatar](https://scm.cms.hu-berlin.de/uploads/-/system/project/avatar/9083/Logo.jpg){width=16px} p_wikidata2gitlab](methodenlabor/p_wikidata2gitlab.qmd) | - | — | — | 2025-06-11 | Authors: Till Grallert; Nicole Dresselhaus | - | ☑: 2 |
< | [data_tool-registry-d…](methodenlabor/data_tool-registry-dump.qmd) | - | — | — | 2025-01-16 | Authors: Till Grallert; Nicole Dresselhaus | - | ☑: 7; ☒: 2 |
< | [Gitlab Runner Docker…](methodenlabor/gitlab-runner-docker-compose-scm-version.qmd) | - | — | — | 2025-01-15 | - | - | ?⃞ |
< | [p_zotero2wikidata](methodenlabor/p_zotero2wikidata.qmd) | - | — | — | 2024-05-24 | Authors: Isabell Trilling | draft | ☑: 1 |
< | [p_bots_social-media](methodenlabor/p_bots_social-media.qmd) | - | — | — | 2024-04-04 | - | - | ☒: 4 |
< | [data_DFGProjects](methodenlabor/data_dfgprojects.qmd) | - | — | — | 2024-03-20 | - | - | ☒: 1 |
< | [TR_publications](methodenlabor/tr_publications.qmd) | - | — | — | 2024-03-20 | - | - | ?⃞ |
< 
< Note: If no supervisors were found, authors of the README are named as supervisors.
< 
< ### templates
< 
< | Repository | Typ | Wichtigkeit | Dringlichkeit | Letzte Aktivität | Betreuung/Autoren | Status | Todos |
< | --- | --- | --- | --- | --- | --- | --- | --- |
< | [code-project-templat…](methodenlabor/templates/code-project-template.qmd) | code | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-19 | Your Name | initial planning... | ☒: 2 |
< | [Data Project Templat…](methodenlabor/templates/data-project-template.qmd) | data | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-19 | Your Name | initial planning... | from README: 2 lines |
< | [writing project temp…](methodenlabor/templates/template_writing-project.qmd) | writing | ★☆☆☆☆ | ★☆☆☆☆ | 2025-06-19 | Your Name | initial planning... | ☒: 6 |
< 
< Note: If no supervisors were found, authors of the README are named as supervisors.
< 
< ### Data Stories
< 
< | Repository | Typ | Wichtigkeit | Dringlichkeit | Letzte Aktivität | Betreuung/Autoren | Status | Todos |
< | --- | --- | --- | --- | --- | --- | --- | --- |
< | [Linked Open Data in …](data-stories/story_lod-geschichtswissenschaften.qmd) | - | — | — | 2025-06-20 | Authors: Till Grallert | - | ☑: 1; ☒: 11 |
< | [Pandoc Templates](data-stories/pandoc-templates.qmd) | - | — | — | 2025-05-12 | Authors: Nicole Dresselhaus | - | ☒: 12 |
< | [Documentation for Da…](data-stories/ds_documentation.qmd) | - | — | — | 2025-03-13 | Authors: Till Grallert | - | ☒: 2 |
< 
< Note: If no supervisors were found, authors of the README are named as supervisors.
< 
< ### Tool Registry for Digital Humanities
< 
< | Repository | Typ | Wichtigkeit | Dringlichkeit | Letzte Aktivität | Betreuung/Autoren | Status | Todos |
< | --- | --- | --- | --- | --- | --- | --- | --- |
< | [Papers](tool-registry-dh/papers.qmd) | - | — | — | 2025-05-14 | Authors: Claus-Michael Schlesinger; Till Grallert | - | ☑: 4 |
< 
< Note: If no supervisors were found, authors of the README are named as supervisors.
< 
< 
< ## Group Methodenlabor
< 
< ### data_dfg-gepris
---
> ### Podcast
77,106c12
< Status
< : done
< 
< Supervisors
< : Till Grallert
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris/-/releases)
< 
< > [!tip] to do  
< >   
< > [x] first scrape of all projects  
< > [x] first scrape of all people from project pages  
< > Problem: I missed some relationships in my initial code  
< > [x] second scrape of people trying to catch as many functions and positions as possible  
< > [ ] first scrape of personal details  
< 
< > [!note] Todo/Status (parsed)  
< > Status
< > : done
< 
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris/-/blob/main/README.md)
< 
< ### data_DFGProjects
< 
< Date
< : 2024-03-20
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/releases)
108c14
< > [!tip] Getting started  
---
> > [!tip] Description  
110,111c16,19
< > To make it easy for you to get started with GitLab, here's a list of recommended next steps.  
< > Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!  
---
> > ---
> title: "NFDI4Memory Audiogesprächsformat"
> description: |
>   Transkriptionen und Begleittexte für ...
115c23,31
< > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/issues/1)
---
> > - [Blogpost o.ä.](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/10)
> > - [Social Media Posts](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/9)
> > - [Ausspielung](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/issues/8)
> > - [Veröffentlichung](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/7)
> > - [Liste der Teilnehmer_innen komplettieren](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/6)
> > - [Begleittext schreiben](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/5)
> > - [Audiodatei schneiden](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/4)
> > - [Probefolge produzieren](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/issues/3)
> > - [Template an die Erfordernisse eines Schreibprojektes anpassen](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/issues/1)
117c33
< > TOTAL: opened: 1
---
> > TOTAL: opened: 9
119c35
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/blob/main/README.md)
121c37
< ### data_DHConferences
---
> ### podcast_digital-history-deleted-10146
124c40
< : 2025-06-18
---
> : 2025-06-13
126,127c42
< Status
< : done
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/podcast_digital-history-deleted-10146/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/podcast_digital-history-deleted-10146/-/releases)
129,130c44
< Supervisors
< : Till Grallert
---
> ### writing_dh-personae
131a46,47
> Date
> : 2025-06-18
133c49
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/releases)
136a53,56
> > ---
> title: "writing_dh-personae"
> description: |
>   UX Personae als Ergebnis eines Workshops beim NFDI...
140c60
< > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/issues/1)
---
> > - [Template an die Erfordernisse eines Schreibprojektes anpassen](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/issues/1)
144c64
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/blob/main/README.md)
146c66
< ### data_DHd
---
> ### p_gitlab-overviewer
149,156c69
< : 2025-06-18
< 
< Status
< : done
< 
< Supervisors
< : Till Grallert
< 
---
> : 2025-06-19
158c71
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/releases)
162c75,78
< > Data: abstracts from the annual DHd conferences  
---
> > ---
> title: "Gitlab Overviewer"
> description: |
>   Collect `README.md`s on all GitLab-Repositories from...
166c82,97
< > Keine offenen mehr Issues vorhanden
---
> > - [Dokumentation & Beispiele](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/16)
> > - [Flexible Sortierlogik für alle Spalten (inkl. Kombinationen)](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/15)
> > - [Dynamische Tabellenerstellung anhand der Konfiguration](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/14)
> > - [Auslagerung der Tabellenspalten-Definition in eine Konfigurationsdatei](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/13)
> > - [CLI-Parser für Sortier- und Konfigurationsparameter](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/12)
> > - [Flexible Sortierung und Spaltenkonfiguration für Übersichtstabellen](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/11)
> > - [Feature: Link Repos in summary table](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/10)
> > - [Support the YAML keys for priority and urgency](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/9)
> > - [Add key values to Readmes of the templates](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/work_items/8)
> > - [Klassifikation nach Wichtigkeit](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/7)
> > - [Klassifikation nach Repoart in der Übersichtstabelle](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/6)
> > - [Mehr als 1 API-Key](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/5)
> > - [Anzahl offener Issues in der Zusammenfassung](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/4)
> > - [Supervisor statt Autor](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/3)
> > - [Issue-Templates .gitlab-Verzeichnis durchgehen.](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/2)
> > - [Docs: Update Documentation Templates](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/1)
168c99
< > TOTAL: closed: 2
---
> > TOTAL: opened: 16
170c101
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/blob/main/README.md)
172c103
< ### data_DHQ
---
> ### Documentation
175,182c106
< : 2025-06-18
< 
< Status
< : done
< 
< Supervisors
< : Till Grallert
< 
---
> : 2025-06-17
184c108
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/releases)
188c112,115
< > DHQ: articles and metadata  
---
> > ---
> title: Good™ Documentation
> description: |
>   Dieses Repository enthält eine Beispielstruktur, nac...
192c119,130
< > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/issues/1)
---
> > - [Sprachliche/Inhaltliche Bemerkungen](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/12)
> > - [Experiment: Code-Projekt-Template so nutzbar?](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/11)
> > - [Lizenz wählen](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/10)
> > - [Erstellung Review-Template](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/9)
> > - [Review zu Anleitung Template-Repo/Umfang Template-Repo](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/8)
> > - [Weitere Literatur rezepieren und einarbeiten](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/7)
> > - [Literaturverweise und Links](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/6)
> > - [Empfehlungen aus Background auf dieses Repo selbst anwenden](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/5)
> > - [Code so dokumentieren, dass er ausgeführt werden kann](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/4)
> > - [Default-Issues in Templates anlegen](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/3)
> > - [Example-project in .templates verschieben und hier nur noch verlinken](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/2)
> > - [create `example-data` for data-repositories](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/1)
194c132
< > TOTAL: opened: 1
---
> > TOTAL: opened: 12
196c134
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/blob/main/README.md)
198c136
< ### data_field-survey
---
> ### Writing
203,204c141
< Status
< : in progress
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/releases)
206,207c143,149
< Supervisors
< : Till Grallert
---
> > [!tip] Description  
> >   
> > ---
> title: "writing"
> subtitle: ""
> description: |
>   smaller pieces of writing that originate from the...
208a151
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/blob/main/README.md)
210c153,158
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/releases)
---
> ### Gitlab Runner Docker Compose - SCM-Version
> 
> Date
> : 2025-01-15
> 
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version/-/releases)
213a162
> > # GitLab Runner with Docker Compose
215,220c164
< > [!note] Open Issues  
< >   
< > - [HSozKult: basalen Datensatz für Events publizieren](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/issues/3)
< > - [Datenmodell für Events etablieren](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/issues/2)
< >   
< > TOTAL: closed: 1; opened: 2
---
> This guide provides instructions on how to set up and run a Git...
222c166
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version/-/blob/main/README.md)
224c168
< ### data_tool-registries
---
> ### data_dfg-gepris
229,236c173
< Status
< : done
< 
< Supervisors
< : Till Grallert
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris/-/releases)
240,246c177,181
< > Data from existing tool registries  
< 
< > [!note] Open Issues  
< >   
< > - [Löschen von deprecated tools](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/5)
< >   
< > TOTAL: closed: 7; opened: 1
---
> > ---
> title: "DFG GEPRIS data base"
> subtitle: "notes on data and infrastructure"
> date: 2024-12-10
> auth...
248c183
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris/-/blob/main/README.md)
250c185
< ### ![Avatar](https://scm.cms.hu-berlin.de/uploads/-/system/project/avatar/9154/Logo.jpg){width=24px} data_tool-registry
---
> ### data_ZfDG
253,261c188
< : 2025-06-16
< 
< Status
< : in Production
< 
< Authors
< : Till Grallert
< : Nicole Dresselhaus
< 
---
> : 2025-06-18
263c190
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg/-/releases)
267,271c194,200
< > Periodically pull data from Wikidata to GitLab, release, and push to Zenodo  
< 
< > [!note] Todo/Status (parsed)  
< > Status
< > : in Production
---
> > ---
> title: "data_zfdg"
> subtitle: ""
> description: |
>    Full text files for ZfDG
> date: 2025-06-18 
> aut...
273c202
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg/-/blob/main/README.md)
275c204
< ### data_tool-registry-dump
---
> ### FS_documentation
278,283c207
< : 2025-01-16
< 
< Authors
< : Till Grallert
< : Nicole Dresselhaus
< 
---
> : 2025-06-18
285c209
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/releases)
287c211
< > [!tip] Was machen wir?  
---
> > [!tip] Description  
289,299c213,216
< > Als Teil der [Tool Registry][toolregistry] bzw. jeden Forschungsprojekts, das  
< > Daten auf [Wikidata][wikidata] publiziert, müssen wir regelmäßig **unseren**  
< > kompletten Datensatz von Wikidata ziehen und in einem Versionskontrollsystem  
< > ablegen, um ihn dann als stabilen und referenzierbaren Datensatz publizieren und  
< > archivieren bzw. wieder in Linked-Open-Data Umgebungen und Triple Stores  
< > einspeisen zu können.  
< > Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,  
< > die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert  
< > werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet  
< > automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs  
< > geändert haben, es Störungen in der Internetverbindung gab, etc.).  
---
> > ---
> subtitle: "README"
> title: "Documentation of our Field Survey of (Digital) History"
> date: 2025-06...
303,304c220
< > - [Improve releases](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/6)
< > - [Add option to filter for items modified within a specified period](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/5)
---
> > - [Recherche der Expertendatenbank von Hermes](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/issues/1)
306c222
< > TOTAL: closed: 7; opened: 2
---
> > TOTAL: opened: 1
308c224
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/blob/main/README.md)
310c226
< ### data_ZfDG
---
> ### jaraid_data
313c229
< : 2025-06-18
---
> : 2025-06-15
315,316c231
< Status
< : done
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/jaraid-data/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/jaraid-data/-/releases)
318,319c233,237
< Supervisors
< : Till Grallert
---
> > [!tip] Description  
> >   
> > ---
> title: "Periodic data pulls of bibliographic data for Arabic periodicals from Wikidata"
> author: ...
320a239
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/jaraid-data/-/blob/main/README.md)
322c241,246
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg/-/releases)
---
> ### data_tool-registry
> 
> Date
> : 2025-06-16
> 
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry/-/releases)
326c250,254
< > Full text files for ZfDG  
---
> > ---
> author:
>   - name: Till Grallert
>     affiliation: Humboldt-Universität zu Berlin
>     email: till....
328,332c256
< > [!note] Todo/Status (parsed)  
< > Status
< > : done
< 
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry/-/blob/main/README.md)
334c258
< ### Documentation
---
> ### p_wikidata2gitlab
337,341c261
< : 2025-06-17
< 
< Supervisors
< : Till Grallert
< 
---
> : 2025-06-11
343c263
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/releases)
347c267,271
< > Dieses Repository enthält eine Beispielstruktur, nach welchen Regeln und in welcher Ausführlichkeit sinnvoll dokumentiert werden sollte.  
---
> > ---
> author:
>   - name: Till Grallert
>     affiliation: Humboldt-Universität zu Berlin
>     email: till....
351,360c275,276
< > - [Sprachliche/Inhaltliche Bemerkungen](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/12)
< > - [Experiment: Code-Projekt-Template so nutzbar?](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/11)
< > - [Lizenz wählen](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/10)
< > - [Erstellung Review-Template](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/9)
< > - [Review zu Anleitung Template-Repo/Umfang Template-Repo](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/8)
< > - [Weitere Literatur rezepieren und einarbeiten](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/7)
< > - [Literaturverweise und Links](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/6)
< > - [Empfehlungen aus Background auf dieses Repo selbst anwenden](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/5)
< > - [Code so dokumentieren, dass er ausgeführt werden kann](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/4)
< > - [create `example-data` for data-repositories](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/issues/1)
---
> > - [Sicherung des Subgraphen](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/issues/2)
> > - [Create a data repository for our tool registry by forking this repo](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/issues/1)
362c278
< > TOTAL: closed: 2; opened: 10
---
> > TOTAL: opened: 2
364c280
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/blob/main/README.md)
366c282
< ### FS_documentation
---
> ### sources_sparql
371,375c287
< Supervisors
< : Till Grallert
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/releases)
377c289
< > [!tip] WikiProject  
---
> > [!tip] Description  
379c291,297
< > The public facing part of the documentation can be found on the projects' [WikiProject][wikiproject]. The source files for this WikiProject are maintained in the folder `WikiProject/`.  
---
> > ---
> title: "sources_sparql"
> date: 2025-06-18 
> author: 
>   - name: Till Grallert
>     institute: 
>      ...
383c301
< > Keine offenen mehr Issues vorhanden
---
> > - [HTML Frontend for adapting SPARQL queries](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/issues/1)
385c303
< > TOTAL: closed: 1
---
> > TOTAL: opened: 1
387c305
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/blob/main/README.md)
394,397d311
< Supervisors
< : Till Grallert
< 
< 
400c314
< > [!tip] Components  
---
> > [!tip] Description  
402,405c316,319
< > The `SELECT` queries in this repository make use of a number of modular subqueries (or components).  
< 
< > [!warning] Todo/Status  
< > Kein aktueller Stand verfügbar/gefunden
---
> > ---
> subtitle: "README"
> title: "SPARQL Queries for a Field Survey of (Digital) History"
> date: 2025-05...
409,426c323
< ### Gitlab Runner Docker Compose - SCM-Version
< 
< Date
< : 2025-01-15
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version/-/releases)
< 
< > [!tip] GitLab Runner with Docker Compose  
< >   
< > This guide provides instructions on how to set up and run a GitLab Runner **ON THE HU SCM GITLAB** using Docker Compose. Follow these steps to get your GitLab Runner up and running seamlessly.  
< 
< > [!warning] Todo/Status  
< > Kein aktueller Stand verfügbar/gefunden
< 
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version/-/blob/main/README.md)
< 
< ### p_bots_social-media
---
> ### data_field-survey
429,430c326
< : 2024-04-04
< 
---
> : 2025-06-18
432c328
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/releases)
434c330
< > [!tip] Readme  
---
> > [!tip] Description  
436c332,338
< > No README found.  
---
> > ---
> title: "data_field-survey"
> subtitle: ""
> description: |
> date: 2025-05-20 
> author: 
>   - name: Till...
440,443c342,344
< > - [Einlesen Fediverse-Stream](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/4)
< > - [Einbettung in Infrastruktur](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/3)
< > - [Preprocessing Wikidata in Format für den Bot](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/2)
< > - [Recherche vorhandene Libraries für Interfacing mit Mastodon](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/1)
---
> > - [HSozKult: basalen Datensatz für Events publizieren](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/issues/3)
> > - [Datenmodell für Events etablieren](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/issues/2)
> > - [Dokumentation: ein kurzes Readme für den Datensatz schreiben](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/issues/1)
445c346
< > TOTAL: opened: 4
---
> > TOTAL: opened: 3
447c348
< [Link to full readme](None)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey/-/blob/main/README.md)
449c350
< ### p_gitlab-overviewer
---
> ### TR_data
452,462c353
< : 2025-06-19
< 
< Status
< : in Development
< 
< Version
< : 0.2
< 
< Supervisors
< : Till Grallert
< 
---
> : 2025-06-18
464c355
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/releases)
468c359,366
< > Collect `README.md`s on all GitLab-Repositories from AccessTokens and generate an overview.  
---
> > ---
> title: "tr_data"
> subtitle: ""
> description: |
>    some description 
> date: 2025-06-18 
> author: 
>   -...
472c370
< > - [Docs: Update Documentation Templates](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/issues/1)
---
> > - [Decide whether to delete this repo or not](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/issues/1)
474c372
< > TOTAL: closed: 15; opened: 1
---
> > TOTAL: opened: 1
476c374
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/blob/main/README.md)
478c376
< ### p_publish2wikidata
---
> ### TR_sparql
481,491c379
< : 2025-06-17
< 
< Status
< : draft
< 
< Authors
< : Till Grallert
< : Isabell Trilling
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/releases)
---
> : 2025-06-18
493,496c381
< > [!tip] Struktur  
< >   
< > `schemas/` Ordner mit den JSON Schemas für den Upload von Daten mithilfe von [OpenRefine](https://www.wikidata.org/wiki/Q5583871).  
< > Unterordner für einzelne Projekte  
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql/-/releases)
498,503c383
< > [!note] Open Issues  
< >   
< > - [Modellierung in QuickStatements](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/work_items/5)
< > - [Rechercher existierende Skripte auf GitHub etc.](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/work_items/4)
< > - [Write EntitySchemas](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/issues/3)
< > - [Script for translating BibLaTeX to Wikidata QuickStatements](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/issues/2)
---
> > [!tip] Description  
505c385,389
< > TOTAL: closed: 1; opened: 4
---
> > ---
> title: "SPARQL queries for the Tool Registry for Digital Humanities"
> date: 2024-04-17
> author: 
>  ...
507c391
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql/-/blob/main/README.md)
509c393
< ### ![Avatar](https://scm.cms.hu-berlin.de/uploads/-/system/project/avatar/9083/Logo.jpg){width=24px} p_wikidata2gitlab
---
> ### data_tool-registry-dump
512,517c396
< : 2025-06-11
< 
< Authors
< : Till Grallert
< : Nicole Dresselhaus
< 
---
> : 2025-01-16
519c398
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/releases)
521c400
< > [!tip] Was machen wir?  
---
> > [!tip] Description  
523,535c402,406
< > Als Teil der  
< > [Tool Registry](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities")  
< > bzw. jeden Forschungsprojekts, das Daten auf  
< > [Wikidata](https://wikidata.org/ "Wikidata") publiziert, müssen wir regelmäßig  
< > **unseren** kompletten Datensatz von Wikidata ziehen und in einem  
< > Versionskontrollsystem ablegen, um ihn dann als stabilen und referenzierbaren  
< > Datensatz publizieren und archivieren bzw. wieder in Linked-Open-Data Umgebungen  
< > und Triple Stores einspeisen zu können.  
< > Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,  
< > die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert  
< > werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet  
< > automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs  
< > geändert haben, es Störungen in der Internetverbindung gab, etc.).  
---
> > ---
> title: "Periodic data pulls from Wikidata to GitLab"
> author: 
>   - Till Grallert
>   - Nicole Dress...
539c410,418
< > Keine offenen mehr Issues vorhanden
---
> > - [$pv funktioniert nicht unter macOS](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/9)
> > - [Bash script: extracting of Wikidata  QID fails and thus the download](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/8)
> > - [remove API-call from bash](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/7)
> > - [Improve releases](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/6)
> > - [Add option to filter for items modified within a specified period](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/5)
> > - [Write documentation and a small tutorial](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/4)
> > - [Write GitLab or GitHub actions to automatically trigger a data dump](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/3)
> > - [Get data as RDF for import into LOD systems](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/2)
> > - [Dump-Infos sammeln, serialisierung erzeugen](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/issues/1)
541c420
< > TOTAL: closed: 2
---
> > TOTAL: opened: 9
543c422
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump/-/blob/main/README.md)
550,556d428
< Status
< : draft
< 
< Authors
< : Isabell Trilling
< 
< 
559c431
< > [!tip] Idee:  
---
> > [!tip] Description  
561,563c433,436
< > Import von bibliographischen Daten: Artikel als eigene Items bei Wikidata  
< > z.B. Verknüpfung dieser Items mit Methoden (wie z.B. TaDiRAH) und digital tools, die in den Artikeln genutzt oder/und thematisiert wurden  
< > Verknüpfung von Autor_Innen der Artikel mit Organisatoren/Projekten etc. die für die DH interessant sind  
---
> > ---
> title: "Readme: documentation for the Upload of Data from Zotero to Wikidata"
> subtitle: 
> author:...
567c440
< > Keine offenen mehr Issues vorhanden
---
> > - [Mapping von TEI/XML zu MODS](https://scm.cms.hu-berlin.de/methodenlabor/p_zotero2wikidata/-/issues/1)
569c442
< > TOTAL: closed: 1
---
> > TOTAL: opened: 1
573c446
< ### Podcast
---
> ### writing project template
576,583c449
< : 2025-06-18
< 
< Status
< : initial planning...
< 
< Supervisors
< : Till Grallert
< 
---
> : 2025-06-19
585c451
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/releases)
589c455,458
< > Transkriptionen und Begleittexte für das NFDI4Memory Audiogesprächsformat.  
---
> > ---
> title: "<Projektname>"
> description: |
>   Kurze Beschreibung (2-3 Sätze), was für Daten hier liege...
593,599c462,467
< > - [Blogpost o.ä.](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/10)
< > - [Social Media Posts](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/9)
< > - [Ausspielung](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/issues/8)
< > - [Veröffentlichung](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/7)
< > - [Liste der Teilnehmer_innen komplettieren](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/6)
< > - [Begleittext schreiben](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/work_items/5)
< > - [Probefolge produzieren](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/issues/3)
---
> > - [Setup: run script to clean the git history](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/work_items/7)
> > - [Set-up: script for cleaning git history](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/6)
> > - [Setup: Select a license](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/work_items/5)
> > - [Docs: Setup](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/4)
> > - [Issues müssen an dieses Template angepasst werden](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/2)
> > - [Docs: Template an die Erfordernisse eines Schreibprojektes anpassen](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/1)
601c469
< > TOTAL: closed: 2; opened: 7
---
> > TOTAL: opened: 6
603c471
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/podcast/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/blob/main/README.md)
605c473
< ### podcast_digital-history-deleted-10146
---
> ### Data Project Template
608,609c476
< : 2025-06-13
< 
---
> : 2025-06-19
611c478
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/podcast_digital-history-deleted-10146/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/podcast_digital-history-deleted-10146/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template/-/releases)
613c480
< > [!tip] Readme  
---
> > [!tip] Description  
615,618c482,485
< > No README found.  
< 
< > [!warning] Todo/Status  
< > Kein aktueller Stand verfügbar/gefunden
---
> > ---
> title: "<Projektname>"
> description: |
>   Kurze Beschreibung (2-3 Sätze), was für Daten hier liege...
620c487
< [Link to full readme](None)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template/-/blob/main/README.md)
622c489
< ### sources_sparql
---
> ### code-project-template
625,629c492
< : 2025-06-18
< 
< Supervisors
< : Till Grallert
< 
---
> : 2025-06-19
631c494
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/releases)
633c496
< > [!tip] Readme  
---
> > [!tip] Description  
634a498,501
> > ---
> title: "<Projektname>"
> description: |
>   Kurze Beschreibung (2-3 Sätze), was für Daten hier liege...
638c505,506
< > - [HTML Frontend for adapting SPARQL queries](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/issues/1)
---
> > - [Issue-Templates .gitlab-Verzeichnis durchgehen.](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/issues/2)
> > - [Docs: Update Documentation Templates](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/issues/1)
640c508
< > TOTAL: opened: 1
---
> > TOTAL: opened: 2
642c510
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/blob/main/README.md)
644c512
< ### TR_data
---
> ### Papers
647c515
< : 2025-06-18
---
> : 2025-05-14
649,650c517
< Status
< : draft
---
> [![Release](https://scm.cms.hu-berlin.de/tool-registry-dh/papers/-/badges/release.svg)](https://scm.cms.hu-berlin.de/tool-registry-dh/papers/-/releases)
652,653c519
< Supervisors
< : Till Grallert
---
> [Link to full readme](https://scm.cms.hu-berlin.de/tool-registry-dh/papers/-/blob/main/README.md)
654a521
> ### p_publish2wikidata
656c523,526
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/releases)
---
> Date
> : 2025-06-17
> 
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/releases)
660c530,535
< > some description   
---
> > ---
> title: "Readme: p_publish2wikidata"
> author: 
>   - Till Grallert
>   - Isabell Trilling
> date: 2024-1...
664c539,543
< > - [Decide whether to delete this repo or not](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/issues/1)
---
> > - [Modellierung in QuickStatements](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/work_items/5)
> > - [Rechercher existierende Skripte auf GitHub etc.](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/work_items/4)
> > - [Write EntitySchemas](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/issues/3)
> > - [Script for translating BibLaTeX to Wikidata QuickStatements](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/issues/2)
> > - [Field Survey: Issues with the current schema](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/issues/1)
666c545
< > TOTAL: opened: 1
---
> > TOTAL: opened: 5
668c547
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/tr_data/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/p_publish2wikidata/-/blob/main/README.md)
670c549
< ### TR_publications
---
> ### p_bots_social-media
673,674c552
< : 2024-03-20
< 
---
> : 2024-04-04
676c554
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_publications/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_publications/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/releases)
678c556
< > [!tip] Readme  
---
> > [!note] Open Issues  
680,685c558,563
< > No README found.  
< 
< > [!warning] Todo/Status  
< > Kein aktueller Stand verfügbar/gefunden
< 
< [Link to full readme](None)
---
> > - [Einlesen Fediverse-Stream](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/4)
> > - [Einbettung in Infrastruktur](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/3)
> > - [Preprocessing Wikidata in Format für den Bot](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/2)
> > - [Recherche vorhandene Libraries für Interfacing mit Mastodon](https://scm.cms.hu-berlin.de/methodenlabor/p_bots_social-media/-/issues/1)
> >   
> > TOTAL: opened: 4
687c565
< ### TR_sparql
---
> ### data_tool-registries
692,697c570
< Status
< : production
< 
< Supervisors
< : Till Grallert
< 
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/releases)
699c572,579
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql/-/releases)
---
> > [!tip] Description  
> >   
> > ---
> title: "data_tool-registries"
> subtitle: ""
> description: |
>    Data from existing tool registries
> ...
701c581
< > [!tip] SPARQL  
---
> > [!note] Open Issues  
703,715c583,592
< > Verschiedene Arten von SPARQL queries (`.rq`) generieren unterschiedliche Output Serialisierungen ([SPARQL 1.2 Dokumentation](https://w3c.github.io/sparql-query/spec/#QueryForms)):  
< > `SELECT`: "Returns all, or a subset of, the variables bound in a query pattern match."  
< > der default Output ist ein [SPARQL result XML](https://www.w3.org/TR/rdf-sparql-XMLres/) (`.srx`) im Namespace "http://www.w3.org/2005/sparql-results#".  
< > Laut Specs sind aber auch JSON, CSV oder TSV möglich  
< > `CONSTRUCT`: "Returns an RDF graph constructed by substituting variables in a set of triple templates."  
< > `ASK`: "Returns a boolean indicating whether a query pattern matches or not."  
< > `DESCRIBE`: "Returns an RDF graph that describes the resources found."  
< > der default Output ist RDF/XML  
< > ein basaler Beispielquery liegt unter <./describe/describe_tools.rq>  
< 
< > [!note] Todo/Status (parsed)  
< > Status
< > : production
---
> > - [Neue Tools anreichern](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/8)
> > - [Fehlende Beschreibungen im Datensatz](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/7)
> > - [Wikidata URLs in `ssh.desc`](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/6)
> > - [Löschen von deprecated tools](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/5)
> > - [Kuratorische Entscheidung: welche Tools sollen **NICHT** zu Wikidata hinzugefügt werden](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/4)
> > - [Edit field "wditem" for new items](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/3)
> > - [Improve processed data set by including the ssh.desc](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/2)
> > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/issues/1)
> >   
> > TOTAL: opened: 8
717c594
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registries/-/blob/main/README.md)
719c596
< ### Writing
---
> ### data_DFGProjects
722,729c599
< : 2025-06-18
< 
< Status
< : in progress
< 
< Supervisors
< : Till Grallert
< 
---
> : 2024-03-20
731c601
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/releases)
735,746c605
< > smaller pieces of writing that originate from the Methods Innovation Lab  
< 
< > [!note] Todo/Status (parsed)  
< > Status
< > : in progress
< 
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/blob/main/README.md)
< 
< ### writing_dh-personae
< 
< Date
< : 2025-06-18
---
> > # data_DFGProjects
748,749d606
< Status
< : published
751,753d607
< Supervisors
< : Till Grallert
< : Jascha Merijn Schmitz
754a609
> ## Getting started
756,760c611
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/releases)
< 
< > [!tip] Description  
< >   
< > UX Personae als Ergebnis eines Workshops beim NFDI4Memory Community Forum 2024 in Halle  
---
> To make it easy for you to get started with GitLab, here's...
764c615
< > - [Template an die Erfordernisse eines Schreibprojektes anpassen](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/issues/1)
---
> > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/issues/1)
768,770c619
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae/-/blob/main/README.md)
< 
< ## Group templates
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dfgprojects/-/blob/main/README.md)
772c621
< ### code-project-template
---
> ### data_DHConferences
775,782c624
< : 2025-06-19
< 
< Status
< : initial planning...
< 
< Supervisors
< : Your Name
< 
---
> : 2025-06-18
784c626
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/releases)
788c630,637
< > Kurze Beschreibung (2-3 Sätze), was für Daten hier liegen.  
---
> > ---
> title: "data_dhconferences"
> subtitle: ""
> description: |
>    
> date: 2024-11-20 
> author: 
>   - name:...
792,793c641
< > - [Issue-Templates .gitlab-Verzeichnis durchgehen.](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/issues/2)
< > - [Docs: Update Documentation Templates](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/issues/1)
---
> > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/issues/1)
795c643
< > TOTAL: opened: 2
---
> > TOTAL: opened: 1
797c645
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dhconferences/-/blob/main/README.md)
799c647
< ### Data Project Template
---
> ### data_DHQ
802,809c650
< : 2025-06-19
< 
< Status
< : initial planning...
< 
< Supervisors
< : Your Name
< 
---
> : 2025-06-18
811c652
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/releases)
815c656,662
< > Kurze Beschreibung (2-3 Sätze), was für Daten hier liegen.  
---
> > ---
> title: "data_dhq"
> subtitle: ""
> description: |
>    DHQ: articles and metadata
> date: 2024-11-20 
> au...
817,819c664,668
< > [!note] Todo/Status (parsed)  
< > Status
< > : initial planning...
---
> > [!note] Open Issues  
> >   
> > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/issues/1)
> >   
> > TOTAL: opened: 1
821c670
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dhq/-/blob/main/README.md)
823c672
< ### writing project template
---
> ### data_DHd
826,833c675
< : 2025-06-19
< 
< Status
< : initial planning...
< 
< Supervisors
< : Your Name
< 
---
> : 2025-06-18
835c677
< [![Release](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/releases)
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/releases)
839c681,685
< > Kurze Beschreibung (2-3 Sätze), was für Daten hier liegen.  
---
> > ---
> title: "data_dhd"
> subtitle: ""
> description: |
>    Data: abstracts from the annual DHd conferences...
843,848c689,690
< > - [Setup: run script to clean the git history](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/work_items/7)
< > - [Set-up: script for cleaning git history](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/6)
< > - [Setup: Select a license](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/work_items/5)
< > - [Docs: Setup](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/4)
< > - [Issues müssen an dieses Template angepasst werden](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/2)
< > - [Docs: Template an die Erfordernisse eines Schreibprojektes anpassen](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/issues/1)
---
> > - [download current DHd data](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/issues/2)
> > - [add documentation for this data set](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/issues/1)
850,852c692
< > TOTAL: opened: 6
< 
< [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/templates/template_writing-project/-/blob/main/README.md)
---
> > TOTAL: opened: 2
854c694
< ## Group Data Stories
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/data_dhd/-/blob/main/README.md)
856c696
< ### Documentation for Data Stories
---
> ### TR_publications
859c699
< : 2025-03-13
---
> : 2024-03-20
861,862c701
< Authors
< : Till Grallert
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_publications/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_publications/-/releases)
863a703
> ### TR_documentation
865c705,706
< [![Release](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/releases)
---
> Date
> : 2024-07-20
867,869c708
< > [!tip] Inhaltliche Ideen  
< >   
< > Inhaltliche Ideen werden über Issues gesammelt, die mit dem Label [Themenvorschlag](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/issues/?label_name%5B%5D=Themenvorschlag) versehen werden.  
---
> [![Release](https://scm.cms.hu-berlin.de/methodenlabor/tr_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/methodenlabor/tr_documentation/-/releases)
871,874c710
< > [!note] Open Issues  
< >   
< > - [Themenvorschlag: Zeitschriftenforschung und Impresso](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/issues/2)
< > - [Themenvorschlag: Quellcodekritik](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/issues/1)
---
> > [!tip] Description  
876c712,717
< > TOTAL: opened: 2
---
> > ---
> title: "Readme: documentation for the Tool Registry"
> subtitle: 
> author:
>     - Till Grallert
> date...
878c719
< [Link to full readme](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/methodenlabor/tr_documentation/-/blob/main/README.md)
880c721
< ### Linked Open Data in den Geschichtswissenschaften
---
> ### Documentation for Data Stories
883,899c724
< : 2025-06-20
< 
< Authors
< : Till Grallert
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/badges/release.svg)](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/releases)
< 
< > [!tip] Workflow  
< >   
< > Entwurfsphase: Markdown und Jupter Notebooks werden mit den Editors / IDEs der individuellen Wahl bearbeitet und mit `.git` versioniert.  
< > Editing:  
< > da es weiterhin keinen guten Markdown-Editor mit Unterstützung für kollaboratives Kommentieren gibt, transformieren wir alle `.md` in `.docx`  
< > die `.docx` liegen in der HU Box und können synchron und kollaborativ bearbeitet werden.  
< > am Ende von Bearbeitungssessions werden `.md` Abzüge erstellt und in `.git` versioniert.  
< > Copy-editing  
< > Die  `.md` Abzüge müssen noch mit scripten oder regex nachbearbeitet werden, bevor sie in eine Pandoc-Pipeline eingespeist werden können.  
---
> : 2025-03-13
901,915c726
< > [!note] Open Issues  
< >   
< > - [Review des ersten Entwurfs](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/12)
< > - [Unify terminology](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/11)
< > - [tabbed display of code and results](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/10)
< > - [Verweise auf Software: Links zu Wikidata](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/9)
< > - [Support für breite Tabellen](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/8)
< > - [Code highlighting für SPARQL](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/7)
< > - [Literaturverweise: fehlen durchgängig](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/6)
< > - [Eindeutige Fußnoten Keys](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/5)
< > - [Keine Fußnoten für Hyperlinks](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/4)
< > - [IDs für Abbildungen, Tabellen etc.](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/3)
< > - [Abbildungen: Bildunterschriften hinzufügen](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/issues/2)
< >   
< > TOTAL: closed: 1; opened: 11
---
> [![Release](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/badges/release.svg)](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/releases)
917c728
< [Link to full readme](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/blob/main/README.md)
---
> [Link to full readme](https://scm.cms.hu-berlin.de/data-stories/ds_documentation/-/blob/main/README.md)
924,927d734
< Authors
< : Nicole Dresselhaus
< 
< 
930,975d736
< > [!tip] Was befindet sich in diesem Repository  
< >   
< > Dieses Repository dient als Template-System für die Erstellung von Data Stories  
< > mit Pandoc und Quarto.  
< > Es besteht aus zwei Hauptkomponenten:  
< > **Pandoc-Templates** (im `converter`-Verzeichnis):  
< > Umwandelt Markdown-Dateien in HTML-Dokumente  
< > Verwendet Pandoc als Konverter  
< > Ermöglicht die Erstellung von professionellen Publikationen  
< > **Quarto-Templates** (im `quarto`-Verzeichnis):  
< > Bietet ein Template-System für Quarto-basierte Dokumente  
< > Unterstützt Markdown mit Codezellen  
< > Enthält vordefinierte Stile und Layouts  
< > Ermöglicht die Erstellung von hochwertigen HTML-Publikationen  
< > Das Projekt wurde im Rahmen des Methods Innovation Lab des  
< > NFDI4Memory-Konsortiums entwickelt. Es zielt darauf ab, neue Publikationsformate  
< > für datafizierte Geschichtswissenschaft zu ermöglichen, die neben traditionellen  
< > historischen Narrativen auch Code und Visualisierungen integrieren.  
< > Grundlage legte hier ein Werkauftrag, dessen Originaldateien unter  
< > `Werkauftrag/` zu finden sind.  
< > Die Templates folgen dabei bestimmten Anforderungen:  
< > Barrierefreiheit (ARIA-Standards)  
< > Endings Principles for Digital Longevity  
< > Themes  
< > Verwendung der visuellen Sprache der Clio Guides  
< > Verwendung der visuellen Sprache des NFDI4Memory-Konsortiums  
< > Das System ist modular aufgebaut, wobei Quarto als technische Grundlage dient  
< > und Pandoc für die Umwandlung verwendet wird.  
< 
< > [!note] Open Issues  
< >   
< > - [Clio-Template auf quarto portieren](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/work_items/12)
< > - [Use of the Pandoc templates with a Quarto pipeline](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/11)
< > - [Aufräumen und Dokumentation](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/10)
< > - [Anzeigefehler bei Verlinkung in license](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/9)
< > - [Author - about](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/8)
< > - [Abstract im HTML-Header](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/7)
< > - [Keywords im HTML-Header](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/6)
< > - [List Institutions](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/5)
< > - [Author - Institute](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/4)
< > - [Correspondence-Author hervorheben / Korrespondenzmail verlinken](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/3)
< > - [Mehrere Autoren richtig anzeigen](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/2)
< > - [Zitierungen im Popup analog zu Fußnoten öffnen](https://scm.cms.hu-berlin.de/data-stories/pandoc-templates/-/issues/1)
< >   
< > TOTAL: opened: 12
< 
978,980c739
< ## Group Tool Registry for Digital Humanities
< 
< ### Papers
---
> ### Linked Open Data in den Geschichtswissenschaften
983,1000c742
< : 2025-05-14
< 
< Authors
< : Claus-Michael Schlesinger
< : Till Grallert
< 
< 
< [![Release](https://scm.cms.hu-berlin.de/tool-registry-dh/papers/-/badges/release.svg)](https://scm.cms.hu-berlin.de/tool-registry-dh/papers/-/releases)
< 
< > [!tip] Arbeitsrepo Aufsatz Tool Registry Mark 1  
< >   
< > In diesem Repo arbeiten wir gemeinsam an einem Aufsatz für eine Dokumentation der Tool Registry (Grundlagen und Prototyp).  
< 
< > [!note] Open Issues  
< >   
< > Keine offenen mehr Issues vorhanden
< >   
< > TOTAL: closed: 4
---
> : 2025-06-20
1002c744
< [Link to full readme](https://scm.cms.hu-berlin.de/tool-registry-dh/papers/-/blob/main/README.md)
---
> [![Release](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/badges/release.svg)](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/releases)
1003a746
> [Link to full readme](https://scm.cms.hu-berlin.de/data-stories/story_lod-geschichtswissenschaften/-/blob/main/README.md)
Nur in quarto/methodenlabor: code-project-template.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/data_dfg-gepris.qmd quarto/methodenlabor/data_dfg-gepris.qmd
2c2
< title: "data_dfg-gepris (Methodenlabor)"
---
> title: "Methodenlabor / data_dfg-gepris (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/data_dfg-gepris"
>       icon: "gitlab"
11c11
< # data_dfg-gepris (Methodenlabor)
---
> # Methodenlabor / data_dfg-gepris (Methodenlabor)
14a15,33
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Data curation"
> >   - "Software"
> > date: "2024-12-10"
> > lang: "de"
> > tags:
> > - "FieldSurvey"
> > - "platform"
> > - "documentation"
16,29d34
< > date: 2024-12-10
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Data curation
< >       - Software
31,43c36,43
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: data
< > status: done
< > lang: de
< > licence: https://creativecommons.org/licenses/by/4.0/
< > markdown: pandoc
< > tags:
< >     - FieldSurvey
< >     - platform
< >     - documentation
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "data"
> > status: "done"
> > licence: "https://creativecommons.org/licenses/by/4.0/"
> > markdown: "pandoc"
45,129d44
< > 
< > The [GEPRIS - Geförderte Projekte der Deutschen Forschungsgemeinschaft](https://gepris.dfg.de/gepris/OCTOPUS) database provides data on all projects funded by the DFG. Unfortunately, and despite its commitment to Open Access and Open Science, DFG does not provide an API or machine-actionable data for reuse. We have, therefore, scraped data from the website.
< > 
< > # to do
< > 
< > - [x] first scrape of all projects
< > - [x] first scrape of all people from project pages
< >     - Problem: I missed some relationships in my initial code
< > - [x] second scrape of people trying to catch as many functions and positions as possible
< > - [ ] first scrape of personal details 
< > 
< > # This repository
< > ## structure
< > 
< > - `code/`: folder for R scripts, wrapped in Quarto notebooks
< > - `data/`: folder holding data frames and CSV files
< > 
< > ## data model / columns
< > 
< > - `country-names.csv`: helper file for finding country names in the larger data set. Originally created via a SPARQL query to Wikidata.
< >     + `country.name.de`: names of countries in German
< >     + `country.id.wiki`: URL of the Wikidata item
< > - `dfg_people`: authority data on people
< >     + `person.id`: numerical GEPRIS ID for people
< >     + `person.name`
< >     + `person.title`
< > - `dfg_projects`: authority data on projects
< >     - `project.id`: numerical GEPRIS ID for projects
< >     - `timestamp`: timestamp of scraping
< > - `dfg_project-ids`: single column holding all current GEPRIS IDs, used for itering the scraping code
< > - `dfg_projects-colab_country`
< >     + `project.id`: numerical GEPRIS ID for projects
< >     + `collaborator.country`: country name in German
< > - `dfg_projects-discipline`
< >     + `project.id`: numerical GEPRIS ID for projects
< >     + `discipline`
< > - `dfg_projects-people`: linking projects to people
< >     + `project.id`: numerical GEPRIS ID for projects
< >     + `person.id`: numerical GEPRIS ID for people
< >     + `person.name`: redundant, better to be looked up in `dfg_people`.
< >     + `role`: project specific role
< >     + `timestamp`
< > 
< > # GEPRIS
< > ## data structure
< > 
< > GEPRIS provides information on three types of entities, all of which have nummerical, non-sequential IDs:
< > 
< > 1. projects. 
< >     - can self-nest
< >     - link to: 
< >         - people in various roles
< >     - Sample URL: `https://gepris.dfg.de/gepris/projekt/260637721`
< > 2. people. Sample URL: `https://gepris.dfg.de/gepris/person/259603769`
< >     - link to:
< >         - projects but uses some embedded javascript on document.ready()
< >     - do not link to organisations: these are only provided in plain text
< > 3. organisations. Sample URL: `https://gepris.dfg.de/gepris/institution/10293`
< > 
< > ## Search
< > 
< > Advanced search, provides multiple ways of facetted browsing. One can always get an URL for a paginated list of projects, which can then be used to scrape a specific subset.
< > 
< > ## scraping
< > 
< > I have written a [Quarto notebook](code/scrape_dfg-gepris.qmd) to scrape the GEPRIS database. This executes the following steps:
< > 
< > 1. Scrape all project IDs from the catalogue pages. This iterates over almost 3.000 pages with 50 projects each.
< > 2. Scrape detail pages of almost 150.000 projects for:
< >     - project descriptions
< >     - applicants
< >     - collaborators
< > 
< > Initially it seemed simple to scrape all entries from the database as the URLs follow the pattern `https://gepris.dfg.de/gepris/projekt/{ID}` with numerical IDs. However, as examples showed that these can have at least 9 digits, a simple incrementing function would take more than 25 years with a one second delay between each call to the server in order the 135273 actual projects listed in GEPRIS (because IDs do not form an uninterrupted sequence of numbers this attempt would make many unnecessary calls).
< > 
< > The first step, therefore, was to scrape the existent project IDs from the catalogue pages. In total this would require to iterate over 2706 catalogue pages with 50 projects IDs each but could be further decreased by limiting our call to a specific sub-field, namely the humanities, encoded in the catalogue URLs as `&fachgebiet=11`. This would reduce the number of catalogue pages to 319.
< > 
< > # other users of GEPRIS IDs
< > ## Wikidata
< > 
< > Wikidata provides properties for
< > 
< > - [GEPRIS project ID](https://www.wikidata.org/wiki/Property:P4870)
< > - [GEPRIS person ID](https://www.wikidata.org/wiki/Property:P4872)
< > - [GEPRIS organization ID](https://www.wikidata.org/wiki/Property:P4871)
131c46,130
< ---
---
> 
> The [GEPRIS - Geförderte Projekte der Deutschen Forschungsgemeinschaft](https://gepris.dfg.de/gepris/OCTOPUS) database provides data on all projects funded by the DFG. Unfortunately, and despite its commitment to Open Access and Open Science, DFG does not provide an API or machine-actionable data for reuse. We have, therefore, scraped data from the website.
> 
> # to do
> 
> - [x] first scrape of all projects
> - [x] first scrape of all people from project pages
>     - Problem: I missed some relationships in my initial code
> - [x] second scrape of people trying to catch as many functions and positions as possible
> - [ ] first scrape of personal details 
> 
> # This repository
> ## structure
> 
> - `code/`: folder for R scripts, wrapped in Quarto notebooks
> - `data/`: folder holding data frames and CSV files
> 
> ## data model / columns
> 
> - `country-names.csv`: helper file for finding country names in the larger data set. Originally created via a SPARQL query to Wikidata.
>     + `country.name.de`: names of countries in German
>     + `country.id.wiki`: URL of the Wikidata item
> - `dfg_people`: authority data on people
>     + `person.id`: numerical GEPRIS ID for people
>     + `person.name`
>     + `person.title`
> - `dfg_projects`: authority data on projects
>     - `project.id`: numerical GEPRIS ID for projects
>     - `timestamp`: timestamp of scraping
> - `dfg_project-ids`: single column holding all current GEPRIS IDs, used for itering the scraping code
> - `dfg_projects-colab_country`
>     + `project.id`: numerical GEPRIS ID for projects
>     + `collaborator.country`: country name in German
> - `dfg_projects-discipline`
>     + `project.id`: numerical GEPRIS ID for projects
>     + `discipline`
> - `dfg_projects-people`: linking projects to people
>     + `project.id`: numerical GEPRIS ID for projects
>     + `person.id`: numerical GEPRIS ID for people
>     + `person.name`: redundant, better to be looked up in `dfg_people`.
>     + `role`: project specific role
>     + `timestamp`
> 
> # GEPRIS
> ## data structure
> 
> GEPRIS provides information on three types of entities, all of which have nummerical, non-sequential IDs:
> 
> 1. projects. 
>     - can self-nest
>     - link to: 
>         - people in various roles
>     - Sample URL: `https://gepris.dfg.de/gepris/projekt/260637721`
> 2. people. Sample URL: `https://gepris.dfg.de/gepris/person/259603769`
>     - link to:
>         - projects but uses some embedded javascript on document.ready()
>     - do not link to organisations: these are only provided in plain text
> 3. organisations. Sample URL: `https://gepris.dfg.de/gepris/institution/10293`
> 
> ## Search
> 
> Advanced search, provides multiple ways of facetted browsing. One can always get an URL for a paginated list of projects, which can then be used to scrape a specific subset.
> 
> ## scraping
> 
> I have written a [Quarto notebook](code/scrape_dfg-gepris.qmd) to scrape the GEPRIS database. This executes the following steps:
> 
> 1. Scrape all project IDs from the catalogue pages. This iterates over almost 3.000 pages with 50 projects each.
> 2. Scrape detail pages of almost 150.000 projects for:
>     - project descriptions
>     - applicants
>     - collaborators
> 
> Initially it seemed simple to scrape all entries from the database as the URLs follow the pattern `https://gepris.dfg.de/gepris/projekt/{ID}` with numerical IDs. However, as examples showed that these can have at least 9 digits, a simple incrementing function would take more than 25 years with a one second delay between each call to the server in order the 135273 actual projects listed in GEPRIS (because IDs do not form an uninterrupted sequence of numbers this attempt would make many unnecessary calls).
> 
> The first step, therefore, was to scrape the existent project IDs from the catalogue pages. In total this would require to iterate over 2706 catalogue pages with 50 projects IDs each but could be further decreased by limiting our call to a specific sub-field, namely the humanities, encoded in the catalogue URLs as `&fachgebiet=11`. This would reduce the number of catalogue pages to 319.
> 
> # other users of GEPRIS IDs
> ## Wikidata
> 
> Wikidata provides properties for
> 
> - [GEPRIS project ID](https://www.wikidata.org/wiki/Property:P4870)
> - [GEPRIS person ID](https://www.wikidata.org/wiki/Property:P4872)
> - [GEPRIS organization ID](https://www.wikidata.org/wiki/Property:P4871)
Nur in quarto_production/methodenlabor: data_dfgprojects.qmd.
Nur in quarto_production/methodenlabor: data_dhconferences.qmd.
Nur in quarto_production/methodenlabor: data_dhd.qmd.
Nur in quarto_production/methodenlabor: data_dhq.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/data_field-survey.qmd quarto/methodenlabor/data_field-survey.qmd
2c2
< title: "data_field-survey (Methodenlabor)"
---
> title: "Methodenlabor / data_field-survey (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/data_field-survey"
>       icon: "gitlab"
11c11
< # data_field-survey (Methodenlabor)
---
> # Methodenlabor / data_field-survey (Methodenlabor)
14a15,46
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Data curation"
> > - name: "Isabell Trilling"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   roles:
> >   - "Data curation"
> > - name: "Nicole Dresselhaus"
> >   email: "nicole.dresselhaus@hu-berlin.de"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   roles:
> >   - "Conceptualization"
> >   - "Data curation"
> > date: "2025-05-20"
> > lang: "de"
> > tags:
> > - "NFDI"
> > - "4Memory"
> > - "FieldSurvey"
16,43c48
< > description: |
< > date: 2025-05-20 
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Data curation
< >   - name: Isabell Trilling
< >     institute: 
< >       - hu
< >       - nfdi
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Data curation
< >   - name: Nicole Dresselhaus
< >     email: nicole.dresselhaus@hu-berlin.de
< >     institute: 
< >       - hu
< >       - nfdi
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Data curation
---
> > description: ""
45,56c50,56
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 5    # value from 1 (low) to 5 (high)
< > urgency: 3     # value from 1 (low) to 5 (high)
< > type: data  # writing, code, or data
< > status: in progress
< > lang: de
< > markdown: pandoc
< > tags:
< >   - NFDI
< >   - 4Memory
< >   - FieldSurvey
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 5
> > urgency: 3
> > type: "data"
> > status: "in progress"
> > markdown: "pandoc"
58d57
< > 
60c59
< ---
---
> 
Nur in quarto/methodenlabor: Data Project Template.qmd.
Nur in quarto_production/methodenlabor: data_tool-registries.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/data_tool-registry-dump.qmd quarto/methodenlabor/data_tool-registry-dump.qmd
2c2
< title: "data_tool-registry-dump (Methodenlabor)"
---
> title: "Methodenlabor / data_tool-registry-dump (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry-dump"
>       icon: "gitlab"
11c11
< # data_tool-registry-dump (Methodenlabor)
---
> # Methodenlabor / data_tool-registry-dump (Methodenlabor)
15,19c15,19
< > author: 
< >   - Till Grallert
< >   - Nicole Dresselhaus
< > date: 2024-10-09
< > lang: de
---
> > author:
> > - "Till Grallert"
> > - "Nicole Dresselhaus"
> > date: "2024-10-09"
> > lang: "de"
21,223d20
< > 
< > [![pipeline status](../../../badges/main/pipeline.svg)](../pipelines?page=1&scope=all&ref=main)  [![Latest Release](../../badges/release.svg)](../../releases)
< > 
< > # Hintergrund
< > 
< > ## Was machen wir?
< > 
< > Als Teil der [Tool Registry][toolregistry] bzw. jeden Forschungsprojekts, das
< > Daten auf [Wikidata][wikidata] publiziert, müssen wir regelmäßig **unseren**
< > kompletten Datensatz von Wikidata ziehen und in einem Versionskontrollsystem
< > ablegen, um ihn dann als stabilen und referenzierbaren Datensatz publizieren und
< > archivieren bzw. wieder in Linked-Open-Data Umgebungen und Triple Stores
< > einspeisen zu können.
< > 
< > Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,
< > die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert
< > werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet
< > automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs
< > geändert haben, es Störungen in der Internetverbindung gab, etc.).
< > 
< > ## Wozu wird das in der Wissenschaft gebraucht?
< > 
< > Es gibt zwei Hauptargumente für die versionierte Sicherung von auf Wikidata
< > publizierten Daten:
< > 
< > 1. Wikidata ist eine Platform außerhalb der unserer Kontrolle. Nicht nur können
< >    Daten jederzeit durch Nutzer_innen geändert und erweitert werden (einer der
< >    Hauptgründe überhaupt auf Wikidata zu setzen), sondern auch die technische
< >    Infrastruktur kann sich ändern bzw. aufhören in ihrer aktuellen Form zu
< >    existieren.
< > 2. Auf diesen Daten aufsetzende Analysen benötigen für die Reproduzierbarkeit
< >    ihrer Ergebnisse einen stabilen und referenzierbaren Datensatz. Gerade die in
< >    unserer Tool Registry erfassten computationellen Werkzeuge unterliegen
< >    rasanten Änderung. Und schon bei kleinen Abweichungen in der Versionsnummer
< >    kann es zu teils massiv unterschiedlichen Ergebnissen in der Evaluation
< >    kommen. Um hier Ergebnisse auch gegen neuere Ideen testen zu können muss für
< >    einen sinnvollen Vergleich natürlich gegen die Version, mit der die
< >    Forscher\*in zum Zeitpunkt der Publikation gearbeitet hat, getestet werden.
< > 
< > # Implementation
< > 
< > Die Implementation erfolgt in fünf Schritten:
< > 1. Der Umfang unseres zu speichernden Datensatzes (Graphs) etabliert: Welche
< >    Wikidata-Items sind unsere Knoten erster Klasse, die den Kern des Graphen
< >    ausmachen?
< > 2. Alle diese Nodes und ihre Beziehungen zu einander werden heruntergeladen.
< >    Dabei muss festgelegt werden, wie viele Schritte von den Kernknoten
< >    weggegangen werden soll um nicht den gesamten Graphen von Wikidata zu
< >    speichern.
< > 3. Die heruntergeladenen Daten werden in ein Archivformat gepackt.
< > 4. Das Archiv wird in das Repository committed und es findet ein Release statt. 
< > 5. Das Archiv wird auf [Zenodo](https://zenodo.org/) langzeitarchiviert[^[](https://about.zenodo.org/policies/) sichert eine Speicherung für **mindestens** die nächsten 20 Jahre zu. ].
< > 
< > Schritte 1-3 werden von einem einzelnen [Bash-Skript](get_tools.bash)
< > übernommen, dass dann im 4. und 5. Schritt von einem
< > [CI/CD-Mechanismus](.gitlab-ci.yml) ausgeführt wird.
< > 
< > WICHTIG: das Bash-Skript ist nur auf UNIX-Systemen (Linux und macOS) entwickelt
< > und getestet worden. Über die Lauffähigkeit auf Windows-Systemen können wir
< > keine Aussage treffen.
< > 
< > ## 1. Umfang des Graphen mit SPARQL festlegen
< > 
< > Zum Auffinden aller Items wird eine einfache SPARQL-Abfrage genutzt <!-- hier
< > können wir Tutorials, Dokumentation zu SPARQL verlinken -->, die die IDs und
< > eine Bezeichnung für die Items ausgibt. Im Fall unserer Tool Registry sind das
< > Werkzeuge für die Digital Humanities und die Abfrage basiert auf den dafür
< > entwickelten [SPARQL
< > Queries](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql). 
< > 
< > ```sparql
< > SELECT DISTINCT
< >   ?tool ?toolLabel
< > WHERE {
< >   ?method wdt:P9309 ?tadirahID.
< >   ?tool wdt:P366 ?method;
< >     (wdt:P31/(wdt:P279*)) wd:Q7397.
< >   SERVICE wikibase:label {
< >       bd:serviceParam wikibase:language "en,de,fr, [AUTO_LANGUAGE]".
< >       ?tool rdfs:label ?toolLabel.
< >   }
< > } LIMIT 5000
< > ```
< > 
< > Diese Abfrage etabliert eine Liste von Methoden (`?method`), die als Items
< > definiert sind, die eine TaDiRAH ID (`P9309`) besitzen. Dann wird nach allen
< > Items gesucht, die über das Statement "has use" (`P366`) mit einer dieser
< > Methoden verknüpft sind und im weitesten Sinne Software beschreiben
< > (`(wdt:P31/(wdt:P279*)) wd:Q7397`). Über den Service "wikibase:label" werden die
< > Items dann noch um ihren Namen angereichert. Dieses ist nicht wirklich technisch
< > notwendig für unseren Zweck, bietet aber einen "sanity check" von
< > menschenlesbaren Bezeichnungen anstatt rein nummerischer IDs. Damit sich die
< > Bezeichnung nicht abhängig von den Einstellungen des Betriebssystems, auf dem
< > die Abfrage abgeführt wird, ändert, haben wir uns für englische Bezeichnungen
< > entschieden und einen Fallback auf andere Sprachen und schließlich die
< > Systemsprache gemacht.
< > 
< > Um direkt über den SPARQL-Endpoint von Wikidata abfragbar zu sein, muss diese
< > Abfrage URL-encoded sein (ergo alle Lehr- und Sonderzeichen müssen escaped
< > werden). Dieses wird über einen entsprechenden `curl`-Aufruf erreicht, der sich
< > um die entsprechende Behandlung kümmert.
< > 
< > Somit wird aus
< > ```bash
< > curl -s -XGET --get \
< >               --data-urlencode "format=json" \
< >               --data-urlencode "query=$QUERY" \
< >               'https://query.wikidata.org/sparql'
< > ```
< > zum Beispiel `https://query.wikidata.org/sparql?query=SELECT%20DISTINCT%20%0A%20%3Ftool%20%3FtoolLabel%0AWHERE%20%7B%0A%20%3Fmethod%20wdt%3AP9309%20%3FtadirahID.%0A%20%3Ftool%20wdt%3AP366%20%3Fmethod%3B%0A%20(wdt%3AP31%2F(wdt%3AP279*))%20wd%3AQ7397.%0A%20SERVICE%20wikibase%3Alabel%20%7B%0A%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cde%2Cfr%2C%20en%22.%0A%20%3Ftool%20rdfs%3Alabel%20%3FtoolLabel.%0A%20%7D%0A%7D%20LIMIT%205000`.
< > 
< > Das Skript fragt diese Liste als JSON an, benennt anschließend programmatisch
< > keys um, und legt diese für den nächsten Schritt ab.
< > 
< > ## 2. Herunterladen der Subgraphen für jedes einzelne Item (Tool)
< > 
< > Im folgenden wird über die Liste aus dem ersten Schritt iteriert und die
< > Subgraphen für jedes einzelnen Item anhand seiner ID von Wikidata
< > heruntergeladen. Wikidata bietet dazu mehrer Möglichkeiten. Zum einen gibt es
< > eine offizielle REST API ([OpenAPI Swagger
< > documentation](https://doc.wikimedia.org/Wikibase/master/js/rest-api/)), die ein
< > Wikidata-spezifisches JSON ausgibt: 
< > 
< > ```bash
< > https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/${toolid}
< > ```
< > 
< > Aktuell unterstützt diese API aber noch nicht die für uns notwendigen RDF-Serialisierungen, wie z.B. JSON-LD, Turtle oder RDF/XML. Diese sind über `Special:EntityData` URLs verfügbar, die quasi direkt das Ergebnis einer SPARQL  `SELECT`-Abfrage aus deren Cache nehmen:
< > 
< > ```bash
< > https://www.wikidata.org/wiki/Special:EntityData/${toolid}.${format}
< > ```
< > 
< > Beide Varianten sind wesentlich performanter als direkte SPARQL Abfragen. 
< > 
< > Im Ergebnis dieses Schrittes haben wir für jedes Item eine lokale RDF-Datei, die
< > dann archiviert und wieder in alle gängigen Knowledge-Graphen importiert werden
< > kann.
< > 
< > ## 3. Archivierung
< > 
< > Zum Abschluss wird aus den heruntergeladenen Daten ein `.tar.bz2`-Archiv
< > erstellt und mit dem aktuellen Datum versehen. Durch diesen Schritt spielt es
< > für den Platzverbrauch so gut wie keine Rolle, wie viele Serialisierungen wir
< > speichern, da viele Angaben redundant sind und damit gut komprimiert werden
< > können.
< > 
< > ## 4. Release
< > 
< > Zur regelmäßigen Archivierung wird das Bash-Skript durch GitLab selbst
< > ausgeführt und das erstellte `.tar.bz2`-Archiv als "Release" zur Verfügung
< > gestellt.
< > 
< > Dies geschieht über GitLab "Pipeline Schedules":
< > 
< > ![](img/gitlab.schedule.png)
< > 
< > Das GitLab CI-Script ist eine YAML Datei (`.gitlab-ci.yml`). Diese legt drei
< > Jobs an und führt sie nacheinander aus: `build-job`, `release-job` und
< > `publish-job`.
< > 
< > 1. Der `build-job` wird ausgeführt, wenn ein geplanter Auftrag oder ein
< >    Commit-Tag vorliegt. In diesem Job werden, falls nicht vorhanden, die
< >    erforderlichen Tools installiert, das eigentliche Skript `get_tools.bash`
< >    ausgeführt und eine Archiv-Datei mit dem aktuellen Datum generiert. Die
< >    generierte Datei wird als Artefakt gespeichert.
< > 2. Der `release-job` wird nur dann ausgeführt, wenn der `build-job`
< >    erfolgreich war. In diesem Job wird eine Release erstellt, die den Namen
< >    `Release Tool-Registry vom <Aktuelles_Datum>` trägt und eine Beschreibung
< >    enthält. Die generierte Datei aus dem `build-job` wird als Asset der Release
< >    hinzugefügt.
< > 3. Der `publish-job` wird nur ausgeführt, wenn in der Gitlab-Pipeline die
< >    Variable `PUBLISH` auf `true` gesetzt wurde - ansonsten wird dieser
< >    übersprungen. Der Job stellt sicher, dass das erstellte Archiv aus dem
< >    `build-job` verfügbar ist und der `release-job` problemfrei durchgelaufen
< >    ist. Dann wird das eigentliche Skript `upload_zenodo.bash` ausgeführt,
< >    welches sich um des gesamten Publikationsprozess kümmert.
< > 
< > ## Anpassungen
< > 
< > Möchte mensch den workflow nun für ihre eigene Domäne anpassen so muss lediglich
< > die SPARQL-query in `query.sparql.example` angepasst und als `query.sparql`
< > gespeichert werden und ggf. der `runner`-Tag in der `.gitlab-ci.yaml` auf die
< > eigene Umgebung konfiguriert werden.
< > 
< > Alle Scripte sind an den entscheidenden Stellen kommentiert und, so dass sie für
< > andere Projekte nachnutzbar sind.
< > 
< > # Voraussetzungen und Abhängigkeiten
< > 
< > Als Tools müssen momentan auf der Kommandozeile folgende Programme verfügbar
< > sein:
< > 
< > - [`jq`](https://jqlang.github.io/jq/): für die Manipulation von JSON.
< > - `curl`: für den Download
< > - `bzip2`: um das Archiv zu packen
< > - `pv`: Für die Statusleiste während des downloads und automatischer Schätzung
< >   der Restzeit
< > 
< > Unter Debian/Ubuntu lauten die entsprechenden Pakete gleichnamig.
< > 
< > [toolregistry]: https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities"
< > [wikidata]: https://wikidata.org/ "Wikidata"
225c22,224
< ---
---
> 
> [![pipeline status](../../../badges/main/pipeline.svg)](../pipelines?page=1&scope=all&ref=main)  [![Latest Release](../../badges/release.svg)](../../releases)
> 
> # Hintergrund
> 
> ## Was machen wir?
> 
> Als Teil der [Tool Registry][toolregistry] bzw. jeden Forschungsprojekts, das
> Daten auf [Wikidata][wikidata] publiziert, müssen wir regelmäßig **unseren**
> kompletten Datensatz von Wikidata ziehen und in einem Versionskontrollsystem
> ablegen, um ihn dann als stabilen und referenzierbaren Datensatz publizieren und
> archivieren bzw. wieder in Linked-Open-Data Umgebungen und Triple Stores
> einspeisen zu können.
> 
> Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,
> die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert
> werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet
> automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs
> geändert haben, es Störungen in der Internetverbindung gab, etc.).
> 
> ## Wozu wird das in der Wissenschaft gebraucht?
> 
> Es gibt zwei Hauptargumente für die versionierte Sicherung von auf Wikidata
> publizierten Daten:
> 
> 1. Wikidata ist eine Platform außerhalb der unserer Kontrolle. Nicht nur können
>    Daten jederzeit durch Nutzer_innen geändert und erweitert werden (einer der
>    Hauptgründe überhaupt auf Wikidata zu setzen), sondern auch die technische
>    Infrastruktur kann sich ändern bzw. aufhören in ihrer aktuellen Form zu
>    existieren.
> 2. Auf diesen Daten aufsetzende Analysen benötigen für die Reproduzierbarkeit
>    ihrer Ergebnisse einen stabilen und referenzierbaren Datensatz. Gerade die in
>    unserer Tool Registry erfassten computationellen Werkzeuge unterliegen
>    rasanten Änderung. Und schon bei kleinen Abweichungen in der Versionsnummer
>    kann es zu teils massiv unterschiedlichen Ergebnissen in der Evaluation
>    kommen. Um hier Ergebnisse auch gegen neuere Ideen testen zu können muss für
>    einen sinnvollen Vergleich natürlich gegen die Version, mit der die
>    Forscher\*in zum Zeitpunkt der Publikation gearbeitet hat, getestet werden.
> 
> # Implementation
> 
> Die Implementation erfolgt in fünf Schritten:
> 1. Der Umfang unseres zu speichernden Datensatzes (Graphs) etabliert: Welche
>    Wikidata-Items sind unsere Knoten erster Klasse, die den Kern des Graphen
>    ausmachen?
> 2. Alle diese Nodes und ihre Beziehungen zu einander werden heruntergeladen.
>    Dabei muss festgelegt werden, wie viele Schritte von den Kernknoten
>    weggegangen werden soll um nicht den gesamten Graphen von Wikidata zu
>    speichern.
> 3. Die heruntergeladenen Daten werden in ein Archivformat gepackt.
> 4. Das Archiv wird in das Repository committed und es findet ein Release statt. 
> 5. Das Archiv wird auf [Zenodo](https://zenodo.org/) langzeitarchiviert[^[](https://about.zenodo.org/policies/) sichert eine Speicherung für **mindestens** die nächsten 20 Jahre zu. ].
> 
> Schritte 1-3 werden von einem einzelnen [Bash-Skript](get_tools.bash)
> übernommen, dass dann im 4. und 5. Schritt von einem
> [CI/CD-Mechanismus](.gitlab-ci.yml) ausgeführt wird.
> 
> WICHTIG: das Bash-Skript ist nur auf UNIX-Systemen (Linux und macOS) entwickelt
> und getestet worden. Über die Lauffähigkeit auf Windows-Systemen können wir
> keine Aussage treffen.
> 
> ## 1. Umfang des Graphen mit SPARQL festlegen
> 
> Zum Auffinden aller Items wird eine einfache SPARQL-Abfrage genutzt <!-- hier
> können wir Tutorials, Dokumentation zu SPARQL verlinken -->, die die IDs und
> eine Bezeichnung für die Items ausgibt. Im Fall unserer Tool Registry sind das
> Werkzeuge für die Digital Humanities und die Abfrage basiert auf den dafür
> entwickelten [SPARQL
> Queries](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql). 
> 
> ```sparql
> SELECT DISTINCT
>   ?tool ?toolLabel
> WHERE {
>   ?method wdt:P9309 ?tadirahID.
>   ?tool wdt:P366 ?method;
>     (wdt:P31/(wdt:P279*)) wd:Q7397.
>   SERVICE wikibase:label {
>       bd:serviceParam wikibase:language "en,de,fr, [AUTO_LANGUAGE]".
>       ?tool rdfs:label ?toolLabel.
>   }
> } LIMIT 5000
> ```
> 
> Diese Abfrage etabliert eine Liste von Methoden (`?method`), die als Items
> definiert sind, die eine TaDiRAH ID (`P9309`) besitzen. Dann wird nach allen
> Items gesucht, die über das Statement "has use" (`P366`) mit einer dieser
> Methoden verknüpft sind und im weitesten Sinne Software beschreiben
> (`(wdt:P31/(wdt:P279*)) wd:Q7397`). Über den Service "wikibase:label" werden die
> Items dann noch um ihren Namen angereichert. Dieses ist nicht wirklich technisch
> notwendig für unseren Zweck, bietet aber einen "sanity check" von
> menschenlesbaren Bezeichnungen anstatt rein nummerischer IDs. Damit sich die
> Bezeichnung nicht abhängig von den Einstellungen des Betriebssystems, auf dem
> die Abfrage abgeführt wird, ändert, haben wir uns für englische Bezeichnungen
> entschieden und einen Fallback auf andere Sprachen und schließlich die
> Systemsprache gemacht.
> 
> Um direkt über den SPARQL-Endpoint von Wikidata abfragbar zu sein, muss diese
> Abfrage URL-encoded sein (ergo alle Lehr- und Sonderzeichen müssen escaped
> werden). Dieses wird über einen entsprechenden `curl`-Aufruf erreicht, der sich
> um die entsprechende Behandlung kümmert.
> 
> Somit wird aus
> ```bash
> curl -s -XGET --get \
>               --data-urlencode "format=json" \
>               --data-urlencode "query=$QUERY" \
>               'https://query.wikidata.org/sparql'
> ```
> zum Beispiel `https://query.wikidata.org/sparql?query=SELECT%20DISTINCT%20%0A%20%3Ftool%20%3FtoolLabel%0AWHERE%20%7B%0A%20%3Fmethod%20wdt%3AP9309%20%3FtadirahID.%0A%20%3Ftool%20wdt%3AP366%20%3Fmethod%3B%0A%20(wdt%3AP31%2F(wdt%3AP279*))%20wd%3AQ7397.%0A%20SERVICE%20wikibase%3Alabel%20%7B%0A%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cde%2Cfr%2C%20en%22.%0A%20%3Ftool%20rdfs%3Alabel%20%3FtoolLabel.%0A%20%7D%0A%7D%20LIMIT%205000`.
> 
> Das Skript fragt diese Liste als JSON an, benennt anschließend programmatisch
> keys um, und legt diese für den nächsten Schritt ab.
> 
> ## 2. Herunterladen der Subgraphen für jedes einzelne Item (Tool)
> 
> Im folgenden wird über die Liste aus dem ersten Schritt iteriert und die
> Subgraphen für jedes einzelnen Item anhand seiner ID von Wikidata
> heruntergeladen. Wikidata bietet dazu mehrer Möglichkeiten. Zum einen gibt es
> eine offizielle REST API ([OpenAPI Swagger
> documentation](https://doc.wikimedia.org/Wikibase/master/js/rest-api/)), die ein
> Wikidata-spezifisches JSON ausgibt: 
> 
> ```bash
> https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/${toolid}
> ```
> 
> Aktuell unterstützt diese API aber noch nicht die für uns notwendigen RDF-Serialisierungen, wie z.B. JSON-LD, Turtle oder RDF/XML. Diese sind über `Special:EntityData` URLs verfügbar, die quasi direkt das Ergebnis einer SPARQL  `SELECT`-Abfrage aus deren Cache nehmen:
> 
> ```bash
> https://www.wikidata.org/wiki/Special:EntityData/${toolid}.${format}
> ```
> 
> Beide Varianten sind wesentlich performanter als direkte SPARQL Abfragen. 
> 
> Im Ergebnis dieses Schrittes haben wir für jedes Item eine lokale RDF-Datei, die
> dann archiviert und wieder in alle gängigen Knowledge-Graphen importiert werden
> kann.
> 
> ## 3. Archivierung
> 
> Zum Abschluss wird aus den heruntergeladenen Daten ein `.tar.bz2`-Archiv
> erstellt und mit dem aktuellen Datum versehen. Durch diesen Schritt spielt es
> für den Platzverbrauch so gut wie keine Rolle, wie viele Serialisierungen wir
> speichern, da viele Angaben redundant sind und damit gut komprimiert werden
> können.
> 
> ## 4. Release
> 
> Zur regelmäßigen Archivierung wird das Bash-Skript durch GitLab selbst
> ausgeführt und das erstellte `.tar.bz2`-Archiv als "Release" zur Verfügung
> gestellt.
> 
> Dies geschieht über GitLab "Pipeline Schedules":
> 
> ![](img/gitlab.schedule.png)
> 
> Das GitLab CI-Script ist eine YAML Datei (`.gitlab-ci.yml`). Diese legt drei
> Jobs an und führt sie nacheinander aus: `build-job`, `release-job` und
> `publish-job`.
> 
> 1. Der `build-job` wird ausgeführt, wenn ein geplanter Auftrag oder ein
>    Commit-Tag vorliegt. In diesem Job werden, falls nicht vorhanden, die
>    erforderlichen Tools installiert, das eigentliche Skript `get_tools.bash`
>    ausgeführt und eine Archiv-Datei mit dem aktuellen Datum generiert. Die
>    generierte Datei wird als Artefakt gespeichert.
> 2. Der `release-job` wird nur dann ausgeführt, wenn der `build-job`
>    erfolgreich war. In diesem Job wird eine Release erstellt, die den Namen
>    `Release Tool-Registry vom <Aktuelles_Datum>` trägt und eine Beschreibung
>    enthält. Die generierte Datei aus dem `build-job` wird als Asset der Release
>    hinzugefügt.
> 3. Der `publish-job` wird nur ausgeführt, wenn in der Gitlab-Pipeline die
>    Variable `PUBLISH` auf `true` gesetzt wurde - ansonsten wird dieser
>    übersprungen. Der Job stellt sicher, dass das erstellte Archiv aus dem
>    `build-job` verfügbar ist und der `release-job` problemfrei durchgelaufen
>    ist. Dann wird das eigentliche Skript `upload_zenodo.bash` ausgeführt,
>    welches sich um des gesamten Publikationsprozess kümmert.
> 
> ## Anpassungen
> 
> Möchte mensch den workflow nun für ihre eigene Domäne anpassen so muss lediglich
> die SPARQL-query in `query.sparql.example` angepasst und als `query.sparql`
> gespeichert werden und ggf. der `runner`-Tag in der `.gitlab-ci.yaml` auf die
> eigene Umgebung konfiguriert werden.
> 
> Alle Scripte sind an den entscheidenden Stellen kommentiert und, so dass sie für
> andere Projekte nachnutzbar sind.
> 
> # Voraussetzungen und Abhängigkeiten
> 
> Als Tools müssen momentan auf der Kommandozeile folgende Programme verfügbar
> sein:
> 
> - [`jq`](https://jqlang.github.io/jq/): für die Manipulation von JSON.
> - `curl`: für den Download
> - `bzip2`: um das Archiv zu packen
> - `pv`: Für die Statusleiste während des downloads und automatischer Schätzung
>   der Restzeit
> 
> Unter Debian/Ubuntu lauten die entsprechenden Pakete gleichnamig.
> 
> [toolregistry]: https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities"
> [wikidata]: https://wikidata.org/ "Wikidata"
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/data_tool-registry.qmd quarto/methodenlabor/data_tool-registry.qmd
2c2
< title: "data_tool-registry (Methodenlabor)"
---
> title: "Methodenlabor / data_tool-registry (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/data_tool-registry"
>       icon: "gitlab"
11c11
< # data_tool-registry (Methodenlabor)
---
> # Methodenlabor / data_tool-registry (Methodenlabor)
13a14
> > title: "Collect Tool-Registry from Wikidata and push to Zenodo"
15,29c16,29
< >   - name: Till Grallert
< >     affiliation: Humboldt-Universität zu Berlin
< >     email: till.grallert@hu-berlin.de
< >     orcid: "https://orcid.org/0000-0002-5739-8094"
< >   - name: Nicole Dresselhaus
< >     affiliation: Humboldt-Universität zu Berlin
< >     email: nicole.dresselhaus@hu-berlin.de
< >     orcid: "https://orcid.org/0009-0008-8850-3679"
< > date: 2025-06-16
< > status: in Production
< > lang: de
< > license: GPL3
< > title: Collect Tool-Registry from Wikidata and push to Zenodo
< > description:
< >   Periodically pull data from Wikidata to GitLab, release, and push to Zenodo
---
> > - name: "Till Grallert"
> >   affiliation: "Humboldt-Universität zu Berlin"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "https://orcid.org/0000-0002-5739-8094"
> > - name: "Nicole Dresselhaus"
> >   affiliation: "Humboldt-Universität zu Berlin"
> >   email: "nicole.dresselhaus@hu-berlin.de"
> >   orcid: "https://orcid.org/0009-0008-8850-3679"
> > date: "2025-06-16"
> > lang: "de"
> > status: "in Production"
> > license: "GPL3"
> > description: "Periodically pull data from Wikidata to GitLab, release, and push to\
> >   \ Zenodo"
32,431d31
< > 
< > [![pipeline
< > status](../../../badges/main/pipeline.svg)](../pipelines?page=1&scope=all&ref=main)
< > [![Latest Release](../../badges/release.svg)](../../releases)
< > 
< > ![Project-logo](img/logo.jpg)
< > 
< > <!--toc:start-->
< > 
< > - [Hintergrund](#hintergrund)
< >   - [Was machen wir?](#was-machen-wir)
< >   - [Wozu wird das in der Wissenschaft gebraucht?](#wozu-wird-das-in-der-wissenschaft-gebraucht)
< > - [Implementation](#implementation)
< > - [Skripte](#skripte)
< >   - [1. Download und Speicherung der Daten](#1-download-und-speicherung-der-daten)
< >     - [1.1 Umfang des Graphen mit SPARQL festlegen](#11-umfang-des-graphen-mit-sparql-festlegen)
< >     - [1.2 Herunterladen der Subgraphen für jedes einzelne Item](#12-herunterladen-der-subgraphen-für-jedes-einzelne-item)
< >     - [1.3 Archivierung](#13-archivierung)
< >   - [2. Push zu Zenodo](#2-push-zu-zenodo)
< >     - [2.1. Herausfinden der Concept-ID](#21-herausfinden-der-concept-id)
< >     - [2.2. Erstellung einer neuen Version](#22-erstellung-einer-neuen-version)
< >     - [2.3. Upload des Archives und Veröffentlichung](#23-upload-des-archives-und-veröffentlichung)
< > - [Setup und Anpassung](#setup-und-anpassung)
< >   - [Forken](#forken)
< >   - [Anpassung auf eigene Umgebung](#anpassung-auf-eigene-umgebung)
< >   - [CI/CD Mechanismus](#cicd-mechanismus) - [das CI-Script](#das-ci-script) -
< >   [Runner](#runner) - [Variablen](#variablen) - [Pipeline](#pipeline)
< >   <!--toc:end-->
< > 
< > ## Hintergrund
< > 
< > ### Was machen wir?
< > 
< > Als Teil der
< > [Tool Registry](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities")
< > bzw. jeden Forschungsprojekts, das Daten auf
< > [Wikidata](https://wikidata.org/ "Wikidata") publiziert, müssen wir regelmäßig
< > **unseren** kompletten Datensatz von Wikidata ziehen und in einem
< > Versionskontrollsystem ablegen, um ihn dann als stabilen und referenzierbaren
< > Datensatz publizieren und archivieren bzw. wieder in Linked-Open-Data Umgebungen
< > und Triple Stores einspeisen zu können.
< > 
< > Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,
< > die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert
< > werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet
< > automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs
< > geändert haben, es Störungen in der Internetverbindung gab, etc.).
< > 
< > ### Wozu wird das in der Wissenschaft gebraucht?
< > 
< > Es gibt zwei Hauptargumente für die versionierte Sicherung von auf Wikidata
< > publizierten Daten:
< > 
< > 1. Wikidata ist eine Platform außerhalb der unserer Kontrolle. Nicht nur können
< >    Daten jederzeit durch Nutzer_innen geändert und erweitert werden (einer der
< >    Hauptgründe überhaupt auf Wikidata zu setzen), sondern auch die technische
< >    Infrastruktur kann sich ändern bzw. aufhören in ihrer aktuellen Form zu
< >    existieren.
< > 2. Auf diesen Daten aufsetzende Analysen benötigen für die Reproduzierbarkeit
< >    ihrer Ergebnisse einen stabilen und referenzierbaren Datensatz. Gerade die in
< >    unserer item Registry erfassten computationellen Werkzeuge unterliegen
< >    rasanten Änderung. Und schon bei kleinen Abweichungen in der Versionsnummer
< >    kann es zu teils massiv unterschiedlichen Ergebnissen in der Evaluation
< >    kommen. Um hier Ergebnisse auch gegen neuere Ideen testen zu können muss für
< >    einen sinnvollen Vergleich natürlich gegen die Version, mit der die
< >    Forscher\*in zum Zeitpunkt der Publikation gearbeitet hat, getestet werden.
< > 
< > ## Implementation
< > 
< > Die Implementation erfolgt in drei Schritten, die in einer Kombination aus
< > Bash-Skripten und einem [CI/CD-Mechanismus](.gitlab-ci.yml) ausgeführt werden.
< > 
< > 1. Download der Daten von Wikidata und Speicherung in einem komprimierten
< >    Archivformat.
< > 2. Das Archiv wird in das Repository committed und es findet ein Release statt.
< > 3. Das Archiv wird auf [Zenodo](https://zenodo.org/) langzeitarchiviert[^1].
< > 
< > [^1]:
< >     [Zenodo](https://about.zenodo.org/policies/) sichert eine Speicherung für
< >     **mindestens** die nächsten 20 Jahre zu.
< > 
< > Das automatisierte Ausführen der Skripte und der Release geschehen über GitLab
< > "Pipeline Schedules" mit Hilfe eines CI-Skriptes.
< > 
< > ::: {.callout-warning}
< > 
< > WICHTIG: Für die Ausführung werden sogenannte _Runner_ benötigt, die die
< > notwendige Hard- und Software für die Ausführung der Scripte bereitstellen.
< > Falls bisher kein _Runner_ erstellt wurde, muss dieser vorher (z.b. durch
< > Administratoren, Projektmanager, ..)
< > [eingerichtet werden](https://docs.gitlab.com/runner/install/).
< > 
< > :::
< > 
< > ::: {.callout-warning}
< > 
< > WICHTIG: die Bash-Skripte sind nur auf UNIX-Systemen (Linux und macOS)
< > entwickelt und getestet worden. Über die Lauffähigkeit auf Windows-Systemen
< > können wir keine Aussage treffen.
< > 
< > :::
< > 
< > ## Skripte
< > 
< > Für die Ausführung der Bash-Skripte müssen momentan auf der Kommandozeile
< > folgende Programme verfügbar sein:
< > 
< > - [`jq`](https://jqlang.github.io/jq/): für die Manipulation von JSON.
< > - `curl`: für den Download
< > - `bzip2`: um das Archiv zu packen
< > - `pv`: Für die Statusleiste während des downloads und automatischer Schätzung
< >   der Restzeit
< > 
< > Unter Debian/Ubuntu lauten die entsprechenden Pakete gleichnamig.
< > 
< > ### 1. Download und Speicherung der Daten
< > 
< > Dieser Schritt wird von einem einzelnen [Bash-Skript](get_items.bash) übernommen
< > und umfasst die folgenden drei Teile:
< > 
< > 1. Der Umfang unseres zu speichernden Datensatzes (Graphs) wird mit SPARQL
< >    etabliert: Welche Wikidata-Items sind unsere Knoten erster Klasse, die den
< >    Kern des Graphen ausmachen?
< > 2. Alle diese Nodes und ihre Beziehungen zu einander werden über die Wikidata
< >    API heruntergeladen. Dabei muss festgelegt werden, wie viele Schritte von den
< >    Kernknoten weggegangen werden soll um nicht den gesamten Graphen von Wikidata
< >    zu speichern.
< > 3. Die heruntergeladenen Daten werden in ein Archivformat gepackt.
< > 
< > #### 1.1 Umfang des Graphen mit SPARQL festlegen
< > 
< > Zum Auffinden aller Items wird eine einfache SPARQL-Abfrage genutzt
< > 
< > <!-- hier können wir Tutorials, Dokumentation zu SPARQL verlinken -->, die die
< > 
< > IDs und eine Bezeichnung für die Items ausgibt. Im Fall unserer Tool Registry
< > sind das Werkzeuge für die Digital Humanities und die Abfrage basiert auf den
< > dafür entwickelten
< > [SPARQL Queries](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql).
< > 
< > ```sparql
< > SELECT DISTINCT
< >   ?item ?itemLabel
< > WHERE {
< >   ?method wdt:P9309 ?tadirahID.
< >   ?item wdt:P366 ?method;
< >     (wdt:P31/(wdt:P279*)) wd:Q7397.
< >   SERVICE wikibase:label {
< >       bd:serviceParam wikibase:language "en,de,fr, [AUTO_LANGUAGE]".
< >       ?item rdfs:label ?itemLabel.
< >   }
< > } LIMIT 5000
< > ```
< > 
< > Diese Abfrage etabliert eine Liste von Methoden (`?method`), die als Items
< > definiert sind, die eine TaDiRAH ID (`P9309`) besitzen. Dann wird nach allen
< > Items gesucht, die über das Statement "has use" (`P366`) mit einer dieser
< > Methoden verknüpft sind und im weitesten Sinne Software beschreiben
< > (`(wdt:P31/(wdt:P279*)) wd:Q7397`). Über den Service "wikibase:label" werden die
< > Tools dann noch um ihren Namen angereichert. Dieses ist nicht wirklich technisch
< > notwendig für unseren Zweck, bietet aber einen "sanity check" von
< > menschenlesbaren Bezeichnungen anstatt rein nummerischer IDs. Damit sich die
< > Bezeichnung nicht abhängig von den Einstellungen des Betriebssystems, auf dem
< > die Abfrage abgeführt wird, ändert, haben wir uns für englische Bezeichnungen
< > entschieden und einen Fallback auf andere Sprachen und schließlich die
< > Systemsprache gemacht.
< > 
< > Um direkt über den SPARQL-Endpoint von Wikidata abfragbar zu sein, muss diese
< > Abfrage URL-encoded sein (ergo alle Lehr- und Sonderzeichen müssen escaped
< > werden). Dieses wird über einen entsprechenden `curl`-Aufruf erreicht, der sich
< > um die entsprechende Behandlung kümmert.
< > 
< > Somit wird aus
< > 
< > ```bash
< > curl -s -XGET --get \
< >               --data-urlencode "format=json" \
< >               --data-urlencode "query@$QUERY" \
< >               'https://query.wikidata.org/sparql'
< > ```
< > 
< > zum Beispiel
< > `https://query.wikidata.org/sparql?query=SELECT%20DISTINCT%20%0A%20%3Fitem%20%3FitemLabel%0AWHERE%20%7B%0A%20%3Fmethod%20wdt%3AP9309%20%3FtadirahID.%0A%20%3Fitem%20wdt%3AP366%20%3Fmethod%3B%0A%20(wdt%3AP31%2F(wdt%3AP279*))%20wd%3AQ7397.%0A%20SERVICE%20wikibase%3Alabel%20%7B%0A%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cde%2Cfr%2C%20en%22.%0A%20%3Fitem%20rdfs%3Alabel%20%3FitemLabel.%0A%20%7D%0A%7D%20LIMIT%205000`.
< > 
< > Das Skript fragt diese Liste als JSON an, benennt anschließend programmatisch
< > keys um, und legt diese für den nächsten Schritt ab.
< > 
< > #### 1.2 Herunterladen der Subgraphen für jedes einzelne Item
< > 
< > Im folgenden wird über die Liste aus dem ersten Schritt iteriert und die
< > Subgraphen für jedes einzelnen Item anhand seiner ID von Wikidata
< > heruntergeladen. Wikidata bietet dazu mehrer Möglichkeiten. Zum einen gibt es
< > eine offizielle REST API
< > ([OpenAPI Swagger documentation](https://doc.wikimedia.org/Wikibase/master/js/rest-api/)),
< > die ein Wikidata-spezifisches JSON ausgibt:
< > 
< > ```bash
< > https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/${itemid}
< > ```
< > 
< > Aktuell unterstützt diese API aber noch nicht die für uns notwendigen
< > RDF-Serialisierungen, wie z.B. JSON-LD, Turtle oder RDF/XML. Diese sind über
< > `Special:EntityData` URLs verfügbar, die quasi direkt das Ergebnis einer SPARQL
< > `SELECT`-Abfrage aus deren Cache nehmen:
< > 
< > ```bash
< > https://www.wikidata.org/wiki/Special:EntityData/${itemid}.${format}
< > ```
< > 
< > Beide Varianten sind wesentlich performanter als direkte SPARQL Abfragen.
< > 
< > Im Ergebnis dieses Schrittes haben wir für jedes Item eine lokale RDF-Datei, die
< > dann archiviert und wieder in alle gängigen Knowledge-Graphen importiert werden
< > kann.
< > 
< > #### 1.3 Archivierung
< > 
< > Zum Abschluss wird aus den heruntergeladenen Daten ein `.tar.bz2`-Archiv
< > erstellt und mit dem aktuellen Datum versehen. Durch diesen Schritt spielt es
< > für den Platzverbrauch so gut wie keine Rolle, wie viele Serialisierungen wir
< > speichern, da viele Angaben redundant sind und damit gut komprimiert werden
< > können.
< > 
< > ### 2. Push zu Zenodo
< > 
< > Auch dieser Schritt wird von einem einzelnen [Bash-Skript](upload_zenodo.bash)
< > übernommen und umfasst die folgenden Teile:
< > 
< > 1. Herausfinden der Concept-ID in dem das Datenset gespeichert werden soll
< > 2. Erstellung einer neuen Version und auslesen der Metadaten
< > 3. Upload des Archives und veröffentlichen der neuen Version
< > 
< > Bevor wir aber auf die eigentliche Arbeit Bezug nehmen können wird zunächst
< > festgestellt, ob alle Umgebungsvariablen korrekt gesetzt sind und andernfalls
< > mit einer entsprechenden Fehlermeldung abgebrochen. Daher können wir im
< > folgenden davon ausgehen, dass diese Variablen korrekt gesetzt sind:
< > 
< > - `API_BASE` für den Server den wir benutzen (z.B. Sandbox oder Live)
< > - `ZENODO_TOKEN` vorhanden ist und auch gültig (eine Test-Anfrage würde sonst
< >   z.B. einen 403 "kein Zugriff" zurückmelden).
< > - `ZENODO_ID` oder `ZENODO_CONCEPT_ID` zum weiteren Bearbeiten. Streng genommen
< >   reicht die Concept-ID - aber diese ist nur schwierig zu finden, daher ist es
< >   einfacher, wenn wir die ID irgendeiner Version haben, die released wurde und
< >   fragen programmatisch nach der korrekten ID.
< > 
< > Generell ist die Kommunikation mit der API eine Abfolge von `curl`-Aufrufen. Die
< > einfachste Weise mit der API auch menschenlesbar zu kommunizieren ist `json`.
< > 
< > Daher hat fast jede Anfrage den Aufbau
< > 
< > ```bash
< > curl -s     # silent -> keine Ausgabe zur Verbindung, Downloadrate, etc.
< >      -XGET  # Methode; Meist GET, POST, DELETE, PUT, ..
< >      -H "Authorization: Bearer ${ZENODO_TOKEN}" # Authentifizierung
< >      --header "Content-Type: application/json"  # Wir senden JSON
< >      --header "Accept: application/json"        # Wir möchten JSON zurück
< >      --data ''                                  # Unsere Daten
< >      "${API_BASE}/api/deposit/depositions/${ZENODO_ID}" # API-Endpunkt
< > ```
< > 
< > Unterschiede gibt es nur in der Methode, den Daten und dem API-Endpunkt.
< > 
< > #### 2.1. Herausfinden der Concept-ID
< > 
< > Da das Script ein "Hands-Off"-Script werden soll, können wir nicht davon
< > ausgehen, dass wir immer die aktuellste Version des Releases kennen. Daher
< > können wir mittels der Concept-ID eine Anfrage stellen und uns die neueste
< > Version zurückgeben lassen. Hierzu benötigen wir nur irgendeine Version des zu
< > aktualisierenden Zenodo-Eintrages. Von diesem lassen wir uns die Metadaten geben
< > und im Feld `conceptrecid` steht dann die zugehörige Concept-ID.
< > 
< > #### 2.2. Erstellung einer neuen Version
< > 
< > Da wir sehr defensiv sind und lieber mit einem Fehler aufhören statt etwas
< > kaputt zu machen holen wir uns zunächst den aktuellen "state" der neuesten
< > Version. Eine Suche nach der `conceptrecid` liefert uns die Metadaten und auch
< > den aktuellen Zustand der neuesten Version. Für gewöhnlich gehen wir davon aus,
< > dass hier alles "done" ist - also released und unbearbeitet.
< > 
< > Falls man im Web allerdings angefangen hat den Eintrag zu editieren (o.ä.) steht
< > hier dann statt einem "done" ein "inprogress", was auf einen gerade laufenden
< > Edit hinweist. In diesem Falle brechen wir mit einem Fehler ab. Entweder
< > verwirft man vorher seine Änderungen oder publiziert sie.
< > 
< > Wir erstellen dann über den `newversion`-endpunkt der API eine neue Version und
< > schreiben den neuen Eintrag, ID, etc. in variablen. Bei Zenodo hängt an einem
< > kopierten (geklontem) Eintrag dann noch ein Verweis zu den alten Datensätzen
< > an - es kann ja sein, dass man mit einer neuen Version nur Metadaten oder Lizenz
< > ändert, aber nicht die Daten selbst. Diese Verweise werden daher direkt
< > entfernt.
< > 
< > #### 2.3. Upload des Archives und Veröffentlichung
< > 
< > Gegen Ende stellen wir noch sicher, dass unser Archiv auch lokal vorhanden ist
< > und laden es hoch. In den Metadaten überschreiben wir dann noch die Felder
< > `publication_date` und fügen zum Feld `dates` noch das Event `updated` mit einer
< > kleinen Beschreibung hinzu.
< > 
< > Vor dem Release holen wir noch einmal den gesamten Datensatz, den wir nun
< > automatisch publishen lesbar von Zenodo und geben ihn ins log aus. So kann man
< > auch innerhalb von Gitlab sehen, was genau hochgeladen wurde.
< > 
< > Zum Abschluss senden wir dann noch die Anfrage an `.../$id/actions/publish` um
< > das Release abzuschließen.
< > 
< > ## Setup und Anpassung
< > 
< > Zur regelmäßigen Archivierung werden die Bash-Skripte durch GitLab selbst mit
< > einer CI/CD Pipeline ausgeführt. Daten von Wikidata heruntergeladen, verpackt,
< > das erstellte `.tar.bz2`-Archiv als "Release" zur Verfügung gestellt und
< > schließlich zu Zenodo hochgeladen.
< > 
< > ### Forken
< > 
< > Wenn mensch dieses Beispielprojekt für eigene Daten in ihrer jeweils eigenen
< > Domäne nutzen möchte, so muss dieses Projekt zunächst
< > "[geforked](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/forks/new)"
< > oder "geklont" und angepasst werden.
< > 
< > ### Anpassung auf eigene Umgebung
< > 
< > Zunächst muss die SPARQL-query geändert werden. Dafür kann `query_example.rq`
< > als Grundlage genommen und dann als `query.rq` gespeichert werden.
< > 
< > Falls die Items nicht nur in einer Query abgefragt werden können, ist dies kein
< > Problem. Alle queries nach dem Muster `query[0-9]*.rq` (also `query.rq`,
< > `query2.rq`, `query123456.rq`, aber NICHT `query123_abc.rq` o.ä.) werden
< > ausgeführt, die Items in einer Datei gesammelt und anschließen nur 1x gesammelt
< > abgefragt.
< > 
< > Je nachdem ob die Bash-Skripte lokal oder in einer CI/CD Pipeline ausgeführt
< > werden sollen, müssen die entsprechenden Zeilen am Beginn der Skripte
< > auskommentiert werden oder nicht (siehe Kommentare in den Skripten selbst).
< > 
< > ### CI/CD Mechanismus
< > 
< > #### das CI-Script
< > 
< > Das GitLab CI-Script ist eine YAML Datei (`.gitlab-ci.yml`). Diese legt drei
< > Jobs an und führt sie nacheinander aus: `build-job`, `release-job` und
< > `publish-job`.
< > 
< > 1. Der `build-job` wird ausgeführt, wenn ein geplanter Auftrag oder ein
< >    Commit-Tag vorliegt. In diesem Job werden, falls nicht vorhanden, die
< >    erforderlichen items installiert, das eigentliche Skript `get_items.bash`
< >    ausgeführt und eine Archiv-Datei mit dem aktuellen Datum generiert. Die
< >    generierte Datei wird als Artefakt gespeichert.
< > 2. Der `release-job` wird nur dann ausgeführt, wenn der `build-job` erfolgreich
< >    war. In diesem Job wird eine Release erstellt, die den Namen
< >    `Release item-Registry vom <Aktuelles_Datum>` trägt und eine Beschreibung
< >    enthält. Die generierte Datei aus dem `build-job` wird als Asset der Release
< >    hinzugefügt.
< > 3. Der `publish-job` wird nur ausgeführt, wenn in der Gitlab-Pipeline die
< >    Variable `PUBLISH` auf `true` gesetzt wurde - ansonsten wird dieser
< >    übersprungen. Der Job stellt sicher, dass das erstellte Archiv aus dem
< >    `build-job` verfügbar ist und der `release-job` problemfrei durchgelaufen
< >    ist. Dann wird das eigentliche Skript `upload_zenodo.bash` ausgeführt,
< >    welches sich um des gesamten Publikationsprozess kümmert.
< > 
< > #### Runner
< > 
< > Es muss ein Runner ausgewählt und der Tag des Runners in `.gitlab-ci.yaml`
< > angegeben werden. Für Mitglieder des _Methods Innovation Lab_ der HU Berlin ist
< > bereits ein Runner eingerichtet.
< > 
< > #### Variablen
< > 
< > Für die CI/CD müssen Variablen gesetzt werden, die vom CI Script genutzt werden.
< > Hierzu ruft mensch die `Settings->CI/CD` auf:
< > 
< > ![Settings CI/CD](img/tutorial-2-settings-ci_cd.png)
< > 
< > - **API_BASE**: Stellt die Basisadresse für API-Aufrufe dar. Standardmäßig ist
< >   es auf den Sandbox-Endpunkt von Zenodo gesetzt, kann aber überschrieben
< >   werden, um Anfragen an die Live-Umgebung zu stellen (z.B.
< >   `https://zenodo.org/`).
< > - **ZENODO_TOKEN**: Dies ist der Token, der zur Authentifizierung bei Zenodo
< >   erforderlich ist und
< >   [entsprechend erstellt werden muss](https://zenodo.org/account/settings/applications/tokens/new/).
< > - **ZENODO_ID** ist die Nummer am Ende der URL eines Zenodo-Eintrages,
< >   beispielsweise `13818437` in `https://zenodo.org/records/13818437`, der den
< >   Datensatz enthalten soll. Dieser **muss vorher** einmalig von Hand angelegt
< >   und ausgefüllt werden, da an diesen die neuen Versionen angehangen werden.
< > 
< > ![Settings after variable creation](img/tutorial-6-settings-post.png)
< > 
< > #### Pipeline
< > 
< > Die automatische Erstellung von Archiven wird über `Build->Pipeline Schedules`
< > eingerichtet. Wichtig ist das setzen der Variable `SCHEDULED` auf `true`, da
< > sonst das Script nichts durchführt. Falls o.g. Variablen für Zenodo
< > bereitgestellt wurden, kann mittels `PUBLISH` auf `true` auch das publizieren
< > automatisiert werden.
< > 
< > ![Schedule creation](img/tutorial-7-schedule.png)
< > 
< > Nach dieser Einrichtung sollte alles weiter automatisch laufen. Man kann prüfen,
< > ob alle funktioniert, indem man die Pipeline einmal manuell startet und dabei
< > die Variable `SCHEDULED` auf `true` setzt und je nach Versuch `PUBLISH` auf
< > `true` oder `false`.
433c33,433
< ---
---
> 
> [![pipeline
> status](../../../badges/main/pipeline.svg)](../pipelines?page=1&scope=all&ref=main)
> [![Latest Release](../../badges/release.svg)](../../releases)
> 
> ![Project-logo](img/logo.jpg)
> 
> <!--toc:start-->
> 
> - [Hintergrund](#hintergrund)
>   - [Was machen wir?](#was-machen-wir)
>   - [Wozu wird das in der Wissenschaft gebraucht?](#wozu-wird-das-in-der-wissenschaft-gebraucht)
> 
> - [Implementation](#implementation)
> - [Skripte](#skripte)
>   - [1. Download und Speicherung der Daten](#1-download-und-speicherung-der-daten)
>     - [1.1 Umfang des Graphen mit SPARQL festlegen](#11-umfang-des-graphen-mit-sparql-festlegen)
>     - [1.2 Herunterladen der Subgraphen für jedes einzelne Item](#12-herunterladen-der-subgraphen-für-jedes-einzelne-item)
>     - [1.3 Archivierung](#13-archivierung)
>   - [2. Push zu Zenodo](#2-push-zu-zenodo)
>     - [2.1. Herausfinden der Concept-ID](#21-herausfinden-der-concept-id)
>     - [2.2. Erstellung einer neuen Version](#22-erstellung-einer-neuen-version)
>     - [2.3. Upload des Archives und Veröffentlichung](#23-upload-des-archives-und-veröffentlichung)
> - [Setup und Anpassung](#setup-und-anpassung)
>   - [Forken](#forken)
>   - [Anpassung auf eigene Umgebung](#anpassung-auf-eigene-umgebung)
>   - [CI/CD Mechanismus](#cicd-mechanismus) - [das CI-Script](#das-ci-script) -
>   [Runner](#runner) - [Variablen](#variablen) - [Pipeline](#pipeline)
>   <!--toc:end-->
> 
> ## Hintergrund
> 
> ### Was machen wir?
> 
> Als Teil der
> [Tool Registry](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities")
> bzw. jeden Forschungsprojekts, das Daten auf
> [Wikidata](https://wikidata.org/ "Wikidata") publiziert, müssen wir regelmäßig
> **unseren** kompletten Datensatz von Wikidata ziehen und in einem
> Versionskontrollsystem ablegen, um ihn dann als stabilen und referenzierbaren
> Datensatz publizieren und archivieren bzw. wieder in Linked-Open-Data Umgebungen
> und Triple Stores einspeisen zu können.
> 
> Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,
> die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert
> werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet
> automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs
> geändert haben, es Störungen in der Internetverbindung gab, etc.).
> 
> ### Wozu wird das in der Wissenschaft gebraucht?
> 
> Es gibt zwei Hauptargumente für die versionierte Sicherung von auf Wikidata
> publizierten Daten:
> 
> 1. Wikidata ist eine Platform außerhalb der unserer Kontrolle. Nicht nur können
>    Daten jederzeit durch Nutzer_innen geändert und erweitert werden (einer der
>    Hauptgründe überhaupt auf Wikidata zu setzen), sondern auch die technische
>    Infrastruktur kann sich ändern bzw. aufhören in ihrer aktuellen Form zu
>    existieren.
> 2. Auf diesen Daten aufsetzende Analysen benötigen für die Reproduzierbarkeit
>    ihrer Ergebnisse einen stabilen und referenzierbaren Datensatz. Gerade die in
>    unserer item Registry erfassten computationellen Werkzeuge unterliegen
>    rasanten Änderung. Und schon bei kleinen Abweichungen in der Versionsnummer
>    kann es zu teils massiv unterschiedlichen Ergebnissen in der Evaluation
>    kommen. Um hier Ergebnisse auch gegen neuere Ideen testen zu können muss für
>    einen sinnvollen Vergleich natürlich gegen die Version, mit der die
>    Forscher\*in zum Zeitpunkt der Publikation gearbeitet hat, getestet werden.
> 
> ## Implementation
> 
> Die Implementation erfolgt in drei Schritten, die in einer Kombination aus
> Bash-Skripten und einem [CI/CD-Mechanismus](.gitlab-ci.yml) ausgeführt werden.
> 
> 1. Download der Daten von Wikidata und Speicherung in einem komprimierten
>    Archivformat.
> 2. Das Archiv wird in das Repository committed und es findet ein Release statt.
> 3. Das Archiv wird auf [Zenodo](https://zenodo.org/) langzeitarchiviert[^1].
> 
> [^1]:
>     [Zenodo](https://about.zenodo.org/policies/) sichert eine Speicherung für
>     **mindestens** die nächsten 20 Jahre zu.
> 
> Das automatisierte Ausführen der Skripte und der Release geschehen über GitLab
> "Pipeline Schedules" mit Hilfe eines CI-Skriptes.
> 
> ::: {.callout-warning}
> 
> WICHTIG: Für die Ausführung werden sogenannte _Runner_ benötigt, die die
> notwendige Hard- und Software für die Ausführung der Scripte bereitstellen.
> Falls bisher kein _Runner_ erstellt wurde, muss dieser vorher (z.b. durch
> Administratoren, Projektmanager, ..)
> [eingerichtet werden](https://docs.gitlab.com/runner/install/).
> 
> :::
> 
> ::: {.callout-warning}
> 
> WICHTIG: die Bash-Skripte sind nur auf UNIX-Systemen (Linux und macOS)
> entwickelt und getestet worden. Über die Lauffähigkeit auf Windows-Systemen
> können wir keine Aussage treffen.
> 
> :::
> 
> ## Skripte
> 
> Für die Ausführung der Bash-Skripte müssen momentan auf der Kommandozeile
> folgende Programme verfügbar sein:
> 
> - [`jq`](https://jqlang.github.io/jq/): für die Manipulation von JSON.
> - `curl`: für den Download
> - `bzip2`: um das Archiv zu packen
> - `pv`: Für die Statusleiste während des downloads und automatischer Schätzung
>   der Restzeit
> 
> Unter Debian/Ubuntu lauten die entsprechenden Pakete gleichnamig.
> 
> ### 1. Download und Speicherung der Daten
> 
> Dieser Schritt wird von einem einzelnen [Bash-Skript](get_items.bash) übernommen
> und umfasst die folgenden drei Teile:
> 
> 1. Der Umfang unseres zu speichernden Datensatzes (Graphs) wird mit SPARQL
>    etabliert: Welche Wikidata-Items sind unsere Knoten erster Klasse, die den
>    Kern des Graphen ausmachen?
> 2. Alle diese Nodes und ihre Beziehungen zu einander werden über die Wikidata
>    API heruntergeladen. Dabei muss festgelegt werden, wie viele Schritte von den
>    Kernknoten weggegangen werden soll um nicht den gesamten Graphen von Wikidata
>    zu speichern.
> 3. Die heruntergeladenen Daten werden in ein Archivformat gepackt.
> 
> #### 1.1 Umfang des Graphen mit SPARQL festlegen
> 
> Zum Auffinden aller Items wird eine einfache SPARQL-Abfrage genutzt
> 
> <!-- hier können wir Tutorials, Dokumentation zu SPARQL verlinken -->, die die
> 
> IDs und eine Bezeichnung für die Items ausgibt. Im Fall unserer Tool Registry
> sind das Werkzeuge für die Digital Humanities und die Abfrage basiert auf den
> dafür entwickelten
> [SPARQL Queries](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql).
> 
> ```sparql
> SELECT DISTINCT
>   ?item ?itemLabel
> WHERE {
>   ?method wdt:P9309 ?tadirahID.
>   ?item wdt:P366 ?method;
>     (wdt:P31/(wdt:P279*)) wd:Q7397.
>   SERVICE wikibase:label {
>       bd:serviceParam wikibase:language "en,de,fr, [AUTO_LANGUAGE]".
>       ?item rdfs:label ?itemLabel.
>   }
> } LIMIT 5000
> ```
> 
> Diese Abfrage etabliert eine Liste von Methoden (`?method`), die als Items
> definiert sind, die eine TaDiRAH ID (`P9309`) besitzen. Dann wird nach allen
> Items gesucht, die über das Statement "has use" (`P366`) mit einer dieser
> Methoden verknüpft sind und im weitesten Sinne Software beschreiben
> (`(wdt:P31/(wdt:P279*)) wd:Q7397`). Über den Service "wikibase:label" werden die
> Tools dann noch um ihren Namen angereichert. Dieses ist nicht wirklich technisch
> notwendig für unseren Zweck, bietet aber einen "sanity check" von
> menschenlesbaren Bezeichnungen anstatt rein nummerischer IDs. Damit sich die
> Bezeichnung nicht abhängig von den Einstellungen des Betriebssystems, auf dem
> die Abfrage abgeführt wird, ändert, haben wir uns für englische Bezeichnungen
> entschieden und einen Fallback auf andere Sprachen und schließlich die
> Systemsprache gemacht.
> 
> Um direkt über den SPARQL-Endpoint von Wikidata abfragbar zu sein, muss diese
> Abfrage URL-encoded sein (ergo alle Lehr- und Sonderzeichen müssen escaped
> werden). Dieses wird über einen entsprechenden `curl`-Aufruf erreicht, der sich
> um die entsprechende Behandlung kümmert.
> 
> Somit wird aus
> 
> ```bash
> curl -s -XGET --get \
>               --data-urlencode "format=json" \
>               --data-urlencode "query@$QUERY" \
>               'https://query.wikidata.org/sparql'
> ```
> 
> zum Beispiel
> `https://query.wikidata.org/sparql?query=SELECT%20DISTINCT%20%0A%20%3Fitem%20%3FitemLabel%0AWHERE%20%7B%0A%20%3Fmethod%20wdt%3AP9309%20%3FtadirahID.%0A%20%3Fitem%20wdt%3AP366%20%3Fmethod%3B%0A%20(wdt%3AP31%2F(wdt%3AP279*))%20wd%3AQ7397.%0A%20SERVICE%20wikibase%3Alabel%20%7B%0A%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cde%2Cfr%2C%20en%22.%0A%20%3Fitem%20rdfs%3Alabel%20%3FitemLabel.%0A%20%7D%0A%7D%20LIMIT%205000`.
> 
> Das Skript fragt diese Liste als JSON an, benennt anschließend programmatisch
> keys um, und legt diese für den nächsten Schritt ab.
> 
> #### 1.2 Herunterladen der Subgraphen für jedes einzelne Item
> 
> Im folgenden wird über die Liste aus dem ersten Schritt iteriert und die
> Subgraphen für jedes einzelnen Item anhand seiner ID von Wikidata
> heruntergeladen. Wikidata bietet dazu mehrer Möglichkeiten. Zum einen gibt es
> eine offizielle REST API
> ([OpenAPI Swagger documentation](https://doc.wikimedia.org/Wikibase/master/js/rest-api/)),
> die ein Wikidata-spezifisches JSON ausgibt:
> 
> ```bash
> https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/${itemid}
> ```
> 
> Aktuell unterstützt diese API aber noch nicht die für uns notwendigen
> RDF-Serialisierungen, wie z.B. JSON-LD, Turtle oder RDF/XML. Diese sind über
> `Special:EntityData` URLs verfügbar, die quasi direkt das Ergebnis einer SPARQL
> `SELECT`-Abfrage aus deren Cache nehmen:
> 
> ```bash
> https://www.wikidata.org/wiki/Special:EntityData/${itemid}.${format}
> ```
> 
> Beide Varianten sind wesentlich performanter als direkte SPARQL Abfragen.
> 
> Im Ergebnis dieses Schrittes haben wir für jedes Item eine lokale RDF-Datei, die
> dann archiviert und wieder in alle gängigen Knowledge-Graphen importiert werden
> kann.
> 
> #### 1.3 Archivierung
> 
> Zum Abschluss wird aus den heruntergeladenen Daten ein `.tar.bz2`-Archiv
> erstellt und mit dem aktuellen Datum versehen. Durch diesen Schritt spielt es
> für den Platzverbrauch so gut wie keine Rolle, wie viele Serialisierungen wir
> speichern, da viele Angaben redundant sind und damit gut komprimiert werden
> können.
> 
> ### 2. Push zu Zenodo
> 
> Auch dieser Schritt wird von einem einzelnen [Bash-Skript](upload_zenodo.bash)
> übernommen und umfasst die folgenden Teile:
> 
> 1. Herausfinden der Concept-ID in dem das Datenset gespeichert werden soll
> 2. Erstellung einer neuen Version und auslesen der Metadaten
> 3. Upload des Archives und veröffentlichen der neuen Version
> 
> Bevor wir aber auf die eigentliche Arbeit Bezug nehmen können wird zunächst
> festgestellt, ob alle Umgebungsvariablen korrekt gesetzt sind und andernfalls
> mit einer entsprechenden Fehlermeldung abgebrochen. Daher können wir im
> folgenden davon ausgehen, dass diese Variablen korrekt gesetzt sind:
> 
> - `API_BASE` für den Server den wir benutzen (z.B. Sandbox oder Live)
> - `ZENODO_TOKEN` vorhanden ist und auch gültig (eine Test-Anfrage würde sonst
>   z.B. einen 403 "kein Zugriff" zurückmelden).
> - `ZENODO_ID` oder `ZENODO_CONCEPT_ID` zum weiteren Bearbeiten. Streng genommen
>   reicht die Concept-ID - aber diese ist nur schwierig zu finden, daher ist es
>   einfacher, wenn wir die ID irgendeiner Version haben, die released wurde und
>   fragen programmatisch nach der korrekten ID.
> 
> Generell ist die Kommunikation mit der API eine Abfolge von `curl`-Aufrufen. Die
> einfachste Weise mit der API auch menschenlesbar zu kommunizieren ist `json`.
> 
> Daher hat fast jede Anfrage den Aufbau
> 
> ```bash
> curl -s     # silent -> keine Ausgabe zur Verbindung, Downloadrate, etc.
>      -XGET  # Methode; Meist GET, POST, DELETE, PUT, ..
>      -H "Authorization: Bearer ${ZENODO_TOKEN}" # Authentifizierung
>      --header "Content-Type: application/json"  # Wir senden JSON
>      --header "Accept: application/json"        # Wir möchten JSON zurück
>      --data ''                                  # Unsere Daten
>      "${API_BASE}/api/deposit/depositions/${ZENODO_ID}" # API-Endpunkt
> ```
> 
> Unterschiede gibt es nur in der Methode, den Daten und dem API-Endpunkt.
> 
> #### 2.1. Herausfinden der Concept-ID
> 
> Da das Script ein "Hands-Off"-Script werden soll, können wir nicht davon
> ausgehen, dass wir immer die aktuellste Version des Releases kennen. Daher
> können wir mittels der Concept-ID eine Anfrage stellen und uns die neueste
> Version zurückgeben lassen. Hierzu benötigen wir nur irgendeine Version des zu
> aktualisierenden Zenodo-Eintrages. Von diesem lassen wir uns die Metadaten geben
> und im Feld `conceptrecid` steht dann die zugehörige Concept-ID.
> 
> #### 2.2. Erstellung einer neuen Version
> 
> Da wir sehr defensiv sind und lieber mit einem Fehler aufhören statt etwas
> kaputt zu machen holen wir uns zunächst den aktuellen "state" der neuesten
> Version. Eine Suche nach der `conceptrecid` liefert uns die Metadaten und auch
> den aktuellen Zustand der neuesten Version. Für gewöhnlich gehen wir davon aus,
> dass hier alles "done" ist - also released und unbearbeitet.
> 
> Falls man im Web allerdings angefangen hat den Eintrag zu editieren (o.ä.) steht
> hier dann statt einem "done" ein "inprogress", was auf einen gerade laufenden
> Edit hinweist. In diesem Falle brechen wir mit einem Fehler ab. Entweder
> verwirft man vorher seine Änderungen oder publiziert sie.
> 
> Wir erstellen dann über den `newversion`-endpunkt der API eine neue Version und
> schreiben den neuen Eintrag, ID, etc. in variablen. Bei Zenodo hängt an einem
> kopierten (geklontem) Eintrag dann noch ein Verweis zu den alten Datensätzen
> an - es kann ja sein, dass man mit einer neuen Version nur Metadaten oder Lizenz
> ändert, aber nicht die Daten selbst. Diese Verweise werden daher direkt
> entfernt.
> 
> #### 2.3. Upload des Archives und Veröffentlichung
> 
> Gegen Ende stellen wir noch sicher, dass unser Archiv auch lokal vorhanden ist
> und laden es hoch. In den Metadaten überschreiben wir dann noch die Felder
> `publication_date` und fügen zum Feld `dates` noch das Event `updated` mit einer
> kleinen Beschreibung hinzu.
> 
> Vor dem Release holen wir noch einmal den gesamten Datensatz, den wir nun
> automatisch publishen lesbar von Zenodo und geben ihn ins log aus. So kann man
> auch innerhalb von Gitlab sehen, was genau hochgeladen wurde.
> 
> Zum Abschluss senden wir dann noch die Anfrage an `.../$id/actions/publish` um
> das Release abzuschließen.
> 
> ## Setup und Anpassung
> 
> Zur regelmäßigen Archivierung werden die Bash-Skripte durch GitLab selbst mit
> einer CI/CD Pipeline ausgeführt. Daten von Wikidata heruntergeladen, verpackt,
> das erstellte `.tar.bz2`-Archiv als "Release" zur Verfügung gestellt und
> schließlich zu Zenodo hochgeladen.
> 
> ### Forken
> 
> Wenn mensch dieses Beispielprojekt für eigene Daten in ihrer jeweils eigenen
> Domäne nutzen möchte, so muss dieses Projekt zunächst
> "[geforked](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/forks/new)"
> oder "geklont" und angepasst werden.
> 
> ### Anpassung auf eigene Umgebung
> 
> Zunächst muss die SPARQL-query geändert werden. Dafür kann `query_example.rq`
> als Grundlage genommen und dann als `query.rq` gespeichert werden.
> 
> Falls die Items nicht nur in einer Query abgefragt werden können, ist dies kein
> Problem. Alle queries nach dem Muster `query[0-9]*.rq` (also `query.rq`,
> `query2.rq`, `query123456.rq`, aber NICHT `query123_abc.rq` o.ä.) werden
> ausgeführt, die Items in einer Datei gesammelt und anschließen nur 1x gesammelt
> abgefragt.
> 
> Je nachdem ob die Bash-Skripte lokal oder in einer CI/CD Pipeline ausgeführt
> werden sollen, müssen die entsprechenden Zeilen am Beginn der Skripte
> auskommentiert werden oder nicht (siehe Kommentare in den Skripten selbst).
> 
> ### CI/CD Mechanismus
> 
> #### das CI-Script
> 
> Das GitLab CI-Script ist eine YAML Datei (`.gitlab-ci.yml`). Diese legt drei
> Jobs an und führt sie nacheinander aus: `build-job`, `release-job` und
> `publish-job`.
> 
> 1. Der `build-job` wird ausgeführt, wenn ein geplanter Auftrag oder ein
>    Commit-Tag vorliegt. In diesem Job werden, falls nicht vorhanden, die
>    erforderlichen items installiert, das eigentliche Skript `get_items.bash`
>    ausgeführt und eine Archiv-Datei mit dem aktuellen Datum generiert. Die
>    generierte Datei wird als Artefakt gespeichert.
> 2. Der `release-job` wird nur dann ausgeführt, wenn der `build-job` erfolgreich
>    war. In diesem Job wird eine Release erstellt, die den Namen
>    `Release item-Registry vom <Aktuelles_Datum>` trägt und eine Beschreibung
>    enthält. Die generierte Datei aus dem `build-job` wird als Asset der Release
>    hinzugefügt.
> 3. Der `publish-job` wird nur ausgeführt, wenn in der Gitlab-Pipeline die
>    Variable `PUBLISH` auf `true` gesetzt wurde - ansonsten wird dieser
>    übersprungen. Der Job stellt sicher, dass das erstellte Archiv aus dem
>    `build-job` verfügbar ist und der `release-job` problemfrei durchgelaufen
>    ist. Dann wird das eigentliche Skript `upload_zenodo.bash` ausgeführt,
>    welches sich um des gesamten Publikationsprozess kümmert.
> 
> #### Runner
> 
> Es muss ein Runner ausgewählt und der Tag des Runners in `.gitlab-ci.yaml`
> angegeben werden. Für Mitglieder des _Methods Innovation Lab_ der HU Berlin ist
> bereits ein Runner eingerichtet.
> 
> #### Variablen
> 
> Für die CI/CD müssen Variablen gesetzt werden, die vom CI Script genutzt werden.
> Hierzu ruft mensch die `Settings->CI/CD` auf:
> 
> ![Settings CI/CD](img/tutorial-2-settings-ci_cd.png)
> 
> - **API_BASE**: Stellt die Basisadresse für API-Aufrufe dar. Standardmäßig ist
>   es auf den Sandbox-Endpunkt von Zenodo gesetzt, kann aber überschrieben
>   werden, um Anfragen an die Live-Umgebung zu stellen (z.B.
>   `https://zenodo.org/`).
> - **ZENODO_TOKEN**: Dies ist der Token, der zur Authentifizierung bei Zenodo
>   erforderlich ist und
>   [entsprechend erstellt werden muss](https://zenodo.org/account/settings/applications/tokens/new/).
> - **ZENODO_ID** ist die Nummer am Ende der URL eines Zenodo-Eintrages,
>   beispielsweise `13818437` in `https://zenodo.org/records/13818437`, der den
>   Datensatz enthalten soll. Dieser **muss vorher** einmalig von Hand angelegt
>   und ausgefüllt werden, da an diesen die neuen Versionen angehangen werden.
> 
> ![Settings after variable creation](img/tutorial-6-settings-post.png)
> 
> #### Pipeline
> 
> Die automatische Erstellung von Archiven wird über `Build->Pipeline Schedules`
> eingerichtet. Wichtig ist das setzen der Variable `SCHEDULED` auf `true`, da
> sonst das Script nichts durchführt. Falls o.g. Variablen für Zenodo
> bereitgestellt wurden, kann mittels `PUBLISH` auf `true` auch das publizieren
> automatisiert werden.
> 
> ![Schedule creation](img/tutorial-7-schedule.png)
> 
> Nach dieser Einrichtung sollte alles weiter automatisch laufen. Man kann prüfen,
> ob alle funktioniert, indem man die Pipeline einmal manuell startet und dabei
> die Variable `SCHEDULED` auf `true` setzt und je nach Versuch `PUBLISH` auf
> `true` oder `false`.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/data_zfdg.qmd quarto/methodenlabor/data_zfdg.qmd
2c2
< title: "data_ZfDG (Methodenlabor)"
---
> title: "Methodenlabor / data_ZfDG (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/data_zfdg"
>       icon: "gitlab"
11c11
< # data_ZfDG (Methodenlabor)
---
> # Methodenlabor / data_ZfDG (Methodenlabor)
14a15,32
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Data curation"
> >   - "Software"
> > date: "2025-06-18"
> > lang: "en"
> > tags:
> > - "NFDI"
> > - "4Memory"
16,31c34
< > description: |
< >    Full text files for ZfDG
< > date: 2025-06-18 
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Data curation
< >       - Software
---
> > description: "Full text files for ZfDG\n"
33,43c36,42
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: data  # writing, code, or data
< > status: done
< > lang: en
< > markdown: pandoc
< > tags:
< >   - NFDI
< >   - 4Memory
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "data"
> > status: "done"
> > markdown: "pandoc"
45,46d43
< > 
< > This repo contains the TEI/XML files for ZdFG and a number of derivative formats.
48c45,46
< ---
---
> 
> This repo contains the TEI/XML files for ZdFG and a number of derivative formats.
Nur in quarto/methodenlabor: data_ZfDG.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/doc_documentation.qmd quarto/methodenlabor/doc_documentation.qmd
2c2
< title: "Documentation (Methodenlabor)"
---
> title: "Methodenlabor / Documentation (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/doc_documentation"
>       icon: "gitlab"
11c11
< # Documentation (Methodenlabor)
---
> # Methodenlabor / Documentation (Methodenlabor)
14,18c14,18
< > title: Good™ Documentation
< > description: |
< >   Dieses Repository enthält eine Beispielstruktur, nach welchen Regeln und in welcher Ausführlichkeit sinnvoll dokumentiert werden sollte.
< > lang: de
< > date: 2025-06-03
---
> > title: "Good™ Documentation"
> > date: "2025-06-03"
> > lang: "de"
> > description: "Dieses Repository enthält eine Beispielstruktur, nach welchen Regeln\
> >   \ und in welcher Ausführlichkeit sinnvoll dokumentiert werden sollte.\n"
20,38c20,38
< >   - name: Nicole Dresselhaus
< >     affiliation:
< >       - name: Humboldt-Universität zu Berlin
< >         url: https://hu-berlin.de
< >     email: nicole.dresselhaus@hu-berlin.de
< >     correspondence: true
< >     orcid: 0009-0008-8850-3679
< >     roles:
< >       - Conceptualization
< >       - "Writing – first draft"
< >       - "Writing – review & editing"
< >   - name: Till Grallert
< >     affiliation:
< >       - name: Humboldt-Universität zu Berlin
< >         url: https://hu-berlin.de
< >     email: till.grallert@hu-berlin.de
< >     roles:
< >       - Supervision
< >       - Validation
---
> > - name: "Nicole Dresselhaus"
> >   affiliation:
> >   - name: "Humboldt-Universität zu Berlin"
> >     url: "https://hu-berlin.de"
> >   email: "nicole.dresselhaus@hu-berlin.de"
> >   correspondence: true
> >   orcid: "0009-0008-8850-3679"
> >   roles:
> >   - "Conceptualization"
> >   - "Writing – first draft"
> >   - "Writing – review & editing"
> > - name: "Till Grallert"
> >   affiliation:
> >   - name: "Humboldt-Universität zu Berlin"
> >     url: "https://hu-berlin.de"
> >   email: "till.grallert@hu-berlin.de"
> >   roles:
> >   - "Supervision"
> >   - "Validation"
40,112d39
< > 
< > ## Ziel / Zweck
< > 
< > Dokumentation ist hilfreich, dennoch fällt sie meist anderen Sachzwängen zum
< > Opfer. Dieses Repository bietet diverse Markdown-Dateien als ausfüllbare
< > Vorlage, damit man sich auf das wesentliche konzentrieren kann bzw. wichtige
< > Dinge für etwaige Nachfolger\*innen nicht vergisst.
< > 
< > ## Nutzung
< > 
< > Wir haben GitLab-Templates, die man benutzen kann, wenn man ein Projekt startet.
< > Falls bereits Code oder ein Repository besteht, ist es am Besten, wenn man
< > dennoch im GitLab ein neues Projekt mit diesem Template erstellt und
< > anschließend die existierenden Dateien herüberkopiert.
< > 
< > 1. Neues Projekt erstellen  
< >    ![](imgs/use_template_1.png)
< > 2. Aus Template  
< >    ![](imgs/use_template_2.png)
< > 3. Gruppe wählen  
< >    ![](imgs/use_template_3.png)
< > 4. Template auswählen & erstellen  
< >    ![](imgs/use_template_4.png)
< > 
< > ### Code-Project
< > 
< > Das
< > [Code-Project-Template](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template)
< > ist für Repositories gedacht, die irgendeine Art von Verarbeitung haben, bei der
< > primär Daten analysiert, weiterverarbeitet oder ausgewertet werden ODER es sich
< > um ein Applikationsprojekt im klassischen Sinne handelt.
< > 
< > Ziel ist hier die Entwicklung und langfristig die Installation,
< > Veröffentlichung,Nutzung und Wartung der Software.
< > 
< > Zur genauer Struktur und Handhabung sei auf die `README.md` dort verwiesen.
< > 
< > ### Daten-Project
< > 
< > Analog zum Code-Project ist das
< > [Daten-Project-Template](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template)
< > für Repositories gedacht, die irgendeine Art von Daten als Output haben. Hierbei
< > geht es um die reine Vorverarbeitung der Daten und nicht um Analyse.
< > Typischerweise liegen hier z.b. Roh-Daten (Bilder, etc.) vor und der Output ist
< > ein Maschinenlesbares Format (z.b. JSON des Textes mit Annotationen).
< > 
< > Ziel ist hier die Dokumentation und die Reproduzierbarkeit von
< > `Quelle -> Datensatz`.
< > 
< > Zur genauer Struktur und Handhabung sei auf die `README.md` dort verwiesen.
< > 
< > ## Wissenschaftlicher Hintergrund
< > 
< > Dieses gesamte Repository wurde erstellt um Forschenden eine fundierte,
< > praktische Hilfe zu geben, um ihre Projekte nach guten Standards zu
< > dokumentieren. Insbesondere hervorzuheben sind hier die
< > [Endings-Principles for Digital Longevity](https://endings.uvic.ca/principles.html),
< > [FAIR-Principles](https://www.go-fair.org/fair-principles/) und den
< > [Ten simple rules for documenting scientific software](https://doi.org/10.1371/journal.pcbi.1006561).
< > 
< > Für eine Ausführliche auseinandersetzung mit dieser Thematik siehe
< > [BACKGROUND.md](background/BACKGROUND.md)
< > 
< > ## Bekannte Einschränkungen
< > 
< > Dieses Repository sollte nicht als der einzig richtige Weg angesehen werden,
< > sondern ist eher ein Aufschlag, Erkenntnisse in der eigenen Arbeit auch
< > praktisch umzusetzen. Jede hier aufgestellte Regel und Empfehlung kann und
< > sollte - je nach Umständen - auch gebrochen werden.
< > 
< > ## Lizenz & Zitation
< > 
< > Folgt...
114c41,114
< ---
---
> 
> 
> ## Ziel / Zweck
> 
> Dokumentation ist hilfreich, dennoch fällt sie meist anderen Sachzwängen zum
> Opfer. Dieses Repository bietet diverse Markdown-Dateien als ausfüllbare
> Vorlage, damit man sich auf das wesentliche konzentrieren kann bzw. wichtige
> Dinge für etwaige Nachfolger\*innen nicht vergisst.
> 
> ## Nutzung
> 
> Wir haben GitLab-Templates, die man benutzen kann, wenn man ein Projekt startet.
> Falls bereits Code oder ein Repository besteht, ist es am Besten, wenn man
> dennoch im GitLab ein neues Projekt mit diesem Template erstellt und
> anschließend die existierenden Dateien herüberkopiert.
> 
> 1. Neues Projekt erstellen  
>    ![](imgs/use_template_1.png)
> 2. Aus Template  
>    ![](imgs/use_template_2.png)
> 3. Gruppe wählen  
>    ![](imgs/use_template_3.png)
> 4. Template auswählen & erstellen  
>    ![](imgs/use_template_4.png)
> 
> ### Code-Project
> 
> Das
> [Code-Project-Template](https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template)
> ist für Repositories gedacht, die irgendeine Art von Verarbeitung haben, bei der
> primär Daten analysiert, weiterverarbeitet oder ausgewertet werden ODER es sich
> um ein Applikationsprojekt im klassischen Sinne handelt.
> 
> Ziel ist hier die Entwicklung und langfristig die Installation,
> Veröffentlichung,Nutzung und Wartung der Software.
> 
> Zur genauer Struktur und Handhabung sei auf die `README.md` dort verwiesen.
> 
> ### Daten-Project
> 
> Analog zum Code-Project ist das
> [Daten-Project-Template](https://scm.cms.hu-berlin.de/methodenlabor/templates/data-project-template)
> für Repositories gedacht, die irgendeine Art von Daten als Output haben. Hierbei
> geht es um die reine Vorverarbeitung der Daten und nicht um Analyse.
> Typischerweise liegen hier z.b. Roh-Daten (Bilder, etc.) vor und der Output ist
> ein Maschinenlesbares Format (z.b. JSON des Textes mit Annotationen).
> 
> Ziel ist hier die Dokumentation und die Reproduzierbarkeit von
> `Quelle -> Datensatz`.
> 
> Zur genauer Struktur und Handhabung sei auf die `README.md` dort verwiesen.
> 
> ## Wissenschaftlicher Hintergrund
> 
> Dieses gesamte Repository wurde erstellt um Forschenden eine fundierte,
> praktische Hilfe zu geben, um ihre Projekte nach guten Standards zu
> dokumentieren. Insbesondere hervorzuheben sind hier die
> [Endings-Principles for Digital Longevity](https://endings.uvic.ca/principles.html),
> [FAIR-Principles](https://www.go-fair.org/fair-principles/) und den
> [Ten simple rules for documenting scientific software](https://doi.org/10.1371/journal.pcbi.1006561).
> 
> Für eine Ausführliche auseinandersetzung mit dieser Thematik siehe
> [BACKGROUND.md](background/BACKGROUND.md)
> 
> ## Bekannte Einschränkungen
> 
> Dieses Repository sollte nicht als der einzig richtige Weg angesehen werden,
> sondern ist eher ein Aufschlag, Erkenntnisse in der eigenen Arbeit auch
> praktisch umzusetzen. Jede hier aufgestellte Regel und Empfehlung kann und
> sollte - je nach Umständen - auch gebrochen werden.
> 
> ## Lizenz & Zitation
> 
> Folgt...
Nur in quarto/methodenlabor: Documentation.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/fs_documentation.qmd quarto/methodenlabor/fs_documentation.qmd
2c2
< title: "FS_documentation (Methodenlabor)"
---
> title: "Methodenlabor / FS_documentation (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation"
>       icon: "gitlab"
11c11
< # FS_documentation (Methodenlabor)
---
> # Methodenlabor / FS_documentation (Methodenlabor)
14d13
< > subtitle: "README"
16,34c15,27
< > date: 2025-06-17
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< > institute:
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 4    # value from 1 (low) to 5 (high)
< > urgency: 3     # value from 1 (low) to 5 (high)
< > type: writing
< > lang: en
---
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> > date: "2025-06-17"
> > lang: "en"
36,40c29,40
< >   - NFDI
< >   - 4Memory
< >   - field survey
< >   - Wikidata
< >   - LOD
---
> > - "NFDI"
> > - "4Memory"
> > - "field survey"
> > - "Wikidata"
> > - "LOD"
> > subtitle: "README"
> > institute:
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 4
> > urgency: 3
> > type: "writing"
42,65d41
< > 
< > This repository gathers the relevant documentation for our field survey of the current state and development of digital/computational approaches to history. 
< > 
< > # WikiProject
< > 
< > The public facing part of the documentation can be found on the projects' [WikiProject][wikiproject]. The source files for this WikiProject are maintained in the folder `WikiProject/`.
< > 
< > # Data
< > 
< > All relevant data will be published or already has been published as linked open data on [Wikidata](https://www.wikidata.org/). Input data and data being currently prepared for publication on Wikidata are kept in individual repositories in our [GitLab Group "Methodenlabor"](https://scm.cms.hu-berlin.de/methodenlabor). Their names start with ["data_"](https://scm.cms.hu-berlin.de/methodenlabor?filter=data_). Note that these repositories aren't necessarily publicly accessible.
< > 
< > The data model is maintained in the current repository (`datenmodell.md`) and published to Zenodo at <https://doi.org/10.5281/zenodo.14752916>.
< > 
< > # Publications
< > 
< > Beyond the [WikiProject][wikiproject], we are in the process of publishing documentation and advertising parts of the project. 
< > 
< > - Blogposts: kept in a separate project ([writing](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/tree/main/blog)).
< > 
< > # SPARQL Queries
< > 
< > The necessary SPARQL queries to query Wikidata and generate the subsets for our field survey are maintained in a [separate repository](https://scm.cms.hu-berlin.de/methodenlabor/fs_sparql).
< > 
< > [wikiproject]: "https://www.wikidata.org/wiki/Wikidata:WikiProject_Field_Survey_Digital_Humanities_/_Digital_History"
67c43,66
< ---
---
> 
> This repository gathers the relevant documentation for our field survey of the current state and development of digital/computational approaches to history.
> 
> # WikiProject
> 
> The public facing part of the documentation can be found on the projects' [WikiProject][wikiproject]. The source files for this WikiProject are maintained in the folder `WikiProject/`.
> 
> # Data
> 
> All relevant data will be published or already has been published as linked open data on [Wikidata](https://www.wikidata.org/). Input data and data being currently prepared for publication on Wikidata are kept in individual repositories in our [GitLab Group "Methodenlabor"](https://scm.cms.hu-berlin.de/methodenlabor). Their names start with ["data_"](https://scm.cms.hu-berlin.de/methodenlabor?filter=data_). Note that these repositories aren't necessarily publicly accessible.
> 
> The data model is maintained in the current repository (`datenmodell.md`) and published to Zenodo at <https://doi.org/10.5281/zenodo.14752916>.
> 
> # Publications
> 
> Beyond the [WikiProject][wikiproject], we are in the process of publishing documentation and advertising parts of the project. 
> 
> - Blogposts: kept in a separate project ([writing](https://scm.cms.hu-berlin.de/methodenlabor/writing/-/tree/main/blog)).
> 
> # SPARQL Queries
> 
> The necessary SPARQL queries to query Wikidata and generate the subsets for our field survey are maintained in a [separate repository](https://scm.cms.hu-berlin.de/methodenlabor/fs_sparql).
> 
> [wikiproject]: "https://www.wikidata.org/wiki/Wikidata:WikiProject_Field_Survey_Digital_Humanities_/_Digital_History"
Nur in quarto/methodenlabor: FS_documentation.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/fs_sparql.qmd quarto/methodenlabor/fs_sparql.qmd
2c2
< title: "fs_sparql (Methodenlabor)"
---
> title: "Methodenlabor / fs_sparql (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/fs_sparql
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/fs_sparql"
>       icon: "gitlab"
11c11
< # fs_sparql (Methodenlabor)
---
> # Methodenlabor / fs_sparql (Methodenlabor)
14d13
< > subtitle: "README"
16,35c15,28
< > date: 2025-05-22
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Software
< > institute:
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: code
< > lang: en
---
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Software"
> > date: "2025-05-22"
> > lang: "en"
37,41c30,41
< >   - NFDI
< >   - 4Memory
< >   - field survey
< >   - SPARQL
< >   - LOD
---
> > - "NFDI"
> > - "4Memory"
> > - "field survey"
> > - "SPARQL"
> > - "LOD"
> > subtitle: "README"
> > institute:
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "code"
43,104d42
< > 
< > This repository holds SPARQL queries for conducting field surveys for specific disciplines on Wikidata. Documentation of the larger project can be found at the [WikiProject](https://www.wikidata.org/wiki/Wikidata:WikiProject_Field_Survey_Digital_Humanities_/_Digital_History) and in this [repository](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation). An initial blog post has been published [here](https://dhistory.hypotheses.org/9858).
< > 
< > Our general approach is premised on the idea that looking for classified output of research is more fruitefuil than the explicitly encoded disciplinary affiliations of researchers or institutions. To check this assumption, one can use the query [`org_clio-online`](select/org_clio-online.rq) and see how few of the institutions with a Clio Organisation ID have some field of work listed with `P101`.
< > 
< > For sample results see this [map of digital humanists in Germany, Austria, and Switzerland](https://query-main.wikidata.org/embed.html#%23title%3A%20Digital%20Historians%20and%20Digital%20Humanists%20in%20the%20DACH%20region%0A%23defaultView%3AMap%7B%22hide%22%3A%5B%22%3Fcoords%22%5D%2C%20%22markercluster%22%3A%20%22true%22%7D%0ASELECT%20DISTINCT%0A%20%20%3Fpers%0A%20%20%28CONCAT%28%3FpersLabel%2C%20%22%20%28%22%2C%20%3ForgLabel%2C%20%22%29%22%29%20AS%20%3Flabel%29%0A%20%20%3Fcoords%0A%23%20get%20researchers%20in%20specific%20fields%20of%20work%3A%20potentially%20very%20large%20number%20of%20results%0AWITH%20%7B%0A%20%20SELECT%20DISTINCT%0A%20%20%20%20%3Fpers%20%3Forg%0A%20%20WHERE%20%7B%0A%20%20%20%20%23BIND%28wd%3AQ49144246%20AS%20%3Fpers%29.%20%23%20debugging%20Q99529696%0A%20%20%20%20%3Fpers%20wdt%3AP31%20wd%3AQ5%3B%20%20%20%20%20%20%20%20%20%20%23%20humans%0A%20%20%20%20%20%20wdt%3AP101%20%3FfieldOfWork%3B%20%20%20%20%20%20%23%20having%20a%20field%20of%20work%0A%20%20%20%20%20%20wdt%3AP108%7Cwdt%3AP1416%20%3Forg.%20%20%20%20%23%20employer%0A%20%20%20%20%3Forg%20wdt%3AP17%2Fwdt%3AP279%2a%20%3Fcountry%20.%20%20%23%20get%20country%0A%20%20%20%20%23%20limit%20to%20fields%20of%20work%0A%20%20%20%20VALUES%20%3FfieldOfWork%20%7B%20%20%20%20%20%20%20%20%20%0A%20%20%20%20%20%20wd%3AQ336387%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20digital%20history%0A%20%20%20%20%20%20wd%3AQ1026962%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20digital%20humanities%0A%20%20%20%20%7D%0A%20%20%20%20%23%20limit%20to%20countries%0A%20%20%20%20VALUES%20%3Fcountry%20%7B%0A%20%20%20%20%20%20wd%3AQ183%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Germany%0A%20%20%20%20%20%20wd%3AQ39%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Switzerland%0A%20%20%20%20%20%20wd%3AQ40%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Austria%0A%20%20%20%20%7D%0A%20%20%7D%20LIMIT%208000%0A%7D%20as%20%25researchers%0A%23%20get%20affiliations%20and%20the%20latest%20start%20and%20end%20date%0AWITH%20%7B%0A%20%20SELECT%20DISTINCT%0A%20%20%20%20%3Fpers%20%3Forg%0A%20%20%20%20%28max%28%3Fonset%29%20as%20%3FonsetLatest%29%0A%20%20%20%20%28max%28%3Fterminus%29%20as%20%3FterminusLatest%29%0A%20%20WHERE%20%7B%0A%20%20%20%20INCLUDE%20%25researchers%20.%0A%20%20%20%20%3Fpers%20p%3AP108%20%7C%20p%3AP1416%20%3ForgStmt.%0A%20%20%20%20%3ForgStmt%20ps%3AP108%7Cps%3AP1416%20%3Forg.%0A%20%20%20%20OPTIONAL%20%7B%3ForgStmt%20pq%3AP580%7Cpq%3AP585%20%3Fonset.%7D%0A%20%20%20%20OPTIONAL%20%7B%3ForgStmt%20pq%3AP582%20%3Fterminus.%7D%0A%20%20%7D%0A%20%20GROUP%20BY%20%3Fpers%20%3Forg%0A%7D%20as%20%25affiliations%0A%23%20filter%20past%20affiliations%0AWITH%20%7B%0A%20%20SELECT%20DISTINCT%0A%20%20%20%20%3Fpers%20%3Forg%20%0A%20%20WHERE%20%7B%0A%20%20%20%20INCLUDE%20%25affiliations%0A%20%20%20%20%23%20remove%20affiliations%20which%20have%20been%20explicitly%20terminated%0A%20%20%20%20BIND%28IF%28bound%28%3FterminusLatest%29%2C%20%3FterminusLatest%2C%20now%28%29%29%20AS%20%3Fterminus%29%0A%20%20%20%20FILTER%28%3Fterminus%20%3E%3D%20now%28%29%29.%0A%20%20%20%20%23%20retain%20only%20the%20latest%20affiliation%20IN%20THE%20GROUP%0A%20%20%20%20BIND%28IF%28bound%28%3FonsetLatest%29%2C%20%3FonsetLatest%2C%20now%28%29%29%20AS%20%3Fonset%29%0A%20%20%20%20%23FILTER%28%3Fonset%20%3C%3D%20max%28%3FonsetLatest%29%29%0A%20%20%20%7D%0A%20%20GROUP%20BY%20%3Fpers%20%3Forg%0A%7D%20as%20%25affilLatest%0AWHERE%20%7B%0A%20%20INCLUDE%20%25affilLatest%0A%20%20%3Forg%20wdt%3AP625%20%3Fcoords%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22.%0A%20%20%20%20%3Fpers%20rdfs%3Alabel%20%3FpersLabel.%0A%20%20%20%20%3Forg%20rdfs%3Alabel%20%3ForgLabel.%0A%20%20%7D%0A%7D%0AORDER%20BY%20%3FpersLabel%20DESC%28%3FonsetLatest%29).
< > 
< > A simple bash script (`run-sparql.sh`) allows to execute queries and saves the results to file. 
< > 
< > # Components
< > 
< > The `SELECT` queries in this repository make use of a number of modular subqueries (or components).
< > 
< > ## field of interest
< > 
< > The field of interest is defined by `PREFIX field: <http://www.wikidata.org/entity/Q1026962>` referencing a Wikidata item at the beginning of queries. While queries have been developed with [Q1026962](https://www.wikidata.org/wiki/Q1026962) for digital humanities, we've also tested the following fields:
< > 
< > - history: Q1066186 and Q309
< > - physics: Q413
< > 
< > ## Find researchers in a field
< > 
< > ```sparql
< > WITH {SELECT DISTINCT
< >   ?pers
< >   WHERE {# find all works in the target field
< >     hint:SubQuery hint:runOnce true # what is the impact on the results?
< >     { field: ^wdt:P279*/^wdt:P31*/^wdt:P921|^wdt:P361+/^wdt:P921|^wdt:P1269+/^wdt:P921 ?work .
< >     ?work wdt:P50 ?pers .}
< >     # or return people in the target field
< >     UNION
< >     { field: ^wdt:P279*/^wdt:P101 ?pers.}
< >   }
< >   LIMIT 1000000
< > } AS %researchers
< > ```
< > 
< > ## Look up affiliations
< > 
< > ```sparql
< > WITH {SELECT DISTINCT
< >   ?pers ?org ?coords
< >   WHERE {include %researchers
< >     hint:SubQuery hint:runOnce true .
< >     ?pers wdt:P31 wd:Q5 ;           # humans
< >           wdt:P108|wdt:P1416 ?org . # institutions of employment or affiliation
< >     ?org wdt:P625 ?coords .         # get coordinates
< >   }
< >   #LIMIT 100000
< > } AS %affiliations
< > ```
< > 
< > ## Filter by country
< > 
< > ```sparql
< > WITH {SELECT DISTINCT
< >   ?pers ?org ?coords
< >   WHERE{ include %affiliations
< >     {?org wdt:P17/wdt:P279* wd:Q183 .} # in Germany
< >   }
< > } AS %result
< > ```
106c44,105
< ---
---
> 
> This repository holds SPARQL queries for conducting field surveys for specific disciplines on Wikidata. Documentation of the larger project can be found at the [WikiProject](https://www.wikidata.org/wiki/Wikidata:WikiProject_Field_Survey_Digital_Humanities_/_Digital_History) and in this [repository](https://scm.cms.hu-berlin.de/methodenlabor/fs_documentation). An initial blog post has been published [here](https://dhistory.hypotheses.org/9858).
> 
> Our general approach is premised on the idea that looking for classified output of research is more fruitefuil than the explicitly encoded disciplinary affiliations of researchers or institutions. To check this assumption, one can use the query [`org_clio-online`](select/org_clio-online.rq) and see how few of the institutions with a Clio Organisation ID have some field of work listed with `P101`.
> 
> For sample results see this [map of digital humanists in Germany, Austria, and Switzerland](https://query-main.wikidata.org/embed.html#%23title%3A%20Digital%20Historians%20and%20Digital%20Humanists%20in%20the%20DACH%20region%0A%23defaultView%3AMap%7B%22hide%22%3A%5B%22%3Fcoords%22%5D%2C%20%22markercluster%22%3A%20%22true%22%7D%0ASELECT%20DISTINCT%0A%20%20%3Fpers%0A%20%20%28CONCAT%28%3FpersLabel%2C%20%22%20%28%22%2C%20%3ForgLabel%2C%20%22%29%22%29%20AS%20%3Flabel%29%0A%20%20%3Fcoords%0A%23%20get%20researchers%20in%20specific%20fields%20of%20work%3A%20potentially%20very%20large%20number%20of%20results%0AWITH%20%7B%0A%20%20SELECT%20DISTINCT%0A%20%20%20%20%3Fpers%20%3Forg%0A%20%20WHERE%20%7B%0A%20%20%20%20%23BIND%28wd%3AQ49144246%20AS%20%3Fpers%29.%20%23%20debugging%20Q99529696%0A%20%20%20%20%3Fpers%20wdt%3AP31%20wd%3AQ5%3B%20%20%20%20%20%20%20%20%20%20%23%20humans%0A%20%20%20%20%20%20wdt%3AP101%20%3FfieldOfWork%3B%20%20%20%20%20%20%23%20having%20a%20field%20of%20work%0A%20%20%20%20%20%20wdt%3AP108%7Cwdt%3AP1416%20%3Forg.%20%20%20%20%23%20employer%0A%20%20%20%20%3Forg%20wdt%3AP17%2Fwdt%3AP279%2a%20%3Fcountry%20.%20%20%23%20get%20country%0A%20%20%20%20%23%20limit%20to%20fields%20of%20work%0A%20%20%20%20VALUES%20%3FfieldOfWork%20%7B%20%20%20%20%20%20%20%20%20%0A%20%20%20%20%20%20wd%3AQ336387%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20digital%20history%0A%20%20%20%20%20%20wd%3AQ1026962%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20digital%20humanities%0A%20%20%20%20%7D%0A%20%20%20%20%23%20limit%20to%20countries%0A%20%20%20%20VALUES%20%3Fcountry%20%7B%0A%20%20%20%20%20%20wd%3AQ183%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Germany%0A%20%20%20%20%20%20wd%3AQ39%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Switzerland%0A%20%20%20%20%20%20wd%3AQ40%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Austria%0A%20%20%20%20%7D%0A%20%20%7D%20LIMIT%208000%0A%7D%20as%20%25researchers%0A%23%20get%20affiliations%20and%20the%20latest%20start%20and%20end%20date%0AWITH%20%7B%0A%20%20SELECT%20DISTINCT%0A%20%20%20%20%3Fpers%20%3Forg%0A%20%20%20%20%28max%28%3Fonset%29%20as%20%3FonsetLatest%29%0A%20%20%20%20%28max%28%3Fterminus%29%20as%20%3FterminusLatest%29%0A%20%20WHERE%20%7B%0A%20%20%20%20INCLUDE%20%25researchers%20.%0A%20%20%20%20%3Fpers%20p%3AP108%20%7C%20p%3AP1416%20%3ForgStmt.%0A%20%20%20%20%3ForgStmt%20ps%3AP108%7Cps%3AP1416%20%3Forg.%0A%20%20%20%20OPTIONAL%20%7B%3ForgStmt%20pq%3AP580%7Cpq%3AP585%20%3Fonset.%7D%0A%20%20%20%20OPTIONAL%20%7B%3ForgStmt%20pq%3AP582%20%3Fterminus.%7D%0A%20%20%7D%0A%20%20GROUP%20BY%20%3Fpers%20%3Forg%0A%7D%20as%20%25affiliations%0A%23%20filter%20past%20affiliations%0AWITH%20%7B%0A%20%20SELECT%20DISTINCT%0A%20%20%20%20%3Fpers%20%3Forg%20%0A%20%20WHERE%20%7B%0A%20%20%20%20INCLUDE%20%25affiliations%0A%20%20%20%20%23%20remove%20affiliations%20which%20have%20been%20explicitly%20terminated%0A%20%20%20%20BIND%28IF%28bound%28%3FterminusLatest%29%2C%20%3FterminusLatest%2C%20now%28%29%29%20AS%20%3Fterminus%29%0A%20%20%20%20FILTER%28%3Fterminus%20%3E%3D%20now%28%29%29.%0A%20%20%20%20%23%20retain%20only%20the%20latest%20affiliation%20IN%20THE%20GROUP%0A%20%20%20%20BIND%28IF%28bound%28%3FonsetLatest%29%2C%20%3FonsetLatest%2C%20now%28%29%29%20AS%20%3Fonset%29%0A%20%20%20%20%23FILTER%28%3Fonset%20%3C%3D%20max%28%3FonsetLatest%29%29%0A%20%20%20%7D%0A%20%20GROUP%20BY%20%3Fpers%20%3Forg%0A%7D%20as%20%25affilLatest%0AWHERE%20%7B%0A%20%20INCLUDE%20%25affilLatest%0A%20%20%3Forg%20wdt%3AP625%20%3Fcoords%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22.%0A%20%20%20%20%3Fpers%20rdfs%3Alabel%20%3FpersLabel.%0A%20%20%20%20%3Forg%20rdfs%3Alabel%20%3ForgLabel.%0A%20%20%7D%0A%7D%0AORDER%20BY%20%3FpersLabel%20DESC%28%3FonsetLatest%29).
> 
> A simple bash script (`run-sparql.sh`) allows to execute queries and saves the results to file.
> 
> # Components
> 
> The `SELECT` queries in this repository make use of a number of modular subqueries (or components).
> 
> ## field of interest
> 
> The field of interest is defined by `PREFIX field: <http://www.wikidata.org/entity/Q1026962>` referencing a Wikidata item at the beginning of queries. While queries have been developed with [Q1026962](https://www.wikidata.org/wiki/Q1026962) for digital humanities, we've also tested the following fields:
> 
> - history: Q1066186 and Q309
> - physics: Q413
> 
> ## Find researchers in a field
> 
> ```sparql
> WITH {SELECT DISTINCT
>   ?pers
>   WHERE {# find all works in the target field
>     hint:SubQuery hint:runOnce true # what is the impact on the results?
>     { field: ^wdt:P279*/^wdt:P31*/^wdt:P921|^wdt:P361+/^wdt:P921|^wdt:P1269+/^wdt:P921 ?work .
>     ?work wdt:P50 ?pers .}
>     # or return people in the target field
>     UNION
>     { field: ^wdt:P279*/^wdt:P101 ?pers.}
>   }
>   LIMIT 1000000
> } AS %researchers
> ```
> 
> ## Look up affiliations
> 
> ```sparql
> WITH {SELECT DISTINCT
>   ?pers ?org ?coords
>   WHERE {include %researchers
>     hint:SubQuery hint:runOnce true .
>     ?pers wdt:P31 wd:Q5 ;           # humans
>           wdt:P108|wdt:P1416 ?org . # institutions of employment or affiliation
>     ?org wdt:P625 ?coords .         # get coordinates
>   }
>   #LIMIT 100000
> } AS %affiliations
> ```
> 
> ## Filter by country
> 
> ```sparql
> WITH {SELECT DISTINCT
>   ?pers ?org ?coords
>   WHERE{ include %affiliations
>     {?org wdt:P17/wdt:P279* wd:Q183 .} # in Germany
>   }
> } AS %result
> ```
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/gitlab-runner-docker-compose-scm-version.qmd quarto/methodenlabor/gitlab-runner-docker-compose-scm-version.qmd
2c2
< title: "Gitlab Runner Docker Compose - SCM-Version (Methodenlabor)"
---
> title: "Methodenlabor / Gitlab Runner Docker Compose - SCM-Version (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version"
>       icon: "gitlab"
11c11
< # Gitlab Runner Docker Compose - SCM-Version (Methodenlabor)
---
> # Methodenlabor / Gitlab Runner Docker Compose - SCM-Version (Methodenlabor)
13,85c13,18
< > # GitLab Runner with Docker Compose
< > 
< > This guide provides instructions on how to set up and run a GitLab Runner **ON THE HU SCM GITLAB** using Docker Compose. Follow these steps to get your GitLab Runner up and running seamlessly.
< > 
< > ## Steps
< > 
< > ### 1. Clone the Repository
< > First, you need to clone the repository that contains the Docker Compose configuration for the GitLab Runner. Open your terminal and run:
< > 
< > ```bash
< > git clone https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version.git
< > cd gitlab-runner-docker-compose-scm-version
< > ```
< > 
< > ### 2. Get a Runner Authentication Token from GitLab
< > Next, you need an authentication token from GitLab to register your runner. Follow these steps:
< > 
< > 1. Go to your GitLab instance and navigate to the project or group where you want to add the Runner.
< > 2. Click on **Settings** > **CI / CD**.
< > 3. Expand the **Runners** section.
< > 4. Look for the **New project runner** button and fillout the next form.
< > 5. Copy the Authentication Token.
< > 
< > Keep this token safe as you'll need it in the next step.
< > 
< > ### 3. Fill Out the Environment File
< > Within the cloned repository, there should be an example environment file, typically named `.env.example`. You need to create a `.env` file based on this example and fill in the necessary details.
< > 
< > ```bash
< > cp .env.example .env
< > ```
< > 
< > Open the `.env` file in your favorite text editor and fill in the following details:
< > 
< > ```env
< > # Name of our Gitlab Runner Container
< > CONTAINER_NAME=""
< > # Gitlab Runner Auhtentication Token
< > TOKEN="you-registration-token"
< > ```
< > 
< > Replace `your-registration-token` with the token you obtained from GitLab in the previous step.
< > 
< > ### 4. (optional) Change Dockerfile
< > You can add packages to be available inside the gitlab-runner instance here.
< > 
< > The current gitlab-runner is based on Ubuntu 20.04 LTS.
< > 
< > ### 5. Run Docker Compose
< > To start your new GitLab Runner, run the following command:
< > 
< > ```bash
< > docker-compose up -d
< > ```
< > 
< > This command will initiate the Docker containers in detached mode, running your GitLab Runner in the background.
< > 
< > ### 6. Verify Your Runner
< > After starting the runner, go back to your GitLab project or group settings under **CI / CD** > **Runners**. Under the **Available specific runners** section, you should see your newly registered runner listed.
< > 
< > Congratulations! Your GitLab Runner is now set up and ready to handle jobs for your projects.
< > 
< > ## Troubleshooting
< > If you encounter any issues, consider the following tips:
< > 
< > - Ensure Docker and Docker Compose are installed and running correctly on your machine.
< > - Double-check your `.env` file for any typos or incorrect values.
< > - Review the Docker Compose logs using `docker-compose logs` to identify any issues.
< > 
< > ## Conclusion
< > By following these simple steps, you can set up a GitLab Runner with Docker Compose quickly. This setup helps you streamline your CI/CD processes, making it easier to run and manage your build jobs.
< > 
< > For additional information and more advanced configurations, refer to the [GitLab Runner documentation](https://docs.gitlab.com/runner/).
---
> > ---
> > title: "Methodenlabor / Gitlab Runner Docker Compose - SCM-Version"
> > author: "Methodenlabor"
> > date: "2025-01-15"
> > lang: "de"
> > ---
87c20,92
< ---
---
> # GitLab Runner with Docker Compose
> 
> This guide provides instructions on how to set up and run a GitLab Runner **ON THE HU SCM GITLAB** using Docker Compose. Follow these steps to get your GitLab Runner up and running seamlessly.
> 
> ## Steps
> 
> ### 1. Clone the Repository
> First, you need to clone the repository that contains the Docker Compose configuration for the GitLab Runner. Open your terminal and run:
> 
> ```bash
> git clone https://scm.cms.hu-berlin.de/methodenlabor/gitlab-runner-docker-compose-scm-version.git
> cd gitlab-runner-docker-compose-scm-version
> ```
> 
> ### 2. Get a Runner Authentication Token from GitLab
> Next, you need an authentication token from GitLab to register your runner. Follow these steps:
> 
> 1. Go to your GitLab instance and navigate to the project or group where you want to add the Runner.
> 2. Click on **Settings** > **CI / CD**.
> 3. Expand the **Runners** section.
> 4. Look for the **New project runner** button and fillout the next form.
> 5. Copy the Authentication Token.
> 
> Keep this token safe as you'll need it in the next step.
> 
> ### 3. Fill Out the Environment File
> Within the cloned repository, there should be an example environment file, typically named `.env.example`. You need to create a `.env` file based on this example and fill in the necessary details.
> 
> ```bash
> cp .env.example .env
> ```
> 
> Open the `.env` file in your favorite text editor and fill in the following details:
> 
> ```env
> # Name of our Gitlab Runner Container
> CONTAINER_NAME=""
> # Gitlab Runner Auhtentication Token
> TOKEN="you-registration-token"
> ```
> 
> Replace `your-registration-token` with the token you obtained from GitLab in the previous step.
> 
> ### 4. (optional) Change Dockerfile
> You can add packages to be available inside the gitlab-runner instance here.
> 
> The current gitlab-runner is based on Ubuntu 20.04 LTS.
> 
> ### 5. Run Docker Compose
> To start your new GitLab Runner, run the following command:
> 
> ```bash
> docker-compose up -d
> ```
> 
> This command will initiate the Docker containers in detached mode, running your GitLab Runner in the background.
> 
> ### 6. Verify Your Runner
> After starting the runner, go back to your GitLab project or group settings under **CI / CD** > **Runners**. Under the **Available specific runners** section, you should see your newly registered runner listed.
> 
> Congratulations! Your GitLab Runner is now set up and ready to handle jobs for your projects.
> 
> ## Troubleshooting
> If you encounter any issues, consider the following tips:
> 
> - Ensure Docker and Docker Compose are installed and running correctly on your machine.
> - Double-check your `.env` file for any typos or incorrect values.
> - Review the Docker Compose logs using `docker-compose logs` to identify any issues.
> 
> ## Conclusion
> By following these simple steps, you can set up a GitLab Runner with Docker Compose quickly. This setup helps you streamline your CI/CD processes, making it easier to run and manage your build jobs.
> 
> For additional information and more advanced configurations, refer to the [GitLab Runner documentation](https://docs.gitlab.com/runner/).
Nur in quarto/methodenlabor: Gitlab Runner Docker Compose - SCM-Version.qmd.
Nur in quarto/methodenlabor: jaraid-data.qmd.
Nur in quarto/methodenlabor: jaraid_data.qmd.
Nur in quarto_production/methodenlabor: p_bots_social-media.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/p_gitlab-overviewer.qmd quarto/methodenlabor/p_gitlab-overviewer.qmd
2c2
< title: "p_gitlab-overviewer (Methodenlabor)"
---
> title: "Methodenlabor / p_gitlab-overviewer (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/p_gitlab-overviewer"
>       icon: "gitlab"
11c11
< # p_gitlab-overviewer (Methodenlabor)
---
> # Methodenlabor / p_gitlab-overviewer (Methodenlabor)
15,19c15,19
< > description: |
< >   Collect `README.md`s on all GitLab-Repositories from AccessTokens and generate an overview.
< > lang: de
< > date: 2025-06-19
< > status: in Development
---
> > date: "2025-06-19"
> > lang: "de"
> > description: "Collect `README.md`s on all GitLab-Repositories from AccessTokens and\
> >   \ generate an overview.\n"
> > status: "in Development"
21c21
< > type: code
---
> > type: "code"
25,40c25,40
< >   - name: Nicole Dresselhaus
< >     affiliation:
< >       - name: Humboldt-Universität zu Berlin
< >         url: https://hu-berlin.de
< >     email: nicole.dresselhaus@hu-berlin.de
< >     correspondence: true
< >     orcid: 0009-0008-8850-3679
< >     roles:
< >       - Conceptualization
< >       - Software
< >       - Validation
< >   - name: Till Grallert
< >     roles:
< >       - Supervision
< >       - Validation
< >       - Project Administration
---
> > - name: "Nicole Dresselhaus"
> >   affiliation:
> >   - name: "Humboldt-Universität zu Berlin"
> >     url: "https://hu-berlin.de"
> >   email: "nicole.dresselhaus@hu-berlin.de"
> >   correspondence: true
> >   orcid: "0009-0008-8850-3679"
> >   roles:
> >   - "Conceptualization"
> >   - "Software"
> >   - "Validation"
> > - name: "Till Grallert"
> >   roles:
> >   - "Supervision"
> >   - "Validation"
> >   - "Project Administration"
42,81d41
< > 
< > # Gitlab Overviewer
< > 
< > ## Kurzüberblick
< > 
< > **Gitlab Overviewer** sammelt automatisiert Informationen aus den
< > `README.md`-Dateien aller GitLab-Repositories, auf die du Zugriff hast, und
< > erstellt daraus eine übersichtliche Zusammenfassung (z.B. als Markdown-Tabelle
< > oder für Quarto/Confluence).
< > 
< > - Extrahiert Metadaten (Frontmatter), Beschreibung, Status/Todo-Abschnitte und
< >   offene Issues
< > - Übersichtliche Ausgabe als `Overview.md` und Quarto-Dateien
< > - Flexible Anpassung über YAML-Keys in den READMEs (z.B. `type`, `priority`,
< >   `urgency`)
< > - Individuelle Sortierung & Spalten (CLI: `--sort`, YAML: `table_config.yaml`)
< > 
< > ## Projektstruktur
< > 
< > - Python-Quellcode: `src/`
< > - Konfiguration: `.env`, `gitlab-api.yaml`
< > - Output: `Overview.md`, `quarto/`
< > - Abhängigkeiten: [poetry](https://python-poetry.org/)
< > 
< > ## Einstieg & Dokumentation
< > 
< > - **Installation:** Siehe [INSTALL.md](INSTALL.md)
< > - **Nutzung & Beispiele:** Siehe [USAGE.md](USAGE.md)
< > - **Lizenz:** EUPD-1.2, siehe [LICENSE](LICENSE)
< > 
< > ## Verantwortlichkeiten
< > 
< > - Hauptverantwortlich: Nicole Dresselhaus
< > - Supervision: Till Grallert
< > 
< > ## Hinweise
< > 
< > - Die API-Spezifikation (`gitlab-api.yaml`) kann sich mit GitLab-Updates ändern.
< > - Für wissenschaftlichen Hintergrund, Zitation und weitere Details siehe die
< >   jeweiligen Dateien.
83c43,83
< ---
---
> 
> 
> # Gitlab Overviewer
> 
> ## Kurzüberblick
> 
> **Gitlab Overviewer** sammelt automatisiert Informationen aus den
> `README.md`-Dateien aller GitLab-Repositories, auf die du Zugriff hast, und
> erstellt daraus eine übersichtliche Zusammenfassung (z.B. als Markdown-Tabelle
> oder für Quarto/Confluence).
> 
> - Extrahiert Metadaten (Frontmatter), Beschreibung, Status/Todo-Abschnitte und
>   offene Issues
> - Übersichtliche Ausgabe als `Overview.md` und Quarto-Dateien
> - Flexible Anpassung über YAML-Keys in den READMEs (z.B. `type`, `priority`,
>   `urgency`)
> - Individuelle Sortierung & Spalten (CLI: `--sort`, YAML: `table_config.yaml`)
> 
> ## Projektstruktur
> 
> - Python-Quellcode: `src/`
> - Konfiguration: `.env`, `gitlab-api.yaml`
> - Output: `Overview.md`, `quarto/`
> - Abhängigkeiten: [poetry](https://python-poetry.org/)
> 
> ## Einstieg & Dokumentation
> 
> - **Installation:** Siehe [INSTALL.md](INSTALL.md)
> - **Nutzung & Beispiele:** Siehe [USAGE.md](USAGE.md)
> - **Lizenz:** EUPD-1.2, siehe [LICENSE](LICENSE)
> 
> ## Verantwortlichkeiten
> 
> - Hauptverantwortlich: Nicole Dresselhaus
> - Supervision: Till Grallert
> 
> ## Hinweise
> 
> - Die API-Spezifikation (`gitlab-api.yaml`) kann sich mit GitLab-Updates ändern.
> - Für wissenschaftlichen Hintergrund, Zitation und weitere Details siehe die
>   jeweiligen Dateien.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/podcast_digital-history-deleted-10146.qmd quarto/methodenlabor/podcast_digital-history-deleted-10146.qmd
2c2
< title: "podcast_digital-history-deleted-10146 (Methodenlabor)"
---
> title: "Methodenlabor / podcast_digital-history-deleted-10146 (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/podcast_digital-history-deleted-10146
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/podcast_digital-history-deleted-10146"
>       icon: "gitlab"
11c11
< # podcast_digital-history-deleted-10146 (Methodenlabor)
---
> # Methodenlabor / podcast_digital-history-deleted-10146 (Methodenlabor)
13,15c13,18
< > No README found.
< 
< ---
---
> > ---
> > title: "Methodenlabor / podcast_digital-history-deleted-10146"
> > author: "Methodenlabor"
> > date: "2025-06-13"
> > lang: "de"
> > ---
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/podcast.qmd quarto/methodenlabor/podcast.qmd
2c2
< title: "Podcast (Methodenlabor)"
---
> title: "Methodenlabor / Podcast (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/podcast
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/podcast"
>       icon: "gitlab"
11c11
< # Podcast (Methodenlabor)
---
> # Methodenlabor / Podcast (Methodenlabor)
15,18c15,17
< > description: |
< >   Transkriptionen und Begleittexte für das NFDI4Memory Audiogesprächsformat.
< > lang: de
< > date: 2025-06-13
---
> > date: "2025-06-13"
> > lang: "de"
> > description: "Transkriptionen und Begleittexte für das NFDI4Memory Audiogesprächsformat.\n"
21,51c20,50
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094
< >     roles: 
< >       - Conceptualization
< >       - Supervision
< >       - Writing – original draft
< >       - Writing – review & editing
< >   - name: Jascha Merijn Schmitz
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: jascha.schmitz@hu-berlin.de
< >     orcid:
< >     roles: 
< >       - Conceptualization
< >       - Writing – original draft
< >       - Writing – review & editing
< >   - name: Isabelle Trilling
< >     email: isabell.trilling@student.hu-berlin.de
< >     correspondence: "yes"
< >     institute: 
< >       - hu
< >       - nfdi
< >     roles:
< >       - Data curation
---
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Writing – original draft"
> >   - "Writing – review & editing"
> > - name: "Jascha Merijn Schmitz"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "jascha.schmitz@hu-berlin.de"
> >   orcid: null
> >   roles:
> >   - "Conceptualization"
> >   - "Writing – original draft"
> >   - "Writing – review & editing"
> > - name: "Isabelle Trilling"
> >   email: "isabell.trilling@student.hu-berlin.de"
> >   correspondence: "yes"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   roles:
> >   - "Data curation"
53,55c52,54
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory
< > bibliography: assets/references.bib
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > bibliography: "assets/references.bib"
57,147d55
< > 
< > Dieses Repo enthält Transkriptionen, Begleittexte und die Dokumentation für das NFDI4Memory Audiogesprächsformat.
< > 
< > ## Über dieses Repository
< > 
< > ### Ziel / Zweck
< > 
< > Kurz das Ziel oder den Bedarf für diese Daten erläutern.  
< > (Beispiel: „Dieser Datensatz besteht aus … und eignet sich als Benchmark um die
< > Performance der Named Entity Recognition zu testen.“)
< > 
< > Sind die Daten Final? Werden sie noch gesammelt? Wann wird mit Abschluss
< > gerechnet?
< > 
< > ### Nutzung / Bekannte Einschränkungen
< > 
< > - Wann sollte ich den Datensatz nutzen?
< > - Wann sollte ich den Datensatz **nicht** nutzen?
< > - Welche **Biases** gibt es in den Daten?
< > 
< > ### Struktur
< > 
< > ```plain
< > .
< > ├── assets/           # supporting files, such as bibliography and images
< > ├── docs/             # documentation
< > ├── draft/            # drafts, mostly written in markdown
< > ├── notes/            # notes and transcriptions
< > ├── src/              # code to process drafts
< > ├── submission/       # final files for publication
< > ├── CHANGELOG.md
< > ├── CITATION.md       # how to cite
< > ├── CONTRIBUTING.md
< > ├── LICENSE.md        # CC BY license text
< > └── README.md         # this file
< > ```
< > 
< > Die Transkriptionen der Gespräche finden sich im Ordner `notes/`. Die Übersicht über die Gesprächspartner_innen in der Datei `docs/participants.md`.
< > 
< > Die Audioaufnahmen der Gespräche werden wegen ihrer Größe nicht in dieses Repository aufgenommen, sondern liegen in der HU Box unter <https://seafile.rlp.net/smart-link/583fc047-d2d0-4c01-8ad8-67536feb33c1/>.
< > 
< > # Meta-Informationen
< > 
< > ## Verantwortlichkeiten
< > 
< > - Wer ist letztendlich verantwortlich für den Inhalt?
< > - Wer genehmigt/weist Inhalte ab?
< > 
< > ## Wissenschaftlicher Hintergrund
< > 
< > Kurze Erklärung der wissenschaftlichen Grundlage (Methode, theoretischer Ansatz)
< > und Referenzen auf Publikationen oder Quellen.
< > 
< > > [!warning]
< > >
< > > **Keine ausführliche Theorie**, diese gehört in Paper oder eigene Datei
< > > ([BACKGROUND.md](BACKGROUND.md))
< > 
< > ## Lizenz & Zitation
< > 
< > Das gesamte Projekt ist CC BY lizensiert. Siehe <LICENSE.md>.
< > 
< > Kurz auf Lizenz verweisen (z.B. „siehe LICENSE“) und erklären, wie das Projekt
< > zu zitieren ist (z.B. DOI oder Verweis auf [CITATION.md](CITATION.md)).
< > 
< > 
< > ## Checklist
< > 
< > Es ist eine gute Idee die sich ändernden Punkte in ein Release-Template zu
< > kopieren.
< > 
< > - [ ] **Grundlegende Nutzung:** Gibt es eine Anleitung oder Beispiele, wie man
< >       die Daten verwendet (Daten -> Variablen in einer Programmiersprache)? Ist
< >       mindestens ein typischer Workflow beschrieben, idealerweise mit
< >       Beispielinput und -output?
< > - [ ] **Hintergrund & Referenzen:** Sind die wichtigsten Hintergründe oder
< >       Referenzen über den Ursprung der Daten angegeben? Das muss kein Essay
< >       sein, aber ein paar Sätze + Referenzen schaffen Vertrauen in die
< >       wissenschaftliche Fundierung.
< > - [ ] **Kontakt & Weiterführung:** Ist angegeben, wie man Hilfe bekommt oder
< >       Fehler melden kann (Issue-Tracker, E-Mail)? Gibt es Hinweise für Beiträge
< >       (falls erwünscht) oder zumindest die Information, wer die Autor\*innen
< >       sind?
< > - [ ] **Rechtliches & Zitation:** Liegt die Lizenz bei und wird sie genannt?
< >       Sind Infos zum Zitieren der Software vorhanden (z. B. “Bitte zitieren Sie
< >       DOI XYZ”)? Das stellt sicher, dass die Software nachnutzbar _und_
< >       akademisch kreditiert wird.
< > - [ ] **Aktualität & Version:** Entspricht die Dokumentation der aktuellen
< >       Softwareversion? (Check: Versionsnummern, Datumsangaben). Veraltete Doku
< >       kann schlimmer sein als keine – planen Sie also ein, die Doku mit jedem
< >       Release kurz zu überprüfen.
149c57,147
< ---
---
> 
> Dieses Repo enthält Transkriptionen, Begleittexte und die Dokumentation für das NFDI4Memory Audiogesprächsformat.
> 
> ## Über dieses Repository
> 
> ### Ziel / Zweck
> 
> Kurz das Ziel oder den Bedarf für diese Daten erläutern.  
> (Beispiel: „Dieser Datensatz besteht aus … und eignet sich als Benchmark um die
> Performance der Named Entity Recognition zu testen.“)
> 
> Sind die Daten Final? Werden sie noch gesammelt? Wann wird mit Abschluss
> gerechnet?
> 
> ### Nutzung / Bekannte Einschränkungen
> 
> - Wann sollte ich den Datensatz nutzen?
> - Wann sollte ich den Datensatz **nicht** nutzen?
> - Welche **Biases** gibt es in den Daten?
> 
> ### Struktur
> 
> ```plain
> .
> ├── assets/           # supporting files, such as bibliography and images
> ├── docs/             # documentation
> ├── draft/            # drafts, mostly written in markdown
> ├── notes/            # notes and transcriptions
> ├── src/              # code to process drafts
> ├── submission/       # final files for publication
> ├── CHANGELOG.md
> ├── CITATION.md       # how to cite
> ├── CONTRIBUTING.md
> ├── LICENSE.md        # CC BY license text
> └── README.md         # this file
> ```
> 
> Die Transkriptionen der Gespräche finden sich im Ordner `notes/`. Die Übersicht über die Gesprächspartner_innen in der Datei `docs/participants.md`.
> 
> Die Audioaufnahmen der Gespräche werden wegen ihrer Größe nicht in dieses Repository aufgenommen, sondern liegen in der HU Box unter <https://seafile.rlp.net/smart-link/583fc047-d2d0-4c01-8ad8-67536feb33c1/>.
> 
> # Meta-Informationen
> 
> ## Verantwortlichkeiten
> 
> - Wer ist letztendlich verantwortlich für den Inhalt?
> - Wer genehmigt/weist Inhalte ab?
> 
> ## Wissenschaftlicher Hintergrund
> 
> Kurze Erklärung der wissenschaftlichen Grundlage (Methode, theoretischer Ansatz)
> und Referenzen auf Publikationen oder Quellen.
> 
> > [!warning]
> >
> > **Keine ausführliche Theorie**, diese gehört in Paper oder eigene Datei
> > ([BACKGROUND.md](BACKGROUND.md))
> 
> ## Lizenz & Zitation
> 
> Das gesamte Projekt ist CC BY lizensiert. Siehe <LICENSE.md>.
> 
> Kurz auf Lizenz verweisen (z.B. „siehe LICENSE“) und erklären, wie das Projekt
> zu zitieren ist (z.B. DOI oder Verweis auf [CITATION.md](CITATION.md)).
> 
> 
> ## Checklist
> 
> Es ist eine gute Idee die sich ändernden Punkte in ein Release-Template zu
> kopieren.
> 
> - [ ] **Grundlegende Nutzung:** Gibt es eine Anleitung oder Beispiele, wie man
>       die Daten verwendet (Daten -> Variablen in einer Programmiersprache)? Ist
>       mindestens ein typischer Workflow beschrieben, idealerweise mit
>       Beispielinput und -output?
> - [ ] **Hintergrund & Referenzen:** Sind die wichtigsten Hintergründe oder
>       Referenzen über den Ursprung der Daten angegeben? Das muss kein Essay
>       sein, aber ein paar Sätze + Referenzen schaffen Vertrauen in die
>       wissenschaftliche Fundierung.
> - [ ] **Kontakt & Weiterführung:** Ist angegeben, wie man Hilfe bekommt oder
>       Fehler melden kann (Issue-Tracker, E-Mail)? Gibt es Hinweise für Beiträge
>       (falls erwünscht) oder zumindest die Information, wer die Autor\*innen
>       sind?
> - [ ] **Rechtliches & Zitation:** Liegt die Lizenz bei und wird sie genannt?
>       Sind Infos zum Zitieren der Software vorhanden (z. B. “Bitte zitieren Sie
>       DOI XYZ”)? Das stellt sicher, dass die Software nachnutzbar _und_
>       akademisch kreditiert wird.
> - [ ] **Aktualität & Version:** Entspricht die Dokumentation der aktuellen
>       Softwareversion? (Check: Versionsnummern, Datumsangaben). Veraltete Doku
>       kann schlimmer sein als keine – planen Sie also ein, die Doku mit jedem
>       Release kurz zu überprüfen.
Nur in quarto/methodenlabor: Podcast.qmd.
Nur in quarto_production/methodenlabor: p_publish2wikidata.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/p_wikidata2gitlab.qmd quarto/methodenlabor/p_wikidata2gitlab.qmd
2c2
< title: "p_wikidata2gitlab (Methodenlabor)"
---
> title: "Methodenlabor / p_wikidata2gitlab (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab"
>       icon: "gitlab"
11c11
< # p_wikidata2gitlab (Methodenlabor)
---
> # Methodenlabor / p_wikidata2gitlab (Methodenlabor)
13a14
> > title: "Periodically pull data from Wikidata to GitLab, release, and push to Zenodo"
15,27c16,26
< >   - name: Till Grallert
< >     affiliation: Humboldt-Universität zu Berlin
< >     email: till.grallert@hu-berlin.de
< >     orcid: "https://orcid.org/0000-0002-5739-8094"
< >   - name: Nicole Dresselhaus
< >     affiliation: Humboldt-Universität zu Berlin
< >     email: nicole.dresselhaus@hu-berlin.de
< >     orcid: "https://orcid.org/0009-0008-8850-3679"
< > date: 2025-04-23
< > lang: de
< > license: GPL3
< > title:
< >   Periodically pull data from Wikidata to GitLab, release, and push to Zenodo
---
> > - name: "Till Grallert"
> >   affiliation: "Humboldt-Universität zu Berlin"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "https://orcid.org/0000-0002-5739-8094"
> > - name: "Nicole Dresselhaus"
> >   affiliation: "Humboldt-Universität zu Berlin"
> >   email: "nicole.dresselhaus@hu-berlin.de"
> >   orcid: "https://orcid.org/0009-0008-8850-3679"
> > date: "2025-04-23"
> > lang: "de"
> > license: "GPL3"
30,429d28
< > 
< > [![pipeline
< > status](../../../badges/main/pipeline.svg)](../pipelines?page=1&scope=all&ref=main)
< > [![Latest Release](../../badges/release.svg)](../../releases)
< > 
< > ![Project-logo](img/logo.jpg)
< > 
< > <!--toc:start-->
< > 
< > - [Hintergrund](#hintergrund)
< >   - [Was machen wir?](#was-machen-wir)
< >   - [Wozu wird das in der Wissenschaft gebraucht?](#wozu-wird-das-in-der-wissenschaft-gebraucht)
< > - [Implementation](#implementation)
< > - [Skripte](#skripte)
< >   - [1. Download und Speicherung der Daten](#1-download-und-speicherung-der-daten)
< >     - [1.1 Umfang des Graphen mit SPARQL festlegen](#11-umfang-des-graphen-mit-sparql-festlegen)
< >     - [1.2 Herunterladen der Subgraphen für jedes einzelne Item](#12-herunterladen-der-subgraphen-für-jedes-einzelne-item)
< >     - [1.3 Archivierung](#13-archivierung)
< >   - [2. Push zu Zenodo](#2-push-zu-zenodo)
< >     - [2.1. Herausfinden der Concept-ID](#21-herausfinden-der-concept-id)
< >     - [2.2. Erstellung einer neuen Version](#22-erstellung-einer-neuen-version)
< >     - [2.3. Upload des Archives und Veröffentlichung](#23-upload-des-archives-und-veröffentlichung)
< > - [Setup und Anpassung](#setup-und-anpassung)
< >   - [Forken](#forken)
< >   - [Anpassung auf eigene Umgebung](#anpassung-auf-eigene-umgebung)
< >   - [CI/CD Mechanismus](#cicd-mechanismus) - [das CI-Script](#das-ci-script) -
< >   [Runner](#runner) - [Variablen](#variablen) - [Pipeline](#pipeline)
< >   <!--toc:end-->
< > 
< > ## Hintergrund
< > 
< > ### Was machen wir?
< > 
< > Als Teil der
< > [Tool Registry](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities")
< > bzw. jeden Forschungsprojekts, das Daten auf
< > [Wikidata](https://wikidata.org/ "Wikidata") publiziert, müssen wir regelmäßig
< > **unseren** kompletten Datensatz von Wikidata ziehen und in einem
< > Versionskontrollsystem ablegen, um ihn dann als stabilen und referenzierbaren
< > Datensatz publizieren und archivieren bzw. wieder in Linked-Open-Data Umgebungen
< > und Triple Stores einspeisen zu können.
< > 
< > Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,
< > die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert
< > werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet
< > automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs
< > geändert haben, es Störungen in der Internetverbindung gab, etc.).
< > 
< > ### Wozu wird das in der Wissenschaft gebraucht?
< > 
< > Es gibt zwei Hauptargumente für die versionierte Sicherung von auf Wikidata
< > publizierten Daten:
< > 
< > 1. Wikidata ist eine Platform außerhalb der unserer Kontrolle. Nicht nur können
< >    Daten jederzeit durch Nutzer_innen geändert und erweitert werden (einer der
< >    Hauptgründe überhaupt auf Wikidata zu setzen), sondern auch die technische
< >    Infrastruktur kann sich ändern bzw. aufhören in ihrer aktuellen Form zu
< >    existieren.
< > 2. Auf diesen Daten aufsetzende Analysen benötigen für die Reproduzierbarkeit
< >    ihrer Ergebnisse einen stabilen und referenzierbaren Datensatz. Gerade die in
< >    unserer item Registry erfassten computationellen Werkzeuge unterliegen
< >    rasanten Änderung. Und schon bei kleinen Abweichungen in der Versionsnummer
< >    kann es zu teils massiv unterschiedlichen Ergebnissen in der Evaluation
< >    kommen. Um hier Ergebnisse auch gegen neuere Ideen testen zu können muss für
< >    einen sinnvollen Vergleich natürlich gegen die Version, mit der die
< >    Forscher\*in zum Zeitpunkt der Publikation gearbeitet hat, getestet werden.
< > 
< > ## Implementation
< > 
< > Die Implementation erfolgt in drei Schritten, die in einer Kombination aus
< > Bash-Skripten und einem [CI/CD-Mechanismus](.gitlab-ci.yml) ausgeführt werden.
< > 
< > 1. Download der Daten von Wikidata und Speicherung in einem komprimierten
< >    Archivformat.
< > 2. Das Archiv wird in das Repository committed und es findet ein Release statt.
< > 3. Das Archiv wird auf [Zenodo](https://zenodo.org/) langzeitarchiviert[^1].
< > 
< > [^1]:
< >     [Zenodo](https://about.zenodo.org/policies/) sichert eine Speicherung für
< >     **mindestens** die nächsten 20 Jahre zu.
< > 
< > Das automatisierte Ausführen der Skripte und der Release geschehen über GitLab
< > "Pipeline Schedules" mit Hilfe eines CI-Skriptes.
< > 
< > ::: {.callout-warning}
< > 
< > WICHTIG: Für die Ausführung werden sogenannte _Runner_ benötigt, die die
< > notwendige Hard- und Software für die Ausführung der Scripte bereitstellen.
< > Falls bisher kein _Runner_ erstellt wurde, muss dieser vorher (z.b. durch
< > Administratoren, Projektmanager, ..)
< > [eingerichtet werden](https://docs.gitlab.com/runner/install/).
< > 
< > :::
< > 
< > ::: {.callout-warning}
< > 
< > WICHTIG: die Bash-Skripte sind nur auf UNIX-Systemen (Linux und macOS)
< > entwickelt und getestet worden. Über die Lauffähigkeit auf Windows-Systemen
< > können wir keine Aussage treffen.
< > 
< > :::
< > 
< > ## Skripte
< > 
< > Für die Ausführung der Bash-Skripte müssen momentan auf der Kommandozeile
< > folgende Programme verfügbar sein:
< > 
< > - [`jq`](https://jqlang.github.io/jq/): für die Manipulation von JSON.
< > - `curl`: für den Download
< > - `bzip2`: um das Archiv zu packen
< > - `pv`: Für die Statusleiste während des downloads und automatischer Schätzung
< >   der Restzeit
< > 
< > Unter Debian/Ubuntu lauten die entsprechenden Pakete gleichnamig.
< > 
< > ### 1. Download und Speicherung der Daten
< > 
< > Dieser Schritt wird von einem einzelnen [Bash-Skript](get_items.bash) übernommen
< > und umfasst die folgenden drei Teile:
< > 
< > 1. Der Umfang unseres zu speichernden Datensatzes (Graphs) wird mit SPARQL
< >    etabliert: Welche Wikidata-Items sind unsere Knoten erster Klasse, die den
< >    Kern des Graphen ausmachen?
< > 2. Alle diese Nodes und ihre Beziehungen zu einander werden über die Wikidata
< >    API heruntergeladen. Dabei muss festgelegt werden, wie viele Schritte von den
< >    Kernknoten weggegangen werden soll um nicht den gesamten Graphen von Wikidata
< >    zu speichern.
< > 3. Die heruntergeladenen Daten werden in ein Archivformat gepackt.
< > 
< > #### 1.1 Umfang des Graphen mit SPARQL festlegen
< > 
< > Zum Auffinden aller Items wird eine einfache SPARQL-Abfrage genutzt
< > 
< > <!-- hier können wir Tutorials, Dokumentation zu SPARQL verlinken -->, die die
< > 
< > IDs und eine Bezeichnung für die Items ausgibt. Im Fall unserer Tool Registry
< > sind das Werkzeuge für die Digital Humanities und die Abfrage basiert auf den
< > dafür entwickelten
< > [SPARQL Queries](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql).
< > 
< > ```sparql
< > SELECT DISTINCT
< >   ?item ?itemLabel
< > WHERE {
< >   ?method wdt:P9309 ?tadirahID.
< >   ?item wdt:P366 ?method;
< >     (wdt:P31/(wdt:P279*)) wd:Q7397.
< >   SERVICE wikibase:label {
< >       bd:serviceParam wikibase:language "en,de,fr, [AUTO_LANGUAGE]".
< >       ?item rdfs:label ?itemLabel.
< >   }
< > } LIMIT 5000
< > ```
< > 
< > Diese Abfrage etabliert eine Liste von Methoden (`?method`), die als Items
< > definiert sind, die eine TaDiRAH ID (`P9309`) besitzen. Dann wird nach allen
< > Items gesucht, die über das Statement "has use" (`P366`) mit einer dieser
< > Methoden verknüpft sind und im weitesten Sinne Software beschreiben
< > (`(wdt:P31/(wdt:P279*)) wd:Q7397`). Über den Service "wikibase:label" werden die
< > Tools dann noch um ihren Namen angereichert. Dieses ist nicht wirklich technisch
< > notwendig für unseren Zweck, bietet aber einen "sanity check" von
< > menschenlesbaren Bezeichnungen anstatt rein nummerischer IDs. Damit sich die
< > Bezeichnung nicht abhängig von den Einstellungen des Betriebssystems, auf dem
< > die Abfrage abgeführt wird, ändert, haben wir uns für englische Bezeichnungen
< > entschieden und einen Fallback auf andere Sprachen und schließlich die
< > Systemsprache gemacht.
< > 
< > Um direkt über den SPARQL-Endpoint von Wikidata abfragbar zu sein, muss diese
< > Abfrage URL-encoded sein (ergo alle Lehr- und Sonderzeichen müssen escaped
< > werden). Dieses wird über einen entsprechenden `curl`-Aufruf erreicht, der sich
< > um die entsprechende Behandlung kümmert.
< > 
< > Somit wird aus
< > 
< > ```bash
< > curl -s -XGET --get \
< >               --data-urlencode "format=json" \
< >               --data-urlencode "query@$QUERY" \
< >               'https://query.wikidata.org/sparql'
< > ```
< > 
< > zum Beispiel
< > `https://query.wikidata.org/sparql?query=SELECT%20DISTINCT%20%0A%20%3Fitem%20%3FitemLabel%0AWHERE%20%7B%0A%20%3Fmethod%20wdt%3AP9309%20%3FtadirahID.%0A%20%3Fitem%20wdt%3AP366%20%3Fmethod%3B%0A%20(wdt%3AP31%2F(wdt%3AP279*))%20wd%3AQ7397.%0A%20SERVICE%20wikibase%3Alabel%20%7B%0A%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cde%2Cfr%2C%20en%22.%0A%20%3Fitem%20rdfs%3Alabel%20%3FitemLabel.%0A%20%7D%0A%7D%20LIMIT%205000`.
< > 
< > Das Skript fragt diese Liste als JSON an, benennt anschließend programmatisch
< > keys um, und legt diese für den nächsten Schritt ab.
< > 
< > #### 1.2 Herunterladen der Subgraphen für jedes einzelne Item
< > 
< > Im folgenden wird über die Liste aus dem ersten Schritt iteriert und die
< > Subgraphen für jedes einzelnen Item anhand seiner ID von Wikidata
< > heruntergeladen. Wikidata bietet dazu mehrer Möglichkeiten. Zum einen gibt es
< > eine offizielle REST API
< > ([OpenAPI Swagger documentation](https://doc.wikimedia.org/Wikibase/master/js/rest-api/)),
< > die ein Wikidata-spezifisches JSON ausgibt:
< > 
< > ```bash
< > https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/${itemid}
< > ```
< > 
< > Aktuell unterstützt diese API aber noch nicht die für uns notwendigen
< > RDF-Serialisierungen, wie z.B. JSON-LD, Turtle oder RDF/XML. Diese sind über
< > `Special:EntityData` URLs verfügbar, die quasi direkt das Ergebnis einer SPARQL
< > `SELECT`-Abfrage aus deren Cache nehmen:
< > 
< > ```bash
< > https://www.wikidata.org/wiki/Special:EntityData/${itemid}.${format}
< > ```
< > 
< > Beide Varianten sind wesentlich performanter als direkte SPARQL Abfragen.
< > 
< > Im Ergebnis dieses Schrittes haben wir für jedes Item eine lokale RDF-Datei, die
< > dann archiviert und wieder in alle gängigen Knowledge-Graphen importiert werden
< > kann.
< > 
< > #### 1.3 Archivierung
< > 
< > Zum Abschluss wird aus den heruntergeladenen Daten ein `.tar.bz2`-Archiv
< > erstellt und mit dem aktuellen Datum versehen. Durch diesen Schritt spielt es
< > für den Platzverbrauch so gut wie keine Rolle, wie viele Serialisierungen wir
< > speichern, da viele Angaben redundant sind und damit gut komprimiert werden
< > können.
< > 
< > ### 2. Push zu Zenodo
< > 
< > Auch dieser Schritt wird von einem einzelnen [Bash-Skript](upload_zenodo.bash)
< > übernommen und umfasst die folgenden Teile:
< > 
< > 1. Herausfinden der Concept-ID in dem das Datenset gespeichert werden soll
< > 2. Erstellung einer neuen Version und auslesen der Metadaten
< > 3. Upload des Archives und veröffentlichen der neuen Version
< > 
< > Bevor wir aber auf die eigentliche Arbeit Bezug nehmen können wird zunächst
< > festgestellt, ob alle Umgebungsvariablen korrekt gesetzt sind und andernfalls
< > mit einer entsprechenden Fehlermeldung abgebrochen. Daher können wir im
< > folgenden davon ausgehen, dass diese Variablen korrekt gesetzt sind:
< > 
< > - `API_BASE` für den Server den wir benutzen (z.B. Sandbox oder Live)
< > - `ZENODO_TOKEN` vorhanden ist und auch gültig (eine Test-Anfrage würde sonst
< >   z.B. einen 403 "kein Zugriff" zurückmelden).
< > - `ZENODO_ID` oder `ZENODO_CONCEPT_ID` zum weiteren Bearbeiten. Streng genommen
< >   reicht die Concept-ID - aber diese ist nur schwierig zu finden, daher ist es
< >   einfacher, wenn wir die ID irgendeiner Version haben, die released wurde und
< >   fragen programmatisch nach der korrekten ID.
< > 
< > Generell ist die Kommunikation mit der API eine Abfolge von `curl`-Aufrufen. Die
< > einfachste Weise mit der API auch menschenlesbar zu kommunizieren ist `json`.
< > 
< > Daher hat fast jede Anfrage den Aufbau
< > 
< > ```bash
< > curl -s     # silent -> keine Ausgabe zur Verbindung, Downloadrate, etc.
< >      -XGET  # Methode; Meist GET, POST, DELETE, PUT, ..
< >      -H "Authorization: Bearer ${ZENODO_TOKEN}" # Authentifizierung
< >      --header "Content-Type: application/json"  # Wir senden JSON
< >      --header "Accept: application/json"        # Wir möchten JSON zurück
< >      --data ''                                  # Unsere Daten
< >      "${API_BASE}/api/deposit/depositions/${ZENODO_ID}" # API-Endpunkt
< > ```
< > 
< > Unterschiede gibt es nur in der Methode, den Daten und dem API-Endpunkt.
< > 
< > #### 2.1. Herausfinden der Concept-ID
< > 
< > Da das Script ein "Hands-Off"-Script werden soll, können wir nicht davon
< > ausgehen, dass wir immer die aktuellste Version des Releases kennen. Daher
< > können wir mittels der Concept-ID eine Anfrage stellen und uns die neueste
< > Version zurückgeben lassen. Hierzu benötigen wir nur irgendeine Version des zu
< > aktualisierenden Zenodo-Eintrages. Von diesem lassen wir uns die Metadaten geben
< > und im Feld `conceptrecid` steht dann die zugehörige Concept-ID.
< > 
< > #### 2.2. Erstellung einer neuen Version
< > 
< > Da wir sehr defensiv sind und lieber mit einem Fehler aufhören statt etwas
< > kaputt zu machen holen wir uns zunächst den aktuellen "state" der neuesten
< > Version. Eine Suche nach der `conceptrecid` liefert uns die Metadaten und auch
< > den aktuellen Zustand der neuesten Version. Für gewöhnlich gehen wir davon aus,
< > dass hier alles "done" ist - also released und unbearbeitet.
< > 
< > Falls man im Web allerdings angefangen hat den Eintrag zu editieren (o.ä.) steht
< > hier dann statt einem "done" ein "inprogress", was auf einen gerade laufenden
< > Edit hinweist. In diesem Falle brechen wir mit einem Fehler ab. Entweder
< > verwirft man vorher seine Änderungen oder publiziert sie.
< > 
< > Wir erstellen dann über den `newversion`-endpunkt der API eine neue Version und
< > schreiben den neuen Eintrag, ID, etc. in variablen. Bei Zenodo hängt an einem
< > kopierten (geklontem) Eintrag dann noch ein Verweis zu den alten Datensätzen
< > an - es kann ja sein, dass man mit einer neuen Version nur Metadaten oder Lizenz
< > ändert, aber nicht die Daten selbst. Diese Verweise werden daher direkt
< > entfernt.
< > 
< > #### 2.3. Upload des Archives und Veröffentlichung
< > 
< > Gegen Ende stellen wir noch sicher, dass unser Archiv auch lokal vorhanden ist
< > und laden es hoch. In den Metadaten überschreiben wir dann noch die Felder
< > `publication_date` und fügen zum Feld `dates` noch das Event `updated` mit einer
< > kleinen Beschreibung hinzu.
< > 
< > Vor dem Release holen wir noch einmal den gesamten Datensatz, den wir nun
< > automatisch publishen lesbar von Zenodo und geben ihn ins log aus. So kann man
< > auch innerhalb von Gitlab sehen, was genau hochgeladen wurde.
< > 
< > Zum Abschluss senden wir dann noch die Anfrage an `.../$id/actions/publish` um
< > das Release abzuschließen.
< > 
< > ## Setup und Anpassung
< > 
< > Zur regelmäßigen Archivierung werden die Bash-Skripte durch GitLab selbst mit
< > einer CI/CD Pipeline ausgeführt. Daten von Wikidata heruntergeladen, verpackt,
< > das erstellte `.tar.bz2`-Archiv als "Release" zur Verfügung gestellt und
< > schließlich zu Zenodo hochgeladen.
< > 
< > ### Forken
< > 
< > Wenn mensch dieses Beispielprojekt für eigene Daten in ihrer jeweils eigenen
< > Domäne nutzen möchte, so muss dieses Projekt zunächst
< > "[geforked](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/forks/new)"
< > oder "geklont" und angepasst werden.
< > 
< > ### Anpassung auf eigene Umgebung
< > 
< > Zunächst muss die SPARQL-query geändert werden. Dafür kann `query_example.rq`
< > als Grundlage genommen und dann als `query.rq` gespeichert werden.
< > 
< > Falls die Items nicht nur in einer Query abgefragt werden können, ist dies kein
< > Problem. Alle queries nach dem Muster `query[0-9]*.rq` (also `query.rq`,
< > `query2.rq`, `query123456.rq`, aber NICHT `query123_abc.rq` o.ä.) werden
< > ausgeführt, die Items in einer Datei gesammelt und anschließen nur 1x gesammelt
< > abgefragt.
< > 
< > Je nachdem ob die Bash-Skripte lokal oder in einer CI/CD Pipeline ausgeführt
< > werden sollen, müssen die entsprechenden Zeilen am Beginn der Skripte
< > auskommentiert werden oder nicht (siehe Kommentare in den Skripten selbst).
< > 
< > ### CI/CD Mechanismus
< > 
< > #### das CI-Script
< > 
< > Das GitLab CI-Script ist eine YAML Datei (`.gitlab-ci.yml`). Diese legt drei
< > Jobs an und führt sie nacheinander aus: `build-job`, `release-job` und
< > `publish-job`.
< > 
< > 1. Der `build-job` wird ausgeführt, wenn ein geplanter Auftrag oder ein
< >    Commit-Tag vorliegt. In diesem Job werden, falls nicht vorhanden, die
< >    erforderlichen items installiert, das eigentliche Skript `get_items.bash`
< >    ausgeführt und eine Archiv-Datei mit dem aktuellen Datum generiert. Die
< >    generierte Datei wird als Artefakt gespeichert.
< > 2. Der `release-job` wird nur dann ausgeführt, wenn der `build-job` erfolgreich
< >    war. In diesem Job wird eine Release erstellt, die den Namen
< >    `Release item-Registry vom <Aktuelles_Datum>` trägt und eine Beschreibung
< >    enthält. Die generierte Datei aus dem `build-job` wird als Asset der Release
< >    hinzugefügt.
< > 3. Der `publish-job` wird nur ausgeführt, wenn in der Gitlab-Pipeline die
< >    Variable `PUBLISH` auf `true` gesetzt wurde - ansonsten wird dieser
< >    übersprungen. Der Job stellt sicher, dass das erstellte Archiv aus dem
< >    `build-job` verfügbar ist und der `release-job` problemfrei durchgelaufen
< >    ist. Dann wird das eigentliche Skript `upload_zenodo.bash` ausgeführt,
< >    welches sich um des gesamten Publikationsprozess kümmert.
< > 
< > #### Runner
< > 
< > Es muss ein Runner ausgewählt und der Tag des Runners in `.gitlab-ci.yaml`
< > angegeben werden. Für Mitglieder des _Methods Innovation Lab_ der HU Berlin ist
< > bereits ein Runner eingerichtet.
< > 
< > #### Variablen
< > 
< > Für die CI/CD müssen Variablen gesetzt werden, die vom CI Script genutzt werden.
< > Hierzu ruft mensch die `Settings->CI/CD` auf:
< > 
< > ![Settings CI/CD](img/tutorial-2-settings-ci_cd.png)
< > 
< > - **API_BASE**: Stellt die Basisadresse für API-Aufrufe dar. Standardmäßig ist
< >   es auf den Sandbox-Endpunkt von Zenodo gesetzt, kann aber überschrieben
< >   werden, um Anfragen an die Live-Umgebung zu stellen (z.B.
< >   `https://zenodo.org/`).
< > - **ZENODO_TOKEN**: Dies ist der Token, der zur Authentifizierung bei Zenodo
< >   erforderlich ist und
< >   [entsprechend erstellt werden muss](https://zenodo.org/account/settings/applications/tokens/new/).
< > - **ZENODO_ID** ist die Nummer am Ende der URL eines Zenodo-Eintrages,
< >   beispielsweise `13818437` in `https://zenodo.org/records/13818437`, der den
< >   Datensatz enthalten soll. Dieser **muss vorher** einmalig von Hand angelegt
< >   und ausgefüllt werden, da an diesen die neuen Versionen angehangen werden.
< > 
< > ![Settings after variable creation](img/tutorial-6-settings-post.png)
< > 
< > #### Pipeline
< > 
< > Die automatische Erstellung von Archiven wird über `Build->Pipeline Schedules`
< > eingerichtet. Wichtig ist das setzen der Variable `SCHEDULED` auf `true`, da
< > sonst das Script nichts durchführt. Falls o.g. Variablen für Zenodo
< > bereitgestellt wurden, kann mittels `PUBLISH` auf `true` auch das publizieren
< > automatisiert werden.
< > 
< > ![Schedule creation](img/tutorial-7-schedule.png)
< > 
< > Nach dieser Einrichtung sollte alles weiter automatisch laufen. Man kann prüfen,
< > ob alle funktioniert, indem man die Pipeline einmal manuell startet und dabei
< > die Variable `SCHEDULED` auf `true` setzt und je nach Versuch `PUBLISH` auf
< > `true` oder `false`.
431c30,430
< ---
---
> 
> [![pipeline
> status](../../../badges/main/pipeline.svg)](../pipelines?page=1&scope=all&ref=main)
> [![Latest Release](../../badges/release.svg)](../../releases)
> 
> ![Project-logo](img/logo.jpg)
> 
> <!--toc:start-->
> 
> - [Hintergrund](#hintergrund)
>   - [Was machen wir?](#was-machen-wir)
>   - [Wozu wird das in der Wissenschaft gebraucht?](#wozu-wird-das-in-der-wissenschaft-gebraucht)
> 
> - [Implementation](#implementation)
> - [Skripte](#skripte)
>   - [1. Download und Speicherung der Daten](#1-download-und-speicherung-der-daten)
>     - [1.1 Umfang des Graphen mit SPARQL festlegen](#11-umfang-des-graphen-mit-sparql-festlegen)
>     - [1.2 Herunterladen der Subgraphen für jedes einzelne Item](#12-herunterladen-der-subgraphen-für-jedes-einzelne-item)
>     - [1.3 Archivierung](#13-archivierung)
>   - [2. Push zu Zenodo](#2-push-zu-zenodo)
>     - [2.1. Herausfinden der Concept-ID](#21-herausfinden-der-concept-id)
>     - [2.2. Erstellung einer neuen Version](#22-erstellung-einer-neuen-version)
>     - [2.3. Upload des Archives und Veröffentlichung](#23-upload-des-archives-und-veröffentlichung)
> - [Setup und Anpassung](#setup-und-anpassung)
>   - [Forken](#forken)
>   - [Anpassung auf eigene Umgebung](#anpassung-auf-eigene-umgebung)
>   - [CI/CD Mechanismus](#cicd-mechanismus) - [das CI-Script](#das-ci-script) -
>   [Runner](#runner) - [Variablen](#variablen) - [Pipeline](#pipeline)
>   <!--toc:end-->
> 
> ## Hintergrund
> 
> ### Was machen wir?
> 
> Als Teil der
> [Tool Registry](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry "Wikidata-based Tool Registry for Digital Humanities")
> bzw. jeden Forschungsprojekts, das Daten auf
> [Wikidata](https://wikidata.org/ "Wikidata") publiziert, müssen wir regelmäßig
> **unseren** kompletten Datensatz von Wikidata ziehen und in einem
> Versionskontrollsystem ablegen, um ihn dann als stabilen und referenzierbaren
> Datensatz publizieren und archivieren bzw. wieder in Linked-Open-Data Umgebungen
> und Triple Stores einspeisen zu können.
> 
> Dafür haben wir Skripte für die Wikidata API bzw. SPARQL Endpoint geschrieben,
> die dann als Teil eines CI/CD-Mechanismus laufen und automatisch publiziert
> werden. Nach der Einrichtung läuft dieses System dann vollautomatisch und sendet
> automatisch Berichte, wenn etwas nicht geklappt hat (z.B. weil sich APIs
> geändert haben, es Störungen in der Internetverbindung gab, etc.).
> 
> ### Wozu wird das in der Wissenschaft gebraucht?
> 
> Es gibt zwei Hauptargumente für die versionierte Sicherung von auf Wikidata
> publizierten Daten:
> 
> 1. Wikidata ist eine Platform außerhalb der unserer Kontrolle. Nicht nur können
>    Daten jederzeit durch Nutzer_innen geändert und erweitert werden (einer der
>    Hauptgründe überhaupt auf Wikidata zu setzen), sondern auch die technische
>    Infrastruktur kann sich ändern bzw. aufhören in ihrer aktuellen Form zu
>    existieren.
> 2. Auf diesen Daten aufsetzende Analysen benötigen für die Reproduzierbarkeit
>    ihrer Ergebnisse einen stabilen und referenzierbaren Datensatz. Gerade die in
>    unserer item Registry erfassten computationellen Werkzeuge unterliegen
>    rasanten Änderung. Und schon bei kleinen Abweichungen in der Versionsnummer
>    kann es zu teils massiv unterschiedlichen Ergebnissen in der Evaluation
>    kommen. Um hier Ergebnisse auch gegen neuere Ideen testen zu können muss für
>    einen sinnvollen Vergleich natürlich gegen die Version, mit der die
>    Forscher\*in zum Zeitpunkt der Publikation gearbeitet hat, getestet werden.
> 
> ## Implementation
> 
> Die Implementation erfolgt in drei Schritten, die in einer Kombination aus
> Bash-Skripten und einem [CI/CD-Mechanismus](.gitlab-ci.yml) ausgeführt werden.
> 
> 1. Download der Daten von Wikidata und Speicherung in einem komprimierten
>    Archivformat.
> 2. Das Archiv wird in das Repository committed und es findet ein Release statt.
> 3. Das Archiv wird auf [Zenodo](https://zenodo.org/) langzeitarchiviert[^1].
> 
> [^1]:
>     [Zenodo](https://about.zenodo.org/policies/) sichert eine Speicherung für
>     **mindestens** die nächsten 20 Jahre zu.
> 
> Das automatisierte Ausführen der Skripte und der Release geschehen über GitLab
> "Pipeline Schedules" mit Hilfe eines CI-Skriptes.
> 
> ::: {.callout-warning}
> 
> WICHTIG: Für die Ausführung werden sogenannte _Runner_ benötigt, die die
> notwendige Hard- und Software für die Ausführung der Scripte bereitstellen.
> Falls bisher kein _Runner_ erstellt wurde, muss dieser vorher (z.b. durch
> Administratoren, Projektmanager, ..)
> [eingerichtet werden](https://docs.gitlab.com/runner/install/).
> 
> :::
> 
> ::: {.callout-warning}
> 
> WICHTIG: die Bash-Skripte sind nur auf UNIX-Systemen (Linux und macOS)
> entwickelt und getestet worden. Über die Lauffähigkeit auf Windows-Systemen
> können wir keine Aussage treffen.
> 
> :::
> 
> ## Skripte
> 
> Für die Ausführung der Bash-Skripte müssen momentan auf der Kommandozeile
> folgende Programme verfügbar sein:
> 
> - [`jq`](https://jqlang.github.io/jq/): für die Manipulation von JSON.
> - `curl`: für den Download
> - `bzip2`: um das Archiv zu packen
> - `pv`: Für die Statusleiste während des downloads und automatischer Schätzung
>   der Restzeit
> 
> Unter Debian/Ubuntu lauten die entsprechenden Pakete gleichnamig.
> 
> ### 1. Download und Speicherung der Daten
> 
> Dieser Schritt wird von einem einzelnen [Bash-Skript](get_items.bash) übernommen
> und umfasst die folgenden drei Teile:
> 
> 1. Der Umfang unseres zu speichernden Datensatzes (Graphs) wird mit SPARQL
>    etabliert: Welche Wikidata-Items sind unsere Knoten erster Klasse, die den
>    Kern des Graphen ausmachen?
> 2. Alle diese Nodes und ihre Beziehungen zu einander werden über die Wikidata
>    API heruntergeladen. Dabei muss festgelegt werden, wie viele Schritte von den
>    Kernknoten weggegangen werden soll um nicht den gesamten Graphen von Wikidata
>    zu speichern.
> 3. Die heruntergeladenen Daten werden in ein Archivformat gepackt.
> 
> #### 1.1 Umfang des Graphen mit SPARQL festlegen
> 
> Zum Auffinden aller Items wird eine einfache SPARQL-Abfrage genutzt
> 
> <!-- hier können wir Tutorials, Dokumentation zu SPARQL verlinken -->, die die
> 
> IDs und eine Bezeichnung für die Items ausgibt. Im Fall unserer Tool Registry
> sind das Werkzeuge für die Digital Humanities und die Abfrage basiert auf den
> dafür entwickelten
> [SPARQL Queries](https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql).
> 
> ```sparql
> SELECT DISTINCT
>   ?item ?itemLabel
> WHERE {
>   ?method wdt:P9309 ?tadirahID.
>   ?item wdt:P366 ?method;
>     (wdt:P31/(wdt:P279*)) wd:Q7397.
>   SERVICE wikibase:label {
>       bd:serviceParam wikibase:language "en,de,fr, [AUTO_LANGUAGE]".
>       ?item rdfs:label ?itemLabel.
>   }
> } LIMIT 5000
> ```
> 
> Diese Abfrage etabliert eine Liste von Methoden (`?method`), die als Items
> definiert sind, die eine TaDiRAH ID (`P9309`) besitzen. Dann wird nach allen
> Items gesucht, die über das Statement "has use" (`P366`) mit einer dieser
> Methoden verknüpft sind und im weitesten Sinne Software beschreiben
> (`(wdt:P31/(wdt:P279*)) wd:Q7397`). Über den Service "wikibase:label" werden die
> Tools dann noch um ihren Namen angereichert. Dieses ist nicht wirklich technisch
> notwendig für unseren Zweck, bietet aber einen "sanity check" von
> menschenlesbaren Bezeichnungen anstatt rein nummerischer IDs. Damit sich die
> Bezeichnung nicht abhängig von den Einstellungen des Betriebssystems, auf dem
> die Abfrage abgeführt wird, ändert, haben wir uns für englische Bezeichnungen
> entschieden und einen Fallback auf andere Sprachen und schließlich die
> Systemsprache gemacht.
> 
> Um direkt über den SPARQL-Endpoint von Wikidata abfragbar zu sein, muss diese
> Abfrage URL-encoded sein (ergo alle Lehr- und Sonderzeichen müssen escaped
> werden). Dieses wird über einen entsprechenden `curl`-Aufruf erreicht, der sich
> um die entsprechende Behandlung kümmert.
> 
> Somit wird aus
> 
> ```bash
> curl -s -XGET --get \
>               --data-urlencode "format=json" \
>               --data-urlencode "query@$QUERY" \
>               'https://query.wikidata.org/sparql'
> ```
> 
> zum Beispiel
> `https://query.wikidata.org/sparql?query=SELECT%20DISTINCT%20%0A%20%3Fitem%20%3FitemLabel%0AWHERE%20%7B%0A%20%3Fmethod%20wdt%3AP9309%20%3FtadirahID.%0A%20%3Fitem%20wdt%3AP366%20%3Fmethod%3B%0A%20(wdt%3AP31%2F(wdt%3AP279*))%20wd%3AQ7397.%0A%20SERVICE%20wikibase%3Alabel%20%7B%0A%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cde%2Cfr%2C%20en%22.%0A%20%3Fitem%20rdfs%3Alabel%20%3FitemLabel.%0A%20%7D%0A%7D%20LIMIT%205000`.
> 
> Das Skript fragt diese Liste als JSON an, benennt anschließend programmatisch
> keys um, und legt diese für den nächsten Schritt ab.
> 
> #### 1.2 Herunterladen der Subgraphen für jedes einzelne Item
> 
> Im folgenden wird über die Liste aus dem ersten Schritt iteriert und die
> Subgraphen für jedes einzelnen Item anhand seiner ID von Wikidata
> heruntergeladen. Wikidata bietet dazu mehrer Möglichkeiten. Zum einen gibt es
> eine offizielle REST API
> ([OpenAPI Swagger documentation](https://doc.wikimedia.org/Wikibase/master/js/rest-api/)),
> die ein Wikidata-spezifisches JSON ausgibt:
> 
> ```bash
> https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items/${itemid}
> ```
> 
> Aktuell unterstützt diese API aber noch nicht die für uns notwendigen
> RDF-Serialisierungen, wie z.B. JSON-LD, Turtle oder RDF/XML. Diese sind über
> `Special:EntityData` URLs verfügbar, die quasi direkt das Ergebnis einer SPARQL
> `SELECT`-Abfrage aus deren Cache nehmen:
> 
> ```bash
> https://www.wikidata.org/wiki/Special:EntityData/${itemid}.${format}
> ```
> 
> Beide Varianten sind wesentlich performanter als direkte SPARQL Abfragen.
> 
> Im Ergebnis dieses Schrittes haben wir für jedes Item eine lokale RDF-Datei, die
> dann archiviert und wieder in alle gängigen Knowledge-Graphen importiert werden
> kann.
> 
> #### 1.3 Archivierung
> 
> Zum Abschluss wird aus den heruntergeladenen Daten ein `.tar.bz2`-Archiv
> erstellt und mit dem aktuellen Datum versehen. Durch diesen Schritt spielt es
> für den Platzverbrauch so gut wie keine Rolle, wie viele Serialisierungen wir
> speichern, da viele Angaben redundant sind und damit gut komprimiert werden
> können.
> 
> ### 2. Push zu Zenodo
> 
> Auch dieser Schritt wird von einem einzelnen [Bash-Skript](upload_zenodo.bash)
> übernommen und umfasst die folgenden Teile:
> 
> 1. Herausfinden der Concept-ID in dem das Datenset gespeichert werden soll
> 2. Erstellung einer neuen Version und auslesen der Metadaten
> 3. Upload des Archives und veröffentlichen der neuen Version
> 
> Bevor wir aber auf die eigentliche Arbeit Bezug nehmen können wird zunächst
> festgestellt, ob alle Umgebungsvariablen korrekt gesetzt sind und andernfalls
> mit einer entsprechenden Fehlermeldung abgebrochen. Daher können wir im
> folgenden davon ausgehen, dass diese Variablen korrekt gesetzt sind:
> 
> - `API_BASE` für den Server den wir benutzen (z.B. Sandbox oder Live)
> - `ZENODO_TOKEN` vorhanden ist und auch gültig (eine Test-Anfrage würde sonst
>   z.B. einen 403 "kein Zugriff" zurückmelden).
> - `ZENODO_ID` oder `ZENODO_CONCEPT_ID` zum weiteren Bearbeiten. Streng genommen
>   reicht die Concept-ID - aber diese ist nur schwierig zu finden, daher ist es
>   einfacher, wenn wir die ID irgendeiner Version haben, die released wurde und
>   fragen programmatisch nach der korrekten ID.
> 
> Generell ist die Kommunikation mit der API eine Abfolge von `curl`-Aufrufen. Die
> einfachste Weise mit der API auch menschenlesbar zu kommunizieren ist `json`.
> 
> Daher hat fast jede Anfrage den Aufbau
> 
> ```bash
> curl -s     # silent -> keine Ausgabe zur Verbindung, Downloadrate, etc.
>      -XGET  # Methode; Meist GET, POST, DELETE, PUT, ..
>      -H "Authorization: Bearer ${ZENODO_TOKEN}" # Authentifizierung
>      --header "Content-Type: application/json"  # Wir senden JSON
>      --header "Accept: application/json"        # Wir möchten JSON zurück
>      --data ''                                  # Unsere Daten
>      "${API_BASE}/api/deposit/depositions/${ZENODO_ID}" # API-Endpunkt
> ```
> 
> Unterschiede gibt es nur in der Methode, den Daten und dem API-Endpunkt.
> 
> #### 2.1. Herausfinden der Concept-ID
> 
> Da das Script ein "Hands-Off"-Script werden soll, können wir nicht davon
> ausgehen, dass wir immer die aktuellste Version des Releases kennen. Daher
> können wir mittels der Concept-ID eine Anfrage stellen und uns die neueste
> Version zurückgeben lassen. Hierzu benötigen wir nur irgendeine Version des zu
> aktualisierenden Zenodo-Eintrages. Von diesem lassen wir uns die Metadaten geben
> und im Feld `conceptrecid` steht dann die zugehörige Concept-ID.
> 
> #### 2.2. Erstellung einer neuen Version
> 
> Da wir sehr defensiv sind und lieber mit einem Fehler aufhören statt etwas
> kaputt zu machen holen wir uns zunächst den aktuellen "state" der neuesten
> Version. Eine Suche nach der `conceptrecid` liefert uns die Metadaten und auch
> den aktuellen Zustand der neuesten Version. Für gewöhnlich gehen wir davon aus,
> dass hier alles "done" ist - also released und unbearbeitet.
> 
> Falls man im Web allerdings angefangen hat den Eintrag zu editieren (o.ä.) steht
> hier dann statt einem "done" ein "inprogress", was auf einen gerade laufenden
> Edit hinweist. In diesem Falle brechen wir mit einem Fehler ab. Entweder
> verwirft man vorher seine Änderungen oder publiziert sie.
> 
> Wir erstellen dann über den `newversion`-endpunkt der API eine neue Version und
> schreiben den neuen Eintrag, ID, etc. in variablen. Bei Zenodo hängt an einem
> kopierten (geklontem) Eintrag dann noch ein Verweis zu den alten Datensätzen
> an - es kann ja sein, dass man mit einer neuen Version nur Metadaten oder Lizenz
> ändert, aber nicht die Daten selbst. Diese Verweise werden daher direkt
> entfernt.
> 
> #### 2.3. Upload des Archives und Veröffentlichung
> 
> Gegen Ende stellen wir noch sicher, dass unser Archiv auch lokal vorhanden ist
> und laden es hoch. In den Metadaten überschreiben wir dann noch die Felder
> `publication_date` und fügen zum Feld `dates` noch das Event `updated` mit einer
> kleinen Beschreibung hinzu.
> 
> Vor dem Release holen wir noch einmal den gesamten Datensatz, den wir nun
> automatisch publishen lesbar von Zenodo und geben ihn ins log aus. So kann man
> auch innerhalb von Gitlab sehen, was genau hochgeladen wurde.
> 
> Zum Abschluss senden wir dann noch die Anfrage an `.../$id/actions/publish` um
> das Release abzuschließen.
> 
> ## Setup und Anpassung
> 
> Zur regelmäßigen Archivierung werden die Bash-Skripte durch GitLab selbst mit
> einer CI/CD Pipeline ausgeführt. Daten von Wikidata heruntergeladen, verpackt,
> das erstellte `.tar.bz2`-Archiv als "Release" zur Verfügung gestellt und
> schließlich zu Zenodo hochgeladen.
> 
> ### Forken
> 
> Wenn mensch dieses Beispielprojekt für eigene Daten in ihrer jeweils eigenen
> Domäne nutzen möchte, so muss dieses Projekt zunächst
> "[geforked](https://scm.cms.hu-berlin.de/methodenlabor/p_wikidata2gitlab/-/forks/new)"
> oder "geklont" und angepasst werden.
> 
> ### Anpassung auf eigene Umgebung
> 
> Zunächst muss die SPARQL-query geändert werden. Dafür kann `query_example.rq`
> als Grundlage genommen und dann als `query.rq` gespeichert werden.
> 
> Falls die Items nicht nur in einer Query abgefragt werden können, ist dies kein
> Problem. Alle queries nach dem Muster `query[0-9]*.rq` (also `query.rq`,
> `query2.rq`, `query123456.rq`, aber NICHT `query123_abc.rq` o.ä.) werden
> ausgeführt, die Items in einer Datei gesammelt und anschließen nur 1x gesammelt
> abgefragt.
> 
> Je nachdem ob die Bash-Skripte lokal oder in einer CI/CD Pipeline ausgeführt
> werden sollen, müssen die entsprechenden Zeilen am Beginn der Skripte
> auskommentiert werden oder nicht (siehe Kommentare in den Skripten selbst).
> 
> ### CI/CD Mechanismus
> 
> #### das CI-Script
> 
> Das GitLab CI-Script ist eine YAML Datei (`.gitlab-ci.yml`). Diese legt drei
> Jobs an und führt sie nacheinander aus: `build-job`, `release-job` und
> `publish-job`.
> 
> 1. Der `build-job` wird ausgeführt, wenn ein geplanter Auftrag oder ein
>    Commit-Tag vorliegt. In diesem Job werden, falls nicht vorhanden, die
>    erforderlichen items installiert, das eigentliche Skript `get_items.bash`
>    ausgeführt und eine Archiv-Datei mit dem aktuellen Datum generiert. Die
>    generierte Datei wird als Artefakt gespeichert.
> 2. Der `release-job` wird nur dann ausgeführt, wenn der `build-job` erfolgreich
>    war. In diesem Job wird eine Release erstellt, die den Namen
>    `Release item-Registry vom <Aktuelles_Datum>` trägt und eine Beschreibung
>    enthält. Die generierte Datei aus dem `build-job` wird als Asset der Release
>    hinzugefügt.
> 3. Der `publish-job` wird nur ausgeführt, wenn in der Gitlab-Pipeline die
>    Variable `PUBLISH` auf `true` gesetzt wurde - ansonsten wird dieser
>    übersprungen. Der Job stellt sicher, dass das erstellte Archiv aus dem
>    `build-job` verfügbar ist und der `release-job` problemfrei durchgelaufen
>    ist. Dann wird das eigentliche Skript `upload_zenodo.bash` ausgeführt,
>    welches sich um des gesamten Publikationsprozess kümmert.
> 
> #### Runner
> 
> Es muss ein Runner ausgewählt und der Tag des Runners in `.gitlab-ci.yaml`
> angegeben werden. Für Mitglieder des _Methods Innovation Lab_ der HU Berlin ist
> bereits ein Runner eingerichtet.
> 
> #### Variablen
> 
> Für die CI/CD müssen Variablen gesetzt werden, die vom CI Script genutzt werden.
> Hierzu ruft mensch die `Settings->CI/CD` auf:
> 
> ![Settings CI/CD](img/tutorial-2-settings-ci_cd.png)
> 
> - **API_BASE**: Stellt die Basisadresse für API-Aufrufe dar. Standardmäßig ist
>   es auf den Sandbox-Endpunkt von Zenodo gesetzt, kann aber überschrieben
>   werden, um Anfragen an die Live-Umgebung zu stellen (z.B.
>   `https://zenodo.org/`).
> - **ZENODO_TOKEN**: Dies ist der Token, der zur Authentifizierung bei Zenodo
>   erforderlich ist und
>   [entsprechend erstellt werden muss](https://zenodo.org/account/settings/applications/tokens/new/).
> - **ZENODO_ID** ist die Nummer am Ende der URL eines Zenodo-Eintrages,
>   beispielsweise `13818437` in `https://zenodo.org/records/13818437`, der den
>   Datensatz enthalten soll. Dieser **muss vorher** einmalig von Hand angelegt
>   und ausgefüllt werden, da an diesen die neuen Versionen angehangen werden.
> 
> ![Settings after variable creation](img/tutorial-6-settings-post.png)
> 
> #### Pipeline
> 
> Die automatische Erstellung von Archiven wird über `Build->Pipeline Schedules`
> eingerichtet. Wichtig ist das setzen der Variable `SCHEDULED` auf `true`, da
> sonst das Script nichts durchführt. Falls o.g. Variablen für Zenodo
> bereitgestellt wurden, kann mittels `PUBLISH` auf `true` auch das publizieren
> automatisiert werden.
> 
> ![Schedule creation](img/tutorial-7-schedule.png)
> 
> Nach dieser Einrichtung sollte alles weiter automatisch laufen. Man kann prüfen,
> ob alle funktioniert, indem man die Pipeline einmal manuell startet und dabei
> die Variable `SCHEDULED` auf `true` setzt und je nach Versuch `PUBLISH` auf
> `true` oder `false`.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/p_zotero2wikidata.qmd quarto/methodenlabor/p_zotero2wikidata.qmd
2c2
< title: "p_zotero2wikidata (Methodenlabor)"
---
> title: "Methodenlabor / p_zotero2wikidata (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/p_zotero2wikidata
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/p_zotero2wikidata"
>       icon: "gitlab"
11c11
< # p_zotero2wikidata (Methodenlabor)
---
> # Methodenlabor / p_zotero2wikidata (Methodenlabor)
15d14
< > subtitle: 
17,22c16,18
< >     - Isabell Trilling
< > date: 2024-04-10
< > status: draft
< > lang: de
< > licence: https://creativecommons.org/licenses/by/4.0/
< > markdown: pandoc
---
> > - "Isabell Trilling"
> > date: "2024-04-10"
> > lang: "de"
24,27c20,27
< >     - Zotero
< >     - Quickstatements
< >     - bibliographische Daten
< >     - documentation
---
> > - "Zotero"
> > - "Quickstatements"
> > - "bibliographische Daten"
> > - "documentation"
> > subtitle: null
> > status: "draft"
> > licence: "https://creativecommons.org/licenses/by/4.0/"
> > markdown: "pandoc"
29,55d28
< > 
< > 
< > Dieses Repository enthält die Dokumentation für den Upload bibliographischer Daten von Zotero nach Wikidata.
< > Um für die **[Tool Registry für die Digital Humanities](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry)** auch Verknüpfungen zu Artikeln zu erstellen, wird hier ausprobiert und gezeigt, wie ein größerer Datensatz von bibliographischen Daten mit dem Tool [Quickstatements](https://quickstatements.toolforge.org/#/batch) nach Wikidata importiert werden kann. 
< > 
< > # Idee:
< > 
< > - Import von bibliographischen Daten: Artikel als eigene Items bei Wikidata
< > - z.B. Verknüpfung dieser Items mit Methoden (wie z.B. TaDiRAH) und digital tools, die in den Artikeln genutzt oder/und thematisiert wurden
< > - Verknüpfung von Autor_Innen der Artikel mit Organisatoren/Projekten etc. die für die DH interessant sind
< > 
< > # Inhalt
< > 
< > - `data/`: Quickstatements-txt-Datei als Beispieldatensgit atz für den automatischen Upload nach Wikidata. 
< >     - Die Quickstatements wurden in Zotero erstellt auf Basis der dhq.MODS.xml-Datei (https://scm.cms.hu-berlin.de/methodenlabor/data_dhq.git)
< > -  `Quickstatement für bibliographische Daten`
< >     - es handelt sich hier um eine Quickstatementvorlage mit allen(?) notwendigen bzw. erwünschten Informationen(statements), vorliegend in der richtigen Struktur und mit den jeweiligen Property-IDs
< > 
< > # To Do:
< > - [ ] Autor_Innen momentan noch als "String" und nicht als verlinkte Items 
< > - [ ] Abgleich mit OpenRefine
< >     - Ähnlich wie bei der Arbeit mit den TaDiRAH-Kategorien für die ToolRegistry (https://scm.cms.hu-berlin.de/methodenlabor/tr_documentation.git) können die erstellten Items in OpenRefine durch Reconciliation gefunden werden. 
< >     - Die Reconciliation funktioniert dabei um einiges schneller und präziser, da die Artikeltitel die Namen der WD-Items sind. Dabei ist aufgefallen, dass es bei 44 Artikeln (von den 693 aus dem Beispieldatensatz) einige Probleme gibt. Ich schaue gerade manuell nach, wo es Probleme gibt bzw. auf was bei dem Zotero-Quickstatements-Wikidata-Upload geachtet werden muss.
< >     - schon jetzt aufgefallen ist, dass eine automatische Beschreibung beim Export von Zotero nach Quickstatements erstellt wird, die angibt, dass die Artikel von DHQ veröffentlicht wurden, dies aber nicht als eigenes Statement aufgelistet wird (siehe `Quickstatement für bibliographische Daten.md`) -> das könnte mit OpenRefine ergänzt werden. 
< > 
< > 
< > 
57c30,53
< ---
---
> 
> 
> Dieses Repository enthält die Dokumentation für den Upload bibliographischer Daten von Zotero nach Wikidata.
> Um für die **[Tool Registry für die Digital Humanities](https://www.wikidata.org/wiki/Wikidata:WikiProject_DH_Tool_Registry)** auch Verknüpfungen zu Artikeln zu erstellen, wird hier ausprobiert und gezeigt, wie ein größerer Datensatz von bibliographischen Daten mit dem Tool [Quickstatements](https://quickstatements.toolforge.org/#/batch) nach Wikidata importiert werden kann.
> 
> # Idee:
> 
> - Import von bibliographischen Daten: Artikel als eigene Items bei Wikidata
> - z.B. Verknüpfung dieser Items mit Methoden (wie z.B. TaDiRAH) und digital tools, die in den Artikeln genutzt oder/und thematisiert wurden
> - Verknüpfung von Autor_Innen der Artikel mit Organisatoren/Projekten etc. die für die DH interessant sind
> 
> # Inhalt
> 
> - `data/`: Quickstatements-txt-Datei als Beispieldatensgit atz für den automatischen Upload nach Wikidata. 
>     - Die Quickstatements wurden in Zotero erstellt auf Basis der dhq.MODS.xml-Datei (https://scm.cms.hu-berlin.de/methodenlabor/data_dhq.git)
> -  `Quickstatement für bibliographische Daten`
>     - es handelt sich hier um eine Quickstatementvorlage mit allen(?) notwendigen bzw. erwünschten Informationen(statements), vorliegend in der richtigen Struktur und mit den jeweiligen Property-IDs
> 
> # To Do:
> - [ ] Autor_Innen momentan noch als "String" und nicht als verlinkte Items 
> - [ ] Abgleich mit OpenRefine
>     - Ähnlich wie bei der Arbeit mit den TaDiRAH-Kategorien für die ToolRegistry (https://scm.cms.hu-berlin.de/methodenlabor/tr_documentation.git) können die erstellten Items in OpenRefine durch Reconciliation gefunden werden. 
>     - Die Reconciliation funktioniert dabei um einiges schneller und präziser, da die Artikeltitel die Namen der WD-Items sind. Dabei ist aufgefallen, dass es bei 44 Artikeln (von den 693 aus dem Beispieldatensatz) einige Probleme gibt. Ich schaue gerade manuell nach, wo es Probleme gibt bzw. auf was bei dem Zotero-Quickstatements-Wikidata-Upload geachtet werden muss.
>     - schon jetzt aufgefallen ist, dass eine automatische Beschreibung beim Export von Zotero nach Quickstatements erstellt wird, die angibt, dass die Artikel von DHQ veröffentlicht wurden, dies aber nicht als eigenes Statement aufgelistet wird (siehe `Quickstatement für bibliographische Daten.md`) -> das könnte mit OpenRefine ergänzt werden.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/sources_sparql.qmd quarto/methodenlabor/sources_sparql.qmd
2c2
< title: "sources_sparql (Methodenlabor)"
---
> title: "Methodenlabor / sources_sparql (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/sources_sparql"
>       icon: "gitlab"
11c11
< # sources_sparql (Methodenlabor)
---
> # Methodenlabor / sources_sparql (Methodenlabor)
15,27c15,29
< > date: 2025-06-18 
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Software
---
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Software"
> > date: "2025-06-18"
> > lang: "en"
> > tags: null
29,35c31,35
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: code
< > lang: en
< > tags:
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "code"
37,38d36
< 
< ---
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/templates/code-project-template.qmd quarto/methodenlabor/templates/code-project-template.qmd
2c2
< title: "code-project-template (templates)"
---
> title: code-project-template (templates)
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template
<         icon: gitlab
---
>     - text: GitLab
>       href: https://scm.cms.hu-berlin.de/methodenlabor/templates/code-project-template
>       icon: gitlab
14c14
< > title: "<Projektname>"
---
> > title: "Gitlab Overviewer"
16c16
< >   Kurze Beschreibung (2-3 Sätze), was für Daten hier liegen.
---
> >   Collect `README.md`s on all GitLab-Repositories from AccessTokens and generate an overview.
18,22c18,23
< > date: 2025-01-01
< > type: code     # code, data or writing
< > status: "initial planning..."
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
---
> > date: 2025-06-19
> > status: in Development
> > version: 0.2
> > type: code
> > priority: 4
> > urgency: 1
24,30c25,32
< >   - name: Your Name
< >     institute:
< >       - hu
< >       - nfdi
< >     email: name@hu-berlin.de
< >     orcid: 0000-0000-0000-0000
< >     roles: # CRediT-Roles - see https://credit.niso.org/
---
> >   - name: Nicole Dresselhaus
> >     affiliation:
> >       - name: Humboldt-Universität zu Berlin
> >         url: https://hu-berlin.de
> >     email: nicole.dresselhaus@hu-berlin.de
> >     correspondence: true
> >     orcid: 0009-0008-8850-3679
> >     roles:
31a34,37
> >       - Software
> >       - Validation
> >   - name: Till Grallert
> >     roles:
34,120c40
< >   # ... weitere Autor*innen
< > institute:
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > ---
< > 
< > Auf Wunsch Beschreibung noch einmal wiederholen
< > 
< > ## Über dieses Repository
< > 
< > ### Ziel / Zweck
< > 
< > Kurz das Ziel oder den Bedarf der Software erläutern.  
< > (Beispiel: „Diese Software analysiert historische Textdaten, um Netzwerke
< > sozialer Interaktionen zu rekonstruieren.“)
< > 
< > Ist die Software noch in Entwicklung? Abgeschlossen? Abgebrochen?
< > 
< > ### Installation
< > 
< > Kurz und präzise beschreiben, wie die Software installiert wird (max. 3-5
< > Schritte).
< > 
< > - Verweise ggf. auf ausführliche [INSTALL.md](INSTALL.md)
< > 
< > > [!warning]
< > >
< > > **Keine ausführliche Erklärung** von Standard-Tools (z.B. Python
< > > installieren), sondern verlinken auf offizielle Seiten
< > 
< > ### Nutzung
< > 
< > Minimalbeispiel, wie die Software genutzt wird (kurzer Codeblock oder
< > Kommandozeilenaufruf mit typischem Input und Output).
< > 
< > > [!warning]
< > >
< > > **Nicht zu komplexe Beispiele**, dafür ggf. auf ausführliches Tutorial (Datei
< > > [USAGE.md](USAGE.md) oder Verzeichnis [examples/](examples/)) verweisen
< > 
< > ### Bekannte Einschränkungen
< > 
< > Kurz bekannte Probleme und Limitationen nennen, um Missverständnisse zu
< > vermeiden.
< > 
< > > [!warning]
< > >
< > > **Keine** ausschweifenden technischen Details, sondern praktische Hinweise.
< > 
< > ### Struktur
< > 
< > ```plain
< > Übersicht der Struktur z.b. generiert mittels
< > `tree -L2` oder `tree -L2 -d`
< > und anschließend überarbeitet
< > ```
< > 
< > - Kurze Beschreibung - entweder direkt im Tree oder hier in Prosa
< > - Ziel: Überblick über "Wo finde ich was". Wo ist Doku? Wo ist Code? Wo ist ...?
< > 
< > > [!warning]
< > >
< > > **Keine Details**, die über 1 Satz pro Element hinaus gehen. Bei detailliertem
< > > Bedarf `README.md` im jeweiligen Verzeichnis.
< > 
< > ## Meta-Informationen
< > 
< > ### Verantwortlichkeiten
< > 
< > - Wer ist letztendlich verantwortlich für den Inhalt?
< > - Wer genehmigt/weist Inhalte ab?
< > 
< > ### Wissenschaftlicher Hintergrund
< > 
< > Kurze Erklärung der wissenschaftlichen Grundlage (Methode, theoretischer Ansatz)
< > und Referenzen auf Publikationen oder Quellen.
< > 
< > > [!warning]
< > >
< > > **Keine ausführliche Theorie**, diese gehört in Paper oder eigene Datei
< > > ([BACKGROUND.md](BACKGROUND.md))
< > 
< > ### Lizenz & Zitation
< > 
< > Kurz auf Lizenz verweisen (z.B. „siehe LICENSE“) und erklären, wie das Projekt
< > zu zitieren ist (z.B. DOI oder Verweis auf [CITATION.md](CITATION.md)).
< > 
---
> >       - Project Administration
122,180d41
< > 
< > ## Empfohlene Dokumentations-Dateien
< > 
< > | **Dokuelement**                    | **Inhalt/Purpose**                                                                                                       | **Format/Ort**                                                                         | **Umfang**                            |
< > | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | ------------------------------------- |
< > | **README (Hauptdoku)**             | Zweck der Software; Kurzbeschreibung; Installationsanleitung; einfaches Nutzungsbeispiel; Lizenz- und Kontaktinfo        | Markdown im Root des Repos (statisch versioniert)                                      | 1–2 Seiten                            |
< > | **Eingabe/Ausgabe-Guide**          | Beschreibung der erwarteten Inputs (Datenformat, Parameter) und generierten Outputs (Dateien, Berichte) inkl. Beispielen | Teil der README oder separate Datei (z.B. USAGE.md)                                    | 1 Seite (mit Beispielen)              |
< > | **Wissenschaftlicher Hintergrund** | Erläuterung der Methode, Theorie, Algorithmen; Verweise auf Literatur                                                    | README-Abschnitt "Hintergrund" oder separate Doku (BACKGROUND.md)                      | 0.5–1 Seite (plus Referenzen)         |
< > | **Bekannte Limitationen**          | Auflistung von Einschränkungen, Annahmen, bekannten Problemen; ggf. Workarounds                                          | README-Abschnitt "Limitations" oder FAQ.md                                             | 0.5 Seite                             |
< > | **Beispiel-Workflow (Tutorial)**   | Schritt-für-Schritt Anleitung mit einem realistischen Anwendungsfall (ggf. mit Code und Screenshot)                      | Jupyter Notebook (`.ipynb`) im Repo `examples/` Ordner oder Markdown in docs/          | 1–3 Seiten / entsprechend Zellen      |
< > | **API-Referenz**                   | Technische Dokumentation von Funktionen/Klassen für Entwickler\*innen                                                    | Automatisch generiert aus Docstrings (z.B. Sphinx in `docs/` Ordner, HTML/PDF Ausgabe) | Je nach Codegröße (ggf. umfangreich)  |
< > | **CONTRIBUTING**                   | Anleitung für Beitragswillige: Code Style, Workflow, Tests, Kontakt                                                      | CONTRIBUTING.md im Repo                                                                | 0.5–1 Seite                           |
< > | **LICENSE** / **CITATION**         | Rechtliche Infos (Lizenztext); Zitationsleitfaden (Bevorzugte Zitierweise, DOI)                                          | Jeweils eigene Datei im Repo (Plain Text/Markdown)                                     | Kurz (Standardtext bzw. Referenz)     |
< > | **Release-Information**            | Versionshinweise, Änderungsprotokoll (Changelog)                                                                         | CHANGELOG.md oder Releases auf GitHub                                                  | fortlaufend pro Version (Stichpunkte) |
< > 
< > ## Checklist
< > 
< > Es ist eine gute Idee die sich ändernden Punkte in ein Release-Template zu
< > kopieren.
< > 
< > - [ ] **Zielklärung:** Ist der Zweck der Software klar benannt und der
< >       wissenschaftliche _Need_ begründet? (Falls nein, ergänzen: _Warum
< >       existiert dieses Tool?_)
< > - [ ] **Installation & Voraussetzungen:** Sind alle Schritte, um die Software
< >       lauffähig zu machen, dokumentiert (inkl. Dependencies, evtl. mit
< >       Installationsbefehlen)? Ist ersichtlich, welche Umgebung nötig ist (OS,
< >       Hardware)?
< > - [ ] **Grundlegende Nutzung:** Gibt es eine Anleitung oder Beispiele, wie man
< >       die Software verwendet (Eingabe -> Ausgaben)? Ist mindestens ein typischer
< >       Workflow beschrieben, idealerweise mit Beispielinput und -output?
< > - [ ] **Optionen & Schnittstellen:** Falls relevant – sind alle wichtigen
< >       Funktionen, Befehlsoptionen oder API-Methoden dokumentiert? (Nicht
< >       unbedingt jede intern, aber alles, was ein Nutzer aufrufen könnte). Für
< >       APIs: Sind Parameter und Rückgaben erläutert?
< > - [ ] **Validierung & Einschränkungen:** Werden Annahmen und Grenzen der
< >       Software genannt? Weiß ein*e Nutzer*in, welche Fälle nicht abgedeckt sind
< >       oder worauf zu achten ist (z. B. Datenqualität, maximale Größen)?
< >       Transparenz hier verhindert Frustration.
< > - [ ] **Hintergrund & Referenzen:** Sind die wichtigsten konzeptionellen
< >       Hintergründe oder Referenzen angegeben? (Z. B. theoretische Grundlagen,
< >       Algorithmen, Literaturverweise). Das muss kein Essay sein, aber ein paar
< >       Sätze + Referenzen schaffen Vertrauen in die wissenschaftliche Fundierung.
< > - [ ] **Kontakt & Weiterführung:** Ist angegeben, wie man Hilfe bekommt oder
< >       Fehler melden kann (Issue-Tracker, E-Mail)? Gibt es Hinweise für Beiträge
< >       (falls erwünscht) oder zumindest die Information, wer die Autor\*innen
< >       sind?
< > - [ ] **Rechtliches & Zitation:** Liegt die Lizenz bei und wird sie genannt?
< >       Sind Infos zum Zitieren der Software vorhanden (z. B. “Bitte zitieren Sie
< >       DOI XYZ”)? Das stellt sicher, dass die Software nachnutzbar _und_
< >       akademisch kreditiert wird.
< > - [ ] **Aktualität & Version:** Entspricht die Dokumentation der aktuellen
< >       Softwareversion? (Check: Versionsnummern, Datumsangaben). Veraltete Doku
< >       kann schlimmer sein als keine – planen Sie also ein, die Doku mit jedem
< >       Release kurz zu überprüfen.
< > - [ ] **Konsistenz & Stil:** Wird ein einheitlicher Ton und Stil durchgehalten?
< >       (z. B. durchgehende Verwendung gleicher Begriffe für Konzepte, Sprache
< >       entweder Deutsch oder Englisch einheitlich je nach Zielgruppe). Kleinliche
< >       Fehler (Tippfehler, kaputte Links) sind auszumerzen, da sie Nutzer
< >       abschrecken.
182a44,211
> title: "<Projektname>"
> description: |
>   Kurze Beschreibung (2-3 Sätze), was für Daten hier liegen.
> lang: de
> date: 2025-01-01
> type: code     # code, data or writing
> status: "initial planning..."
> priority: 1    # value from 1 (low) to 5 (high)
> urgency: 1     # value from 1 (low) to 5 (high)
> authors:
>   - name: Your Name
>     institute:
>       - hu
>       - nfdi
>     email: name@hu-berlin.de
>     orcid: 0000-0000-0000-0000
>     roles: # CRediT-Roles - see https://credit.niso.org/
>       - Conceptualization
>       - Supervision
>       - Validation
>   # ... weitere Autor*innen
> institute:
>   - hu: Humboldt-Universität zu Berlin
>   - nfdi: NFDI4Memory 
> ---
> 
> Auf Wunsch Beschreibung noch einmal wiederholen
> 
> ## Über dieses Repository
> 
> ### Ziel / Zweck
> 
> Kurz das Ziel oder den Bedarf der Software erläutern.  
> (Beispiel: „Diese Software analysiert historische Textdaten, um Netzwerke
> sozialer Interaktionen zu rekonstruieren.“)
> 
> Ist die Software noch in Entwicklung? Abgeschlossen? Abgebrochen?
> 
> ### Installation
> 
> Kurz und präzise beschreiben, wie die Software installiert wird (max. 3-5
> Schritte).
> 
> - Verweise ggf. auf ausführliche [INSTALL.md](INSTALL.md)
> 
> > [!warning]
> >
> > **Keine ausführliche Erklärung** von Standard-Tools (z.B. Python
> > installieren), sondern verlinken auf offizielle Seiten
> 
> ### Nutzung
> 
> Minimalbeispiel, wie die Software genutzt wird (kurzer Codeblock oder
> Kommandozeilenaufruf mit typischem Input und Output).
> 
> > [!warning]
> >
> > **Nicht zu komplexe Beispiele**, dafür ggf. auf ausführliches Tutorial (Datei
> > [USAGE.md](USAGE.md) oder Verzeichnis [examples/](examples/)) verweisen
> 
> ### Bekannte Einschränkungen
> 
> Kurz bekannte Probleme und Limitationen nennen, um Missverständnisse zu
> vermeiden.
> 
> > [!warning]
> >
> > **Keine** ausschweifenden technischen Details, sondern praktische Hinweise.
> 
> ### Struktur
> 
> ```plain
> Übersicht der Struktur z.b. generiert mittels
> `tree -L2` oder `tree -L2 -d`
> und anschließend überarbeitet
> ```
> 
> - Kurze Beschreibung - entweder direkt im Tree oder hier in Prosa
> - Ziel: Überblick über "Wo finde ich was". Wo ist Doku? Wo ist Code? Wo ist ...?
> 
> > [!warning]
> >
> > **Keine Details**, die über 1 Satz pro Element hinaus gehen. Bei detailliertem
> > Bedarf `README.md` im jeweiligen Verzeichnis.
> 
> ## Meta-Informationen
> 
> ### Verantwortlichkeiten
> 
> - Wer ist letztendlich verantwortlich für den Inhalt?
> - Wer genehmigt/weist Inhalte ab?
> 
> ### Wissenschaftlicher Hintergrund
> 
> Kurze Erklärung der wissenschaftlichen Grundlage (Methode, theoretischer Ansatz)
> und Referenzen auf Publikationen oder Quellen.
> 
> > [!warning]
> >
> > **Keine ausführliche Theorie**, diese gehört in Paper oder eigene Datei
> > ([BACKGROUND.md](BACKGROUND.md))
> 
> ### Lizenz & Zitation
> 
> Kurz auf Lizenz verweisen (z.B. „siehe LICENSE“) und erklären, wie das Projekt
> zu zitieren ist (z.B. DOI oder Verweis auf [CITATION.md](CITATION.md)).
> 
> ---
> 
> ## Empfohlene Dokumentations-Dateien
> 
> | **Dokuelement**                    | **Inhalt/Purpose**                                                                                                       | **Format/Ort**                                                                         | **Umfang**                            |
> | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | ------------------------------------- |
> | **README (Hauptdoku)**             | Zweck der Software; Kurzbeschreibung; Installationsanleitung; einfaches Nutzungsbeispiel; Lizenz- und Kontaktinfo        | Markdown im Root des Repos (statisch versioniert)                                      | 1–2 Seiten                            |
> | **Eingabe/Ausgabe-Guide**          | Beschreibung der erwarteten Inputs (Datenformat, Parameter) und generierten Outputs (Dateien, Berichte) inkl. Beispielen | Teil der README oder separate Datei (z.B. USAGE.md)                                    | 1 Seite (mit Beispielen)              |
> | **Wissenschaftlicher Hintergrund** | Erläuterung der Methode, Theorie, Algorithmen; Verweise auf Literatur                                                    | README-Abschnitt "Hintergrund" oder separate Doku (BACKGROUND.md)                      | 0.5–1 Seite (plus Referenzen)         |
> | **Bekannte Limitationen**          | Auflistung von Einschränkungen, Annahmen, bekannten Problemen; ggf. Workarounds                                          | README-Abschnitt "Limitations" oder FAQ.md                                             | 0.5 Seite                             |
> | **Beispiel-Workflow (Tutorial)**   | Schritt-für-Schritt Anleitung mit einem realistischen Anwendungsfall (ggf. mit Code und Screenshot)                      | Jupyter Notebook (`.ipynb`) im Repo `examples/` Ordner oder Markdown in docs/          | 1–3 Seiten / entsprechend Zellen      |
> | **API-Referenz**                   | Technische Dokumentation von Funktionen/Klassen für Entwickler\*innen                                                    | Automatisch generiert aus Docstrings (z.B. Sphinx in `docs/` Ordner, HTML/PDF Ausgabe) | Je nach Codegröße (ggf. umfangreich)  |
> | **CONTRIBUTING**                   | Anleitung für Beitragswillige: Code Style, Workflow, Tests, Kontakt                                                      | CONTRIBUTING.md im Repo                                                                | 0.5–1 Seite                           |
> | **LICENSE** / **CITATION**         | Rechtliche Infos (Lizenztext); Zitationsleitfaden (Bevorzugte Zitierweise, DOI)                                          | Jeweils eigene Datei im Repo (Plain Text/Markdown)                                     | Kurz (Standardtext bzw. Referenz)     |
> | **Release-Information**            | Versionshinweise, Änderungsprotokoll (Changelog)                                                                         | CHANGELOG.md oder Releases auf GitHub                                                  | fortlaufend pro Version (Stichpunkte) |
> 
> ## Checklist
> 
> Es ist eine gute Idee die sich ändernden Punkte in ein Release-Template zu
> kopieren.
> 
> - [ ] **Zielklärung:** Ist der Zweck der Software klar benannt und der
>       wissenschaftliche _Need_ begründet? (Falls nein, ergänzen: _Warum
>       existiert dieses Tool?_)
> - [ ] **Installation & Voraussetzungen:** Sind alle Schritte, um die Software
>       lauffähig zu machen, dokumentiert (inkl. Dependencies, evtl. mit
>       Installationsbefehlen)? Ist ersichtlich, welche Umgebung nötig ist (OS,
>       Hardware)?
> - [ ] **Grundlegende Nutzung:** Gibt es eine Anleitung oder Beispiele, wie man
>       die Software verwendet (Eingabe -> Ausgaben)? Ist mindestens ein typischer
>       Workflow beschrieben, idealerweise mit Beispielinput und -output?
> - [ ] **Optionen & Schnittstellen:** Falls relevant – sind alle wichtigen
>       Funktionen, Befehlsoptionen oder API-Methoden dokumentiert? (Nicht
>       unbedingt jede intern, aber alles, was ein Nutzer aufrufen könnte). Für
>       APIs: Sind Parameter und Rückgaben erläutert?
> - [ ] **Validierung & Einschränkungen:** Werden Annahmen und Grenzen der
>       Software genannt? Weiß ein*e Nutzer*in, welche Fälle nicht abgedeckt sind
>       oder worauf zu achten ist (z. B. Datenqualität, maximale Größen)?
>       Transparenz hier verhindert Frustration.
> - [ ] **Hintergrund & Referenzen:** Sind die wichtigsten konzeptionellen
>       Hintergründe oder Referenzen angegeben? (Z. B. theoretische Grundlagen,
>       Algorithmen, Literaturverweise). Das muss kein Essay sein, aber ein paar
>       Sätze + Referenzen schaffen Vertrauen in die wissenschaftliche Fundierung.
> - [ ] **Kontakt & Weiterführung:** Ist angegeben, wie man Hilfe bekommt oder
>       Fehler melden kann (Issue-Tracker, E-Mail)? Gibt es Hinweise für Beiträge
>       (falls erwünscht) oder zumindest die Information, wer die Autor\*innen
>       sind?
> - [ ] **Rechtliches & Zitation:** Liegt die Lizenz bei und wird sie genannt?
>       Sind Infos zum Zitieren der Software vorhanden (z. B. “Bitte zitieren Sie
>       DOI XYZ”)? Das stellt sicher, dass die Software nachnutzbar _und_
>       akademisch kreditiert wird.
> - [ ] **Aktualität & Version:** Entspricht die Dokumentation der aktuellen
>       Softwareversion? (Check: Versionsnummern, Datumsangaben). Veraltete Doku
>       kann schlimmer sein als keine – planen Sie also ein, die Doku mit jedem
>       Release kurz zu überprüfen.
> - [ ] **Konsistenz & Stil:** Wird ein einheitlicher Ton und Stil durchgehalten?
>       (z. B. durchgehende Verwendung gleicher Begriffe für Konzepte, Sprache
>       entweder Deutsch oder Englisch einheitlich je nach Zielgruppe). Kleinliche
>       Fehler (Tippfehler, kaputte Links) sind auszumerzen, da sie Nutzer
>       abschrecken.
> 
Nur in quarto_production/methodenlabor/templates: data-project-template.qmd.
Nur in quarto/methodenlabor/templates: Data Project Template.qmd.
Nur in quarto_production/methodenlabor/templates: template_writing-project.qmd.
Nur in quarto/methodenlabor/templates: writing project template.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/tr_data.qmd quarto/methodenlabor/tr_data.qmd
2c2
< title: "TR_data (Methodenlabor)"
---
> title: "Methodenlabor / TR_data (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/tr_data
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/tr_data"
>       icon: "gitlab"
11c11
< # TR_data (Methodenlabor)
---
> # Methodenlabor / TR_data (Methodenlabor)
14a15,33
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Writing -- original draft"
> >   - "Writing -- review & editing"
> > date: "2025-06-18"
> > lang: "de"
> > tags:
> > - "NFDI"
> > - "4Memory"
> > - "ToolRegistry"
16,31c35
< > description: |
< >    some description 
< > date: 2025-06-18 
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Writing -- original draft
< >       - Writing -- review & editing
---
> > description: "some description \n"
33,39c37,42
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: data  # writing, code, or data
< > status: draft
< > lang: de
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "data"
> > status: "draft"
41,46c44,45
< >   - assets/references.bib
< > markdown: pandoc
< > tags:
< >   - NFDI
< >   - 4Memory
< >   - ToolRegistry
---
> > - "assets/references.bib"
> > markdown: "pandoc"
48,49d46
< 
< ---
Nur in quarto/methodenlabor: TR_data.qmd.
Nur in quarto_production/methodenlabor: tr_publications.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/tr_sparql.qmd quarto/methodenlabor/tr_sparql.qmd
2c2
< title: "TR_sparql (Methodenlabor)"
---
> title: "Methodenlabor / TR_sparql (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/tr_sparql"
>       icon: "gitlab"
11c11
< # TR_sparql (Methodenlabor)
---
> # Methodenlabor / TR_sparql (Methodenlabor)
15,27c15,28
< > date: 2024-04-17
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Software
---
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Software"
> > date: "2024-04-17"
> > lang: "en"
29,35c30,35
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: code
< > status: production
< > lang: en
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "code"
> > status: "production"
37,123d36
< > 
< > This repo hosts all SPARQL queries that make our Wikidata-based Tool Registry for Digital Humanities into an actual tool registry. Without the queries, one only has loads of Wikidata Items. Currently, the main query is [[tools_basic-graph.rq]], which will return all tools classified through the TaDiRAH taxonomy.
< > 
< > # SPARQL
< > 
< > Verschiedene Arten von SPARQL queries (`.rq`) generieren unterschiedliche Output Serialisierungen ([SPARQL 1.2 Dokumentation](https://w3c.github.io/sparql-query/spec/#QueryForms)):
< > 
< > - `SELECT`: "Returns all, or a subset of, the variables bound in a query pattern match."
< >     - der default Output ist ein [SPARQL result XML](https://www.w3.org/TR/rdf-sparql-XMLres/) (`.srx`) im Namespace "http://www.w3.org/2005/sparql-results#". 
< >     - Laut Specs sind aber auch JSON, CSV oder TSV möglich
< > - `CONSTRUCT`: "Returns an RDF graph constructed by substituting variables in a set of triple templates."
< > - `ASK`: "Returns a boolean indicating whether a query pattern matches or not."
< > - `DESCRIBE`: "Returns an RDF graph that describes the resources found."
< >     - der default Output ist RDF/XML
< >     - ein basaler Beispielquery liegt unter <./describe/describe_tools.rq>
< > 
< > ## Optionale statements
< > 
< > Optionale Statements können sehr einfach mit einer Pfadsprache in eine einzelne "Art" von Nodes gruppiert werden um beispielsweise die Anzahl von Variablen zu minimieren:
< > 
< > `OPTIONAL {?tool ( wdt:P1547 | wdt:P277 | wdt:P2283 | wdt:P1073 | wdt:P1072 ) ?dependency1 .}`
< > 
< > ## Fehlende statements
< > 
< > Um Items zu finden, die das Datenmodell nicht komplett erfüllen können folgende Filter angewandt werden. Ein sample query ist [hier](select/tools_missing-statements.rq).
< > 
< > ```sparql
< > OPTIONAL {?tool (wdt:PP6216 | wdt:P275) ?statement .} #statements on copyright and license
< > FILTER (!bound(?statement))
< > ```
< > 
< > Eigentlich gibt es die Möglichkeit von `MINUS { ... }` und `FILTER NOT EXISTS ( ... )`, aber diese haben in meinen Versuchen nicht funktioniert.
< > 
< > ## Einfärben von Nodes
< > 
< > Es besteht offensichtlich die Möglichkeit Nodes im Graph geziehlt einzufärben. Dazu wird die Variable `?rgb` benötigt. Ich habe bis jetzt keine Dokumentation, sondern nur Beispiele bei Scholia gefunden (<https://github.com/WDscholia/scholia/>).
< > 
< > `?rgb` wird [hier](https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Wikidata_Query_Help/Result_Views/it) kurz für erwähnt: "Color of the item just before the rgb variable.", d.h.  `?target ("7eb8ff" AS ?rgb)` in einem `SELECT` statement wird die `?target` Nodes einfärben.
< > 
< > ## "Funktionen" und sub queries
< > 
< > Subqueries sind ein schönes Feature um einen Subgraphen zu erzeugen, der dann später abgefragt werden kann, ohne die detaillierte Abfrage über den gesamten Graph laufen zu lassen.
< > 
< > ```sparql
< > WITH {                                # find all tools for a given method
< >   SELECT DISTINCT 
< >     ?tool
< >   WHERE {
< >     ?tool wdt:P366 target: ;
< >       wdt:P31/wdt:P279* wd:Q7397.     # limit tools to software in the broadest sense
< >   }
< > } AS %result
< > ```
< > 
< > Auf diese kann dann in späteren `WHERE{}` und `OPTIONAL{}` Klauseln mit `INCLUDE %result` zugegriffen werden.
< > 
< > Solche Subqueries können aber auch genutzt werden um quasi Funktionen bereitzustellen:
< > 
< > ```
< > WITH {                                # generic "function" to add properties to nodes
< >   SELECT DISTINCT ?property WHERE {
< >     ?property a wikibase:Property;
< >       wdt:P31/wdt:P279* wd:Q26940804 .# representative image
< >     }
< > } AS %properties
< > ```
< > 
< > Damit lassen sich dann später zum Beispiel die Properties für verschiedene Arten von Nodes abfragen:
< > 
< > ```sparql
< > OPTIONAL {                         # generic call to add properties to target
< >     INCLUDE %properties
< >     ?property wikibase:directClaim ?targetClaim.
< >     ?target ?targetClaim ?targetImage. 
< >   }
< > ```
< > 
< > ## Optimisierung
< > 
< > Wikidata's endpoint times out after one minute, in order to retrieve as many items as possible, one has / can optimise the query. Some help can be found [here](https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization).
< > 
< > - inverted paths seem to be much quicker, but are not enough to, for instance return all historians on Wikidata.
< > - Alternative paths (`|`) are much quicker than unions!
< > - named subqueries: this is a BlazeGraph extention. Named subqueries are guaranteed to run only once
< > - `hint:SubQuery hint:runOnce true` seems to make a lot of expensive subqueries work, but I am not sure about the impact on the results.
< > - The Wikidata endpoint has a parameter to explain the query: `https://query.wikidata.org/sparql?explain&query=`
< > 
125c38,123
< ---
---
> 
> This repo hosts all SPARQL queries that make our Wikidata-based Tool Registry for Digital Humanities into an actual tool registry. Without the queries, one only has loads of Wikidata Items. Currently, the main query is [[tools_basic-graph.rq]], which will return all tools classified through the TaDiRAH taxonomy.
> 
> # SPARQL
> 
> Verschiedene Arten von SPARQL queries (`.rq`) generieren unterschiedliche Output Serialisierungen ([SPARQL 1.2 Dokumentation](https://w3c.github.io/sparql-query/spec/#QueryForms)):
> 
> - `SELECT`: "Returns all, or a subset of, the variables bound in a query pattern match."
>     - der default Output ist ein [SPARQL result XML](https://www.w3.org/TR/rdf-sparql-XMLres/) (`.srx`) im Namespace "http://www.w3.org/2005/sparql-results#". 
>     - Laut Specs sind aber auch JSON, CSV oder TSV möglich
> - `CONSTRUCT`: "Returns an RDF graph constructed by substituting variables in a set of triple templates."
> - `ASK`: "Returns a boolean indicating whether a query pattern matches or not."
> - `DESCRIBE`: "Returns an RDF graph that describes the resources found."
>     - der default Output ist RDF/XML
>     - ein basaler Beispielquery liegt unter <./describe/describe_tools.rq>
> 
> ## Optionale statements
> 
> Optionale Statements können sehr einfach mit einer Pfadsprache in eine einzelne "Art" von Nodes gruppiert werden um beispielsweise die Anzahl von Variablen zu minimieren:
> 
> `OPTIONAL {?tool ( wdt:P1547 | wdt:P277 | wdt:P2283 | wdt:P1073 | wdt:P1072 ) ?dependency1 .}`
> 
> ## Fehlende statements
> 
> Um Items zu finden, die das Datenmodell nicht komplett erfüllen können folgende Filter angewandt werden. Ein sample query ist [hier](select/tools_missing-statements.rq).
> 
> ```sparql
> OPTIONAL {?tool (wdt:PP6216 | wdt:P275) ?statement .} #statements on copyright and license
> FILTER (!bound(?statement))
> ```
> 
> Eigentlich gibt es die Möglichkeit von `MINUS { ... }` und `FILTER NOT EXISTS ( ... )`, aber diese haben in meinen Versuchen nicht funktioniert.
> 
> ## Einfärben von Nodes
> 
> Es besteht offensichtlich die Möglichkeit Nodes im Graph geziehlt einzufärben. Dazu wird die Variable `?rgb` benötigt. Ich habe bis jetzt keine Dokumentation, sondern nur Beispiele bei Scholia gefunden (<https://github.com/WDscholia/scholia/>).
> 
> `?rgb` wird [hier](https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Wikidata_Query_Help/Result_Views/it) kurz für erwähnt: "Color of the item just before the rgb variable.", d.h.  `?target ("7eb8ff" AS ?rgb)` in einem `SELECT` statement wird die `?target` Nodes einfärben.
> 
> ## "Funktionen" und sub queries
> 
> Subqueries sind ein schönes Feature um einen Subgraphen zu erzeugen, der dann später abgefragt werden kann, ohne die detaillierte Abfrage über den gesamten Graph laufen zu lassen.
> 
> ```sparql
> WITH {                                # find all tools for a given method
>   SELECT DISTINCT 
>     ?tool
>   WHERE {
>     ?tool wdt:P366 target: ;
>       wdt:P31/wdt:P279* wd:Q7397.     # limit tools to software in the broadest sense
>   }
> } AS %result
> ```
> 
> Auf diese kann dann in späteren `WHERE{}` und `OPTIONAL{}` Klauseln mit `INCLUDE %result` zugegriffen werden.
> 
> Solche Subqueries können aber auch genutzt werden um quasi Funktionen bereitzustellen:
> 
> ```
> WITH {                                # generic "function" to add properties to nodes
>   SELECT DISTINCT ?property WHERE {
>     ?property a wikibase:Property;
>       wdt:P31/wdt:P279* wd:Q26940804 .# representative image
>     }
> } AS %properties
> ```
> 
> Damit lassen sich dann später zum Beispiel die Properties für verschiedene Arten von Nodes abfragen:
> 
> ```sparql
> OPTIONAL {                         # generic call to add properties to target
>     INCLUDE %properties
>     ?property wikibase:directClaim ?targetClaim.
>     ?target ?targetClaim ?targetImage. 
>   }
> ```
> 
> ## Optimisierung
> 
> Wikidata's endpoint times out after one minute, in order to retrieve as many items as possible, one has / can optimise the query. Some help can be found [here](https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization).
> 
> - inverted paths seem to be much quicker, but are not enough to, for instance return all historians on Wikidata.
> - Alternative paths (`|`) are much quicker than unions!
> - named subqueries: this is a BlazeGraph extention. Named subqueries are guaranteed to run only once
> - `hint:SubQuery hint:runOnce true` seems to make a lot of expensive subqueries work, but I am not sure about the impact on the results.
> - The Wikidata endpoint has a parameter to explain the query: `https://query.wikidata.org/sparql?explain&query=`
Nur in quarto/methodenlabor: TR_sparql.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/writing_dh-personae.qmd quarto/methodenlabor/writing_dh-personae.qmd
2c2
< title: "writing_dh-personae (Methodenlabor)"
---
> title: "Methodenlabor / writing_dh-personae (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/writing_dh-personae"
>       icon: "gitlab"
11c11
< # writing_dh-personae (Methodenlabor)
---
> # Methodenlabor / writing_dh-personae (Methodenlabor)
15,22d14
< > description: |
< >   UX Personae als Ergebnis eines Workshops beim NFDI4Memory Community Forum 2024 in Halle
< > lang: de
< > date: 2025-06-18
< > status: "published"
< > type: writing
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
24,44c16,44
< >     - name: Till Grallert
< >       institute: 
< >         - hu
< >         - nfdi
< >       correspondence: "yes"
< >       email: till.grallert@hu-berlin.de
< >       orcid: 0000-0002-5739-8094
< >       roles: # CRediT-Roles - see https://credit.niso.org/
< >         - Conceptualization
< >         - Supervision
< >         - Writing -- review & editing
< >     - name: Jascha Merijn Schmitz
< >       institute: 
< >         - hu
< >         - nfdi
< >       correspondence: "yes"
< >       email: jascha.schmitz@hu-berlin.de
< >       orcid:
< >       roles: # CRediT-Roles - see https://credit.niso.org/
< >         - Conceptualization
< >         - Supervision
---
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Writing -- review & editing"
> > - name: "Jascha Merijn Schmitz"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "jascha.schmitz@hu-berlin.de"
> >   orcid: null
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> > date: "2025-06-18"
> > lang: "de"
> > description: "UX Personae als Ergebnis eines Workshops beim NFDI4Memory Community\
> >   \ Forum 2024 in Halle\n"
> > status: "published"
> > type: "writing"
> > priority: 1
> > urgency: 1
46,47c46,47
< >     - hu: Humboldt-Universität zu Berlin
< >     - nfdi: NFDI4Memory
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
49,93d48
< > 
< > UX Personae als Ergebnis eines Workshops beim NFDI4Memory Community Forum 2024 in Halle
< > 
< > # Über dieses Repository
< > 
< > Das Repo enthält den je aktuellen Stand zu dieser Publikation, inklusive aller Notizen und Entwürfe. Der Prozess ist intern in den Unterlagen der Task Area "Data Culture" dokumentiert. Die je zitierfähige, kanonische Fassung ist auf Zenodo unter <https://doi.org/10.5281/zenodo.15690623> publiziert.
< > 
< > ## Ziel / Zweck
< > 
< > Alles Wichtige ist in <draft/Einleitung.md> ausgeführt.
< > 
< > ## Nutzung / Bekannte Einschränkungen
< > 
< > - Wann sollte ich den Datensatz nutzen?
< > - Wann sollte ich den Datensatz **nicht** nutzen?
< > - Welche **Biases** gibt es in den Daten?
< > 
< > ## Struktur
< > 
< > ```plain
< > .
< > ├── assets/           # supporting files, such as bibliography and images
< > ├── draft/            # drafts, mostly written in markdown
< > ├── notes/            # notes for the drafts
< > ├── src/              # code to process drafts
< > ├── submission/       # final files for publication
< > ├── CHANGELOG.md
< > ├── CITATION.md       # how to cite
< > ├── CONTRIBUTING.md
< > └── README.md         # this file
< > ```
< > 
< > # Meta-Informationen
< > 
< > ## Verantwortlichkeiten
< > 
< > Till Grallert und Jascha Schmitz haben das Projekt konzipiert und durchgeführt
< > 
< > ## Wissenschaftlicher Hintergrund
< > 
< > Das ist in <draft/Einleitung.md> ausgeführt.
< > 
< > ## Lizenz & Zitation
< > 
< > Die Texte in diesem Repo sind als CC BY lizensiert (siehe LICENSE.md) und auf Zenodo unter <https://doi.org/10.5281/zenodo.15690623> publiziert
95c50,94
< ---
---
> 
> UX Personae als Ergebnis eines Workshops beim NFDI4Memory Community Forum 2024 in Halle
> 
> # Über dieses Repository
> 
> Das Repo enthält den je aktuellen Stand zu dieser Publikation, inklusive aller Notizen und Entwürfe. Der Prozess ist intern in den Unterlagen der Task Area "Data Culture" dokumentiert. Die je zitierfähige, kanonische Fassung ist auf Zenodo unter <https://doi.org/10.5281/zenodo.15690623> publiziert.
> 
> ## Ziel / Zweck
> 
> Alles Wichtige ist in <draft/Einleitung.md> ausgeführt.
> 
> ## Nutzung / Bekannte Einschränkungen
> 
> - Wann sollte ich den Datensatz nutzen?
> - Wann sollte ich den Datensatz **nicht** nutzen?
> - Welche **Biases** gibt es in den Daten?
> 
> ## Struktur
> 
> ```plain
> .
> ├── assets/           # supporting files, such as bibliography and images
> ├── draft/            # drafts, mostly written in markdown
> ├── notes/            # notes for the drafts
> ├── src/              # code to process drafts
> ├── submission/       # final files for publication
> ├── CHANGELOG.md
> ├── CITATION.md       # how to cite
> ├── CONTRIBUTING.md
> └── README.md         # this file
> ```
> 
> # Meta-Informationen
> 
> ## Verantwortlichkeiten
> 
> Till Grallert und Jascha Schmitz haben das Projekt konzipiert und durchgeführt
> 
> ## Wissenschaftlicher Hintergrund
> 
> Das ist in <draft/Einleitung.md> ausgeführt.
> 
> ## Lizenz & Zitation
> 
> Die Texte in diesem Repo sind als CC BY lizensiert (siehe LICENSE.md) und auf Zenodo unter <https://doi.org/10.5281/zenodo.15690623> publiziert
Nur in quarto/methodenlabor: writing project template.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/methodenlabor/writing.qmd quarto/methodenlabor/writing.qmd
2c2
< title: "Writing (Methodenlabor)"
---
> title: "Methodenlabor / Writing (Methodenlabor)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/methodenlabor/writing
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/methodenlabor/writing"
>       icon: "gitlab"
11c11
< # Writing (Methodenlabor)
---
> # Methodenlabor / Writing (Methodenlabor)
14a15,46
> > author:
> > - name: "Till Grallert"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   correspondence: "yes"
> >   email: "till.grallert@hu-berlin.de"
> >   orcid: "0000-0002-5739-8094"
> >   roles:
> >   - "Conceptualization"
> >   - "Supervision"
> >   - "Writing -- original draft"
> >   - "Writing -- review & editing"
> > - name: "Isabell Trilling"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   roles:
> >   - "Writing -- original draft"
> > - name: "Anica Skibba"
> >   institute:
> >   - "hu"
> >   - "nfdi"
> >   roles:
> >   - "Writing -- original draft"
> > date: "2025-04-25"
> > lang:
> > - "de"
> > - "en"
> > tags:
> > - "NFDI"
> > - "4Memory"
16,43c48,49
< > description: |
< >   smaller pieces of writing that originate from the Methods Innovation Lab
< > date: 2025-04-25
< > author: 
< >   - name: Till Grallert
< >     institute: 
< >       - hu
< >       - nfdi
< >     correspondence: "yes"
< >     email: till.grallert@hu-berlin.de
< >     orcid: 0000-0002-5739-8094 
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Conceptualization
< >       - Supervision
< >       - Writing -- original draft
< >       - Writing -- review & editing
< >   - name: Isabell Trilling
< >     institute: 
< >       - hu
< >       - nfdi
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Writing -- original draft
< >   - name: Anica Skibba
< >     institute: 
< >       - hu
< >       - nfdi
< >     roles: # CRediT-Roles - see https://credit.niso.org/
< >       - Writing -- original draft
---
> > description: "smaller pieces of writing that originate from the Methods Innovation\
> >   \ Lab\n"
45,57c51,57
< >   - hu: Humboldt-Universität zu Berlin
< >   - nfdi: NFDI4Memory 
< > priority: 1    # value from 1 (low) to 5 (high)
< > urgency: 1     # value from 1 (low) to 5 (high)
< > type: writing  # writing, code, or data
< > status: in progress
< > lang: 
< >   - de
< >   - en
< > markdown: pandoc
< > tags:
< >   - NFDI
< >   - 4Memory
---
> > - hu: "Humboldt-Universität zu Berlin"
> > - nfdi: "NFDI4Memory"
> > priority: 1
> > urgency: 1
> > type: "writing"
> > status: "in progress"
> > markdown: "pandoc"
59,60d58
< 
< ---
Nur in quarto/methodenlabor: Writing.qmd.
Nur in quarto/: obsidian-style-callouts.lua.
Nur in quarto/: _publish.yml.
Nur in quarto/: .quarto.
Nur in quarto/: _quarto.yml.
Nur in quarto/: _site.
Nur in quarto/: templates.
Nur in quarto/tool-registry-dh: data_dfgprojects.qmd.
Nur in quarto/tool-registry-dh: data_DFGProjects.qmd.
Nur in quarto/tool-registry-dh: data_dhconferences.qmd.
Nur in quarto/tool-registry-dh: data_DHConferences.qmd.
Nur in quarto/tool-registry-dh: data_dhd.qmd.
Nur in quarto/tool-registry-dh: data_DHd.qmd.
Nur in quarto/tool-registry-dh: data_dhq.qmd.
Nur in quarto/tool-registry-dh: data_DHQ.qmd.
Nur in quarto/tool-registry-dh: data_tool-registries.qmd.
diff '--color=auto' -r '--exclude=.DS_Store' '--exclude=*.tmp' '--exclude=*.log' '--exclude=*.bak' quarto_production/tool-registry-dh/papers.qmd quarto/tool-registry-dh/papers.qmd
2c2
< title: "Papers (Tool Registry for Digital Humanities)"
---
> title: "Tool Registry for Digital Humanities / Papers (Tool Registry for Digital Humanities)"
6,8c6,8
<       - text: GitLab
<         href: https://scm.cms.hu-berlin.de/tool-registry-dh/papers
<         icon: gitlab
---
>     - text: "GitLab"
>       href: "https://scm.cms.hu-berlin.de/tool-registry-dh/papers"
>       icon: "gitlab"
11c11
< # Papers (Tool Registry for Digital Humanities)
---
> # Tool Registry for Digital Humanities / Papers (Tool Registry for Digital Humanities)
14,19c14,17
< > title: "Readme"
< > author:
< >     - Claus-Michael Schlesinger
< >     - Till Grallert
< > date: 2025-01-07
< > lang: de
---
> > title: "Tool Registry for Digital Humanities / Papers"
> > author: "Tool Registry for Digital Humanities"
> > date: "2025-05-14"
> > lang: "de"
21,131d18
< > 
< > **UPDATE Dezember 2024**: bei unserem Redaktionstreffen haben CM und TG beschlossen für die Redaktionsphase in einen Word Processor zu wechseln und die Markdownfassung "nur" als Archivformat zu benutzen. Dafür liegt die aktuelle Datei in der HU Box unter https://box.hu-berlin.de/smart-link/fe7c5ada-27da-4221-a8d6-6f2dc493230b/. Damit addressieren wir die unten genannten Schwierigkeiten, für die wir keine andere Lösung gefunden haben.
< > 
< > # Arbeitsrepo Aufsatz Tool Registry Mark 1
< > 
< > In diesem Repo arbeiten wir gemeinsam an einem Aufsatz für eine Dokumentation der Tool Registry (Grundlagen und Prototyp). 
< > 
< > ## Zeitlicher Ablauf
< > 
< > - Ende April: Grobgliederung fertig, Abschnitte an Bearbeiter\*innen verteilt
< > - 15.5. Arbeitstreffen Feingliederung
< > - 31.5. Feingliederung fertig
< > - 14.6. Feingliederung Redaktion fertig
< > - 15.7.--7.9. ~~Rohfassung fertig~~
< > - 25.11. Rohfassung fertig
< > - 28.11. 10-12 Redaktionstreffen
< > - 20.12. Redaktion abgeschlossen
< > - 20.12. Einreichung
< > 
< > - Publikationsort: ZfdG oder DHQ
< > - Sprache: englisch
< > 
< > ## Dateien und Ordner
< > 
< > Wir arbeiten mit den folgenden Dateien und Ordnern:
< > 
< > ### [gliederung.md](gliederung.md)
< > 
< > Hier wird gemeinsam die möglichst genaue Gliederung des Texts erstellt. Erlaubt sind Stichwörter, Listen, kurze Sätze, Referenzen. Die Gliederung soll für alle nachvollziehbar sein und beinhaltet nach Möglichkeit (fast) alle Punkte, die später im Fließtext durchgearbeitet werden. 'fast', weil beim Schreiben der Rohfassung Ergänzungen im Detail erwartbar sind, aber keine ganz neuen Punkte mehr eingeführt werden sollten. Profis brauchen die meiste Zeit für die Erstellung einer guten Gliederung :)
< > 
< > ### [rohfassung.md](rohfassung.md)
< > 
< > Die final abgestimmte Gliederung wird, sobald sie fertig ist, in eine neue Arbeitsdatei für die Rohfassung kopiert. Dann kann in diesem Abschnitt ein Gliederungsteil nach dem anderen ausformuliert werden. Dabei werden die Gliederungspunkte jeweils auskommentiert oder, bei kleinteiligen Unterpunkten, nach Bedarf gelöscht. Für den Rückgriff auf die Gliederung bleibt `gliederung.md` erhalten.
< > 
< > ### referenzen.[json,bib]
< > 
< > Die bibliografischen Referenzen werden in einer [Zotero-Gruppe](https://www.zotero.org/groups/5497674/) verwaltet. In diese Gruppe werden ausschließlich Referenzen eingefügt, die im Text auch referenziert werden, um alles möglichst übersichtlich zu halten. Fürs Ausrendern können die Einträge aus der Zotero-Gruppe dann nach `referenzen.json` oder `referenzen.bib` exportiert werden, je nachdem wer sich nachher ums Ausrendern kümmert und welche Vorlieben dann bedient werden.
< > 
< > Till hat für den Arbeitsprozess `referenzen.json` angelegt, die über automatische Exporte über *Better BibTeX* aus Zotero heraus aktuell gehalten wird.
< > 
< > ### [img/](img/)
< > 
< > In diesen Ordner können Bilder gelegt werden, die im Dokument eingebettet sind. 
< > 
< > 
< > ## Bearbeitung
< > 
< > Da wir mit Versionierung arbeiten können alle Änderungen nachvollzogen werden. Da Versionierung aber nicht für die kollaborative Textarbeit entwickelt wurde, ist es zum Teil schwierig, komplexe Änderungen und Kommentierungen am Text nachzuvollziehen. Deshalb ist es sinnvoll, Kommentare und Änderungen, die für andere sichtbar sein sollen,direkt ins Dokument zu schreiben. 
< > 
< > **Kommentare** im Text nach folgendem Schema (beachte die drei Dashes am Anfang eines Kommentars):
< > 
< > ```
< > <!--- CM: das ist Kommentartext -->
< > ```
< > 
< > - Kommentare können inline oder zwischen Absätzen platziert werden. 
< > - Längere Kommentare bekommen eine eigene Zeile. 
< > - Kommentare werden hinter dem kommentierten Begriff, Satz, Absatz platziert.
< > - Kommentare können kommentiert werden, dann als verschachtelter Kommentar
< > 
< > ```
< > <!--- CM: das ist ein zweiter Kommentartext 
< >  <!--- CM: das finde ich einen ganz bemerkenswerten Kommentar und möchte ergänzen dass X 
< >   <!--- CM: Außerdem Y -->
< >  -->
< > -->
< > <!--- CM: Verschachtelte Kommentare können schnell unübersichtlich werden. Der Text wird so gut, wir werden kaum kommentieren :) -->
< > ```
< > 
< > **Änderungen** werden als Alternativvorschlag in einem Kommentar umgesetzt. Über kleinteilige Änderungen, insbesondere bei der Redaktion der Rohfassung, müssen wir uns noch verständigen.
< > 
< > **Referenzen** werden inline mit Citation-Key eingefügt [@Toller1922, 135-140]. 
< > 
< > ## Schwierigkeiten
< > 
< > Die gewählte Arbeitsweise mit Markdown in einem Repository hat mit Blick auf die kollaborative Textproduktion den Nachteil, dass Änderungen nicht unmittelbar sichtbar gemacht und dann eingearbeitet werden können, wie z.B. in OnlyOffice mit 'Änderungen nachverfolgen'. Das kriegen wir aber schon hin. Für die Gliederung und die Rohfassung können wir das mit Kommentaren lösen, für die Redaktion ebenfalls, für eine mögliche Schlussfassung müssen wir dann sehen in welchem Format wir das sinnvoll machen (hängt auch von der Einreichung ab).
< > 
< > 
< 
< ---
< 
< ## Issues
< 
< ### Shift to a less LaTeX-y approach?
< 
< Status: closed
< 
< Vielen herzlichen Dank für den Aufschlag in diesem Repo. Es ist meines Eindruckes nach ein massiv auf LaTeX angewiesener Workflow, der sich zu großen Teilen (bzw. Komplett) durch reines Markdown und modernere Formate ersetzen ließe.
< 
< - Für bibliographische Angaben: BibTeX ist ein grauenvoll altes Format, das viele modernere Reference Types und für Historiker_innen relevante Quellenarten nicht unterstützt. Mein Vorschlag ist hier CSL-JSON, dass sich direkt aus Zotero exportieren und von Pandoc (citeproc) verarbeiten lässt.
< - Für die Zitationsstile: CSL Stile. Diese sind der aktuelle Stand der Technik. Es gibt tausende auf zentralen Repositories und eine breite Community. Wird ebenso von Pandoc (citeproc) verwendet.
< - Highlights: lassen sich in Markdown (Pandoc) mit Inline und Block-level Klassen umsetzen (ergo, der gleiche Ansatz wie hier in LaTeX): `[inline highlight]{.highlight}`
< - Für die Cross-references zu Abbildungen und Tabellen braucht mensch dann noch den "pandoc-crossref" Filter.
< 
< ### devcontainer hinzufügen
< 
< Status: closed
< 
< für, wenn leute keine ordentliche LaTeX-Umgebung aufsetzen (können). Gerade einzelne Pakete nachinstallieren kann unter windows extrem frickelig sein..
< 
< ### Pipeline importieren
< 
< Status: closed
< 
< Markdown -> Tex -> Pdf
< 
< ### Vorlage für Paper einbauen
< 
< Status: closed
< 
< 
Nur in quarto/tool-registry-dh: Papers.qmd.
Nur in quarto/tool-registry-dh: p_bots_social-media.qmd.
Nur in quarto/tool-registry-dh: p_publish2wikidata.qmd.
Nur in quarto/tool-registry-dh: tr_documentation.qmd.
Nur in quarto/tool-registry-dh: TR_documentation.qmd.
Nur in quarto/tool-registry-dh: tr_publications.qmd.
Nur in quarto/tool-registry-dh: TR_publications.qmd.
