Humanistyka Cyfrowa |

Stare nawyki, nowe narzędzia

Fri, 02 Oct 2026 00:00:00 +0000

Wczesnonowożytni humaniści, którzy przyswoili sobie druk, nadali edycji kształt zachowany do dziś: tekst się ustala, składa, publikuje raz i poprawia – jeśli w ogóle – w drugim wydaniu wiele lat później. Komputery mamy od pół wieku, a edycje cyfrowe wciąż robimy tak, jakby były drukowanymi książkami. Kończymy tekst, publikujemy go za jednym zamachem, a erratę odkładamy na później. Narzędzia są nowe, nawyki – stare.

Moja nowa lekcja dla Programming Historian en français, , łapie nowe narzędzia za słowo. Jeśli kodowanie TEI jest kodem – a jest – to można je wersjonować, walidować i przekształcać jak każdy kod. Programiści dawno przestali czekać na gotowy produkt: każda zmiana jest automatycznie sprawdzana i wydawana, gdy tylko przejdzie testy. Nic nie stoi na przeszkodzie, by edycja krytyczna działała tak samo: publikowała każdy list, gdy tylko zostanie zakodowany i sprawdzony, i poprawiała go jawnie, ilekroć pojawi się lepsze odczytanie.

Część pierwsza: cegiełki

Pierwsza część przedstawia elementy, które uwalniają edytora od odziedziczonego sposobu pracy, wszystkie otwartoźródłowe:

plik ODD, jedyny dokument, w którym zapisano reguły kodowania w projekcie;
wygenerowany z niego schemat RELAX NG, który egzekwuje strukturę;
reguły Schematron, które dokładają ograniczenia edytorskie niewyrażalne w samym schemacie;
skrypt walidacyjny, który jednym poleceniem sprawdza cały korpus i za pomocą XSLT generuje czytelne wyniki.

Przykłady pochodzą z korespondencji Filippa Cavriany, której edycję . Część druga doda łańcuch spinający te elementy, tak by każda zmiana w korpusie była walidowana i publikowana na bieżąco. Lekcja powstała w ramach mojego projektu , który szuka sposobów na obniżenie kosztów edycji naukowych; automatyzacja publikacji – dzięki której edytor nie musi już czekać na specjalistę na końcu łańcucha – to jedna z największych oszczędności, jakie da się osiągnąć.

Oburzenie, wyparcie albo kosmetyka

Sztuczną inteligencję przyjmuje się według tego samego schematu: oburzenie, wyparcie albo powierzchowne przyswojenie. To jeden z powodów, dla których lubię humanistykę cyfrową: mało która dziedzina obnaża ten paradoks tak dobitnie. Nowe narzędzia powinny być zaproszeniem do przemyślenia na nowo, jak pracować lepiej, a nie świeżą warstwą farby na starych nawykach. Ta lekcja przyjmuje to zaproszenie w imieniu edytorstwa naukowego. Ciąg dalszy nastąpi w części drugiej.

Dziękuję wszystkim, bez których ta lekcja by nie powstała. Redakcja: Daphné Mathelier i Matthias Gille Levenson. Recenzje: Jasmin Macarios i Elsa Van Kote. Nieoceniona pomoc: Anisa Hawes.

Lekcja ukazała się w otwartym dostępie: (DOI: ).

persNamer 1.2: jeden numer VIAF, dziewięć kartotek haseł wzorcowych

Mon, 07 Sep 2026 00:00:00 +0000

był na początku zwykłym udogodnieniem: numer VIAF na wejściu, wpis TEI <person> na wyjściu, do tego znacznik <persName>, którym adnotuje się tekst. Nic ponadto – a i sam wpis był chudy: nazwa, dwie daty, jeden identyfikator. Wydana dziś wersja 1.2 wciąż robi tylko tę jedną rzecz, ale wpis, który zwraca, jest nareszcie wart zachowania.

Co dziś zawiera wpis osobowy

Zacznijmy od nazwy. W klastrze VIAF każda uczestnicząca biblioteka wnosi własną formę nazwy, a stary persNamer brał po prostu pierwszą etykietę, jaka mu się nawinęła. Zapytany o Woltera odpowiadał „فولتير،” – po arabsku, z przecinkiem na końcu – i dorzucał do tego pusty xml:id. Teraz program zlicza formy w całym klastrze i zostawia tę, która wśród rekordów źródłowych powtarza się najczęściej; pozostałe idą za nią jako <persName type="variant">, od najczęstszej. Daty są normalizowane (1572-08-00 zamienia się w 1572-08) i zapisywane dwa razy: jako tekst i w atrybucie @when, bo to właśnie tam zajrzy każde przetwarzanie, które ma cokolwiek do czynienia z datami. Płeć i opisy dochodzą, o ile VIAF je udostępnia.

No i to, na czym zależało mi najbardziej: każdy identyfikator, który VIAF wiąże z daną osobą – przez schema:sameAs albo przez własne identyfikatory źródeł – trafia do osobnego <idno>: BnF, GND, Biblioteka Kongresu, SUDOC, Wikidata, ISNI, BNE, LIBRIS, NDL. Jeden numer wchodzi, dziewięć katalogów wychodzi. Dla personografii to cała różnica między listą nazwisk a węzłem w sieci danych wzorcowych.

<person xml:id="pers-teligny-c">
 <persName>Charles de Téligny</persName>
 <birth when="1535">1535</birth>
 <death when="1572-08-24">1572-08-24</death>
 <sex value="M">M</sex>
 <idno type="VIAF">314802260</idno>
 <idno type="BNF">16133360</idno>
 <idno type="Wikidata">Q1868249</idno>
 <idno type="ISNI">0000000071126808</idno>
</person>

Od luźnych fragmentów do personografii

Dla jednej osoby XML wypisany w terminalu w zupełności wystarczy. Edycja ma jednak osób setki. Dlatego persNamer przyjmuje teraz kilka numerów VIAF naraz, grzecznie daje VIAF-owi odetchnąć między jednym żądaniem a drugim, buforuje to, co już pobrał, a z opcją --merge wstawia nowe wpisy prosto do <listPerson> istniejącego pliku TEI. Kogo już tam zapisano, tego rozpoznaje po numerze VIAF i zostawia mu dotychczasowy xml:id; nowe identyfikatory sprawdza względem pliku i w razie kolizji dokleja im przyrostek (-2, -3); na koniec plik dostaje nowe wcięcia – ale dopiero wtedy, gdy kopia .bak leży już odłożona na bok.

persnamer --merge edition.xml 314802260 36925746

Jedna zmiana, o której trzeba wiedzieć: partykuła nazwiska domyślnie wypada już z identyfikatora, toteż Charles de Téligny to odtąd pers-teligny-c, nie pers-deteligny-c. Jeśli twój projekt zdążył się przyzwyczaić do dawnej formy, --keep-particle ją przywraca; jeśli zaś wolisz w ogóle nie polegać na nazwiskach, --id-format viaf da ci pers-viaf-314802260.

Porządki

Ze skryptu zrobił się porządny pakiet z poleceniem persnamer: jedna linijka wystarczy, by go zainstalować (uv tool install albo pipx) lub uruchomić jednorazowo przez uvx, niczego nie instalując. Dwadzieścia sześć testów sprawdza go na nagranych odpowiedziach VIAF – zestaw obywa się więc bez sieci. CI przepuszcza je na Pythonie od 3.9 do 3.13, a wynik jest walidowany względem TEI P5. Licencja: Apache 2.0, jak dotąd.

Czego nadal nie umie, to powiedzieć, gdzie ktoś się urodził ani z czego żył: klastrowy RDF VIAF-u nie zawiera ani miejsc, ani zawodów. Zawierają je za to powiązane rekordy BnF i GND – a ich numery masz już w ręku.

Kod i dokumentacja na .

tei-mcp v0.3: kodowanie TEI bez przepisywania źródła

Tue, 05 May 2026 00:00:00 +0000

Kiedy , celem było powstrzymanie asystentów AI przed halucynowaniem znakowania TEI. Osadzenie w schemacie rozwiązało część problemu: mając bezpośredni, oparty na narzędziach dostęp do specyfikacji P5, model nie musi już zgadywać, co znaczy dany element ani jakie atrybuty przyjmuje. Wynik przechodzi walidację.

Ale halucynacja w kodowaniu TEI ma dwa oblicza, a schemat wyłapuje tylko jedno z nich. Walidacja względem specyfikacji mówi, że znakowanie jest poprawne. Nie mówi nic o tekście, który to znakowanie obejmuje. A właśnie tam – w samym tekście – gnieżdżą się groźniejsze halucynacje. Kompozycja z blokadą zakresów (span-locked composition), główna nowość w v0.3, została zaprojektowana właśnie po to, by im zapobiegać.

Spis treści

Halucynacja, której schemat nie wyłapie

Poproś model o zakodowanie szesnastowiecznego francuskiego listu, a często dostaniesz z powrotem dokument TEI, który wygląda nienagannie. Nagłówek wypełniony, znaczniki <persName> na swoich miejscach, <dateline> poprawnie zbudowany. Przepuść go przez validate_document – przejdzie.

Potem porównaj tekst główny ze źródłem.

mesme stało się même. Przecinek się przesunął. luy po cichu zmodernizowano na lui. Zdanie trudne do odczytania w rękopisie zostało „poprawione” na coś gładszego. Żadnej z tych zmian nikt nie zlecił. Żadna nie została oznaczona. Dokument jest zgodny ze schematem i po cichu błędny.

W pracy archiwalnej – gdzie zakodowany tekst staje się trwałym zapisem, na którym polegają czytelnicy, indeksy wyszukiwania i cytowania – to właśnie ten rodzaj awarii liczy się najbardziej. Zniekształcony znacznik irytuje. Zmodernizowana pisownia, której nikt nie zauważy przez pięć lat, to skażenie tekstu.

Kompozycja z blokadą zakresów

Nowe wydanie (v0.3) zawiera mechanizm zapobiegania halucynacjom wycelowany dokładnie w ten rodzaj awarii. Cel projektowy: sprawić, by halucynacje w tekście głównym były niemożliwe z samej konstrukcji, a nie tylko mało prawdopodobne.

Pomysł jest prosty: model nigdy nie wpisuje tekstu głównego.

Zamiast tego przebieg pracy wygląda tak:

Model wywołuje get_source("letter_001") i otrzymuje źródłowy czysty tekst jako niezmienny ciąg znaków.
Dla każdego znacznika, który chce zastosować, wywołuje tag_span("letter_001", start, end, element_path, attrs) – rejestrując element TEI na zakresie znaków w źródle.
Gdy skończy, wywołuje compose("letter_001"). Serwer przeplata zarejestrowane znaczniki z pierwotnym czystym tekstem, renderuje końcowy dokument TEI, a następnie sprawdza bajt po bajcie, czy płaska zawartość tekstowa wyrenderowanego dokumentu jest równa źródłu.

Jeśli bajty się zgadzają, dokument wraca. Jeśli nie – jeśli znaczniki modelu w jakiś sposób implikują tekst główny różniący się od źródła choćby jednym znakiem – compose() zgłasza wyjątek, zamiast zwracać skażony dokument.

W tym przebiegu nie ma ścieżki, na której model wyprodukowałby dokument TEI z tekstem głównym różnym od źródła. Ten niezmiennik jest mechaniczny, nie behawioralny. Nie musisz ufać, że model nie halucynuje; musisz ufać porównaniu == dwóch ciągów bajtów.

Czym to jest, a czym nie jest

Kompozycja z blokadą zakresów jest uzupełnieniem osadzenia w schemacie, nie jego zamiennikiem. Narzędzia osadzające w schemacie (validate_document, lookup_element, valid_children i reszta pierwotnej szesnastki) pomagają modelowi wytwarzać poprawne TEI. Kompozycja z blokadą zakresów gwarantuje, że tekst główny wewnątrz tego TEI jest wierny źródłu. Przebieg kodowania nadający się do wdrożenia musi spełniać oba warunki – i teraz oba pokrywa jeden serwer.

Nie jest to też magiczne lekarstwo na wszystko. compose() nie sprawdza jeszcze, czy zarejestrowane znaczniki są dopuszczalne wedle wczytanego dostosowania ODD – to zadanie na później. Zarejestrowane znaczniki żyją w pamięci procesu i nie przetrwają restartu. A pliki źródłowe muszą być czytelne z miejsca, w którym działa serwer. Wszystko to da się rozwiązać; nic z tego nie podważa głównego niezmiennika.

Dlaczego to ważne poza TEI

Ten wzorzec się uogólnia. Zawsze, gdy model ma adnotować, przekształcać lub obudowywać fragment tekstu – i zawsze, gdy integralność tekstu bazowego liczy się bardziej niż zdolność modelu do jego „ulepszania” – stosuje się ten sam kształt rozwiązania. Nie każ modelowi przepisywać tekstu. Każ mu wytwarzać instrukcje nad tekstem, a deterministycznemu kompozytorowi pozwól je zastosować pod niezmiennikiem równości.

Dla edycji cyfrowych w szczególności zmienia to zakres tego, co można odpowiedzialnie zlecić modelowi. Kodowanie staje się nagle zadaniem, które można delegować bez ręcznego porównywania każdego wyniku ze źródłem. Maszyna idzie nudną ścieżką; edytor sprawdza znakowanie, nie pisownię.

Jak pobrać aktualizację

Jeśli masz już zainstalowany tei-mcp:

uvx tei-mcp@latest

Albo od zera:

pip install tei-mcp

Aby korzystać z kompozycji z blokadą zakresów, wskaż serwerowi katalog z plikami źródłowymi w postaci czystego tekstu:

export TEI_MCP_SPAN_SOURCE_ROOT=/path/to/sources
uvx tei-mcp

Rdzeń nazwy każdego pliku staje się identyfikatorem dokumentu (letter_001.txt → letter_001).

Kod źródłowy, pełna dokumentacja i notatki projektowe dotyczące niezmiennika:

Edycja cyfrowa inna niż wszystkie

Tue, 24 Mar 2026 00:00:00 +0000

Większość źródeł pierwotnych nigdy nie doczeka się publikacji. Model, na którym polegamy, by temu zaradzić – edycje cyfrowe finansowane z grantów – jest zbyt drogi, zbyt scentralizowany i zbyt kruchy, by działać na dużą skalę. Właśnie opublikowałem , w którym tłumaczę, dlaczego edycję krytyczną listów Cavriany buduję inaczej: jako zdigitalizowane źródła pierwotne, które rosną organicznie, przy minimalnej infrastrukturze, z automatyczną konserwacją, otwarte na współpracę i tak tanie, że nie potrzebują żadnych grantów. To argument na rzecz takiej humanistyki cyfrowej, która działa niezależnie od wsparcia instytucji.

tei-mcp: TEI P5 dla agentów AI

Sun, 15 Mar 2026 00:00:00 +0000

Kto choć raz prosił asystenta AI o napisanie TEI XML, ten zapewne zauważył, że coś mu nie wychodzi. Elementy pojawiają się tam, gdzie nie powinny. Atrybuty są zmyślone. Reguły zagnieżdżania – ignorowane. Model ma z grubsza pojęcie, jak wygląda TEI, ale żadnej pewnej wiedzy o specyfikacji.

tei-mcp rozwiązuje ten problem, dając agentom AI bezpośredni, oparty na narzędziach dostęp do wytycznych TEI P5.

Spis treści

Czym jest MCP?

(MCP) to otwarty standard, który pozwala aplikacjom AI łączyć się z zewnętrznymi źródłami danych i narzędziami. Można o nim myśleć jak o porcie USB dla AI: jeden protokół, dzięki któremu każdy zgodny klient – Claude, Cursor, Windsurf i inne – może się podłączyć do wyspecjalizowanych usług.

Serwer MCP udostępnia narzędzia, które AI może wywoływać w trakcie rozmowy. Zamiast polegać na zapamiętanych danych treningowych, model może odpytać żywe, miarodajne źródło.

Co robi tei-mcp

tei-mcp parsuje specyfikację ODD TEI P5 i udostępnia 16 narzędzi, które odpowiadają na najczęstsze pytania edytora czy kodera:

Co to za element? Wyszukaj dowolny element, klasę, makro lub moduł po nazwie, bez rozróżniania wielkości liter i z podpowiedziami przy literówkach.
Jakie przyjmuje atrybuty? Rozwiąż atrybuty w całej hierarchii klas – najpierw lokalne, potem po kolei dziedziczone.
Co może się w nim znaleźć? Rozwiń modele zawartości w ustrukturyzowane drzewa albo pobierz płaską listę dopuszczalnych dzieci.
Czy ten element może tu stać? Sprawdź zagnieżdżenie rodzic–dziecko albo prześledź osiągalność w całej hierarchii elementów.
Czy mój dokument jest poprawny? Zwaliduj plik TEI XML względem specyfikacji: modele zawartości, wartości atrybutów, zamknięte listy wartości, spójność odwołań i ostrzeżenia o elementach przestarzałych.
A co z moim schematem projektowym? Wczytaj plik dostosowania ODD, by zawęzić wszystko powyższe do podzbioru TEI właściwego dla twojego projektu.

Dlaczego to ważne

Kodowanie w TEI wymaga ciągłego zaglądania do wytycznych. Doświadczeni koderzy mają najczęstsze wzorce w małym palcu, ale nawet oni muszą sprawdzać w specyfikacji mniej znane elementy czy złożone modele zawartości. Dla asystentów AI, które takiej przyswojonej wiedzy nie mają, problem jest poważniejszy: halucynują znakowanie, które wygląda wiarygodnie, ale jest błędne.

Z tei-mcp AI nie musi zgadywać. Może sprawdzić odpowiedź w specyfikacji, zanim napisze choćby jeden nawias ostry. W rezultacie powstaje znakowanie zgodne z TEI P5 – albo z dostosowaniem ODD twojego projektu.

Pierwsze kroki

Zainstaluj z PyPI:

pip install tei-mcp

Następnie dodaj go do konfiguracji swojego klienta MCP:

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

Serwer pobiera specyfikację TEI przy pierwszym uruchomieniu i współpracuje z każdym klientem zgodnym z MCP.

Kod źródłowy i pełna dokumentacja:

Nauka kodu dwójkowego z emulatorem telegrafu ITA2

Thu, 13 Feb 2025 00:00:00 +0000

Abstrakcja, którą można wziąć do ręki

Ten emulator ITA2 to praktyczna pomoc dydaktyczna. Unaoczniając abstrakcyjne pojęcia z zakresu kodowania i pozwalając się nimi bawić, wprowadza studentów w jedno z kluczowych zagadnień informatyki i telekomunikacji – reprezentację binarną, czyli to, jak tekst zamienia się w ciągi jedynek i zer. Często uczymy tego na sucho; tymczasem widok dziurek pojawiających się na taśmie pomaga studentom pojąć, w jaki sposób fizyczne układy mogą przechowywać informację cyfrową.

ITA2 (Baudot-Murray) Telegraph Type Emulator

Type a word in the input below to see its representation on the ITA2 tape.

Type word:

Kontekst historyczny: od telegrafu do komputera

Kod ITA2 (Międzynarodowy Alfabet Telegraficzny nr 2), znany też jako kod Baudota-Murraya, opracowano w latach dwudziestych XX wieku jako udoskonalenie pierwotnego kodu telegraficznego Émile’a Baudota z lat siedemdziesiątych XIX wieku. Te wczesne systemy telekomunikacyjne wywarły bezpośredni wpływ na późniejszy rozwój informatyki:

pięciobitowy schemat kodowania był jednym z pierwszych przykładów kodowania znaków;
ograniczony zestaw znaków (pięć bitów daje zaledwie 32 kombinacje) wymusił pomysłowy mechanizm przełączania rejestrów LETTERS/FIGURES (litery/cyfry);
system ten służył dalekopisom jeszcze przez dobrą część XX wieku.

Automaty skończone przez zabawę

Mechanizm przełączania LETTERS/FIGURES wprowadza pojęcie automatu skończonego w sposób zupełnie naturalny. Studenci sami, eksperymentując, odkrywają, że ten sam wzór może oznaczać różne znaki w zależności od bieżącego trybu. To doświadczenie z kodowaniem zależnym od stanu przygotowuje ich do bardziej złożonych zagadnień informatycznych. Na przykład ciąg bitów 00011 oznacza:

literę „A” w trybie LETTERS,
cyfrę „1” w trybie FIGURES. Taka podwójna interpretacja zależna od stanu leży u podstaw tego, jak komputery obchodzą się z danymi.

Ćwiczenia na zajęcia

Oto kilka sposobów wykorzystania emulatora ITA2 w dydaktyce:

Łamanie szyfru: studenci dekodują wiadomości zapisane jako wzory ITA2.
Oszczędne kodowanie: dyskusja o tym, dlaczego mechanizm przełączania rejestrów był tak ważny dla oszczędzania pasma.
Ewolucja kodowania: porównanie pięciobitowego kodu ITA2 z ASCII (7 bitów) i Unicode.
Fizyczna informatyka: powiązanie tego historycznego systemu ze współczesnymi mikrokontrolerami, takimi jak Arduino.

Korzyści w zakresie dostępności

Poza walorem historycznym podejście to pomaga studentom o różnych stylach uczenia się:

wzrokowcy widzą wzory,
kinestetycy wchodzą w bezpośrednią interakcję z procesem kodowania,
umysły teoretyczne mogą zgłębiać matematyczną stronę teorii informacji.

Szczegóły implementacji

Emulator napisano w JavaScripcie i można go łatwo osadzić na dowolnej internetowej platformie edukacyjnej. Kod jest modułowy i daje się dostosować do różnych kontekstów dydaktycznych. Kod źródłowy oraz działający emulator można znaleźć tu: