Lou Burnard
Czym jest Text Encoding Initiative?
oryginał: What is the Text Encoding Initiative? How to add intelligent markup to digital resources,
OpenEdition Press, Marseille 2014,
zpISBN 9782821834606.
tłumaczenie: Joanna Bilińska
DELab UW Warszawa: 2015

Wprowadzenie

Text Encoding Initiative (TEI) jest jednym z najtrwalszych i najbardziej wpływowych projektów w dziedzinie znanej jako humanistyka cyfrowa. Jego celem jest dostarczenie wskazówek w zakresie tworzenia i zarządzania w formie cyfrowej każdym typem danych stworzonych i wykorzystywanych przez humanistów, takich jak teksty źródłowe, rękopisy, dokumenty archiwalne, teksty starożytne i wiele innych. W tej niewielkiej książce postaramy się wyjaśnić naturę i cele TEI oraz przedstawić kilka konkretnych przykładów tego, jak można ten system wykorzystać w różnych projektach związanych z tworzeniem źródeł cyfrowych. Przedtem jednak postaramy się odpowiedzieć na pytanie, które zwykle w takich wprowadzających tekstach jest pomijane: dlaczego w ogóle interesować się TEI? W gruncie rzeczy, obecnie prawie każdy potrafi korzystać z edytora tekstów, by stworzyć dokumenty cyfrowe, za pomocą systemów bazodanowych tworzyć informacje i zarządzać nimi, czy też tworzyć strony internetowe za pomocą prostego edytora. Jaki jest sens uczenia się XML czy TEI, żeby wykonać tę samą pracę?

Jest wiele powodów, ale zajmiemy się zwłaszcza trzema. Pierwszy to fakt, że TEI XML koncentruje się bardziej na znaczeniu tekstu niż jego wyglądzie. Drugim powodem jest to, że TEI XML jest niezależne od platformy sprzętowej. Trzeci to natomiast fakt, że TEI XML zostało stworzone przez środowisko naukowe do jego własnych celów i to samo środowisko zajmuje się jego dalszym rozwojem.

Jeśli ważne są dla nas bardziej słowa w tekście i ich znaczenia niż forma, w jakiej są one zaprezentowane na stronie, wkrótce zauważymy pewne frustrujące ograniczenia typowych edytorów tekstów. Prawie każdy taki system daje możliwość przeszukiwania setek stron i pokazuje wszystkie wystąpienia ciągu „London”. Jednakże inteligentne zapytanie, np. takie, w którym „London” będący nazwą miejscową w Kanadzie jest odróżniony od miejsca w Anglii, czy nazwiska pisarza wymaga czegoś więcej. Jak zauważono już w pracy Coombs i in. z 1987, sposób patrzenia badaczy akademickich na źródła znacząco różni się od tego, do czego przygotowane są edytory tekstów. Używając często cytowanej frazy, „Otrzymujesz to, co widzisz”What You See is What You Get means What You See is ALL you Get weźmy pod uwagę, że: „Otrzymujesz TYLKO to, co widzisz”. Są to więc systemy, które w większości są zaprojektowane tak, by zmniejszyć różnicę między tym, co widzimy na ekranie, a tym, co wpisujemy na klawiaturze ― starają się osiągnąć to poprzez ograniczanie możliwości wyrażania i zapisywania w formie cyfrowej jedynie informacji na temat wyglądu ciągów znaków, a nie ich własności gramatycznych czy funkcji. W dokumencie możemy swobodnie dostosować font, rozmiar, wyrównanie czy kolor każdego z wystąpień słowa „Moskwa”, jednak nie możemy edytora tekstów używać w sposób jednoznaczny i pewny do oznaczania, że jest to nazwisko albo nazwa miejscowa.

Jeśli chcemy współdzielić tworzone materiały tekstowe z innymi osobami (czy samymi sobą parę dekad później), powinniśmy też wziąć pod uwagę to, że wiele systemów komputerowych zmusza do stosowania ich wewnętrznych sposobów przechowywania informacji. W jakim stopniu dokument czy baza danych sporządzona w waszym ulubionym obecnie programie mogą być używane w innych programach? Czy mogą zostać przeniesione z PC na Maca i na Linuksa bez straty informacji? Oczywiście istnieje oprogramowanie umożliwiające konwersje pomiędzy wieloma różnymi formatami plików ― to jest dobra wiadomość. Zła jest taka, że takie konwersje są zawsze konieczne, często kompleksowe, stratne lub kosztowne. Nawet w przypadku oprogramowania tego samego rodzaju prawdziwa wymienialność pozostaje problematyczna: dokument przygotowany za pomocą jednego edytora tekstów (powiedzmy Worda) może, ale nie musi wyglądać identycznie, gdy zostanie otwarty w innym (powiedzmy Open Office); baza danych z Filemaker Pro może, ale nie musi zostać łatwo skonwertowana do formatu wykorzystywanego w Microsoft Access i vice versa.

Informacja przechowywana w dokumentach TEI XML wygląda zawsze dokładnie tak samo w każdym rodzaju oprogramowania. Nie ma w tym żadnych magicznych sztuczek dostępnych jedynie jednemu konkretnemu oprogramowaniu działającemu w jednym konkretnym środowisku. TEI XML, podobnie jak inne pliki XML, jest jedynie sekwencją czytelnych znaków bez żadnych sekretnych wbudowanych kodów. W gruncie rzeczy, dokument TEI XML przedstawia tekst bez żadnego uwzględniania oprogramowania, które mogłoby zostać wykorzystane do jego wizualizacji, analizy czy przechowywania. Wręcz przeciwnie, zawartość dokumentu TEI XML przedstawia bezpośrednio to, co twórca uzna za ważne, jeśli chodzi o strukturę i zawartość. Jeśli znajduje się tam ciąg znaków, który znakujący uznał za nazwę osobową czy miejscową albo wyraz obcy, tytuł piosenki czy ciąg mowy zależnej (na przykład), TEI posiada odpowiednie etykiety do oznaczenia tego. Podczas drukowania może się okazać wskazane, by tytuły piosenek oznaczać kursywą czy dodać linki do wpisów bazodanowych przy wyświetlaniu ich na stronie internetowej. Może się okazać wskazane, by włączyć (lub wykluczyć) fragmenty będące mową niezależną czy wyrazami obcymi, gdy robi się analizę leksykalną tekstu. Teksty w formie cyfrowej mogą być wykorzystywane na wiele różnych sposobów: po to właśnie je tworzymy. Jeśli tym, czego potrzebujemy, jest nowa wersją starej książki, wystarczy cyfrowa fotokopia. Jeśli jednak celem jest to, by stary tekst stał się dostępny dla różnych nowych czytelników, wtedy reprodukowanie jego wyglądu raczej nie wystarczy. TEI XML daje nam strukturę umożliwiającą reprezentację wszystkiego, co uznamy za ważne w tekście, a nie tylko jego wyglądu, dzięki czemu oprogramowanie może bazować na tak wprowadzonych oznaczeniach, by generować nowe wizualizacje i nowe perspektywy. W rezultacie, decydowanie, jakie znakowanie TEI XML wykorzystać, jest zawsze zajęciem naukowym, zawsze wymagającym świadomego wyboru.

Książka ma na celu przedstawienie kilku z wielu możliwości znakowania TEI, bez wchodzenia w nadmierne szczegóły. Mamy nadzieję, że będzie dostępna dla szerokiego grona czytelników, wliczając w to i praktykujących humanistów cyfrowych, jak i tych, którzy jeszcze nie w pełni poddali się urokowi komputera. Zakładamy posiadanie jedynie bardzo podstawowej wiedzy na temat technologii XML i zainteresowania tradycyjnymi problemami tekstologii.

Pierwszy rozdział książki 1. TEI a XML zawiera trochę technikaliów wprowadzających założenia XML leżące u podstaw znakowania TEI. Drugi rozdział 2. Strukturalna organizacja dokumentu TEI opisuje, w jaki sposób zbudowane są dokumenty TEI, po czym następuje pewna liczba typowych przykładów w trzecim rozdziale zatytułowanym „Zróżnicowanie struktur tekstowych” 3. Zróżnicowanie struktur tekstowych. Dwa następujące potem rozdziały bardziej szczegółowo opisują „róg obfitości TEI”, przedstawiając najpierw pewne własności tekstowe typowe dla większości dokumentów 4. Róg obfitości TEI; część pierwsza, a następnie kilka bardziej specjalistycznych możliwości oferowanych przez system TEI 5. Róg obfitości TEI; część druga. Rozdział szósty 6. Nagłówek TEI opisuje Nagłówek TEI, czyli ‘obowiązkową stronę tytułową’ dokumentu TEI zawierającą metadane. Rozdział siódmy 7. Dostosowywanie TEI zatytułowany „Dostosowywanie TEI” pokazuje, jak dopasować system TEI do potrzeb konkretnego projektu. Na zakończenie przedstawiamy pewną dyskusję na temat organizacji TEI, jego teraźniejszości i przyszłości.

Każdy wspomniany tutaj element odsyła do strony na witrynie TEI , gdzie można znaleźć wyczerpujące informacje i szybko za pomocą kilku kliknięć myszy przejść do objaśnień ich funkcji oraz przykładów.

Table of contents

1. TEI a XML

TEI podkreśla to, co jest wspólne dla każdego typu dokumentu, niezależnie od tego, czy został fizycznie zapisany w postaci cyfrowej na dysku lub karcie pamięci, w formie drukowanej jako książka lub czasopismo, rękopiśmiennej w manuskrypcie czy kodeksie, rytej w kamieniu czy tabliczce woskowej. Ułatwia to przeniesienie tekstu ze starszych form takich jak druk czy rękopis do nowszych takich jak dysk czy ekran. Stąd spojrzenie TEI na to, czym jest tekst jest w dużym stopniu uzależnione od tego, czym był w przeszłości, jednakże bez umniejszania znaczenia tego, czym tekst może się stać w przyszłości. System ten stara się traktować wszystkie typy dokumentów cyfrowych w ten sam sposób, niezależnie od tego, czy zostały ‘zrodzone cyfrowo’, czy nie.

W związku z tym, system TEI daje użyteczny sposób myślenia na temat natury tekstu: tworzy coś w rodzaju encyklopedii ogólnie przyjętych pojęć tekstowych. W niniejszym krótkim przewodniku postaramy się zaprezentować kilka z tych pojęć, wykorzystując słownictwo zdefiniowane przez TEI w jego Wskazówkach.

Aktualnie dokumenty TEI w formie cyfrowej są zapisywane za pomocą rozpowszechnionego formalnego języka znakowania zwanego XML ( extensible markup language), po raz pierwszy opublikowanego przez konsorcjum World Wide Web (W3C) w 1998 r., jednak sięgającego korzeniami do systemów przygotowywania tekstów z lat 80. XX wieku. XML daje prosty sposób reprezentowania ustrukturyzowanych danych w postaci linearnego ciągu znaków oraz etykietowania poszczególnych części tego ciągu za pomocą ‘znaczników’ ( ‘tagów’) służących wskazywaniu funkcji strukturalnej lub znaczeniowej tych ciągów. Ponieważ stał się tak dominującą technologią, wszędzie można znaleźć świetne wprowadzenia do tego tematu, więc zakładamy, że czytelnik posiada podstawowe rozumienie takich kluczowych pojęć jak ‘element’, ‘atrybut’, ‘schema’, ‘przestrzeń nazwy’, w skrócie objaśnionych poniżej na potrzeby zrozumiałości tekstu. Wskazówki TEI zawierają ‘Delikatne wprowadzenie do XML’, co może być użyteczne dla nowicjuszy, jednak można też znaleźć wiele innych tutoriali.

Poniżej znajduje się przykład minimalnego dokumentu XML:
            <?xml version="1.0"?>             <doc xmlns="http://example.org/namespace">             <p n="1">To jest akapit.</p>             <p n="2">Ten akapit zawiera wzmiankę na temat miasta <placeName>Bristol</placeName>.</p>           </doc>

Pierwsza linia dokumentu TEI zawsze wygląda tak, jak to zostało pokazane powyżej: jest to specjalny rodzaj instrukcji stwierdzającej, że to, co dalej następuje, to dokument XML zgodny z tą wersją XML, na którą wskazuje (w tym wypadku, wersją 1.0). Dokument XML składa się z sekwencji znaków. W ramach tej sekwencji wykorzystywane są znaki < oraz > służące do oznaczenia początku oraz końca znaczników (tagów). Znacznik może być znacznikiem otwierającym (tak jak <p>) albo zamykającym (tak jak </p>). Zawsze rozpoczyna się od nazwy (doc, p, placeName w powyższym przykładzie) i może też zawierać specyfikację atrybutową (tak jak n="1"). Celem znacznika otwierającego jest wskazanie miejsca w sekwencji znaków, w którym rozpoczyna się jakiś element, którego typ został wskazany przez nazwę znacznika, natomiast celem znacznika zamykającego jest pokazanie, gdzie kończy się ten element. Specyfikacja atrybutowa zawiera dodatkową informację na temat występowania elementu poza jego nazwą. W powyższym przykładzie mamy element nazwany <doc>, który zawiera dwa elementy <p>. Oba elementy <p> posiadają atrybut n z numerem oraz czysty tekst. Drugi element <p> zawiera też element <placeName>.

Taki dokument XML jest nazywany ‘poprawnym składniowo’ ( well-formed), jeśli jest zgodny z pokazaną tu składnią i zawiera odpowiednio zagnieżdżone znaczniki otwierające i zamykające. Jednakże standard XML nie mówi nic o tym, jak powinny być nazwane elementy czy atrybuty (w przeciwieństwie do np. HTML, w którym zostały zdefiniowane konkretne zestawy znaczników, które powinny być wykorzystywane w odpowiedni sposób we wszystkich dokumentach), a jeszcze mniej o tym, co powinny one znaczyć. Możemy wnioskować, że elementy <p> powyżej służą do numerowania akapitów, jednak nie ma reprezentacji w XML, która mogłaby to potwierdzić ― mogłyby równie dobrze oznaczać strony albo artykuły hasłowe w słowniczku, linie albo wersy. Jeśli więc znajdę inny dokument zawierający elementy <p>, skąd będę wiedzieć, czy pełnią tę samą funkcję? Funkcją atrybutu xmlns powyżej jest pomoc w rozwiązaniu tego problemu poprzez wskazanie danej przestrzeni nazwy obejmującej wszystkie możliwe elementy występujące przy <doc>.

Nie ma niczego nadzwyczajnego w tym, że w jednym dokumencie znajdziemy elementy z wielu przestrzeni nazwy: na przykład dokument zawierający notacje muzyczne, grafikę wektorową czy tekst w całości reprezentowany w XML mogą wykorzystywać tagi z trzech różnych przestrzeni nazwy, dla elementów muzycznych, graficznych i tekstowych. Przestrzeń nazwy jest sposobem etykietowania grupy elementów: w naszym przykładzie to użycie wskazuje na to, że elementy <p> są innymi elementami niż te zdefiniowane w jakiejś innej przestrzeni nazwy.

Powodem wprowadzenia znaczników do dokumentu jest potrzeba etykietowania i organizowania tekstu na potrzeby przetwarzania maszynowego. Jeśli akapity są jasno oznakowane, edytor może rozłożyć je w odpowiedni sposób. Jeśli nazwy miejscowe są jasno zaznaczone, program może je automatycznie wyekscerpować do stworzenia indeksu geograficznego. Jednakże może to zostać zrobione w sposób miarodajny, jeśli mamy kontrolę nad tym, jakie znaczniki są wprowadzone do dokumentu i gdzie się pojawiają. Technologia XML udostępnia ten poziom kontroli za pomocą (schemy), czyli rodzaju połączonego leksykonu i gramatyki służących do sprawdzania poprawności (walidowania) dokumentów XML. Powyżej powiedzieliśmy, że dokument XML jest uważany za poprawny składniowo, jeśli jest zgodny z zasadami składniowymi standardu XML. Ponadto może on, opcjonalnie, zostać nazwany poprawnym strukturalnie (valid), jeśli jest zgodny ze schemą.

Schema określa zestaw nazw elementów, a także nazw i typu danych wszystkich atrybutów z nimi powiązanych oraz zasady dotyczące kontekstów, w których mogą się one pojawiać. W przypadku naszego prostego przykładu powyżej będzie zawierać informacje, że istnieją elementy nazwane <doc>, <p>, <placeName> itp. Może też informować, że elementy <p> mogą pojawiać się w elementach <doc>, że <placeName> może pojawić się w elemencie <p>, że atrybut n musi mieć wartość liczbową itp. Warto zauważyć, że schema XML nie określa mimo to, że znacznik <placeName> wskazuje na nazwę miejscową czy to, co nazwalibyśmy miejscem: takie dodatkowe ograniczenia semantyczne muszą zostać dostarczone przez osobę przygotowującą schemę.

TEI oferuje nazwy i definicje setek znaczników wraz z zasadami ich łączenia. A dokładniej, Wskazówki TEI definiują 500-600 różnych konceptów wraz z dokładną specyfikacją dla elementów XML i klas elementów, które mogą zostać wykorzystane do ich wyrażenia. Większość, jeśli nie wszystkie, dokumenty TEI wymagają wykorzystania jedynie niewielkiej części tego, co jest oferowane. Z tego też powodu pewnym nieporozumieniem jest traktowanie TEI jako jednej monolitycznej struktury. W celu ułatwienia wymienialności danych, każdy dokument TEI wykorzystuje komponenty pochodzące z tej samej gigantycznej schemy, jednak łatwiej myśleć o TEI jako o przestrzeni nazwy.

Do wyboru i generowania swojej własnej schemy odpowiadającej potrzebom danego projektu można wykorztystać specjalne oprogramowanie, takie jak na przykład aplikacja internetowa Roma albo też po prostu samemu ręcznie zbudować schemę. Temat ten omawiamy bardziej szczegółowo w następnym rozdziale 7. Dostosowywanie TEI. Wskazówki TEI, dostępne bezpłatnie na stronie www.tei-c.org/Guidelines, stanowią kompletny podręcznik omawiający te koncepty, łącząc jednocześnie specyfikację techniczną wraz ze szczegółowymi opisami ich przeznaczenia.

Istnieje wiele narzędzi informatycznych, które pozwalają na tworzenie, zmienianie i przetwarzanie dokumentów XML lub TEI XML. Jest to żywy i bardzo obszerny temat, który nie zostanie tu omówiony. Pewne użyteczne wskazówki można jednak znaleźć na stronie TEI oraz TEI Wiki.

2. Strukturalna organizacja dokumentu TEI

Wszystkie dokumenty TEI są zorganizowane w podobny sposób, niezależnie od tego, jakiego źródła są reprezentacją. Wprowadzimy kilka najpowszechniej pojawiających się rodzajów struktury za pomocą kilku prostych przykładów.

2.1. Nagłówek, tekst i podziały

Na samym początku każdy dokument TEI (oznaczony za pomocą elementu <TEI>) posiada minimum dwie części: nagłówek (header) (oznaczony za pomocą elementu <teiHeader>) zawierający metadane opisujące dokument oraz same tekst (zwykle oznaczony za pomocą elementu <text>). Na przykład:

<TEI xmlns='http://www.tei-c.org/ns/1.0'> <teiHeader> <!-- metadane opisujące tekst --> </teiHeader> <text> <!-- tekst właściwy --> </text> </TEI>

Jak każdy inny dokument TEI XML, także ten wyraźnie informuje, że elementy, które zawiera, należy rozumieć jako pochodzące z przestrzeni nazwy http://www.tei-c.org/ns/1.0

Nagłówek został opisany dokładniej w następnym podrozdziale 6. Nagłówek TEI, więc w tym miejscu jedynie zwracamy uwagę na fakt, że minimalny nagłówek musi zawierać informację służącą do identyfikacji samego dokumentu (w <titleStmt>), informację na temat tego, w jaki sposób jest on dystrybuowany lub opublikowany (w <publicationStmt>) oraz pewne dane na temat jego pochodzenia (w <sourceDesc>). W elemencie <text> zawarta jest oznakowana wersja tekstu, w której struktura jest opisana za pomocą takich elementów jak <front> (dla wstępów itp.), <body> (dla tekstu głównego) oraz <back> (dla aneksów itp.). W ramach tych składników można też opisać dalsze podziały takie jak tomy, części, rozdziały itp., wykorzystując element <div>.

Dla przykładu tutaj przedstawiamy początek minimalnej wersji TEI dla znanej powieści, tak jak mogłaby być dystrybuowana przez wymyślonego wydawcę:
<!--TEI xmlns="http://www.tei-c.org/ns/1.0"--><TEI xmlns="http://www.tei-c.org/ns/1.0">  <teiHeader>   <fileDesc>    <titleStmt>     <title>Życie i myśli JW Pana Tristrama Shandy: wydanie TEI</title>    </titleStmt>    <publicationStmt>     <publisher>Wydawnictwo Cyfrowe</publisher>     <date>2015</date>    </publicationStmt>    <sourceDesc>     <p>Transkrypcja pierwszego wydania, 1708</p>    </sourceDesc>   </fileDesc>  </teiHeader>  <text>   <body>    <div type="volumexml:id="TS01">     <div type="chapterxml:id="TS0101">      <head>Chap. I</head>      <p>I wish either my father or my mother, or indeed both of them, as they            were in duty both equally bound to it, had minded what they were about            when they begot me; ...</p> <!-- tu dalsza część rozdziału I -->     </div>     <div type="chapterxml:id="TS0102">      <head>Chap. II</head>      <p>―― Then, positively, there is nothing in the question, that I can see,            either good or bad.―― Then let me tell you, Sir, it was a very            unseasonable question at least ...</p> <!-- tu dalsza część rozdziału II -->     </div> <!-- tu pozostałe rozdziały z tomu I -->    </div> <!-- tu pozostałe tomy -->   </body>  </text> </TEI>

W powyższym przykładzie główna część tekstu składa się z mniejszych części zawierających jeszcze mniejsze części. Są one różnie nazywane w róznych kulturach i typach dokumentów; wiele kultur zachodnich używa w tym celu nazw typu ‘sekcja’, ‘część’, ‘księga’, ‘rozdział’ (albo ich odpowiedników), jednak częstokroć w sposób niespójny lub niekompatybilny z innymi. To, co w niektórych tekstach nazywane jest ‘częścią’ ‘księgi’ w innych tekstach może być ‘sekcją’ ‘rozdziału’ albo ‘księgą’ ‘części’ w jeszcze innych. Dlatego też w TEI każdy rodzaj podziału strukturalnego części głównej tekstu jest oznaczany elementem <div>.

Element <div> może posiadać różne atrybuty dookreślające jego funkcję lub właściwości. Powyżej zastosowaliśmy atrybut type, by opisać lub sklasyfikować zawartość elementu, odróżniając w ten sposób elementy <div> zawierające ‘tomy’ od tych zawierających ‘rozdziały’. Wykorzystaliśmy też atrybut xml:id, by każdej z części powieści nadać indywidualny identyfikator.

Tego rodzaju struktura hierarchiczna może zostać zastosowana w przypadku każdego tekstu. Przykładowo poemat podzielony na księgi może zawierać elementy div type='book' dla każdej z ksiąg; sztuka podzielona na akty i sceny może odpowiednio zawierać div type='act' i div type='scene' itd. Możliwe do użycia wartości w ramach atrybutów type oraz xml:id nie są zdefiniowane w TEI i mogą zostać dowolnie wybrane przez znakującego. W przypadku atrybutów xml:id wartości są arbitralnie indywidualnymi kodami odnoszącymi się do elementów, przy których się pojawiają: stanowią sposób etykietowania omawianych elementów w taki sposób, by inne części tego lub innego dokumentu mogły się do nich bezpośrednio odnosić. Jeśli chodzi o atrybuty type, to wartości są również arbitralnymi kodami wybieranymi przez znakującego do określenia funkcji danego <div>. Pewne powszechnie pojawiające się wartości takie jak chapter czy volume zostały zasugerowane we Wskazówkach TEI, ale stworzenie własnych taksonomii pozostawiono poszczególnym projektom TEI. Jednakże dokumentowanie oraz wprowadzanie wybranej taksonomii za pomocą adaptacji TEI jest łatwe, co zostało opisane w kolejnym rozdziale 7. Dostosowywanie TEI.

Nazwa elementu <div> pochodzi od angielskiego słowa division oznaczającego podział; nie powinno więc być wykorzystywane do oznaczania czegoś, co jest całością samą w sobie. Jeśli więc część główna tekstu nie jest podzielona, nie ma powodu, by wprowadzać jeden element <div>, któryby ją zawierał. Zamiast tego element <body> może zawierać jeden (lub więcej) z elementów opisanych w następnej części.

<text> zwykle jest czymś w rodzaju książki czy artykułu, jednak może być czymkolwiek, co jest wygodnie nazywać pojedynczym, lecz kompletnym obiektem tekstowym takim jak np. wiersz, dokument archiwalny czy coś tak małego jak pocztówka. Jako alternatywa albo dodatek do elementu <text> TEI oferuje także element <facsimile>, który może zostac wykorzystany do dostarczenia dodatkowej reprezentacji wizualnej, na przykład skanów poszczególnych stron. TEI daje też możliwość reprezentowania zbiorów takich rzeczy, co zostało opisane w części 3.6. Teksty złożone.

3. Zróżnicowanie struktur tekstowych

W przypadku TEI teksty i ich części mogą zawierać dość ograniczoną liczbę komponentów ‘strukturalnych’. Zaliczają się do nich takie elementy jak nagłówki, partie wstępne lub końcowe danej części tekstu, a także pewna liczba podstawowych elementów składowych charakterystycznych dla prozy, poezji czy dramatu. Proza zasadniczo składa się z akapitów i list, oznaczanych odpowiednio za pomocą elementów <p> or <list>. Poezja składa się z wersów, oznaczanych za pomocą elementu <l>, albo sekwencji wersów, oznaczonych elementem <lg>. W dramacie przewidziany jest dodatkowy element składowy w postaci <sp> (wypowiedź), który łączy elementy <speaker> (osoba dramatu) z jednym lub więcej <p> lub <l> w zależności od tego, czy jest to dramat pisany prozą, czy wierszem.

3.1. Artykuł gazetowy

Artykuł naukowy może zostać oznakowany przykładowo w następujący sposób:

<body xml:lang="pl">  <div type="section">   <head>Wstęp</head>   <p>Zalecamy wykorzystywanie znakowania TEI jako sposobu reprezentowania tekstów      naukowych. Rozwiązanie to ma wiele zalet praktycznych: </p>   <list>    <item>Znakowanie TEI jest łatwe;</item>    <item>Znakowanie TEI jest dość powszechnie zrozumiałe;</item>    <item>Znakowanie TEI łatwo się konwertuje na inne formaty.</item>   </list>   <p>Znakowanie TEI posiada także pewne zalety naukowe, które omówimy w części <ptr target="#SEC3"/>.</p> <!-- tu dalsze akapity wstępne -->  </div>  <div type="section">   <head>Początki TEI</head>   <p>The Text Encoding Initiative powstało w 1987... </p> <!-- tu kolejne akapity -->  </div>  <div xml:id="SEC3">   <head>Własności naukowe znakowania TEI</head>   <p>Znakowanie TEI wyraża pogląd na właściwości tekstu... </p> <!-- tu kolejne akapity -->  </div> </body>

Warto zauważyć, że znakowanie to dotyczy jedynie organizacji dokumentu. Nie dotyczy tego, w jaki sposób powinno to zostać zwizualizowane na ekranie albo papierze. Informuje jedynie o tym, że istnieją trzy zatytułowane części, z których każda składa się z akapitów i list. Elementy na liście zostały oznaczone, ale nie zostało określone, czy powinny zostać one poprzedzone kropeczką, pauzą czy numerem. Element <ptr> wskazuje na istnienie odesłania z jednej części dokumentu (miejsca wystąpienia elementu <ptr>) do innego miejsca (tu elementu <div> zatytułowanego ‘Własności naukowe...’ Wartość atrybutu xml:idwprowadzonego powyżej określa miejsce odniesienia, ale nie informuje, czy powinno to zostać zrealizowane jako (powiedzmy) link HTML, czy jakiś dodany tekst (jak np. numer odpowiedniej części dokumentu), czy obie te rzeczy jednocześnie. Oczywiście nie jest trudno sobie wyobrazić, jak można wyświetlić te elementy dokumentu, używając języka formatowania takiego jak Word, HTML, czy LaTeX, ale nie jest to głównym celem tego znakowania. Ponieważ aspekty te są w znakowaniu nieokreślone, ten sam dokument może być powtórnie wykorzystany w innej sytuacji edytorskiej.

3.2. Tekst poetycki

Nasz drugi przykład pokazuje jeden z "Sonetów krymskich" Mickiewicza:

<lg type="sonnet">  <head>Stepy akermańskie</head>  <lg type="stanza">   <l>Wpłynąłem na suchego przestwór oceanu,</l>   <l>Wóz nurza się w zieloność i jak łódka brodzi,</l>   <l>Śród fali łąk szumiących, śród kwiatów powodzi,</l>   <l>Omijam koralowe ostrowy burzanu.</l>  </lg>  <lg type="stanza">   <l>Już mrok zapada, nigdzie drogi ni kurhanu;</l>   <l>Patrzę w niebo, gwiazd szukam przewodniczek łodzi;</l>   <l>Tam z dala błyszczy obłok? tam jutrzenka wschodzi?</l>   <l>To błyszczy Dniestr, to weszła lampa Akermanu.</l>  </lg>  <lg type="stanza">   <l> Stójmy! — Jak cicho! — Słyszę ciągnące żurawie,</l>   <l>Których by nie dościgły źrenice sokoła;</l>   <l>Słyszę, kędy się motyl kołysa na trawie,</l>  </lg>  <lg type="stanza">   <l>Kędy wąż śliską piersią dotyka się zioła.</l>   <l>W takiéj ciszy — tak ucho natężam ciekawie,</l>   <l>Że słyszałbym głos z Litwy. — Jedźmy, nikt nie woła!</l>  </lg> </lg>

Ponownie, znakowanie to dotyczy jedynie struktury sonetu: wskazuje poszczególne wersy, z których jest zbudwany tekst, zaznacza początki i końce zwrotek. Ponieważ linie zostały odpowiednio oznakowane, a nie są traktowane jako akapity czy jakieś szczególne formatowanie tekstu, możliwe jest automatyczne wygenerowanie analizy metrycznej wiersza.

Figure 1. Stepy akermańskie

3.3. Tekst sztuki

Nasz trzeci przykład pokazuje, jak można oznakować strukturę tekstu dramatycznego: w tym przypadku fragmentu Szewców Witkiewicza.

<div type="scene"> <!-- ... -->  <sp>   <speaker>II CZELADNIK</speaker>   <p> Takeście to mądrze rzekli, że nawet to wstrętne „hej” mnie nie raziło.      Przebaczyłem wam. Ale więcej tego nie róbcie — niech was ręka Boska broni. </p>  </sp>  <sp>   <speaker>SAJETAN </speaker>   <p>    <stage>/ nie zwracając na to uwagi /</stage>   </p>   <p> A to jest najgorsze, że praca nigdy nie ustanie, bo się nie cofnie ta, psiamać,      machina społeczna. Ta będzie tylko pociecha, że wszyscy jako jeden wstrętny mąż, z      zapamiętaniem nieprzytomnym orać będą, że nie będzie nawet takich próżniaków… </p>  </sp>  <sp>   <speaker> I CZELADNIK</speaker>   <p>    <stage> / domyślnie / </stage>   </p>   <p> Tych na naczelnych stanowiskach kontrolnych? </p>  </sp> </div>

W znakowaniu tym wprowadziliśmy kilka elementów TEI umożliwiających odróżnienie didaskaliów (<stage>) od poszczególnych wypowiedzi postaci (<sp>). Warto zauważyć, że didaskalia mogą się pojawić zarówno w środku wypowiedzi, jak i pomiędzy nimi, i że wypowiedź zawsze zawiera jednocześnie etykietę mówcy (<speaker>) i akapit zawierający jego słowa (<p>). W dramacie wierszowanym oczywiście wypowiedzi zawierałyby sekwencje elementów <l>.

3.4. Pocztówka

TEI jest powszechnie wykorzystywane do znakowania publikowanych tekstów literackich i formalnych. Jednakże można go użyć także do zupełnie innych rodzajów dokumentów, takich jak rękopisy, dokumenty archiwalne czy jakikolwiek inny rodzaj tekstu nieformalnego. Nasz czwarty przykład pokazuje, jak można za pomocą TEI oznaczyć strukturę poniższej pocztówki:

Pocztówka (rewers)
Figure 2. Pocztówka (rewers)

Każda pocztówka posiada dwie strony: awers i rewers. Można to odzwierciedlić za pomocą elementów <div>. Na pokazanej wyżej stronie widoczne jest jasne rozróżnienie pomiędzy częścią zawierającą wiadomość, znajdującą się po lewej stronie, a częścią dotyczącą wysyłki kartki, zawierającą różne pieczątki, znaczek i adres. Oto jedno z możliwych znakowań, w którym wykorzystane zostały te same elementy <div> oraz <p>, które widzieliśmy już powyżej, wraz z kilkoma bardziej specjalistycznymi elementami i atrybutami.

<div type="verso">  <div type="message">   <p>You should try this place. You can see how genteel it is</p>   <p> Hope you enjoyed Wales, as they said to Mrs Fitzherbert</p>   <signed>Mama</signed>  </div>  <div type="destination">   <ab>    <stamp type="publicity">Silhouette of vintage car and slogan <mentioned>Brighton          &amp; Hove all set for the seventies.</mentioned>    </stamp>    <stamp type="postmark">Circular mark specifying <mentioned>Brighton &amp; Hove          - Sussex</mentioned> and <date when="1970-10-26">26 Oct 1970</date>    </stamp>    <stamp type="postage"> Machin design. 4d, vermillion. </stamp>   </ab>   <address>    <addrLine>Mr Louis Burnard</addrLine>    <addrLine>4 Freeland Cottages,</addrLine>    <addrLine>Stanton St John</addrLine>    <addrLine>OXFORD</addrLine>   </address>  </div> </div>

Element <signed> otaczający blok z podpisem jest jednym ze specjalnych elementów przewidzianych w TEI do takich danych jak podpisy czy nagłówki, które mogą pojawić się na początku lub końcu <div>. Wydaje się, że warto je oddzielić od reszty wiadomości, ponieważ inne frazy, takie jak ‘pozdrowienia’ czy formules de politesse zawierają inne, bardziej formalne formy stylistyczne niż reszta tekstu.

W kolejnej części zostały zaznaczone trzy różne formy znaków: znaczek pocztowy, pieczęć z datą i miejscem wysłania pocztówki oraz dodatkowy znaczek reklamujący rajd zabytkowych samochodów. Element <stamp> powinien zawierać tekst opisujący każdy rodzaj pieczęci; kiedy w opisie pojawiają się słowa będące rzeczywistym elementem tejże pieczęci, używamy elementu <mentioned>. W przypadku znaczka pocztowego wyróżniona została też data. W przypadku znacznej części badań nad znakowanymi archiwaliami tego typu będziemy chcieli wyszukiwać i grupować pocztówki zgodnie z ich datą wysłania. Daty pojawiające się na znaczkach pocztowych są zwykle zapisane w różny sposób i mogą być niekompletne: z tego powodu do oznakowanej daty dodaje się jej znormalizowaną wartość, korzystając z atrybutu when. Natomiast adres, pod który została wysłana pocztówka, został podany z uwzględnieniem podziału na linie.

W bardziej szczegółowym znakowaniu prawdopodobnie wyróżnione zostałyby nazwiska osób i nazwy miejscowe, możliwie z podaniem ich lokalizacji. Moglibyśmy chcieć dodać jakieś wyjaśnienie do żarciku na temat ‘Walii’. Prawdopodobnie chcielibyśmy wyróżnić skonwencjonalizowane fragmenty wiadomości, takie jak rozpoczęcie czy zakończenie. Moglibyśmy też rozważać, jak dokładnie odnotować informacje wydrukowane na odwrocie pocztówki ― takie jak na przykład nazwa wydawcy. Zakres metadanych zawierających użyteczne informacje na temat produkcji i wykorzystania pocztówki jest bardzo szeroki i czasem trudno stwierdzić, w którym miejscu skończyć. Na przykład żółta plama widoczna na skanie sugeruje, że niniejsza pocztówka została do czegoś przymocowana za pomocą taniej taśmy samoprzylepnej. Gdyby był to bardzo rzadki obiekt historyczny, taki ślad mógłby mieć znaczącą wartość i powinien byłby zostać oznakowany na przykład za pomocą elementu <damage>.

3.5. Minimalny ustrukturyzowany tekst

Na koniec, jeśli to wszystko wydaje się zbyt rozbudowane, wart zwrócić uwagę także na to, że TEI wspiera też bardzo proste spojrzenie strukturalne, w którym wszystkie te konwencjonalne, obciążone semantycznie składniki takie jak akapity, mówcy, wersy itp. są opuszczone albo zignorowane na rzecz neutralnej segmentacji opartej o ortograficznie zdefiniowane zdania. Przy takim podejściu możemy zdecydować się na utrzymanie głównego podziału tekstu, a dalej podzielić go jedynie na wygodne językoznawczo segmenty po każdym odpowiednim znaku interpunkcyjnym, korzystając z ogólnego elementu <s> (segment) oraz elementów <ab> (blok anonimowy). Powtaórzmy nasz pierwszy przykład:

<body xml:lang="en">  <div type="section">   <ab>    <s n="1">Wstęp</s>    <s n="2">Zalecamy wykorzystywanie znakowania TEI jako sposobu reprezentowania tekstów        naukowych. </s>    <s n="3">Rozwiązanie to ma wiele zalet praktycznych:</s>    <s n="4">Znakowanie TEI jest łatwe;</s>    <s n="5">Znakowanie TEI jest dość powszechnie zrozumiałe;</s>    <s n="6">Znakowanie TEI łatwo się konwertuje na inne formaty.</s>    <s n="7">Znakowanie TEI posiada także pewne zalety naukowe, które omówimy w części    <ptr target="#SEC3"/>.</s>   </ab>  </div> </body>

Chociaż takie znakowanie oczywiście nie zawiera informacji dostępnych w bogatszej wersji, która została zaprezentowana wcześniej, więc jest tym samym zasadniczo mniej użyteczne, jego prostota i regularność powoduje, że jest dużo łatwiejsze do wykorzystania przy takich stosunkowo mechanicznych zadaniach, jakimi są np. analiza słownictwa czy wzbogacenie leksykalne. Jak zawsze, aby wydobyć to, co najlepsze w TEI, trzeba dokładnie przemyśleć swoje priorytety, zanim podejmie się decyzje w sprawie znakowania.

3.6. Teksty złożone

Tekst oznakowany w TEI może być prosty (np. pojedyncza książka) albo złożony (np. zbiór albo antologia). W obu wypadkach główna część tekstu może zostać poprzedzona lub zakończona dodatkowymi elementami (strona tytułowa, wstępy, dedykacje, indeksy itp.). TEI zakłada wprowadzenie obowiązkowego elementu <body> dla głównej części tekstu oraz opcjonalnych elementów <front> i <back> służących do pogrupowania odpowiednio dodatkowych partii poprzedzających lub kończących główną część tekstu. W tekście złożonym część główna jest reprezentowana za pomocą elementu group, który może zawierać kilka elementów <text> albo ich grupy, tak jak w następującym schemacie:

<TEI xmlns="http://www.tei-c.org/ns/1.0">  <teiHeader> <!--[ nagłówek tekstu złożonego ]-->  </teiHeader>  <text>   <front> <!--[ części wstępne tekstu złożonego ]-->   </front>   <group>    <text>     <front> <!--[ część wstępna pierwszego tekstu ]-->     </front>     <body> <!--[ część główna pierwszego tekstu ]-->     </body>     <back> <!--[ zakończenia, aneksy, dodatki do pierwszego tekstu ]-->     </back>    </text>    <text>     <front> <!--[ część wstępna drugiego tekstu ]-->     </front>     <body> <!--[ część główna drugiego tekstu ]-->     </body>     <back> <!--[ zakończenia, aneksy, dodatki do drugiego tekstu ]-->     </back>    </text> <!--[ kolejne teksty proste lub złożone ]-->   </group>   <back> <!--[ zakończenia, aneksy, dodatki do tekstu złożonego ]-->   </back>  </text> </TEI>

Schemat tego typu może być odpowiedni do znakowania planowanej antologii wierszy wielu autorów opracowanych przez jednego redaktora.

W modelu tym jest tylko jeden nagłówek TEI dla całego tekstu złożonego. TEI pozwala również na stworzenie tekstu złożonego, który stanowi zbiór pierwotnie samodzielnych dokumentów, które osoba znakująca połączyła w jakimś celu. Typowym przykładem tego typu tekstów złożonych są korpusy językowe. Każdy dokument wchodzący w skład korpusu ma swoje własne metadane zapisane za pomocą nagłówka TEI, jednak jest też dodatkowa warstwa metadanych odnosząca się do korpusu jako całości i ta jest zapisana w TEI w sposób następujący:

<teiCorpus xmlns="http://www.tei-c.org/ns/1.0">  <teiHeader> <!--[metadane całego korpusu]-->  </teiHeader>  <TEI>   <teiHeader> <!--[metadane pierwszego tekstu w korpusie]-->   </teiHeader>   <text> <!--[pierwszy tekst korpusu]-->   </text>  </TEI>  <TEI>   <teiHeader> <!--[metadane drugiego tekstu w korpusie]-->   </teiHeader>   <text> <!--[drugi tekst korpusu]-->   </text>  </TEI> </teiCorpus>

Struktura tego typu byłaby odpowiednia do znakowania stworzonego zbioru pocztówek albo innych niezależnych obiektów tekstowych.

4. Róg obfitości TEI; część pierwsza

W tym i następnym rozdziale zostaną omówione elementy zdefiniowane przez pełne TEI. Elementy opisane w niniejszym rozdziale mogą okazać się użyteczne w niemal każdym typie projektu dotyczącego znakowania, podczas gdy te omówione w kolejnym są bardziej fachowe. Należy podkreślić, że naszym celem jest zdanie sprawy z bogatej różnorodności oferowanej przez TEI, a pełnej informacji należy zawsze szukać we Wskazówkach TEI.

4.1. Słupki kilometrowe

Powyżej zostało napisane, że TEI jest najczęściej wykorzystywane przy reprezentacji podziału książki na rozdziały, akapity itp. czy też wiersza na wersy i zwrotki. Jednak książki i wydrukowane wiersze są też obiektami fizycznymi, które są zwykle złożone z kartek posiadających awers i rewers. Dlaczego TEI nie oferuje elementu <page> do reprezentacji poszczególnych kartek książki? Czy na pewno to, na której stronie zaczyna się zdanie jest tak samo ważne, jak to, że jest ono w piątym akapicie drugiego rozdziału dziewiątej części publikacjia? Na pewno chcielibyśmy wyświetlać tekst na ekranie podzielony na strony tak, jak w tekście źródłowym?

Odpowiedź na te zupełnie uzasadnione pytania jest być może zaskakująco złożona. Właściwie TEI zawiera element umożliwiający zaznaczenie granic stron (<pb>), ale jest to pusty element, który powinien zostać umieszczony na początku tekstu transkrybowanego z poszczególnych stron:

<body xml:lang="en">  <pb n="42"/>  <p>Akapit ten zaczyna się na stronie numer 42... <!-- tutaj dużo tekstu -->   <pb n="43"/> <!-- jeszcze sporo tekstu tutaj -->... i kończy się w połowie strony numer 43.</p>  <p>Ten o wiele krótszy akapit zaczyna się i kończy na stronie 43. </p> </body>

Krótka analiza powyższego przykładu może pomóc w wyjaśnieniu, dlaczego nie może zostać tu wykorzystany element <page>, który otacza cały tekst na stronie (w przeciwieństwie do pustego elementu <pb>, który jedynie wskazuje początek strony). W XML i podobnych językach znakowania koniecznym wymogiem jest to, by znaczniki były odpowiednio zagnieżdżone w stosunku do siebie. Jeśli zaczniemy od elementu <page>, a następnie rozpoczniemy element <p>, składnia tego języka będzie wymagać od nas zamknięcia tego <p> przed otwarciem <page>, nawet jeśli, jak to znamy z życia, akapity często przekraczają granice stron.

Użytkownicy XML (a wcześniej SGML) przez dekady próbowali znaleźć lepsze sposoby reprezentacji struktury tekstowej by uniknąć tego ograniczenia i nie mamy planu dyskutować tu na temat ‘problemu zachodzenia na siebie’. Zauważmy po prostu, że przyjęty w TEI sposób zajmowania się tym problemem przyjął formę znaczników w postaci tzw. ‘słupków kilometrowych’, z których najczęściej spotykanym jest prawdopodobnie pokazany przykład <pb>. Podczas gdy normalne znaczniki w dokumencie XML wskazują początek i koniec elementu i w ten sposób zawsze coś otaczają, znacznik będący słupkiem kilometrowym zwyczajnie wskazuje punkt, od którego coś sie zmienia, ale niczego nie otacza. Słupek kilometrowy nr 42 na drodze z Londynu do Bath wskazuje punkt, w którym zaczyna się czterdziesty drugi odcinek tej drogi. Możemy spodziewać się, że jeśli będziemy nadal kierować się po tej drodze, dotrzemy do słupka kilometrowego numer 43, który będzie wskazywać punkt, w którym zaczyna się odcinek czterdziesty trzeci tej drogi, a tym samym (jako że droga nie może być w dwóch odcinkach jednocześnie) punkt, w którym kończy się czterdziesty drugi odcinek, choć nie jest wyraźnie zaznaczony.

Element <lb> (podział linii), <cb> (podział kolumny) oraz <gb> (podział strony) są słupkami kilometrowymi w tym znaczeniu. Na dodatek TEI oferuje też element <milestone>, który może zostać wykorzystany do zaznaczenia jakiejkolwiek jednostki nieposiadającej innego znacznika. Na przykład weźmy pod uwagę częstą w XIX wieku praktykę drukowania powieści w odcinkach. Możemy chcieć zaznaczyć granice konkretnej części, chociaż niekoniecznie odpowiada to dobrze wewnętrznej organizacji powieści będącej zbiorem rozdziałów (Dickens, na przykład, potrafił kończyć rozdział w kulminacyjnym momencie). Można tu wykorzystać znacznik milestone unit='serialPart' n='12'/, który może wyznaczyć punkt, w którym zaczyna się ‘serialPart’ numer 12, niezależnie od struktury elementów <div> i <p> wykorzystanych do samego tekstu.

Ten ogólny element może oczywiście zostać wykorzystany do opisu jakiegokolwiek przesunięcia, nie tylko w przypadku jednostek strukturalnych. Analiza narratologiczna może zostać zaprezentowana w ten sposób, że elementy <milestone> będą wskazywać miejsca, w których zmieniają się formy narracji; w analizie stylistycznej można wykorzystać je to zaznaczania miejsc zmian stylistycznych. Są też inne konkretne elementy, które zachowują się w sposób podobny do słupków kilometrowych np. przy zaznaczaniu zmian w jakości dźwięku przy transkrybowaniu mowy czy zmian ręki przy transkrybowaniu rękopisów.

4.2. Języki i pismo

O ile nie jest to pusty słupek kilometrowy, każdy element w dokumencie TEI może zawierać czysty tekst albo tzw. ‘zawartość elementu’, albo (zdecydowanie częściej), tzw. ‘zawartość mieszaną’. Czysty tekst składa się ze znaków zapisanych w standardzie Unicode; zawartość elementu składa się z innych elementów XML, a zawartość mieszana łączy oba poprzednie. Do powiązania semantycznych i innych właściwości z zawartością tak, by oprogramowanie mogło zajmować się nimi w różnych sytuacjach, służą elementy TEI i atrybuty. Szczególnie ważną własnością jest język ludzki, za pomocą którego wyrażona jest zawartość tekstowa; inną jest sposób wyświetlania lub formatowania tej zawartości. Właściwości te są potencjalnie ważne na prawie każdym poziomie: możemy chcieć powiedzieć, że cały dokument wykorzystuje konkretny język albo że jedynie kilka słów tu i ówdzie; możemy chcieć powiedzieć, że cały dokument został wydrukowany krojem prostym danej wielkości, a następnie wskazać te fragmenty, które zostały wydrukowane innym krojem albo zastosowano inną wielkość. Ponieważ taka informacja może potencjalnie pasować do każdego elementu, TEI proponuje do tego atrybuty globalne.

4.2.1. Języki

Zalecanym sposobem podawania informacji o tym, w którym z języków naturalnych wyrażony jest dany element, jest stosowanie globalnego atrybutu xml:lang. (Jak wskazuje prefiks xml:, atrybut ten jest typowy dla wszystkich dokumentów XML: nie został zdefiniowany przez TEI, ale przez W3C, jako część definicji XML). Wartość tego elementu stosuje się hierarchicznie do wszystkich elementów zawartych w tym elemencie, o ile nie zostanie unieważniona:

<div xml:lang="la">  <s>Pars haec lingua Latine composita est.</s>  <s xml:lang="pl">Oprócz tego zdania po polsku.</s>  <s>Vita brevis, ars longa.</s> </div>

Zaznaczamy tutaj, że cały element <div> wykorzystuje język z zakodowanym identyfikatorem ‘la’, czyli łacinę (kody pochodzą ze standardu ISO 639 dla identyfikatorów jezykowych). W pierwszym elemencie <s> nie trzeba dodawać znów tej informacji, ponieważ zawiera się w elemencie <div>. Jednakże drugi element <s> unieważnia tę wartość i wskazuje, że jego zawartość jest zapisana po polsku (język z identyfikatorem pl). Zawartość trzeciego elementu <s> jest znów po łacinie. Żeby określić język dla jakiejś zawartości elementu, procesor musi sprawdzić, czy dany element (lub jego rodzice) zawiera wartość dla xml:lang. Jak można się spodziewać, jeśli jest ich więcej niż jeden, jest to najbliższy rodzic. Załóżmy dla przykładu, że drugie zdanie powyżej zawiera też frazę po francusku. Fraza ta będzie musiała oczywiście zostać oznaczona za pomocą jakiegoś elementu. Tam, gdzie chcemy po prostu pokazać, że dana część zawartości wykorzystuje inny język, stosujemy element <foreign>:

<div xml:lang="la">  <s>Pars haec lingua Latine composita est.</s>  <s xml:lang="pl">Oprócz tego <foreign xml:lang="fr">sacrebleu</foreign> to zdanie    jest po polsku.</s>  <s>Vita brevis, ars longa.</s> </div>

Kody użyte do identyfikacji języków mogą (tak jak tutaj) być standardowymi dwuliterowymi kodami; do rozróżniania takich rzeczy jak warianty geograficzne lub socjalne albo w przypadku języków zapisywanych różnymi alfabetami wykorzystywane są kody bardziej złożone. Kody te, oraz sposoby ich użycia, są zdefiniowane w ISO, a nie w TEI, dlatego nie będziemy o nich więcej mówić.

4.2.2. Znaki niestandardowe

Powyżej zwróciliśmy uwagę na to, że dokument TEI jest dokumentem XML, dlatego jest zapisywany znakami w standardzie Unicode. Standard ten (w momencie pisania) umożliwia zapis bardzo wielu istniejących i historycznych systemów pisma, ale własciwie nie ma na celu standaryzowania systemów pisma w trakcie analizy czy definiowana, ani nie ma na celu zaoferowania kodów na wszystkie znaki czy glify możliwe do zaobserowania w dokumentach historycznych. Z tego powodu TEI zawiera element <g>, który może zostać wykorzystany do zaznaczenia obecności w dokumencie znaku lub glifu, dla którego w istniejącym standardzie Unicode nie ma odpowiedniej wartości.

Załóżmy, że zajmujemy się zbiorem rękopisów zawierających szczególnie nietypowy wariant jakiejś litery (powiedzmy R); nasza traksrypcja TEI może odzróżniać ten wariant glifu od zwykłej formy tej samej litery poprzez wykorzystanie elementu <g> do zaznaczenia tego pierwszego. Zawartość elementu <g> może być po prostu formą znormalizowaną albo element może pozostać pusty; w oby wypadkach będzie zawierać atrybut ref odsyłający do elementu <glyph>, w którym zdefiniowaliśmy naturę, funkcję, wygląd, nazwę itp. tego wariantu. Stąd, zakładając, że zidentyfikowaliśmy i opisaliśmy trzy warianty form litery R, dając im identyfikatory R1, R2, R3, możemy przedstawić indywidualne pojawienia się tych form jako g ref='#R1'/, g ref='#R2'/ lub g ref='#R3'/. Powiązane definicje mogą zostać dołączone za pomocą elementu <charsDecl> w Nagłówku TEI, tak jak zostało to opisane poniżej w 6. Nagłówek TEI.

4.3. Renderowanie (wizualizacja)

Termin renderowanie jest wykorzystywany w kontekście TEI do opisania sposobu, w jaki element jest formatowany lub prezentowany na ekranie lub stronie. TEI nie jest systemem edycji tekstów, i (jak pokazaliśmy powyżej) zasadniczo ma na celu umożliwienie znakowania bardziej wiernego znaczeniu tekstu niż oddawanie jego aktualnego czy planowanego wyglądu. Jest to jeden z wielu aspektów, które odróżniają TEI od systemów typowo wykorzystywanych do edycji tekstów, na co już zwracaliśmy wcześniej uwagę. Niemniej, biorąc pod uwagę, że może być ważne pozostawienie informacji o oryginalnym wyglądzie dokumentu do celów analizy (zwłaszcza, że wygląd może być jedyną rzeczą, którą możemy wiarygodnie opisać w przypadku dokumentu historycznego), TEI oferuje pewne mechanizmy umożliwiające znakowanie takich danych. Podkreślamy ponownie, że funkcją takiego znakowania jest zawsze opis wyglądu jednego lub lub więcej dokumentów źródłowych; oczywiście możliwe jest, że wyświetlając tekst oznakowany w ten sposób będziemy chcieli osiągnąć podobną formę, używając innej technologii, ale to niekoniecznie i nie zawsze jest naszym celem.

Najprostszą metodą jest zastosowanie globalnego atrybutu rend. Atrybut ten zachowuje się w sposób podobny do atrybutu xml:lang omówionego powyżej: dostarcza zakodowaną wartość dla wyglądu związanego z elementem i jego dzieci (o ile nie zostanie unieważniony). Jednak w przeciwieństwie do xml:lang, wartości, które mogą zostać użyte z atrybutem rend, nie są formalnie zdefiniowane ani przez TEI, ani przez inną instancję, chociaż zwyczajowo wykorzystywana jest stosunkowo niewielka liczba kodów. Znakujący może stworzyć swój własny zestaw etykiet i stosować je konsekwentnie (lub niekonsekwentnie) tak, jak chce.

Atrybut rendition dla odmiany, zachowuje się bardziej jak atrybut ref w przypadku <g>, jako że odnosi się do definicji (lub zestawu definicji) podanych w innym miejscu; osoba znakująca jest więc zmuszona do wykorzystywania tylko konkretnego zestawu etykiet dotyczących wyglądu oraz do dostarczenia jakiejś definicji dla każdej z etykiet albo odesłania do takiej definicji w innym miejscu.

Takie ‘definicje stylu’ oczywiście najłatwiej wyrazić za pomocą języka znakowania zaprojektowanego dla oprogramowania formatującego, takiego jak przeglądarki internetowe czy edytory dokumentów. TEI pozwala na zapisywanie definicji w którymkolwiek z takich języków; obecnie najbardziej praktyczna jest przyjęta rekomendacja W3C zwana CSS (Cascading Stylesheets), ponieważ daje wiele możliwości i powszechnie stosowana. Składnia tego języka jest bardzo prosta i może być nawet wykorzystywana bezpośrednio w dokumencie TEI, czy to do podania domyślnego wyglądu dla danego elementu, czy to do unieważnienia domyślnego wyglądu za pomocą kolejnego atrybutu globalnego style.

Pokażemy, jak te metody mogą zostać wykorzystane do oznakowania następującego krótkiego fragmentu wziętego z podręcznika z początku XVII wieku.

Fragment z  Henry'ego Care'a (1687), s.
              70.
Figure 3. Fragment z The tutor to true English Henry'ego Care'a (1687), s. 70.

We fragmencie tym możemy zobaczyć sekwencję słów zapisaną fakturą, krojem prostym i kursywą. Możemy spekulować na temat powodów tego zróżnicowania typograficznego, ale zakładając, że przynajmniej na początku naszym celem jest po prostu zapisanie tego, możemy przyjąć następujące znakowanie:

<p rend="roman">  <lb/>And here note, for a Caution against <hi rend="italic">Extrava-<lb break="no"/>gance</hi>, and for encouragement to <hi rend="italic">Frugality</hi> and <lb/>good Husbandry in all People, especially <hi rend="italic">Youth</hi>, </p> <p rend="gothic">  <lb/>That <hi rend="roman">every Penny</hi> any Person spends <lb/>idly, would purchase a <hi rend="roman">Yard</hi> (that is three <lb/>foot) square, and somewhat above, of as <hi rend="roman">   <lb/>good Land</hi> as most in England, to <hi rend="roman">him <lb/>and his Heirs    for ever.</hi> </p>

Znakowanie to wykorzystuje słupek kilometrowy <lb> do wyraźnego zaznaczenia, gdzie rozpoczynają się linie typograficzne. Wykorzystuje też nowy element <hi> (podkreślenie). Element ten nie ma konkretnego znaczenia - po prostu wskazuje, że jego zawartość jest wizualnie różna od tego, co ją otacza, mniej więcej w ten sam sposób, jak element <foreign> po prostu wkazuje, że jego zawartość jest językowo inna od tego, co ją otacza. Natura tego wizualnego odróżnienia nie jest w pełni opisana, ponieważ znakowanie to nie wyjaśnia, co znaczą wartości roman, italic czy gothic ani nie ma tu możliwości podania takiego wyjaśnienia inaczej niż w postaci przypisu. Oczywiście, czytelnik będzie mniej więcej wiedział, co znaczy italic, ale program renderujący raczej nie. Załóżmy, że przygotowaliśmy definicje (wyrażone w CSS) w odpowiednim miejscu Nagłówka TEI przeznaczonym do tego celu:

<rendition xml:id="itscheme="css">font-family: roman; font-style: italic</rendition> <rendition xml:id="roscheme="css">font-family: roman; font-style: normal</rendition> <rendition xml:id="goscheme="css">font-family: unifraktur cursive</rendition>

Dzięki tym definicjami w tym miejscu moglibyśmy teraz nieznacznie uprościć nasz przykład:

<p rendition="#go">That <hi rendition="#ro">every Penny</hi> any Person spends idly ...</p>

Każdy program renderujący może obecnie bezpośrednio przetwarzać CSS i wyświetlać nasz tekst sposób charakterystyczny wizualnie.

Ponadto, ponieważ wyrażenia CSS są dość proste, możemy użyć atrybutu style do podania ich bezpośrednio w naszym tekście:

<p style="font-family: roman">And here note, for a Caution against <hi style="font-style:italic">Extravagance</hi>, and for encouragement to <hi style="font-style:italic">Frugality</hi> ...</p>

Zwróciliśmy wyżej uwagę, że element <hi> nie ma żadnego znaczenia poza wskazywaniem, że jakaś część znakowanego dokumentu wygląda pod jakimś względem znacząco inaczej. W wielkich projektach oznaczanie takich różnic może być jedyną wykonalną rzeczą; w projektach dotyczących bardzo starych, wizualnie skomplikowanych albo prawie niezrozumiałych źródeł, może być trudno wyjść poza stwierdzenie, że ‘ta część tekstu jest wizualnie inna w pewien sposób’. Jednak dla znaczącej większości projektów TEI zwykle pożądane i wykonalne jest wzbogacenie znakowania wskutek zastanowienia się, dlaczego coś jest wizualnie znaczące w teksćie. Tam, gdzie odpowiedź na to pytanie może zostać uzyskana z jakimś stopniem pewności, znakowanie pokazujące, co było motywacją dla oryginalnej decyzji co do wygladu, jest raczej bardziej użyteczna niż takie, które tego nie pokazuje.

Nietrudno wymienić główne powody, dla których drukarz mógł zdecydować się, by podkreślić pewne słowa w tekście wydrukowanym zgodnie z zasadami wypracowanymi w Europie Zachodniej w ciągu ostatnich 300 lat. Często tak wyróżniane są słowa obcojęzyczne oraz te, które autor jakoś podkreślił lingwistycznie. Zwykle podkreślane są też tytuły i terminy techniczne, gdy pojawiają się w zwykłym tekście. Do niedawna traktowane tak były też nazwy osobowe, miejscowe oraz abstrakcyjne.

Zwróćmy uwagę, że wykorzystujemy tu termin podkreślony w odniesieniu do każdej formy wizualnego uwydatnienia, czy to jest fragment zapisany kursywą otoczony przez krój prosty, czy (jak wyżej) fragment zapisany krojem prostym w tekście z dominującą frakturą. Jeśli rozszerzymy znaczenie tego terminu tak, by włączyć tu też fragmenty wyróżnione różnego rodzaju cudzysłowami, lista powodów do podkreślenia rozszerzy się tak, że będzie zawierała fragmenty w mowie niezależnej, materiał cytowany albo taki, który pisarz chciał zaznaczyć jako w jakimś sensie nieautorski, czy też nieużywane, ale omawiane słowa itd.

TEI zawiera elementy, które umożliwiają znakującemu robienie wszystkich tych oraz innych rozróżnień semantycznych pomiędzy słowami tekstu, w oparciu o wizualne wskazówki widoczne w oryginalnym wyglądzie dokumentu, a także to, jak znakujący go rozumie. Jest to często użytecznym sposobem odróżniania w innym wypadku wieloznacznego fragmentu tekstu. We współczesnym artykule w gazecie, na przykład, fragment zapisany kursywą może być wyrażeniem obcojęzycznym, tytułem innego artykułu, filmu albo piosenki, terminem technicznym albo frazą, którą autor chce zaakcentować. Za pomocą odpowiedniego znacznika (odpowiednio <foreign>, <title>, <term> czy <emph>) znakujący wzbogaca tekst i ułatwia bardziej wyrafinowane przetwarzanie, na przykład polegające na wyszukaniu tytułów prac wspomnianych w dokumencie, z wykluczeniem słów obcojęzycznych czy zaakcentowanych.

Znaczniki te mogą być oczywiście też wykorzystane wtedy, gdy nie zostało zastosowane żadne podreślenie. W przypadku wszystkich tych elementów dostępny jest atrybut rend, w związku z czym znakujący może określić, co powinno zostać podkreślone i pod jakim względem (jeśli w ogóle) jest to wizualnie uwydatnione.

4.4. Nazwy i daty

Zwrócilismy powyżej uwagę na konwencję polegającą na podkreślaniu nazw osobowych, miejscowych itp. w tekstach drukowanych. Praktyka ta, która była powszechna do połowy XIX wieku, świadczy o tym, że część czytelników potrzebowała, by jasno odróżniać nazwy od innych słów. Jest to też ważne współcześnie dla osób znakujących teksty cyfrowe. Odróżnianie od pozostałych słów tego, co jest często określane jako ‘jednostki nazwane’, jest tak ważnym zadaniem dla współczesnych lingwistów komputerowych budujących systemy służące do rozpoznawania języka, czy też współczesnych historyków cyfrowych badających związki społeczne w korpusach korespondencji osiemnastowiecznej, tak jak jest dla dzisiejszych służb wywiadowczych poszukiwanie w ogromnych zbiorach danych odniesień do podejrzanych o terroryzm.

TEI zawiera pewne elementy umożliwiające znakowanie takich obiektów, gdy już zostały zidentyfikowane. Najogólniejszym jest prawdopodobnie <rs> (skrót od ‘referring string’, czyli odniesienie), który może zostać wykorzystany do oznakowania każdej sekwencji słów uznanej przez znakującego za taką, która odnosi się do obiektu będącego osobą lub miejscem, nawet jeśli forma nie pochodzi od tej nazwy, ale jest raczej odnośnikiem zaimkowym (‘ona’, ‘król’) albo frazą wskazującą (‘ta dziewczyna’, ‘facet, którego zobaczyliśmy w czwartek’), czy idiomem (‘Wielkie Jabłko’). Jednak jeśli odnośnik tego typu zawiera co najmniej jedną nazwę własną, powinien zostać oznakowany za pomocą ogólnego elementu <name>.

Oba elementy <rs> i <name> mają atrybut type, który może zostać wykorzystany do odróżnienia rodzaju jednostki nazwanej, w związku z czym, na przykład miejsce <name type="place">Moskwa</name> może zostać odróżnione od osoby o nazwisku <name type="person" >Moskwa</name>. Jednakże TEI zawiera także specjalne znaczniki umożliwiające dokonanie tego samego rozróżnienia oraz innych z większą precyzją. Te bardziej wyspecjalizowane elementy odróżniają nazwy, które odnoszą się jawnie do różnych jednostek: stąd mamy <persName> (nazwa osobowa), <placeName> (nazwa miejscowa), <orgName> (nazwa instytucji), w przypadku których jesteśmy pewni, że nazwa odnosi się do osoby, miejsca czy organizacji. Dodatkowe znaczniki pozwalają nam na zidentyfikowanie znaczących składników takich nazw: stąd mamy <surname> (nazwisko), <foreName> (imię), <altName> (dla nazw alternatywnych, np. pseudonimów), <roleName> (dla społecznie zdefiniowanych ról lub tytułów takich jak ‘Lady’, ‘Proboszcz’, etc.), <genName> (dla nazw generacyjnych takich jak ‘Junior’, ‘starszy’, etc.) i inne. W przypadku nazw miejscowych TEI odróżnia elementy określające nazwę socjopolitycznie, takie jak <settlement>, <region>, <country> oraz składniki takie jak <geogName> dla czysto geograficznych nazw takich jak ‘Góra Synaj’ czy ‘Rzeka Tamiza’, które mogą być dalej rozczłonkowane na nazwę (‘Tamiza’, ‘Synaj’) oraz nazwę jakiegoś rodzaju elementu geograficznego (‘Góra’, ‘Rzeka’).

Elementy tego rodzaju są zwłaszcza przydatne wtedy, gdy zajmujemy się dokumentami archiwalnymi, w których głównym zadaniem jest wskazanie nazw osób i miejsc, do których odwołuje się dokument, ale mogą być przydatne także przy każdej innej edycji cyfrowej lub badaniu leksykalnym.

Załóżmy, na przykład, że przygotowujemy cyfrową edycję źródła historycznego, jakim jest Current Record of Events from 1792 to 1885, As recorded by The Shaker community of Canterbury, New Hampshire (rękopis przechowywany w Zbiorach Specjalnych Biblioteki Hamilton College). Ten dziewiętnastowieczny dokument rozpoczyna się następującym zdaniem: ‘On the first of February 1792 Father Job Bishop and Elder Edmond Lougee came from New Lebanon N.Y. to organize and establish a community of Believers at Canterbury N.H.’.

Moglibyśmy być zadowoleni z odnotowania obecności nazw własnych (‘Father Job Bishop’, ‘Canterbury’ itd.) za pomocą elementów <name>:

<p>On the first of February 1792 <name>Father Job Bishop</name> and <name>Elder Edmond    Lougee</name> came from <name>New Lebanon, N.Y.</name> to organize and establish a Community of Believers at <name>Canterbury, N.H.</name> </p>

Nawet takie minimalne znakowanie ułatwia zauważenie wspomnianych tam nazw osobowych i miejscowych, a tym samym przetwarzanie ich niezależnie od reszty tekstu, np. w celu stworzenia wykazu nazw oraz połączenia tych odniesień do dalszych informacji o omawianych osobach i miejscach.

Dokładniejsze znakowanie uwydatniłoby części składowe nazw, które często łączą nazwiska (‘Bishop’, ‘Lougee’) z nazwami wskazującymi role społeczne (‘Father’, czyli Ojciec, ‘Elder’, czyli Starszy) z imionami (‘Job’, ‘Edmond’). Takie rozróżnienia mogą stać się jasne jedynie dzięki odpowiedniemu znakowaniu ― ‘Bishop’ może być funkcją (biskup) albo nazwiskiem, w zależności od kontekstu. Podobnie, w przypadku elementu <placeName> wygodnie jest odróżniać nazwę administracyjnego lub innego regionu takiego jak np. stan w USA od nazwy miejscowości (settlement) (TEI wykorzystuje ten neutralny termin zamiast innych takich jak ‘town’, ‘village’, ‘city’ itd., które są trudne do zdefiniowania poza konkretnym kontekstem).

<p>On the first of February 1792 <persName>   <roleName>Father</roleName>   <forename>Job</forename>   <surname>Bishop</surname>  </persName> and <persName>   <roleName>Elder</roleName>   <forename>Edmond</forename>   <surname>Lougee</surname>  </persName> came from <placeName>   <settlement>New      Lebanon</settlement>   <region>N.Y.</region>  </placeName> to organize and establish a Community of Believers at <placeName>   <settlement>Canterbury</settlement>,  <region>N.H.</region>  </placeName> </p>

Z definicji, nazwa odwołuje się do konkretnej jednostki (osoby lub miejsca), ale badania historyczne lub genealogiczne nie byłyby tak trudne, gdyby było to jednoznaczne i bezpośrednie. Czy ‘Edmond Lougee’ jest tą samą osobą, co ‘Edmund Lougee’ zapisany w innych źródłach? Kiedy niewiele dalej w aktualnym źródle znajdujemy wspomnienie ‘Elder Lougee’ (Lougee Starszy), możemy zakładać, że odnosi się to do tej samej osoby? Jak zawsze, TEI nie pomoże odpowiedzieć na te pytania, ale oferuje rózne sposoby przedstawienia odpowiedzi (o ile są), do których dotarliśmy.

Zaproponowanie wersji znormalizowanej dla danej nazwy było oczywiście długo zajęciem bibliotekarzy i katalogujących. W przypadku prac literackich i postaci literackich, a także współczesnych i klasycznych geografii istnieją powszechnie uznane prace będące indeksami bibliograficznymi, które stanowią użyteczny punkt odniesienia w przypadku wielu jednostek, które mogą zostać nazwane w dokumencie TEI; dla innych natomiast można znaleźć pewnego rodzaju kanoniczne informacje w innych źródłach online takich jak wikipedia czy ancestry.com. Jednym ze sposobów wyjaśnienia, którą z wielu możliwych osób jest według nas ten ‘Edmond Lougee’, mogłoby być dodanie odnośnika do dostępnego rekordu online odnoszacego się do tej osoby:

... <persName ref="http://records.ancestry.co.uk/Edmund_Lougee_records.ashx?pid=24762763"> Elder Edmond Lougee </persName> ...

Jednak, biorąc pod uwagę, że prawdopodobnie niewielka liczba osób wymienionych w takich dokumencie archiwalnym może mieć tego typu rekordy, często w przypadku takich projektów konieczne będzie stworzenie swojej własnej kartoteki, zawierającej oddzielne rekordy dla poszczególnych jednostek. TEI oferuje dodatkowe elementy, które mogą zostać wykorzystane do zapisania takich informacji z dość znaczną szczegółowością: informacja biograficzna i prozograficzna może na przykład zostać zgrupowana w ramach elementu <person>, podczas gdy informacja geograficzna może zostać zgrupowana w ramach elementu <place>; jeśli to jest już zrobione, można użyć elementu ref do wskazania takiego opisu:

<persName ref="#P1234"> Elder Edmond Lougee </persName> <!-- .... --> <person xml:id="P1234">  <p>Edmund albo Edmond Lougee urodził się w Exeter Newmarket w Rockingham, New    Hampshire w Stanach Zjednoczonych w 1731 r. jako syn Johna Lougee i Anne Gilman.    Ożenił się z Hannah Lord i miał siedmioro dzieci. Zmarł 3 czerwca 1807 r. w Loudon,    New Hampshire w Stanach Zjednoczonych.</p> </person>

Warto zwrócić uwagę, że w tym przykładzie zdecydowaliśmy się jedynie na podanie tekstowego podsumowania dostępnych informacji o Lougee Starszym w ramach odnośnego elementu <person>; mogliśmy alternatywnie ustrukturyzować je, używając fachowych elementów takich jak <birth>, <death>, <marriage>, <relation> itp.

Do celów projektu może jednak być wystarczające podanie do każdego odsyłacza arbitralnego kodu albo znormalizowanej formy imienia, może z uwzględnieniem dat albo znaczników generacyjnych, by stał się ujednoznaczniony. Służy do tego atrybut key:

<persName key="Lougee, Edmond (1731-1807)"> Edmond Lougee Starszy</persName>

Normalizacja za pomocą wartości atrybutów jest mechanizmem często występującym w TEI. Jest ona zwłaszcza użyteczna tam, gdzie coś, co wyszukiwarka lub inny procesor mogłyby preferować w konkretnym formacie, a w dokumencie pojawia się w wielu różnych formach, z których część może być interesująca lub znacząca lingwistycznie. Jeśli na przykład chcemy wydobyć z tego dokumentu wszystkie odesłania do wydarzeń występujących przed konkretną datą lub po niej, zadanie będzie o wiele łatwiejsze, jeśli te daty będą reprezentowane w sposób standardowy. W powyższym przykładzie możemy wybrać pierwszą datę w sposób następujący:

<p>  <date when="1792-02-01">Pierwszego lutego 1792</date> ... </p>

Wykorzystano tu rekomendację W3C dotyczącą formatu dat. Zastosowany tutaj atrybut when pozwala nam na powiązanie daty z konkretnym punktem w czasie. TEI oferuje ponadto zestaw innych atrybutów, które mogą zostać użyte łącznie w celu przedstawienia szeregu pojęć czasowych:

<p>  <date notAfter="1792-02-28"   notBefore="1792-02-01">W lutym 1792</date> ... </p>
<p>  <date from="1792-02-01to="1792-02-07">W pierwszym tygodniu lutego 1792</date> ... </p>

4.5. Tabele, ilustracje i bibliografie

W rzeczywistości dokument może posiadać wiele nietekstowych lub tylko częściowo tekstowych składników takich jak ilustracje czy tabele, a także elementy tekstowe, które posiadają swoją wewnętrzną strukturę, takie jak indeksy czy bibliografie. Szczególnie wtedy, gdy TEI jest wykorzystywane do znakowania nowego dokumentu, ale także wtedy, gdy istnieje potrzeba wskazania istnienia takich elementów w starszym dokumencie, znakujący musi wykorzystywać takie elementy, jak <table>, <figure> albo <bibl>, które omówimy zwięźle w następnych sekcjach.

4.5.1. Tabele

Tabela jest sposobem organizacji kilku powiązanych fragmentów informacji tekstowej za pomocą wierszy (lub kolumn) zbudowanych z komórek. Większość systemów służących do tworzenia dokumentów rozwinęła dość złożone sposoby dokładnego określania tego, jak komórki tabeli powinny zostać wyświetlone, jednak w większości nie ma tego w modelu tabeli w TEI. W systemie tym element <table> jest złożony z elementów oznaczających wiersze (<row>), z których każdy jest zbudowany z komórek (<cell>); tabela TEI nie może więc zostać w łatwy sposób reprezentowana jako zestaw kolumn. Istnieje atrybut role, który wskazuje, czy konkretny wiersz albo komórka zawiera informację etykietującą, czy dane, a także są atrybuty rows oraz cols, które mogą zostać wykorzystane do wskazania, kiedy wiersz czy komórka zajmuje więcej niż jeden wiersz czy kolumnę.

Załóżmy, że znajdujemy taką (wymyśloną) tabelę w dokumencie, który znakujemy:

Wymyślona tabela
Figure 4. Wymyślona tabela

W naszej wersji TEI możemy zapisać, że pierwsza kolumna komórek zawiera etykietę dla wpisów dla reszty każdego wiersza, oraz że komórka w trzeciej kolumnie pierwszego wiersza rozciąga się na dwie kolumny.

<table>  <row>   <cell role="label">Owoce</cell>   <cell>jabłko</cell>   <cell>banan</cell>   <cell cols="2">wiśnia</cell>   <cell>daktyl</cell>  </row>  <row>   <cell role="label">Orzechy</cell>   <cell>migdał</cell>   <cell>orzech brazylijski</cell>   <cell>kokos</cell>   <cell>orzech laskowy</cell>   <cell>pistacje</cell>  </row> </table>

4.5.2. Ilustracje

Każdy rodzaj elementu graficznego taki jak ilustracja, wykres, diagram może zostać osadzony w dokumencie, czasami jako oddzielny składnik, taki jak frontyspis czy ilustracja na oddzielnej stronie, czasem jako część jakiegoś fragmentu tekstu. Takie ilustracje zwykle zawierają nagłówki lub tytuły, możliwie powiązane z jakimś fragmentem tekstu, oraz obrazki. Żeby je oznakować, TEI oferuje element <figure>, który zwykle zawiera przynajmniej elementy <graphic> oraz <head>, choć mogą zostać wykorzystane także inne elementy tekstowe, jeśli sama ilustracja zawiera tekst.

Elementy <graphic> jest wyspecjalizowanym typem wskaźnika. Jego atrybut url odsyła do lokalizacji, w której znajduje się cyfrowa reprezentacja ilustracji. Dostępne są atrybuty scale, width oraz height, które opisują pożądany rozmiar ilustracji przy wyświetlaniu.

Rozważmy następujący przykład z "Puncha", znanego dziewiętnastowiecznego brytyjskiego czasopisma humorystycznego:

John Leech: , ilustracja w "Punch" nr 13 (lipiec
                1847), strona 14.
Figure 5. John Leech: Domestic Bliss, ilustracja w "Punch" nr 13 (lipiec 1847), strona 14.
Możemy to oznaczyć w sposób następujący:
<figure type="cartoonplace="topLeft">  <head rend="caps">Domestic Bliss</head>  <graphic url="vol13p14.png"/>  <sp>   <speaker rend="italic">Wife of your bussum</speaker>   <p rend="smallcaps">    <q>Oh! I don't want to interrupt you dear. I only want some        money for Baby's socks — and to know whether you will have the mutton cold        or hashed.</q>   </p>  </sp>  <figDesc>Wnętrze mieszkania narysowane przez Leecha, ukazujące rozczochranego    mężczyznę w koszuli nocnej siedzącego przy zasypanym papierami biurku, jego    żonę, dwoje dzieci, w tym jedno grające na bębenku, oraz kota. </figDesc> </figure>

W naszym znakowaniu tekst poniżej ilustracji został przetranskrybowany za pomocą omówionego wcześniej elementu <sp>, by pokazać, że prezentowany tekst jest częścią dialogu dramatycznego. Wykorzystaliśmy też element <figDesc>, by dołączyć dodatkowy tekst, niezapisany na ilustracji, ale dostarczający użytecznych metadanych opisowych, które mogą zostać wyświetlone zamiast elementu graficznego albo zostać wykorzystane do indeksowania jego zawartości.

4.5.3. Opisy bibliograficzne

Powszechną cechą tekstów naukowych sa opisy bibliograficzne, takie jak zwykle bibliografia czy lista odsyłaczy na końcu artykułów akademickich albo w przypisach. Wygodnie jest wyróżniać takie elementy, a zwłaszcza ich składniki (autor, tytuł, wydawca, data publikacji itp.), by były łatwiej wyszukiwalne oraz by łatwiej było je wyświetlać czy formatować na różne sposoby. W przypadku, gdy trzeba pracować z wieloma takimi odnośnikami, skuteczny sposób pracy z nimi oferują specjalistyczne narzędzia takie jak Zotero umożliwiające import i eksport danych z formacie TEI, jednakże mogą one być także traktowane w taki sam sposób jak każdy inny składnik dokumentu TEI, niezależnie od tego, czy pojawiają się w części głównej tekstu, jako oddzielna sekcja w części końcowej tekstu czy w części początkowej.

Skowencjonalizowaną praktyką w piśmiennictwie naukowym jest podawanie odnośników w postaci znormalizowanej, gdzie poszczególne elementy pojawiają się w ustalonym porządku oraz wykorzystuje się konsekwentną formę graficzną. Czy to w przypisie, czy na osobnej liście odsyłaczy, książka zostanie zwykle zapisana jako coś w rodzaju:

Cameron, D. (1995) Verbal Hygiene. London and New York: Routledge.

Znakowanie TEI może zostać wykorzystane do wskazania, która część tego zapisu jest tytułem, która miejscem publikacji itp. TEI oferuje dwa odrębne elementy do tego celu: <biblStruct> oraz <bibl>.

Element <biblStruct> oferuje ‘ustrukturyzowany’ albo zorientowany na dane wygląd wpisu bibliograficznego, w którym każda z części opisu (autor, tytuł itp.) jest oznakowana odrębnie, tak jakby była częścią bazy danych. Warto zwrócić uwagę, że interpunkcja pomiędzy składnikami nie jest dozwolona: to dlatego, że do różnych stylów bibliograficznych mogą być odpowiednie różne wizualizacje. Szczegółowe znakowanie tego typu pozwala na zrobienie tego w prosty sposób: program formatujący wybiera potrzebne elementy i ustawia je w wymaganym porządku, wstawiając pomiędzy nie znaki interpunkcyjne zgodne z wymaganym stylem.

<biblStruct xml:id="Cameron1995">  <monogr>   <author>    <surname>Cameron</surname>    <forename>Deborah</forename>   </author>   <title>Verbal Hygiene</title>   <imprint>    <publisher>Routledge</publisher>    <pubPlace>London</pubPlace>    <pubPlace>New York</pubPlace>    <date>1995</date>   </imprint>  </monogr> </biblStruct>

Element <monogr> wskazuje tu, że jest to coś, co specjaliści od bibliografii nazywają monografią, czyli pracą indywidualną, a nie analitycznym elementem, takim jak artykuł w czasopiśmie.

Element <bibl> oferuje mniej ustrukturyzowany, a bardziej zorientowany na tekst wygląd wpisu bibliograficznego, w którym dozwolone jest stosowanie interpunkcji pomiędzy znakowanymi elementami, a także tekstu ciągłego, a porządek składników nie jest ustalony. Jest to wygodne w sytuacji, gdy znakujący chce przestrzegać zasad (zwykle drukowanego) katalogu, z którego został przejęty opis albo do którego jest on przeznaczony.

Wykorzystując to, mozemy oznakować ten element w sposób bliższy wersji oryginalnej za cenę tego, że późniejsze jego przetwarzanie będzie trudniejsze:
<bibl>  <author>Deborah Cameron</author>: <title level="m">Verbal Hygiene.</title>. London, New York: Routledge.<date>1995</date> </bibl>

Większość elementów dostępnych w ramach <biblStruct> jest też dostępna (ale opcjonalnie) w ramach <bibl>, więc możliwe jest użycie ich do stworzenia szczegółowego znakowania każdego rodzaju cytatu bibliograficznego. Dalsze przykłady zamieściliśmy w sekcji 6. Nagłówek TEI poniżej.

Kiedy w tekście dokumentu znajduje się odesłanie do książki, szczególnie jeśli zdarza się to częściej niż raz, zwykle robi się to za pomocą krótkiego odsyłacza takiego jak Cameron 1995. Żeby połączyć go z pełniejszym opisem bibliograficznym, możemy wykorzystać atrybut target przy elementach <ref> lub <ptr>:
<p>Ludzie mają <q>zdrową obsesję na temat języka</q> (<ref target="#Cameron1995">Cameron 1995</ref>). Zaskakujące byłoby, gdyby nie mieli...</p>

5. Róg obfitości TEI; część druga

5.1. Zagadnienia edycyjne

Kiedy podejmuje się dygitalizację jakichś materiałów źródłowych, pierwszym priorytetem jest zwykle stworzenie dobrej jakości obrazów cyfrowych oryginalnych dokumentów źródłowych. Transkrybowanie i znakowanie tych obrazów jest drogą i trudną operacją, która nie może być bez trudu zautomatyzowana, o ile w ogóle, ale jest ważnym kolejnym krokiem w ramach tworzenia prawdziwej ‘cyfrowej edycji’. Dla umiejętnego czytelnika, obraz cyfrowy stron może być wystarczający, by źródło było użyteczne. Dla szerszej gupy czytelników jednak, a zwłaszcza do wszystkich rodzajów automatycznej analizy i przeszukiwania, koniecznym dodatkiem do obrazu jest oznakowana transkrypcja. TEI oferuje pewne mechanizmy ułatwiające produkcję cyfrowych edycji każdego rodzaju.

5.1.1. Obraz i transkrypcja

Jak zauważyliśmy powyżej, element <fascimile>, który może być wykorzystany do grupowania i organizowania obrazów cyfrowych na zasadzie powierzchni fizycznch, które reprezentują (używając elementu <surface>) oraz logicznych sfer zainteresowań w ramach tych przestrzeni (używając elementu <zone>). Element <fascimile> może być wszystkim, co dokument TEI zawiera, a może być opatrzone także transkrypcją.

Kiedy dostępne są łącznie fascimile i transkrypcja, można wykorzystać globalny atrybut facs, by je połączyć (lub ich części). Załóżmy na przykład, że mamy pojedyńczą kartkę wraz z obrazami obu powierzchni nazwanymi odpowiednio strona1r.png and strona1v.png. Możemy je przetranskrybować jak zwykle za pomocą elementu <text>, używając <pb> do zaznaczenia miejsc w transkrypcji, które odnoszą się do początku każdej nowej strony źródła. Dokument w rezultacie mógłby wyglądać w sposób następujący:

<facsimile>  <surface xml:id="s1">   <graphic url="strona1r.png"/>  </surface>  <surface xml:id="s2">   <graphic url="strona1v.png"/>  </surface> </facsimile> <text>  <body>   <pb facs="#s1"/> <!-- tutaj tekst przetranskrybowany ze strony 1 kartki -->   <pb facs="#s2"/> <!-- tutaj tekst przetranskrybowany ze strony 2 kartki -->  </body> </text>

Warto zwrócić uwagę na powiązanie transkrypcji z powierzchniami, a nie samym plikiem z obrazem daje elastyczność w dodawaniu falszych plików z obrazami (np. lepszej lub gorszej rozdzielczości) bez uszkadzania struktury.

Atrybut facs wykorzystany powyżej jest globalny i może więc zostać wykorzystany do połączenia jakiejkolwiek części transkrypcji z jakąkolwiek częścią <fascimile>. Moglibyśmy na przykład połączyć kilka słów transkrypcji z tą częścią obrazka, gdzie się pojawiają.

5.1.2. Edytowanie transkrypcji

Przy transkrypcji źródła, zwłaszcza starszego, zawsze jest napięcie pomiędzy chęcią wiernego odzwierciedlenia ktualnego stanu dokumentu, a chęcią stworzenia dokumentu zrozumiałego dla współczesnego i nieprzygotowanego czytelnika. Proces transkrypcji z konieczności zawiera w sobie rodzaj normalizacji, w ramach której różne symbole pisma (glify) w rękopisie albo starodrukach są mapowane na niejednoznaczne kody pochodzące ze współczesnego zestawu znaków. Znakowanie, które próbuje reprezentować słowa w dokumencie wytworzone zgodnie z normami odmiennymi od naszych, albo poprawiać ‘ewidentne’ błędy w kopii tekstu jest więc prawie nieuniknione. TEI oferuje różne sposoby zaznaczania fragmentów tekstu jako znormalizowanych albo skorygowanych przez osobę znakującą, niezależnie od tego, czy rozważamy to jako ‘edytowanie’ w tradycyjnym sensie, czy nie.

Wspomnieliśmy powyżej, że TEI świadomie ummieszcza się w ramach długiej zachodniej tradycji filologicznej zainteresowanej identyfikacją oraz odzyskiwaniem tekstu z rozproszonych świadectw dokumentacyjnych. Nie jest więc zaskakujące to, że oferuje także udogodnienia do reprezentacji takich zjawisk, jak poprawki skryptora czy zmiany występujące w konkretnym dokumencie, albo do reprezentacji zestawień wariantów odczytań. Tam gdzie przedcyfrowi edytorzy tekstów byli z konieczności zainteresowani stworzeniem jednej starannie przemyślanej i popartej dowodami wersji tekstu, oszczędność produkcji cyfrowej znacząco ułatwiła tworzenie ‘dyplomatycznych’ cyfrowych lub dokumentacyjnych edycji, które mają reprezentować obiektywnie fakty zawarte w danej kolekcji dokumentów w taki sposób, że czytelnik może sam zdecydować o prawdopodobieństwie którejkolwiek z dołączonych wersji ‘edytowanych’ albo nawet stworzyć z tego edycję dla siebie.

Transkrybując tekst źródłowy, można wykorzystać element <corr>, żeby zaznaczyć część, która została skorygowana, oraz element <reg> dla części, która została znormalizowana. W odwrotnym wypadku można wykorzystać element <sic> tam, gdzie coś powinno zostać poprawione, ale tego nie zrobiono; a także element <orig> dla przypadków, gdzie zachowano oryginalną pisownię, mimo że wygląda nieznajomo. Na przykład zmodernizowana wersja poniższego fragmentu sonetu Szekspira

<l>My Mistres eyes are nothing like the Sunne,</l> <l>Currall is farre more red, then her lips red,</l> <l>If snow be white why then her brests are dun:</l> <l>If haires be wiers, black wiers grow on her head:</l>

mogłaby wyglądać w sposób następujący:

<l>My Mistress' eyes are nothing like the sun,</l> <l>Coral is far more red than her lips red,</l> <l>If snow be white, why then her breasts are dun:</l> <l>If hairs be wires, black wires grow on her head:</l>

Nawet w takiej zmodernizowanej wersji, skrupulatny znakujący, chcąc pokazać, gdzie znajdują się odstępstwa od tekstu źródłowego, może po prostu otoczyć słowa ‘Mistress'’ ‘sun’ itp. elementami <reg>. Zwykle jednak znakujący będzie chciał zachować oryginalną ortografię wraz ze zmodernizowaną wersją tak, by można je było obie wyświetlać. Wymaganie to spełnia element <choice:>

<l>My <choice>   <reg>Mistress'</reg>   <orig>Mistres</orig>  </choice> eyes are nothing like the <choice>   <reg>sun</reg>   <orig>Sunne</orig>  </choice>,</l> <l>  <choice>   <reg>Coral</reg>   <orig>Curral</orig>  </choice> is far more red <choice>   <reg>than</reg>   <orig>then</orig>  </choice> her lips red, </l>

Element <choice> może być wykorzystywany tam, gdzie są możliwe różne znakowania, ale tylko jedno z nich może zostać wybrane dla konkretnej aplikacji. Jest to mniej odpowiednie w przypadku, gdy jest wiele różnych możliwych świadectw dających różnorodne odczytania, z których każde powinno zostać wzięte pod rozwagę. TEI oferuje silniejszy i bardziej rozbudowany zestaw znaczników do wykorzystania aparatu krytycznego tego rodzaju. Do zaznaczenia omawianego miejsca z odmianą jest przeznaczony element <app> (apparatus). W ramach tego elementu znakujący może dostarczyć zbiór elementów <rdg> (odczytanie), po jednym dla każdego wariantu. (Jeśli polityka wydawnicza zezwala, jedno z tych odczytań może być uważane za ‘prymarne’ albo ‘poprawne’ ― w tym wypadku zostanie oznaczone raczej za pomocą elementu <lem>, a nie kolejnego <rdg>.) Element <rdg> ma atrybuty wit, które mogą zostać wykorzystane do zidentyfikowania świadectw, w których znajdują się poświadczenia dla wątpliwych odczytań. Na przykład pierwsza linia Chaucera Wife of Bath's Tale rozpoczyna się od ‘Experience though noon Auctoritee...’, jednak pierwsze słowo jest zapisane odmiennie w trzech zachowanych rękopisach. Przy spojrzeniu całościowym takie warianty pisowniowe dają użyteczne świadectwo w przypadku rekonstrukcji historii wspomnianej tradycji rękopiśmiennej i nasze znakowanie stara się je zachować. Może to wygladać w sposób następujący:

<l n="1">  <app>   <rdg wit="#El #Hg">Experience</rdg>   <rdg wit="#La">Experiment</rdg>   <rdg wit="#Ra2">Eryment</rdg>  </app> though noon Auctoritee... </l>

Wartości atrybutu wit wskazują tutaj wątpliwe rękopisy: jak można wnioskować po zastosowaniu znaku #, są to linki do obiektów na liście rękopisów, które zostały zebrane do stworzenia tego aparatu.

5.1.3. Znakowanie procesu pisania

Nasz ostatni przykład udogodnień oferowanych przez TEI do pracy nad szczegółową transkrypcją prymarnych materiałów źródłowych przedstawia kilka elementów potrzebnych do zapisania samego procesu pisania, na przykład do odnotowania fragmentów, które zostały usunięte, dodane, poprawione itp. czy to przez autora tekstu czy przez skryptora przepisującego rękopis. Analiza takich modyfikacji dokumentu może być niezbędna przed prezentacją tekstu i jest oczywiście ważna w procesie edycyjnym.

Nasz przykład został wzięty z zachowanego rękopisu autorskiego wiersza angielskiego pisarza Wilfreda Owena, którego część prezentujemy poniżej:

Wilfred Owen:
Figure 6. Wilfred Owen:

Owen najpierw napisał ‘Helping the worst amongst us’, ale potem usunął te słowa, dodając ‘Dragging the worst amongt us’ na górze. W ten sam sposób zmienił frazę ‘half-blind’ poprzez usunięcie ‘half-’ i dodanie ‘all’ powyżej niej. W ostatniej linii zaczął słowo rozpoczynające się od ‘fif’, a następnie je usunął i napisał słowo ‘five-nines’. Możemy to oznakować w następujący sposób:

<l>And towards our distant rest began to trudge,</l> <l>  <subst>   <del>Helping the worst amongst us</del>   <add>Dragging the worst amongt us</add>  </subst>, who'd no boots </l> <l>But limped on, blood-shod. All went lame; <subst>   <del status="shortEnd">half-</del>   <add>all</add>  </subst> blind;</l> <l>Drunk with fatigue ; deaf even to the hoots</l> <l>Of tired, outstripped <del>fif</del> five-nines that dropped behind.</l>

Elementy <add> oraz <del> zostały wykorzystane odpowiednio do otoczenia fragmentów dodanych lub usuniętych. Dostępne są dodatkowe atrybuty takie jak resp służący do wskazania odpowiedizalności za modyfikację, oraz place do wskazania, gdzie w tekście (na przykład powyżej albo poniżej linii) znajduje się modyfikacja. Tam gdzie znakujący chce potwierdzić, że dodanie lub usunięcie tworzą jeden edytorski akt zamiany, elementy te może połączyć w ramach elementu <subst> tak jak to zostało pokazane powyżej.

Bardzo dokładna analiza drugiej zmiany Owena pokazuje, że rzeczywiście napisał ‘amongt’, a nie ‘amongst’, prawdopodobnie w wyniku błędu. Tak samo dokładny znakujący chcący odtworzyć brakujące ‘s’ może użyć elementu <supplied> na oznaczenie, że to zrobił:

<add>Dragging the worst among<supplied resp="#ED">s</supplied>t us</add>

Wykorzystaliśmy to element resp, by zaznaczyć, że S nie zostało dodane przez Owena, tylko przez kogoś innego, a dokładniej przez osobę odnotowaną w innym miejscu przez element z identyfikatorem ED

5.2. Mowa transkrybowana

Media cyfrowe przechowują i reprezentują dźwięk lub wideo w taki sam prosty i efektywny sposób jak obrazy. Transkrypcje dźwięku lub nagrań wideo mogą zostać wykorzystane do uzupełnienia ich w taki sam sposób jak są wykorzystywane do uzupełnienia obrazów stron. Czy to wyprodukowane automatycznie, czy ręcznie, transkrypcje mowy są obiektem zainteresowania wielu dziedzin językoznawstwa; np. w badaniach nad akwizycją mowy, badaniach nad różnorodnością językową czy związkami pomiędzy mową a pismem w społeczeństwach piśmiennych i niepiśmiennych. Analizy transkrybowanej mowy są też często niezbędnym elementem badań socjologicznych takich jak historii ustnej.

Jednak jednostki, w których takie analizy są realizowane ― w ujęciu TEI w postaci elementów <text> obejmujących mowę transkrybowaną ― nie są powszechnie przyjęte i mogą nawet być kontrowersyjne. Kolejnym czynnikiem komplikującym jest to, że proces transkrypcji mowy jest trudny technicznie i często prowadzony za pomocą wyspecjalizowanego oprogramowania; jest to komplikacją, ponieważ większość takich systemów preferuje swoje wewnętrzne formaty zamiast zewnętrznie zdefiniowanych standardów.

Niezależnie od tego TEI oferuje zestaw elementów, które mogą być użyteczne przy szczegółowym znakowaniu transkrypcji mowy, które, jak pokazuje artykuł Thomasa Schmidta, mogą zostać wykorzystane jako rodzaj języka pośrednika w stosunku do istniejących alternatywnych metod znakowania.

Model TEI jest zainteresowany mową jako systemem komunikacji: dlatego proponuje jawne etykietowanie każdej części zarejestrowanego dźwięku, który ma funkcję lub efekt komunikacyjny. Zdarzenia takie jak dźwięk telefonu czy przelatującego samolotu ponad głowami są więc wyraźnie zaznaczone za pomocą elementu <incident>. Komunikacja mówiona jest prowadzona za pomocą głosu, ale nie wszystkie efekty głosowe są uważane za leksykalne, i nie cała komunkacja jest dźwiękowa: stąd też TEI oferuje element <vocal> na oznaczenie nieleksykalnych zjawisk takich jak kaszel czy śmiech oraz element <kinesic> dla nieleksykalnych i niewokalicznych zjawisk takich jak gesty czy mimika. Elementy te są uzupełnione niewielką liczbą innych zorientowanych na to, co można nazwać ‘prezentacją’ mowy, zwłaszcza pauza (<pause>) i zmiana (<shift>); ten drugi jest wykorzystywany do wskazywania zmian w jakości głosu (na przykład głośności, tonie czy prędkości) oraz funkcjonuje w sposób podobny do wcześniej omawianych kamieni milowych kamieni milowych.

Jednym z bardziej kontrowersyjnych pojęć w badaniach nad mową jest ‘zmiana’ i ‘wypowiedź’: TEI proponuje element <u>, który może zostać wykorzystany do wydzielenia fragmentu mowy należącego do pojedynczego mówcy, bez określania statusu albo funkcji w dyskursie takiego fragmentu. Element ten ma atrybut who, który pozwala na połączenie go z innym elementem zawierającym informację o mówiącej osobie, w ten sam sposób jak omówiony już atrybut ref.

W wielu analizach językoznawczych wspomniany wyżej elemet <s> może okazać się użyteczny przy organizowaniu transkrypcji, jako że pozwala znakującemu na kategoryzowanie każdego segmentu niezależnie od zawierającej go wypowiedzi, szczególnie że wypowiedź może być znacznie dłuższa (lub krótsza) niż zwykłe analizowane jednostki.

Oto uproszczony spolszczony przykład wzięty z British National Corpus (BNC), w którym do segmentowania transkrybowanej mowy zostały wykorzystane elementy <s> oraz <u>:

<u who="#PS6P0">  <s n="3">Nie ma</s> </u> <u who="#PS6NY">  <s n="4">   <shift new="laughing"/>Jest<shift/>  </s> </u> <u who="#PS6P0">  <s n="5">Zamknij się</s> </u> <u who="#PS6NY">  <s n="6">Tak, znajdziesz rogi na łódce</s> </u> <u who="#PS6P0">  <s n="7">Nie</s>  <s n="8">Łódki mają kształt jak cholerna piłka do rugby</s> </u> <u who="#PS6NY">  <s n="9">Nie</s>  <s n="10">Jeden koniec jest i jeden nie <pause/> i to był jacht <pause/> a jachty mają pokoiki i coś <unclear/> w istocie</s> </u> <u who="#PS6P0">  <s n="11">Och <pause/> te pomieszczenia są w kształcie <pause/> takim jak wielkość łódki <pause/> bez sen <vocal desc="tut"/>  </s> </u> <u who="#PS6NY">  <s n="12">Zapytaj swoją Mamę, czy są <pause/> czy są jakieś rogi na łódce</s> </u> <u who="#PS6P0">  <s n="13">Oczywiście, że nie ma</s> </u> <u who="#PS6NY">  <s n="14">Zapytaj Mamę</s> </u> <u who="#PS6P0">  <s n="15">Taaa</s> </u> <u who="#PS6NY">  <unclear/> </u> <u who="#PS6P0">  <s n="16">Założę się, że będzie po twojej stronie</s> </u>

Przy transkrypcji mowy osoba transkrybująca musi często dokonywać decyzji co do tego, jak oddać niestandardowe albo jedynie semi-zleksykalizowane dźwięki mówców, takie jak w języku polskim ‘hmmm’, ‘eh’, czy ‘phi’. W tym wypadku część została potraktowana jako słowo, a część jako po prostu dźwięk (<vocal>). Nawet kiedy jest jasne, że dany dźwięk na znaczenie leksykalne, nie zawsze jest jasne, jak powinien zostać zapisany. Przykładowo powyższe ‘taa’ równie dobrze mogłoby zostać zapisane jako ‘ta’ lub ‘taaa’ albo nawet ‘tak’.

W korpusach językowych tego typu częstą praktyką jest wyraźne znakowanie każdego słowa za pomocą elementu <w>. Decyzja, w jaki sposób powinna się odbywać ta tokenizacja nie zawsze jest oczywista: przykładowo w Brytyjskim Korpusie Narodowym połączenia typu ‘ain't’ czy ‘there's’ są znakowane jako dwa elementy <w>, a dodatkowe znaczniki są wykorzystywane do oznaczania fałszywych początków lub skróconych form takich jak ‘th’ i ‘ni’ w powyższym przykładzie. Znakowanie takie jest jednak głównie wykorzystywane w celu dodania takich informacji jak ‘część mowy’ czy analiza ‘morfosyntaktyczna’, tak jak to zostało opisane w części 5.5. Anotacja lingwistyczna poniżej.

Jest jeszcze jedna ważna cecha modelu TEI dotyczącego transkrypcji mowy: zestawienie. Podczas gdy na ilustracji transkrypcja musi zostać dopasowana w ramach przestrzeni dwuwymiarowej, w przypadku medium opartego na czasie, jakmi jest nagranie, różne części transkrypcji muszą zostać ulokowane w czasie. Mówcy zwykle sobie przerywają albo mówią w tym samym czasie; zrozumienie dialogu jest niemożliwe bez informacji o sekwencji transkrybowanych wydarzeń. TEI proponuje sposób wyraźnego zapisywania czegoś w rodzaju skali czasu, za pomocą elementu <timeline>, który zawiera definicje punktów w czasie reprezentowanych jako elementy <when>. Wydarzenia w trankrypcji mające miejsce w określonym punkcie czasu mogą zostać zestawione z odpowiednimi elementami <when> za pomocą atrybutów sync (synchroniczny). Zaletą tej metody jest to, że umożliwia ona przekazanie w tranksrypcji minimalnej informacji potrzebnej do zestawienia jej składników bez konieczności tworzenia dokładnych znaczników czasu dla każdego z nich; takie znaczniki są jednak zasadniczo oferowane przez systemy do automatycznej transkrypcji i w związku z tym może być prościej używać właśnie ich.

5.3. Słowniki

TEI zawiera elementy do szczegółowego znakowania tylko kilku odmiennych rodzajów dokumentów, preferując zasadniczo definiowanie elementów typowych dla danych rodzajów analizy lub podejścia do badań. Oferuje jednakże też zestaw znaczników do pracy ze słownikami i leksykonami, być może dlatego, że historycznie były one wśród pierwszych typów sporych prac referencyjnych, które w oczywisty sposób były łatwiejsze do zarządzania w formie cyfrowej niż drukowanej.

Słowniki, zwłaszcza drukowane, w przeciwieństwie do wielu dokumentów nie zawierają tekstu ciągłego, ale raczej odrębne hasła, w ramach których można łatwo zauważyć indywidualne i semantycznie znaczące składniki, nawet jeśli nie zawsze są one prezentowane tak konsekwentnie, jak mógłby sobie życzyć twórca bazy danych. Artykuł słownikowy zawsze zawiera hasło, następnie zwykle informację lingwistyczną taką jak np. część mowy, oraz listę definicji, często uporządkowanch hierarchicznie. Mogą być też obecne informacje etymologiczne, przykłady użycia, odnośniki do homonimów itp.

Przy znakowaniu w stylu TEI wszystkie te i inne części artykułu hasłowego zostaną rozróżnione na tyle, na ile to tylko możliwe, czy to do celów tworzenia nowego słownika (w którym takie rzeczy muszą zostać zaprezentowane w spójny sposób), czy to do reprezentacji już istniejącego (gdzie rozróżnianie tych fragmentów zwiększy skalę inteligentnego przeszukiwania).

Jako pierwszy przykład rozważmy następujący artykuł hasłowy:

 ze (1900-1927)
Figure 7. ‘Bufor’ ze Słownika warszawskiego(1900-1927)

Minimalne znakowanie TEI tego fragmentu dotyczyłoby wyróżnienia słowa będącego hasłem, zapisu i części gramatycznej, etymologii oraz znaczeń:

<entry>  <form type="lemma">   <orth>Bufor</orth>, <gramGrp>    <case>a</case>, <number>lm.</number> y</gramGrp>  </form>  <sense n="1">   <def>kol. przyrząd sprężysty dla miarkowania siły uderzenia wagonów o siebie, zderzak.</def>    Przen.: Pas neutralny, mający służyć za B. między Birmanją a Sjamem.  </sense>  <sense n="2">   <def>resor gumowy.</def>   <etym>    <lang>Ang.</lang>    <foreign xml:lang="ang">buffer</foreign>.</etym>  </sense> </entry>

5.4. Notatki, przypisy, glosy

Teksty, szczególnie starsze, często są opatrzone obszernymi anotacjami oraz komentarzami pochodzącymi od autora lub częściej redaktora albo późniejszego komentatora. Wszystkie teksty naukowe zawierają zwykle przypisy, notatki na marginesie, glosy, odnośniki bibliograficzne itp. Wszystkie te rzeczy można znakować za pomocą elementu <note>, który obejmuje samą anotację, jak i miejsce, gdzie zostały osadzone w anotowanym tekście, tzw. ‘miejsce zaczepienia’, czyli miejsce, gdzie typowo pojawia się odnośnik do przypisu lub inny znak w drukowanym tekście. Można też stosować atrybuty elementu <note>, które umożliwiają pewną ich kategoryzację, umożliwiającą wskazanie przybliżonego miejsca, a także osoby odpowiedzialnej.

Współcześnie anotacje wyjaśniające są zwykle zamieszczane na końcu książki. Na przykład w tekście o współczesnych podejściach do językoznawstwa opublikowanym w 1995 r. znajdujemy następujący komentarz:
Extract from Deborah Cameron's  (p 229)
Figure 8. Extract from Deborah Cameron's Verbal Hygiene (p 229)
Znak 6 w indeksie górnym wskazuje, że autor umieścił dalsze uwagi, które pojawiają się razem ze wszystkimi jakieś 18 stron dalej:
Extract from Deborah Cameron's  (p 247)
Figure 9. Extract from Deborah Cameron's Verbal Hygiene (p 247)
. Moglibyśmy to oznakować w sposób następujący:
<div>  <head>Beyond "anything goes"</head>  <p> Why does the language-maven in the street (or the senior common-room, or the bar    at the Groucho Club <note>An establishment patronized by media folk in London      (provided the club will have them as members).</note>) have such a low opinion    of linguists? Because...</p> </div>
Postanowiliśmy tutaj oznakować uwagi w tekście, pomimo że w wydrukowanym materiale źródłowym są one oddzielone of tekstu, ponieważ ułatwia to prezentowanie tych uwag w rózny sposób (np. w postaci dymku w wersji internetowek) oraz dla uproszczenia znakowania. Jednakże możliwe jest traktowanie takich uwag jako oddzielnej części dokumentu i umieszczenie jawnych linków w tekście w miejscu ich pojawienia się, za pomocą alementu <ptr> element:
<div>  <head>Beyond "anything goes"</head>  <p> Why does the language-maven in the street (or the senior common-room, or the bar    at the Groucho Club <ptr target="#note6"/>) have such a low opinion of linguists?    Because...</p> </div> <back>  <head>Przypisy</head> <!-- tu inne przypisy -->  <note xml:id="note6">An establishment patronized by media folk in London (provided    the club will have them as members).</note> <!-- i tutaj --> </back>
Żeby przedstawić połączenie pomiędzy tekstem i przypisem po pierwsze nadajemy elementowi <note> unikatowy identyfikator (note6), a następnie umieszczamy element <ptr> w odpowiednim miejscu w tekście. Element wskazujący reprezentuje podniesione 6 z naszego źródła, którego funkcją jest wskazywanie na przypis, którego identyfikator został dodany za pomocą atrybutu target. Zamiast tego, jeśli chcemy dokładnie zapisać to, jak pojawia się w tekście odnośnik, możemy wykorzystać element <ref>:
...the Groucho Club <ref target="#note6">6</ref>) have ...

5.5. Anotacja lingwistyczna

W czasie przygotowywania znakowanego tekstu, u znakującego naturalnie pojawia się chęć dodania własnych anotacji. Każde znakowanie dodane do tekstu przedstawia wynik analizy, czy to dokonanej przez człowieka, czy automatycznej, i dlatego naturalne jest myślenie o tym, by dodawać takie anotacje do tekstu cyfrowego przyrostowo za pomocą znakowania. W tym celu można wykorzystać element <note>. Jednakże, dla wielu ludzi, analiza motywowana językoznawczo (typu ‘to jest czasownik’ albo ‘ten ciąg słów ma funkcję składniową’, czy nawet ‘to jest metafora’) jest odmienna od innych rodzajów anotacji (‘to jest tytuł’, ‘to jest nazwa osobowa’ itp.), o której mówimy w innych miejscach książki. W szczególności, w tym wypadku jest mniejsza zgodność co do kategorii, które się stosuje: większość ludzi bez wahania zgodzi się, że ‘nazwa miejscowa’ jest użytecznym i definiowalnym pojęciem, ale pojęcia stojące za analizą językoznawczą są dużo bardziej zróżnicowane. W związku z tym TEI nie proponuje takich znaczników jak <noun> (rzeczownik) czy <adjunct> (uzupełnienie), tylko oferuje elementy ogólne służące do segmentowania tekstów na mniejsze jednostki, z których każdy może posiadać etykiety zdefiniowane na potrzeby konkretnego projektu.

Metoda ta jest zwłaszcza użyteczna w przypadku, gdy tekst cyfrowy jest automatycznie analizowany za pomocą programu komputerowego (np. analizatora morfosyntaktycznego czy taggera części mowy), ponieważ formaty wyjściowe takich systemów znacznie się różnią. TEI oferuje prosty sposób na wyraźne segmentowanie tekstu ciągłego na jednostki słowopodobne oraz powiązanie z nimi kodów lingwistycznych. Na przykład, jak w wielu korpusach językowych, Brytyjski Korpus Narodowy wykorzystuje kody wskazujące część mowy (rzeczownik, przymiotnik, czasownik itd.) dla każdego słowa, a ponadto formy bazowe oraz nieodmienione. Możemy więc zdanie z korpusu oznakować w TEI w sposób następujący:
<u who="PS6NY">  <s n="12">   <w ana="#VM0lemma="lets">Let's</w>   <w ana="#VVIlemma="ask">ask </w>   <w ana="#DPSlemma="you">your </w>   <w ana="#NN1lemma="mum">Mum </w>   <w ana="#CJSlemma="if">if </w>   <w ana="#EX0lemma="there">there</w>   <w ana="#VBZlemma="be">'s</w>   <w ana="#DT0lemma="any">any </w>   <w ana="#NN2lemma="corner">corners </w>   <w ana="#PRPlemma="on">on </w>   <w ana="#AT0lemma="a">a </w>   <w ana="#NN1lemma="boat">boat</w>   <pc>. </pc>  </s> </u>
Analogiczny polski przykład wyglądałby mniej więcej tak:
<u who="PS6NY">  <s n="12">   <w ana="#VVIlemma="zapytać">Zapytaj </w>   <w ana="#DPSlemma="twój">swoją </w>   <w ana="#NN1lemma="mama">Mamę </w>   <w ana="#CJSlemma="czy">czy </w>   <w ana="#PRPlemma="on">na </w>   <w ana="#NN1lemma="łódka">łódce</w>   <w ana="#VBZlemma="być"></w>   <w ana="#DT0lemma="jakiś">jakieś </w>   <w ana="#NN2lemma="róg">rogi </w>   <pc>. </pc>  </s> </u>

W tym znakowaniu, które w większości jest zautomatyzowane, oczywiście, element <w> został wykorzystany do wyznaczenia granic każdej jednostki leksykalnej. Dla każdej takiej jednostki wykorzystano atrybut ana wskazujący definicję części mowy oraz atrybut lema, który zawiera formę bazową.

Analiza lingwistyczna tego rodzaju jest praktykowana od wielu dekad i jest podstawową formą analizy w welu najnowszych systemach wykorzystywanych w przetwarzaniu języka naturalnego (NLP). W związku z tym techniki i kategorie są w trakcie standaryzacji, przynajmniej dla większych języków zachodnioeuropejskich. Podejście TEI pozwala znakującemu na wybranie, do jakiego stopnia chce uczynić dokładnym znaczenie analizy wskazanej przez atrybuty ana: czyli jak objaśnić, co właściwie znaczą VBZ czy NN1.

Jedną z metod jest podanie definicji kategorii, zwykle w Nagłówku TEI, za pomocą elementu <taxonomy> omówionego w części 6.3. Opis znakowania. Definicja taka będzie zwykle zrozumiała jedynie dla człowieka, ale mimo to jej podanie może być użyteczne.

Inną skrajnością są kategorie formalnie zdefiniowane za pomocą połączonych rekomendacji TEI i ISO służących do reprezentacji analiz lingwistycznych na zasadach struktur cech charakterystycznych (por. Rozdział 18 Wskazówek TEI). Analiza taka jest obecnie dość powszechnie wykorzystywana przez środowisko NLP, na przykład jako sposób mapowania informacji pomiędzy różnymi leksykonami komputerowymi.

Pomiędzy tymi rozwiązaniami znajduje się tworzenie rozróżnień lingwistycznych z odnośnikami do istniejącego standardu takiego jak np. ISO Data Category Registry (por. Ide and Romary 2009.). Podejście to ma wiele wspólnego z wieloma innymi zabiegami służącymi ujednolicaniu danych w Internecie: ułatwia to systemom współpracę w taki sam sposób, w jaki w ogólności dokumenty TEI mogą być ze sobą kompatybilne.

Warto zwrócić uwagę, że te same mechanizmy są dostępne w przypadku wszystkich analiz, niekoniecznie lingwistycznycj; analizy stylistyczne (które zwykle zajmują się fragmentami tekstów dłuższymi od pojedynczych słów) mogą być również oznakowane w ten sam sposób za pomocą dodania atrybutu ana do wybranego elementu wybranego do otoczenia omawianego fragmentu tekstu, np. <p>, <div>, <s>, itd.

Oczywiście analizowane jednostki tekstu niekoniecznie współwystępują z jednostkami tekstu reprezentowanymi w obrębie tekstu. Przedstawiliśmy jedną z metod radzenia sobie z tym powszechnym ‘problemem zachodzenia na siebie’ części 4.1. Słupki kilometrowe powyżej. Innym sposobem jest zastosowanie znakowania ‘przeciwstawnego’, w którym analizowane jednostki nie są reprezentowane przez elementy XML, tylko przez wskaźniki. Tę i inne techniki bardziej szczegółowo omawia rozdział 20 Wskazówek TEI.

6. Nagłówek TEI

Każdy dokument TEI musi posiadać Nagłówek TEI, reprezentowany przez element <teiHeader>. Jest on opakowaniem dla wszystkich metadanych powiązanych z samym dokumentem cyfrowym, analogicznym do strony tytułowej drukowanej książki. W bibliotekach cyfrowych i innych repozytoriach online zwykle metadane powiązane z każdym dokumentem cyforywm przechowuje się oddzielnie, na przykład w bazie danych, co zwiększa ich skuteczność. Powszechną praktyką jest wystawianie zestawu takich metadanych na potrzeby wyszukiwarek internetowych zgodnie z co najmniej jednym powszechnym standardem np. Dublin Core. Element zwany Nagłówkiem TEI został przwidziany jako forma przechowywania wszystkich tego typu informacji w jednym miejscu, niezależnie od tego, jak mogą być wykorzystywane. Oczywiście zakres i ilość danych przechowwanych w Nagłówku może się znacznie różnić w przypadku dokumentów przygotowanych w różnych celach albo w różnych projektach. Ponadto przynajmniej zgodnie ze wstępnym wyobrażeniem, zawartość Nagłówka TEI nie musi koniecznie odpowiadać najwyższym standardom katalogowania. Niezależnie od tego służy jako użyteczne miejsce, gdzie na przykład twórca danych i ich kurator mogą wymieniać się informacjami.

Na początku nagłówek TEI został zaprojektowany na potrzeby dwóch raczej różnych zestawów wymagań. Z jednej strony miał wspomóc osoby zajmujace się bibliografiami i bibliotekarzy mierzących się z (wtedy) nowym problemem dokumentowania "książek elektronicznych"; z drugiej strony miał odpowiadać na potrzeby badaczy pracujących nad zbiorami tekstów cyfrowych, którzy potrzebowali jakoś udokumentować zastosowane tam "zasady znakowania". Dla badaczy ważną rzeczą w nagłówku jest to, że jest tam miejsce na wszystko i wspiera na tyle, na ile to pełen zakres różnorodnych praktyk różnych środowisk naukowych, nie wprowadzając takich barier jak szczegółowa wiedza z zakresu standardów i praktyk katalogowania. Dla bibliotekarza ważną rzeczą w Nagłówku TEI jest to, że odpowiada standardowym modelom bibliograficznym, wykorzystując podobną terminologię, i że oferuje pojedyncze źródło informacji dla opisu bibliograficznego źródła cyfrowego, wraz z pewnymi przyjętym odwołaniami do innych podobnych rekordów (jak MARC czy EAD). Istnieje oczywiście pewne napięcie pomiędzy tymi dwoma perspektywami oraz potrzeba szczegółowego omówienia profili albo ‘Wskazówek do Dobrych Praktyk’ dla różnych środowisk.

Nagłówek TEI ma czetery główne składniki, odpowiadające częściom zdefiniowanym w jednym z pierwszych podejść do uniwersalnego opisu bibliograficznego (the International Bibliographic Standard Description, tj. ISBD):

6.1. Opis pliku

Ponieważ (zwykle) nie jest to wcześniej istniejący dokument, struktura nagłówka TEI może być dość ściśle określona przez TEI. Pierwsza i jedyna obowiązkowa część, zwana opisem pliku, jest reprezentowana przez element <fileDesc>, który zawiera trzy obowiązkowe części: tytuł, wydanie i opis źródła. Minimalny nagłowek TEI wygląda więc mniej więcej tak:

<teiHeader>  <fileDesc>   <titleStmt>    <title>Tytuł dzieła</title>   </titleStmt>   <publicationStmt>    <p>Informacje o wydaniu dzieła</p>   </publicationStmt>   <sourceDesc>    <p>Informacje na temat źródła dokumentu.</p>   </sourceDesc>  </fileDesc> </teiHeader>

W obrębie czterech głównych części nagłówka TEI możliwe jest wystąpienie wielu elementów, więc możemy podać jedynie ich pobieżny przegląd. Na przykład <fileDesc> może zwierać też <editionStmt> dokumentujące konkretne wydanie opisywanego materiału, <seriesStmt>, jeśli jest to część serii publikacji, <extent> wskazujący rozmiar, a nawet <noteStmt> obejmujący notatki i różnego rodzaju komentarze.

Obowiązkowe pole tytułu i jego nazwa sugerują, że zawierają tytuł materiału wraz z informacją o ludziach lub organizacjach odpowiedzialnych za jego zawartość intelektualną w mniej więcej ten sam sposób jak tytuł w książce drukowanej albo konwencjonalnym wpisie katalogowym. Na przykład:

<titleStmt>  <title xml:lang="sk">Yogadarśanam (arthāt yogasūtrapūphah).</title>  <title>The Yoga sūtras of Patañjali: wydanie cyfrowe.</title>  <author>Patañjali</author>  <funder>Wellcome Institute for the History of Medicine</funder>  <principal>Dominik Wujastyk</principal>  <respStmt>   <name>Wieslaw Mical</name>   <resp>dane i korekta</resp>  </respStmt>  <respStmt>   <name>Jan Hajic</name>   <resp>konwersja do TEI</resp>  </respStmt> </titleStmt>

W przykładzie tym materiał ma dwa tytuły, z czego jeden został podany w sanskrycie. Podane są też dane autora, fundatora edycji cyfrowej, głównego badacza oraz innych osób wraz z ich konkretnymi zadaniami. Wiele projektów bibliotek cyfrowych będzie miało swoje własne zasady dotyczące np. formatu nazw albo będzie wykorzystywać zatwierdzone spisy do podawania tytułów, które mogą się znacznie różnić: TEI pozwala na dokładniejsze znakowanie składników takich jak nazwy własne (np. poprzez rozróżnienie imion i nazwisk), ale tego nie wymaga.

Opis pliku zawiera opis całego źródła (tzn. że cały materiał cyfrowy może się oczywiście składać z kilku plików jako takich). Pojęcie informacji o wydaniu dzieła odnosi się do tego, jak można zdobyć dany materiał, mniej więcej w ten sam sposób jak w drukowanej książce znajduje się informacja na temat tego, kto jest odpowiedzialny za jej dystrybucję czy wydanie. Nawet jeśli dokument TEI jest prywatny i nie jest dostępny poza prywatnym twardym dyskiem właściciela, fakt ten powinien zostać tu odnotowany; zwykle oczywiście nagłówek będzie tworzony jedynie dla materiałów TEI, które są rozpowszechniane. Informacje o wydaniu pozwalają na sprecyzowanie, kto udostępnia materiał, jaki ma identyfikator, jak np. numer katalogowy albo URI oraz informację na temat zasad dystrybucji takich jak licencja, tak jak widać poniżej:

<publicationStmt>  <publisher>Humanities Media and Computing Center</publisher>  <pubPlace>University of Victoria</pubPlace>  <date when="2011-08-04">19 sierpnia 2011</date>  <idno type="filename">maladies_des_femmes.xml</idno>  <availability status="free">   <p>Copyright 2011. Tekst jest swobodnie dostępny pod warunkiem dystrybucji wraz      z informacjami zawartymi w nagłówku.</p>   <p xml:lang="fr">Les droits de reproduction des gravures ont été achetés de la      Bibliothèque Nationale de France grâce à une subvention accordée par le <ref target="http://www.sshrc-crsh.gc.ca/">Conseil de recherches en sciences humaines        du Canada</ref>. Les autres éléments du projet (les contributions des éditeurs,      les transcriptions des textes, l'encodage et le code) sont distribués sous les      termes de cette licence: <ref target="http://creativecommons.org/licenses/by-nc-nd/2.5/ca/deed.fr_CA">Creative        Commons Paternité ― Pas d'Utilisation Commerciale ― Pas de Modification 2.5        Canada</ref>.</p>  </availability> </publicationStmt>

Przykład ten pokazuje typową mieszankę elementów ustrukturyzowanych i tekstu nieformalnego. Nazwa i adres instytucji odpowiedzialnej za dystrybucję pliku zostały wyróżnione w postaci elementów <publisher> i <pubPlace> (możliwe jest też zastosowanie bardziej szczegółowego adresu z wykorzystaniem elementu <address>, który widzieliśmy powyżej); na dodatek podane zostały data publikacji oraz nazwa pliku umożliwiające identyfikację udostępnionego materiału. Jako że zasady udostępniana są tu dość złożone, zostały zaprezentowanie nieformalnie jako ciąg akapitów zawierających odnośniki do innnych odpowiednich dokumentów online. W prostszej sytuacji można zastosować element TEI <licence>.

6.2. Różnorodność opisu źródła

Następnym i jedynym obligatoryjnym składnikiem <fileDesc> jest opis źródła, wprowadzony za pomocą elementy <sourceDesc>. Nawet dla dokumentów ‘zrodzonych cyfrowo’ i tym samym nieposiadających swojego źródła, element ten musi zostać zamieszczony. Jego celem jest udokumentowanie formalne przedmiotu lub przedmiotów, z których powstał dokument TEI z wykorzystaniem tradycyjnych terminów bibliograficznych. <sourceDesc> może zawierać prosty akapit z opisem albo zawierać jeden lub więcej elementów oipsu bibliograficznego zaproponowanych przez TEI.

Naszym pierwszym przykładem będzie dokument, który nie posiada wcześniejszej formy poza tą cyfrową. Możemy opisać to za pomocą oszczędnego elementu <bibl>:

<sourceDesc>  <bibl>   <title>Manifeste des Digital humanities</title>. <author>Marin Dacos et al.</author>    Dostępny pod adresem <ref target="http://tcp.hypotheses.org/318">http://tcp.hypotheses.org/318</ref>   <date when="2010-05-21"/>  </bibl> </sourceDesc>

albo po prostu dając krótki akapit z wyjaśnieniem

<sourceDesc>  <p>Brak źródła: dokument zrodzony cyfrowo.</p> </sourceDesc>
Często zdarza się, że cyfrowa edycja jest pochodną konkretnego źródła drukowanego. Także to może zostać opisane za pomocą elementu <bibl>:
<sourceDesc>  <bibl xml:id="Sue1846">   <author>    <surname>Sue</surname>, <forename>Eugène</forename>   </author>   <title level="m">Martin, l’enfant trouvé : Mémoires d’un valet de chambre</title>   <imprint>    <publisher>C. Muquardt</publisher>    <pubPlace>Bruksela</pubPlace>    <pubPlace>Lipsk</pubPlace>    <date when="1846">MDCCCXLVI</date>   </imprint>  </bibl> </sourceDesc>

Do cyfrowych transkrypcji nagrań dźwiękowych albo wideo, powinno się stosować element <recordingStmt>. Może on zostać wykorzystany do przechowywania wszelkich szczegółów technicznych dotyczących nagrania, a także szczegółowych danych bibiograficznych czy socjologicznych dotyczących uczestników transkrybowanego dialogu.

<sourceDesc>  <recordingStmt>   <recording type="audiodur="P30M">    <respStmt>     <resp>Nagranie na odległość</resp>     <name>Sound Services Ltd.</name>    </respStmt>    <equipment>     <p>Wiele blisko zlokalizowanych mikrofonów połączonych w postaci taśmy stereo          typu DAT, nagranie standardowe, próbkowanie 44,1 KHz.</p>    </equipment>    <date>12 stycznia 1987 r.</date>   </recording>  </recordingStmt> </sourceDesc>

Element <bibl> może być stosowany także w przypadku innych nieksiążkowych źródeł takich jak np. wspomniana wyżej pocztówka:

<sourceDesc>  <bibl>   <title level="m">The Bathing Beach, Brighton, w 1845 [pocztówka]</title>   <respStmt>    <resp>Litografia</resp>    <name>G. F. Bragg</name>   </respStmt>   <respStmt>    <resp>za rysunkiem</resp>    <name>R. H. Nibbs</name>   </respStmt>   <publisher>Księgarnia K. J. Bredona</publisher>   <pubPlace>Brighton, ul. East Street 10</pubPlace>  </bibl> </sourceDesc>

W przypadku cyfrowej edycji rękopisu albo starodruku, gdzie ważne jest zapisanie cech charakterystycznych dla konkretnego transkrybowanego egzemplarza, bardziej odpowiednie mogą być szczegółowe elementy oferowane przez TEI w celu opisowego katalogowania rękopisów. Opisy te wykorzystują odrębny element <msDesc>, który ma dość złożoną strukturę wewnętrzną, co pokazuje kolejny przykład:

<sourceDesc>  <msDesc>   <msIdentifier>    <country>Francja</country>    <settlement>Paryż</settlement>    <repository>Archiwum narodowe</repository>    <collection>Handel i przemysł</collection>    <idno>F/12/5080</idno>   </msIdentifier>   <msContents>    <p>Minute d’un rapport de proposition à la Légion d’honneur fait, en 1850, par le        ministre du Commerce et de l’Agriculture et président de la Société de        géographie, Jean-Baptiste Dumas, au Président de la République, en faveur des        frères d’Abbadie, Antoine (1810-1897) et Arnaud (1815-1893), auteurs d’un voyage        en Abyssinie.</p>   </msContents>   <physDesc>    <p>Deux feuilles de papier 24 x 12 cm ; écriture à l’encre noire.</p>    <handDesc>     <handNote xml:id="AAscope="major">Antoine d’Abbadie</handNote>     <handNote xml:id="DJBscope="minor">Jean-Baptiste Dumas</handNote>     <handNote xml:id="EPRscope="minor">membre inconnu du cabinet du          ministre</handNote>    </handDesc>   </physDesc>  </msDesc> </sourceDesc>

6.3. Opis znakowania

Drugą ważną częścią Nagłówka TEI jest opis znakowania, który jest reprezentowany za pomocą elementu <encodingDesc>. Ten opcjonalny element może być stosowany do dostarczenia informacji na temat prawie każdego aspektu procesu znakowania, czy to podanego w postaci tekstu ciągłego, czy też w ramach bardziej precyzyjnych elementów. Ogólnie rzecz biorąc, zawartość <encodingDesc> zbliża się do informacji zwykle zawartej w dokumentacji technicznej jakiegoś projektu.

Niektóre jego składniki są całkowicie dokumentujace, np.:

Oto przykład pokazujący wykorzystanie niektórych z tych elementów:

<encodingDesc>  <projectDesc>   <p>Teksty zebrane w Klinice Claremont Shakespeare w czerwcu 1990.</p>  </projectDesc>  <samplingDecl>   <p>Każdy tekst zawiera próbkę składającą się z maksymalnie 2000 słów, licząc od      początku dokumentu do końca zdania przekraczającego liczbę 2000 słów. Przy      liczeniu dywizy i apostrofy traktowane były jako spacje.</p>  </samplingDecl>  <editorialDecl>   <normalization>    <p>Formy wyrazowe przerwane z powodu dzielenia wynikającego z pojawienia się na        końcu linii zostały zrekonstruowane bez komentarzy. Dywiz został usunięty za        wyjątkiem form z dywizem poświadczonych w innym miejscu tekstu.</p>   </normalization>   <quotation marks="allform="std">    <p>Wszystkie znaki zapytania zostały usunięte. Mowa niezależna została oznaczona        za pomocą <gi>said</gi>; pozostały materiał cytowany oznakowany został za pomocą        znacznika <gi>q</gi>    </p>   </quotation>  </editorialDecl> </encodingDesc>

Dokumentacja tego typu jest oczywiście użyteczna jedynie dla człowieka. Jednakże są też inne składniki opisu znakowania przeznaczone do wykorzystania w procesie automatycznym. Zwykle oferują one zestaw deklaracji poszczególnych kodów, które są następnie używane w części głównej tekstu. Przykładowo są to:

Bardziej szczegółówe przykłady tych trzech elementów znajdują się poniżej.

Po pierwsze, typowy element <charDecl> może definiować wariantywną formę znaku Z, którą znakujący chce wyróżnić w transkrypcji. Wariant ten ma dwie kreski, ale może zostać zastąpiony normalnym Z.

<charDecl>  <glyph xml:id="z103">   <glyphName>LATIN LETTER Z WITH TWO STROKES</glyphName>   <mapping type="standardized">z</mapping>   <mapping type="PUA">U+E304</mapping>  </glyph> </charDecl>

Wystąpienia tego wariantu w transkrypcji mogą być teraz wyróżniane za pomocą elementu <g> odsyłającego do powyższej definicji za pomocą wartości jej xml:id. Program przetwarzający może zdecydować o oddaniu jego wyglądu albo poprzez formę standardową albo zastosowanie niestandardowego kodu podanego przez mapowanie PUA 1.

<p> ... mulct<g ref="#z103"/> ... </p>

Teraz zajmiemy się omówieniem elementu <classDecl>. Może on być stosowany do definiowania dowolnego rodzaju systemu klasyfikacji albo taksonomii. Dla zbioru artykułów prasowych możemy wykorzystać następującą taksonomię:

<classDecl>  <taxonomy xml:id="rozmiar">   <category xml:id="duży">    <catDesc>wiadomość zajmuje więcej niż pół strony</catDesc>   </category>   <category xml:id="średni">    <catDesc>wiadomość zajmuje od ćwierci do połowy strony</catDesc>   </category>   <category xml:id="mały">    <catDesc>wiadomość zajmuje mniej niż ćwierć strony</catDesc>   </category> <!-- itd. -->  </taxonomy>  <taxonomy xml:id="temat">   <category xml:id="polityka-wewn">    <catDesc>Odnosi się do wewnętrznych wydarzeń politycznych</catDesc>   </category>   <category xml:id="polityka-zagr">    <catDesc>Odnosi się do polityki zagranicznej</catDesc>   </category>   <category xml:id="soc-kobieta">    <catDesc>Odnosi się do roli kobiety w społeczeństwie</catDesc>   </category>   <category xml:id="soc-służba">    <catDesc>Odnosi się do roli służących w społeczeństwie</catDesc>   </category> <!-- itd. -->  </taxonomy> </classDecl>

Pojedynczy tekst zawierający, powiedzmy, wiadomość krótszą niż ćwierć strony dotyczącą roli kobiety w społeczeństwie mógłby więc odwoływać się do tej klasyfikacji za pomocą elementu <catRef> w sposób następujący:

<catRef target="#mały #soc-kobieta"/>

Ten sam mechanizm może zostać zastosowany do dokumentowania kodów wykorzystywanych do prostej analizy lingwistycznej takich jak te opisane w rozdziale 5.5. Anotacja lingwistyczna powyżej.

Na koniec omówimy element <tagsDecl>. Może on być stosowany do wyliczenia elementów rzeczywiście wykorzystanych w dokumencie, a także do zdefiniowania dla nich domyślnego formatowania stylów (zwykle z wykorzystaniem W3C CSS). W kolejnym przykładzie najpierw definiujemy za pomocą CSS dwa fonty: kursywę i krój prosty. Możemy wtedy stwierdzić, że w przestrzeni nazwy TEI wszystko oznakowane jako <emph> albo <hi> jest domyślnie zapisane kursywą. Możemy też stwierdzić, że element <text> i z zasady wszystko, co zawiera, wykorzystuje krój prosty.

<tagsDecl>  <rendition xml:id="ITscheme="css">font-style: italic</rendition>  <rendition xml:id="FontRomanscheme="css">font-family: serif</rendition>  <namespace name="http://www.tei-c.org/ns/1.0">   <tagUsage gi="emphrender="#IT"/>   <tagUsage gi="hirender="#IT"/>   <tagUsage gi="textrender="#FontRoman"/>  </namespace> </tagsDecl>

W części głównej dokumentu domyślne style dla elementu mogą zostać unieważnione za pomocą atrybutu rendition; por. 4.3. Renderowanie (wizualizacja) powyżej.

6.4. Opis tekstu i wersji

Trzecią dużą częścią nagłówka TEI jest coś, co zostało nazwane opisem profilu, oznaczone elementem <profileDesc>. Tak jak pozostałe, służy do grupowania opcjonalnych notatek albo bardziej wyspecjalizowannych elementów; ich cechą wspólną jest to, że są zwyczajnie "niebibliograficzne". Domyślnymi składnikami tej klasy są:

Zwrócilismy wyżej uwagę na możliwość wykorzystania elementu <catRef> jako sposobu klasyfikacji tekstu w odniesieniu do wcześniej zdefiniowanej taksonomii. <profileDesc> umożliwia kilka dodatkowych sposobów zrobienia tego samego:

za pomocą <catRef>
poprzez odesłanie do lokalnie zdefiniowanej kategorii (np. w nagłówku korpusu)
używając <classCode>
poprzez odesłanie do jakiejś przyjętej i zewnętrznie zdefiniowanej kategorii, takiej jak Uniwersalna Klasyfikacja Dziesiętna,
używając <keywords>
poprzez przypisanie opisowych terminów wziętych ze ustalonego bibliograficznie słownictwa albo chmury znaczników

W następującym spolszczonym przykładzie z Brytyjskiego Korpusu Narodowego tekst został sklasyfikowany za pomocą wszystkich tych trzech możliwych metod:

<profileDesc>  <creation>   <date when="1962"/>  </creation>  <textClass>   <catRef target="#WRI #ALLTIM1 #ALLAVA2 #ALLTYP3 #WRIDOM5 #WRILEV2 #WRIMED1 #WRIPP5 #WRISAM3 #WRISTA2 #WRITAS0"/>   <classCode scheme="DLEE">W nonAc: humanities arts</classCode>   <keywords scheme="COPAC">    <term>Historia, Współczesność ― XIX wiek</term>    <term>Kapitalizm ― Historia ― XIX wiek</term>    <term>Świat, 1848―1875</term>   </keywords>  </textClass> </profileDesc>

Zwróćmy uwagę, że ta kategoryzacja dotyczy całego tekstu. Do bardziej szczegółowej klasyfikacji można zastosować atrybut decls umożliwiający wybranie klasyfikacji odpowiedniej dla każdego wybranego elementu, na przykład dla pojedycznego <div>.

Czwartą i ostatnią częścią Nagłówka TEI jest opcjonalny opis wersji, reprezentowany przez element <revisionDesc>, który zawiera elementy <change> posiadajace atrybuty date oraz who dotyczące znaczących etapów ewolucji dokumentu. Zwyczajowo na początku podaje się najbardziej aktualny element tego typu. Do podania informacji o poszczególnych etapach ewolucji dokumentu elektronicznego, w odróżnieniu od tekstu znakowanego, może zostać też wykorzystany wspomniany wyżej element <listChange>. W środowisku produkcyjnym wykorzystywany będzie jakiś system kontroli wersji typu SVN, dzięki któremu zostaną zapisane szczegółowe dane na temat ewolucji dokumentu; znakowanie TEI dotyczące znaczących etapów rozwoju dokumentu może zostać wykonane ręcznie lub półautomatycznie za pomocą tego typu narzędzi.

<revisionDesc>  <listChange>   <change when="2013-05-11">Pierwszy skończony brudnopis</change>   <change when="2013-04-07">Stworzenie nagłówka i struktury dokumentu</change>  </listChange> </revisionDesc>

7. Dostosowywanie TEI

Jak widzieliśmy, TEI zostało zaprojektowane tak, by dać szeroki zakres wyboru sposobu znakowania. Może zostać wykorzystane do prostej transkyrpcji tekstu źródłowego na potrzeby czytania, niezależnie od tego, czy jest to autorski rękopis, drukowane dzieło literackie, nagranie audycji czy słownik. Może też zostać wykorzystane do wzbogaconego znakowania objaśniającego wiele aspektów takich tekstów, dzięki czemu można z nimi pracować za pomocą różnorodnego oprogramowania ― od narzędzi do wizualizacji poprzez systemy służącego do cyfrowego wydawania aż po specjalistyczne narzędzia do analizy statystycznej. Może też zostać użyte do udostępniania dodatkowych anotacji oraz różnorodnych metadanych. Prawie nikt nie ma potrzeby, by wszystko zostało zdefiniowane za pomocą TEI, jednak każdy z elementów może się okazać użyteczny lub interesujący dla kogoś. Jak powinniśmy wybierać fragmenty TEI, których potrzebujemy? Jedną z głównych motywacji do tworzenia dokumentów TEI jest możliwość dzielenia się nimi z innymi oraz włączania ich w inne dokumenty TEI. Jak powinniśmy informować innych o poszczególnych wyborach w zakresie znakowania TEI, by nadal pozostała możliwość integracji danych?

TEI oferuje możliwość uwzględnienia tych wątpliwości i jednocześniej odpowiedzi na ważną potrzebę szczegółowej dokumentacji projektu, a to za pomocą zestawu elementów, które mogą służych i do określenia schemy w zakresie nazw i własności formalnych zawartych tam elementów i atrybutów, a także do dokumentowania sposobu wyboru tych elementów oraz atrybutów w danym przypadku.

Pojęcie schemy jest fundamentalne dla języka XML: dostarcza rodzaj gramatyki dokumentu, nazywając wszystkie możliwe składniki, oraz ograniczając budowę dokumentu XML. Schema umożliwia poinformowanie o ograniczeniach takich jak to, że ‘elementy <p> mogą się pojawić w ramach elementów <div> albo ‘każdy element <list> musi zawierać przynajmniej jeden element <item>. Zasady tego typu są łatwe do sprawdzenia przez procesor automatyczny (walidator). Ograniczenia typu ‘Używaj elementu <p> do oznaczania akapitów, a nie stron’ albo ‘używaj <placeName> dla nazw miejscowych, <persName> dla nazw osobowych, a <name> dla wszystkich innych nazw’ są zdecydowanie trudniejsze do sprawdzania automatycznego, jako że odwołują się do semantyki konktekstu, a nie organizacji dokumentu. Zasady tego typu są zdefiniowane np. we Wskazówkach TEI albo dokumentach odwołujących się do nich. Zrozumienie tych semantycznych ograniczeń jest niezwykle ważne przy tworzeniu oprogramowania, które miałoby w pełni wykorzystywać znakowany dokument, a także dla osób chcących tworzyć nowe dokumenty oznakowane w ten sam sposób. Jest to zwłaszcza prawdziwe, jeśli schema w praktyce pozwala na znaczną różnorodność elementów pojawiających się w podobnych znaczeniach, czyli np. w przypadku niezmodyfikowanej i niedostosowanej schemy TEI.

Z tego powodu poważne wykorzystywanie TEI wymaga dokładnego przemyślenia, które konkretnie elementy odpowiadają potrzebom naszego projektu oraz być może rzeczy, które trzeba sprecyzować dokładniej niż wymaga tego samo TEI. Na przykład TEI nie ma wiążących wymagań co do możliwych wartości atrybutów type przy elementach <div>, jako że moga się znacznie różnić pomiędzy projektami. W konktetnym projekcie jednak może się okazać pomocne zestandaryzowanie wybranego zestawu wartości i w związku z tym będzie konieczność upewnienia się, że wszystkie dokumenty korzystają jedynie z ustalonego zestawu wartości oraz że dokumentacja, jakie są te wartości i co oznaczają jest utrzymywana razem ze schemą i bez trudu dostępna dla systemów służących do przygotowywania i redagowania dokumentów XML (takich jak np. popularny program oXygen) wspomagających ludzi zajmujących się edycją tych dokumentów.

W TEI jest zestaw elementów, który może zostać wykorzystany do stworzenia takiej specyfikacji schemy. Elementy te (<schemaSpec>, <moduleRef>, <elementSpec>, <classSpec> i inne) łączą formalne deklaracje XML dotyczące włączania do DTD albo schemy wraz ze szczegółową dokumentacją i przykładami włącania do dokumentacji technicznej informacji o ustalonym systemie znakowania. W związku z tym dokument wykorzystujący te elementy jest nieformalnie znany jako ‘ODD’ (‘One Document Does it all’, czyli jeden dokument odpowiada za wszystko): w jednym zintegrowanym dokumencie XML zawiera informacje dla komputera na temat przetwarzania i jest jednocześnie czytelny dla człowieka. Nie jest więc raczej zaskoczeniem, że sam system TEI jest opisany za pomocą tych samych elementów, ale wolelibyśmy się tu skupić na dostosowywaniu TEI.

7.1. Przygotowywanie adaptacji TEI

Najprostszym dostosowaniem TEI jest zerwowe dostosowanie, co zwyczajnie oznacza ‘zezwalaj na każdy element zdefiniowany w ramach TEI’. Tak powstała schema, zwana TEI-all dostarcza (w czasie pisania tego tekstu) około 450 różnych elementów oraz wiele, wiele różnych sposobów radzenia sobie z częstymi problemami zachodzącego na siebie znakowania. Rozmiar i liberalność takiej schemy powoduje, że jest ona praktycznie nieużywalna, oprócz jednej ważnej sytuacji odnoszącej się zgodności TEI, do czego wrócimy dalej.

Prawdopodobnie najczęściej wykorzystywanym dostosowaniem TEI jest TEI Lite, czyli podzbiór około pięćdziesięciu elementów mających odpowiadać potrzebom 90% użytkowników TEI, o czym świadczy ich rzeczywista praktyka przy tworzeniu tekstów cyfrowych. Zestaw ten został przygotowany w czasie warsztatów TEI w 1997 r., ale po paru aktualizacjach okazał się użyteczny w wielu kontekstach, do tego stopnia, że wielu ludzi myśli, że to jest schema TEI. TEI Lite jest włączone (jako wzór) do standardowego wydania TEI w postaci źródłowej, jak i pochodnych.

Szybki rzut oka na ODD TEI Lite i jego kod źródłowy XML pozwala stwierdzić, że jest to typowy dokument TEI, w którym znajdują się elementy <div> zawierające elementy <head>, <p> oraz <list>, zawierające tekst oraz elementy <ptr> służące do tworzenia odwołań oraz kilka bardziej fachowych elementów takich jak <egXML> dla przykładów XML. Faktyczna schema określona przez ten dokument ma swoją reprezentacją pod koniec dokumentu, w ramach elementu <schemaSpec> zawierającego następujące deklaracje:
<schemaSpec ident="tei_lite"  start="TEI teiCorpus">  <moduleRef key="analysis"   include="interp interpGrp pc s w"/>  <moduleRef key="linking"   include="anchor seg"/>  <moduleRef key="tagdocs"   include="att code eg gi ident val"/>  <moduleRef key="tei"/>  <moduleRef key="textstructure"   include="TEI argument back body byline closer dateline div docAuthor docDate docEdition docImprint docTitle epigraph front group imprimatur opener postscript salute signed text titlePage titlePart trailer"/> </schemaSpec>
Element <moduleRef> służy do odwoływania się do modułu TEI, który jest jakby nazwanym pojemnikiem dla pewnych deklaracji elementów TEI i klas. TEI aktualnie definiuje 22 moduły, z których każdy odpowiada jednemu rozdziałowi Wskazówek TEI, gdzie szczegółowo opisano jego składnię. Domyślnie odsyłacz modułowy informuje, że wszystkie zawarte w nim deklaracje przekładają się na określoną schemę, ale do modyfikacji tego domyślnego zachowania można wykorzystać atrybuty include oraz except. Stąd też w powyższym przykładzie tworzona schema będzie zawierać wszystkie deklaracje z modułu zwanego tei, a deklaracje dla elementów <anchor> i <seg> z modułu zwanego linking. Zamiast tego można było zastosować moduł except, by wybrać wszystko oprócz elementów podanych jako jego wartości.

Moduł udostępnia do elementowi <schemaSpec> deklarację dla każdego wybranego elementu w postaci elementu <elemSpec>. Posiada on kilka składników, z których większość została zwizualizowana w dokumentacji TEI. Zawiera np.:

Aneks C do Wskazówek TEI zawiera ładnie przedstawioną dokumentację każdego zdefiniowanego elementu TEI na podstawie takich deklaracji.

Oprócz wybierania lub wykluczania deklaracji, <schemaSpec> służy również do modyfikowania pewnych części deklaracji. Trochę dalej w ODD dla TEI Lite znajduje się następujący zapis:
<elementSpec ident="TEImode="change">  <attList>   <attDef ident="versionmode="delete"/>  </attList> </elementSpec>
Rezultatem jest druga deklaracja elementu <TEI> wraz z tą wybraną z modułu textstructure. Procesor ODD musi pogodzić lub ujednolicić tego typu duplikaty pod kontrolą atrybutu mode. W tym konkretnym wypadku rezultatem będzie zmiana <attList> zadeklarowanego dla elementu <TEI> poprzez usunięcie z niego atrybutu ident.
Dokładnie ta sama procedura jest wykorzystywana w pozostałej części adaptacji TEI Lite do usuwania z niej pewnych niechcianych atrybutów. Na przykład atrybuty notBefore, notAfter i inne są oferowane przez atrybuty klasy att.datable.w3c. Najłatwiejszym sposobem usunięcia ich jest więc dodanie następującego deklaracji dla klasy:
<classSpec type="atts"  ident="att.datable.w3cmodule="teimode="change">  <attList>   <attDef ident="notBeforemode="delete"/>   <attDef ident="notAftermode="delete"/>   <attDef ident="frommode="delete"/>   <attDef ident="tomode="delete"/>  </attList> </classSpec>
Specyfikacja ODD może uwzględniać lub wykluczać elementy lub atrybuty w ten czy inny sposób. Może też modyfikować istniejącą deklarację poprzez dodanie do niej pewnych ograniczeń. Na przykład przyjrzyjmy się adaptacji TEI zwanej Epidoc, powszechnie używanej wśród specjalistów od epigrafów i innych starożytnych inskrypcji. Jak zauważyliśmy wcześniej, atrybut type przy elemencie <div> nie jest ograniczony w żaden sposób przez TEI. Środowisko związane z projektem Epidoc zdecydowało jednak, że chciałoby narzucić obecność tego atrybutu i dopuścić jedynie sześć predefiniowanych wartości. Oto fragment Epidoc ODD dający ten efekt:
<elementSpec ident="divmode="change"  module="textstructure">  <attList>   <attDef ident="typemode="replace"    usage="req">    <valList type="closed">     <valItem ident="apparatus">      <desc>zawiera aparat krytyczny albo notatki tekstowe</desc>     </valItem>     <valItem ident="bibliography">      <desc>zawiera informację bibliograficzną, wcześniejsze publikacje            itd.</desc>     </valItem>     <valItem ident="commentary">      <desc>zawiera cały komentarz redaktorski, dyskusję            historyczną/prozograficzną itd.</desc>     </valItem>     <valItem ident="edition">      <desc>zawiera sam tekst edycji; może być podzielony na kilka części</desc>     </valItem>     <valItem ident="textpart">      <desc>użyty do podzielenia <tag>div type="edition"</tag> na mniejsze części            (fragmenty, kolumny itp.)</desc>     </valItem>     <valItem ident="translation">      <desc>zawiera tłumaczenie tekstu na co najmniej jeden język nowożytny</desc>     </valItem>    </valList>   </attDef>  </attList> </elementSpec>
Należy zwrócić uwagę, że możliwe jest dodanie kolejnych ograniczeń umożliwiających sprawdzenie, czy te wartości zostały poprawnie użyte: np. żeby sprawdzić, że div type="textpart" zawsze posiada div type="edition" jako swojego rodzica.

Projekt Epidoc pokazuje, w jaki sposób konkretne środowisko badaczy może dostosować TEI do swoich potrzeb, a ich adaptacja jest dobrą demonstracją metod, których zastosowanie umożliwia język ODD.

7.2. Dodawanie nowego elementu

System ODD umożliwia ponadto dodanie całkowicie nowych elementów do schemy. W najprostszym przypadku oznacza to ni mniej, ni więcej, tylko dodatnie <elementSpec> dla nowego elementu w specyfikacji schemy, ale decyzja co do tego, jaka będzie właściwa zawartość tego nowego elementu wymaga pewnej wiedzy na temat tego, jak zbudowany jest system TEI. Przykładowo, wybór, które składniki klasy powinny zostać określone dla danego elementu, jest trudny, gdy nie posiada się wiedzy, jakie w ogóle klasy istnieją i jak na siebie wzajemnie działają. Wybór odpowiedniego modelu zawartości nowego elementu podobnie wymaga pewnego przemyślenia na temat tego, jak są zdefiniowane pozostałe elementy, przy założeniu, że chcemy, aby nasz nowy element zachowywał się spójnie z resztą TEI. I na koniec, ponieważ nie jest to element TEI, musimy pamiętać o zdefiniowaniu w innej przestrzeni nazwy niż przestrzeń nazwy TEI.

Dla przykładu, załóżmy, że chcemy dodać nowy element <speciesName> do znakowania nazw gatunków botanicznych i innych pojawiających się w tekście. Nasz nowy element jest semantycznie podobny do istniejących elementów <persName> czy <name>, więc dobrym punktem wyjścia będzie zajrzenie do specyfikacji ODD dla innych elementów dotyczących nazw. Na przykład w przypadku <elementSpec> dla elementu <persName> widzimy, że jest członkiem klasy model.nameLike.agent, która jest podklasą bardziej ogólnej klasy model.nameLike. Dodając tam nasz nowy element, otrzymamy gwarancję, że będzie się pojawiać w modelach zawartości innych elementów TEI w tych samych miejscach, co inne elementy nazwowe, bez żadnej dalszej pracy z naszej strony. Zauważmy też, że <persName> jest członkiem kilku klas atrybutowych, w szczególności att.global (posiadające kilka własnych podklas) oraz att.canonical, które wydają się użyteczne do naszych celów. Dodanie naszego nowego elementu do tych klas zagwarantuje nam, że będzie korzystał z tych atrybutów w ten sam sposób jak inne elementy nazwowe.

Teraz zajmijmy się modelem zawartości naszego nowego elementu. Najłatwiejszym sposobem postępowania byłoby robienie tego samego, co inne elementy nazwowe, powiedzmy, że może zawierać po prostu tekst, pomieszany z innymi elementami z poziomu fraz, elementami typu <g> oraz elementami globalnymi. Powszechnym wymogiem schemy TEI jest to, by istniał skrót ("macro") zdefiniowany w tzw. macro.phraseSeq. Jeśli jednak chcemy przedstawić wewnętrzną zawartość <speciesName> (na przykład, by odróżnić "nazwę gatunku" od "nazwy rodzaju"), możemy chcieć zdefiniować więcej specyficznych modeli zawartości, być może uwzględniajacych inne nowe elementy albo inne ograniczenia. Którykolwiek sposób postępowania wybierzemy, musimy go dokładnie udokumentować w naszym ODD, by inny użytkownicy naszych danych mogli sprawdzić, jak dostosowaliśmy podstawowy model TEI.

7.3. Dostosowywanie a zgodność

TEI musi odzwierciedlać różnorodność działań swojego środowiska użytkowników, jeśli nie chce przestać być użyteczne. Mówi się czasami, że zadanie dwóm naukowcom tego samego pytania da nam co najmniej trzy odpowiedzi. Jak można się spodziewać, tę samą różnorodność można znaleźć w rekomendacjach TEI.

Niemniej jednym z celów Wskazówek TEI jest prowadzenie przez zasady znakowania. Nie jest to standard, który mówi, co robić (w sposób podobny do standardów w inżynierii, przykładowo specyfikując dokładnie kształt i wymiary instalacji elektrycznych). Zamiast tego pokazuje, jak informować innych, co zrobiliśmy. Dlatego też w części Wskazówek TEI dotyczącej zgodności jedną z podstawowych rzeczy jest zwrócenie uwagi na istnienie ODD, definiowanie schemy, która może służyć do walidowania (sprawdzania) wspomnianych dokumentów wraz z pozostałymi możliwymi ograniczeniami. Innymi ważnymi kryteriami zgodności TEI jest formalna poprawność strukturalna w odniesieniu do schemy tei_all, odpowiadanie zdefiniowanej semantyce użytych elementów TEI: zgodny dokument TEI może zawierać elementy z innych przestrzeni nazwy, ale wszystkie elementy z przestrzeni nazwy TEI muszą posiadać semantykę zdefiniowaną przez TEI.

Przyjrzyjmy się przykładowi pochodzącemu od szacownego dziewiętnastowiecznego powieściopisarza Edwarda Bulwer-Lytton. W zbiorze dokumentów TEI możemy spodziewać się zaleźć pełne oznakowane imię i powiązane z definicją samej osoby, w rodzaju:
<persName ref="https://pl.wikipedia.org/wiki/Edward_Bulwer-Lytton">  <forename>Edward</forename>  <forename>George</forename>  <surname type="linked">Bulwer-Lytton</surname>, <roleName>baron Lytton z  <placeName>Knebworth</placeName>  </roleName> </persName>
W innych natomiast moglibyśmy znaleźć wersje z mniej informacyjnym znakowaniem albo z wykorzystaniem nnych elementów TEI, jak na przykład:
<p>  <rs type="name">Baron Lytton z Knebworth</rs> </p>
albo
<p>  <name type="personkey="BWLY">Wielce Czcigodny Lord Lytton PC</name> </p>
albo
<p>  <persName ref="#BWLY">Pierwszy Baron Lytton z Knebworth</persName> </p>
Wariacje tego typu mogą się zdarzać: projekty różnią się między sobą znacznie, jeśli chodzi o priorytety. W niektórych przypadkach wystarczy wskazanie, że dany ciąg słów jest nazwą; w innych ważne jest odróżnienie nazw osobowych od nazw miejscowych; w jeszcze innych ważne jest ujednoznacznienie znanych jednostek nazwanych. Wyniki takich projektów nie mogą być łączone w sposób bezpośredni, bez dodatkowego wysiłku. Czy wszystkie można uznać za zgodne z TEI?

Najłatwiejszym sposobem informowania o tym, jakie decyzje zostały podjęte w danym projekcie w odniesieniu do TEI, jest zastosowanie przedstawionych tu funkcji ODD. Jest to jednocześnie najłatwiejszy sposób na sprawienia, że dokumenty projektu mogą być wymienne z innymi. Projekt może zwyczajnie usunąć (powiedzmy) element <rs> ze swojej schemy albo określić zamkniętą listę wartości dla atrybutów type. Można zdecydować się na wykorzystywanie jednego lub obu atrybutów key i ref, by łączyć rózne wersje nazw osobowych z danymi na ich temat, a tym samym je ujednoznaczniać. Wybory tego typu mogą zostać udokumentowane w dostosowanej schemie i w ten sposób informować, które z wielu różnych podejść do znakowania nazw jednostkowych zostało zastosowane w danym zestawie dokumentów. A ponieważ możliwe jest też automatyczne stworzenie ODD z zestawu dokumentów TEI XML, możemy też wyróżnić zamierzone dostosowania ― wyrażone w postaci tego, co twórcy dokumentu uznali za swoją metodę znakowawnia ― od rzeczywistego dostosowania, wyrażonego w postaci tego, jakie metody znakowania można faktycznie znaleźć w dokumencie.

Jeśli TEI zostało zaplanowane tak, by mogło być dostosowywane, jak może być uważane za format wymiany danych? Do "ślepej wymiany" (zwanej też współdzieleniem), odbiorca musi być pewien, że dokument zawiera jedynie elementy TEI i że zostały one wykorzystane zgodnie z zasadami TEI. Niezmodyfikowane zasady pozwalają na taką różnorodność, więc niemożliwe jest, by twórca oprogramowania mógł przewidzieć wszystkie możliwości, z którymi będzie musiało poradzić sobie oprogramowanie. Dostępność ODD znacznie ułatwia zadanie tak poprzez ograniczenie dostępnych elementów, jak i przez opcjonalne dodanie ograniczeń dotyczących zawartości danych.

8. Podsumowanie: czym jest TEI?

Co mamy na myśli, kiedy mówimy o ‘TEI’? Ciało administracyjne wspierane finansowo przez członków konsorcjum Text Encoding Initiative? Kiedy mówimy ‘TEI wysłało mi newsletter’ albo ‘wspieramy TEI’ prawdopodobnie mówimy o konsorcjum jako organizacji. Ale gdy mówimy ‘TEI wspiera teraz znakowanie notacji muzycznej’ albo ‘TEI oferuje teraz metody znakowania wydań krytycznych’ mówimy raczej o czymś innym ― technicznej zawartości Wskazówek TEI. A kiedy mówimy ‘to naprawdę zgodne z punktem widzenia TEI’ (na przykład w odniesieniu do zaleceń dotyczących długotermonowego archiwowania źródeł cyfrowych) czy ‘TEI ilustruje nasze podejście do zagadnień wolnego dostępu’ jasne jest, że mówimy o czymś więcej niż zbiór rekomendacji technicznych albo ludziach zajmujących się nimi lub je wykorzystujących. Niektórzy ludzie mówią o ‘TEI’ jakby było rodzajem klubu lub religii z członkami i niewierzącymi, do którego aspirują albo od których chcą się odróżnić. Na hałaśliwym rynku ‘Humanistyki Cyfrowej’ TEI jest rodzajem ważnego członka, denerwującym rodzicem dla niektórych, życzliwym dla innych, czymś wręcz zwyczajnie zbyt staromodnym dla innych. Jednak w ciągu ostatniego dziesięciolecia stało się jasne, że TEI jest częścią humanistyki cyfrowej: stało się częścią infrastruktury, z którą każdy musi sobie jakoś poradzić technicznie i socjalnie, gdy tylko zacznie myśleć o tekście lub innych formach tekstów kultury w formie cyfrowej. TEI oferuje zestaw narzędzi do tych przemyśleń i, co najważniejsze, jest także wynikiem tego myślenia, zainteresowania, jak i sporadycznych dziwactw. W tym znaczeniu TEI jest architekturą informacyjną i w ten sposób pojawia się w większej części niniejszego tekstu. Jednakże wydaje się, że należy zakończyć ten temat pewnymi rozważaniami o TEI jako organizacji.

Jedną z dziwniejszych rzeczy dotyczących TEI, przynajmniej z pewnej perspektywy, jest to, że TEI nie jest agencją rządową jak ANSI czy uznaną organizacją międzynarodową typu ISO albo konsorcjum przemysłowym typu W3C, chociaz organizacyjnie Konsorcjum TEI ma pewne punkty styczne z nimi wszystkimi. TEI jest organizacją typu non-profit, prowadzoną w całości dzięki niewielkiemu dofinansowaniu od instytucji i ludzi, których interesuje to na tyle, by wkładać pieniądze we wsparcie i utrzymanie systemu, a także dzięki ochotniczo zaangażowanej wielkiej grupie instytucji i ludzi chcących mieć wkład w jego dalszy rozwój. Co roku TEI jest gospodarzem konferencji, podczas której członkowie spotykają zbierają się, by przeprowadzić konieczne sprawy oficjalne i wybrać przedstawicieli, a także, by oczywiście przedyskutować zagadnienia, w których TEI jest naukowo silne lub słabe. Jednakże społeczność osób wykorzystujących TEI i wnoszących swój wkład w jego ciągły rozwój jest o wiele większa niż ci, którzy wybrali płatne członkostwo. Każda zainteresowana osoba ma prawo proponowania modyfikacji lub rozszerzeń do systemu, a także raportowania błędów i nieścisłości ― i wielu ludzi to robi. TEI utrzymuje wybieralną Radę Techniczną TEI, która jest odpowiedzialna za ocenianie i rozpracowywanie wszystkich proponowanych modyfikacji oraz zarządzanie tworzeniem nowych wydań. Proces ten jest prowadzony publicznie w duchu Open Source. Z tego powodu naturalne dla nas jest odwoływanie się do Społeczności TEI, chociaż granice oraz składniki tej społeczności użytkowników pozostają w znacznym stopniu niezbadane. Jest to społeczność, która posiada TEI, wypowiada się w jej imieniu w ramach szerszej społeczności Humanistyki, i która informuje o jej ewolucji i ją determinuje.

Słowo ‘ewolucja’ nie zostało wybrane przypadkowo. TEI z 2015 r. nie jest tym samym, czym było w 1998 r. ani nawet tym z 2009 r., chociaż większość nazw elementów pozostała ta sama. Organizacja i elastyczność TEI jako architektury systemowej umożliwia adaptowanie go to zmieniających się potrzeb i priorytetów jego społeczności, mniej więcej w ten sam sposób jak inne żywe formy ewoluowały w odpowiedzi na zmiany środowiska. Burnard 2013 i inni uzasadniali, że sekretem długowieczności TEI jest to, że jest zorganizowane w taki sposób, by zapewnić możliwość prostej i efektywnej modyfikacji w zależności od potrzeb użytkowników. Wydaje się możliwe, że TEI będzie nadal ewoluować ― i poprzez przejmowanie nowych przestrzeni do znakowania, i poprzez modyfikowanie tego, co już zostało zaproponowane, by nadążać za zmieniającym się krajobrazem cyfrowym. Pod koniec 2010 r. na przykład wydanie TEI 5 2.0 wprowadziło nowy sposób reprezentowania wydań krytycznych i dokumentujących zdefiniowanych rok wcześniej przez zewnętrzenie finansowaną grupę roboczą. Mniej więcej w tym samym czasie wprowadzono metodę tworzenia dokumentów TEI tak, by były zgodne z nowym standardem reprezentacji notacji muzycznej. Niedawno prace specjalnej grupy TEI zajmującej się ontologiami zagwarantowały to, że teksty oznakowane w TEI sprzyjają powstającym zalecenion dotyczącym reprezentacji tzw. Linked Data.

TEI jest organizacją zobowiązaną do poprawiania dostępności i zrozumiałości TEI jako systemu technicznego. Jako dodatek do strony internetowej TEI, która pełni rolę pełnego źródła danych na temat tego systemu, pojawia się ciągła potrzeba udostępniania aktualnych materiałów szkoleniowych oraz propagowania aktywnego zangażowania wśród osób zainteresowanych używaniem, rozwijaniem i utrzymywaniem TEI za pomocą systemów typu wiki, grupy dyskusyjne i cokolwiek innego pojawi się w przyszłości. Rozwój takich materiałów jest aktualnym zadaniem wszystkich członków społeczności TEI i nie tylko. Ta niewielka książeczka stanowi skromny wkład w te działania.

Appendix A Literatura

Strona internetowa TEI zawiera wykaz linków do tutoriali pod następującym adresem: http://www.tei-c.org/Support/Learn/tutorials.xml; kilka z nich zamieszczamy poniżej.

Wskazówki TEI zawierają obszerną listę publikacji dotyczących teorii znakowania i TEI http://www.tei-c.org/release/doc/tei-p5-doc/en/html/BIB.html#BIB-RDG. Poniżej zamieszczamy kilka przykładów, które mogą okazać się pomocne i informatywne dla przeciętnego czytelnika.

Na stronie Zotero znajdują się dwa zestawy cytowań dotyczących TEI: ogólna pod adresem https://www.zotero.org/groups/tei/items oraz druga, bardziej zorientowana na tematy lingwistyczne: https://www.zotero.org/groups/tei-lingsig/items/

Appendix A.1 Tutoriale i podręczniki

  1. Lauranne Bertrand Marie Luce Demonet Jorge Fins Manuel d’encodage XML-TEI Renaissance et temps modernes (Imprimés - manuscrits) http://www.bvh.univ-tours.fr/XML-TEI/index.asp (Szczegółowy podręcznik znakowania starodruków; po francusku.)
  2. Marcus Bingenheimer TEI使用指南──運用TEI處理中 文文獻 Chinese TEI – A guide to using TEI with Chinese texts Tajwan Taiwan E-learning and Digital Archive Program 數位典藏與數位學習國家型科技計畫 2009 http://www.tei-c.org/Support/Learn/TEI-ChinLoc-2ndPrintEd.pdf (Chińskie tłumaczenie tutorialu TEI (edycja P5) i dodatkowych artykułów. )
  3. Gabriel Bodard Tom Elliott Elli Mylonas EpiDoc Guidelines: Ancient documents in TEI XML http://www.stoa.org/epidoc/gl/latest/ (Szczegółowy podręcznik znakowania epigrafów i innych antycznych materiałów źródłowych; po angielsku.)
  4. Lou Burnard C.M. Sperberg-McQueen TEI Lite: Encoding for Interchange: an introduction to the TEI: final revised edition for TEI P5 http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_lite.doc.html Sierpień 2012 (Oryginalny ogólny tutorial korzystania z TEI; po angielsku. Dostępny także we francuskim tłumaczeniu autorstwa Sophie David i Lou Burnarda.)
  5. Fabio Ciotti Il Manuale TEI Lite: Introduzione Alla Codifica Elettronica Dei Testi Letterari Milano Sylvestre Bonnard 2005 (Włoskie tłumaczenie tutorialu TEI Lite (edycja P4) wraz z wprowadzającymi artykułami dotyczącymi XML, przejścia z P4 na P5 oraz narzędzi i technik TEI.)
  6. Michelle Dalmau Kevin Hawkins Best Practices for TEI in Libraries http://purl.oclc.org/NET/teiinlibraries (Szczegółowa specyfikacja części TEI odpowiedniej do wykorzystania materiałów źródłowych na potrzeby bibliotek cyfrowych; po angielsku.)
  7. Julia Flanders Syd Bauman Women Writers Project Guide to Scholarly Text Encoding http://www.wwp.brown.edu/research/publications/guide/ 2007 (Strona internetowa zawierająca dokumentację i materiały pomocnicze dotyczące wykorzystania TEI do znakowania starodruków; po angielsku.)
  8. Kevin Hawkins Introduction to XML for Text www.ultraslavonic.info/intro-to-xml (Krótkie wprowadzenie do znakowania za pomocą XML dla zupełnie początkujących; po angielsku.)
  9. Sylvain Loiseau Les standards : autour d'XML et de la TEI http://www.revue-texto.net/Corpus/Manufacture/standards/sommaire.html 2002 (Szczegółowy przegląd TEI P4 i powiązanych standardów XML; po francusku.)
  10. Ron Van den Branden Edward Vanhoutte TEI By Example http://www.teibyexample.org (Tutorial online zawierający ćwiczenia i przykłady użycia wielu modułów TEI (P4); po angielsku.)

Appendix A.2 Artykuły w czasopismach i książki

  1. David T. Barnard, Lou Burnard, C. Michael Sperberg-McQueen. Lessons learned from using SGML in the Text Encoding Initiative. Computer Standards & Interfaces 1996. 18 (1) p. 3–10. http://dx.doi.org/10.1016/0920-5489(95)00035-6 (Techniczny artykuł podsumowujący wykorzystanie SGML w TEI P3 do zaimplementowania modułowości, dostosowywania oraz linkowania; po angielsku. Ciekawy ze względu na historię ODD.)
  2. Lou Burnard, Sebastian Rahtz. RelaxNG with Son of ODD, http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Burnard01/EML2004Burnard01.pdf Proceedings of Extreme Markup Languages 2004, 2004. (Techniczny opis nowego systemu ODD zaprojektowanego dla TEI P5; po angielsku.)
  3. Lou Burnard Text Encoding for Interchange: A New Consortium http://www.ariadne.ac.uk/issue24/tei/ Ariadne, Issue 24 Czerwiec 2000 (Notatka prasowa opisująca przeorganizowanie TEI w Konsorcjum członkowskie; po angielsku.)
  4. Lou Burnard. On the Hermeneutic Implications of Text Encoding. http://users.ox.ac.uk/~lou/wip/herman.htm Domenico Fiormonte, Jonathan Usher (eds.) New Media and the Humanities: Research and Applications, 2001. Oxford: Humanities Computing Unit. p. 31–38. (Krótki artykuł podkreślający interpretacyjne właściwości znakowania i umieszczający je w ramach antycznej tradycji naukowej; po angielsku.)
  5. Lou Burnard. The Evolution of the Text Encoding Initiative: From Research Project to Research Infrastructure . Journal of the Text Encoding Initiative 2013. (5) . http://jtei.revues.org/811 (Historyczna recenzja rozwoju TEI do czasów współczesnych; po angielsku.)
  6. James H. Coombs, Allen Renear, Steven J. DeRose. Markup Systems and The Future of Scholarly Text Processing. http://xml.coverpages.org/coombs-hallgren.html http://xml.coverpages.org/coombs.html Communications of the ACM 1987. 30 (11) p. 933–947. http://doi.acm.org/10.1145/32206.32209 (Klasyczna i wpływowa polemika optująca za wykorzystywaniem w działalności naukowej znakowania opisowego, a nie procedualnego; po angielsku.)
  7. Steven J. DeRose, David G. Durand, Elli Mylonas, Allen H. Renear. What is Text, Really?. Journal of Computer Documentation 1997. 21 (3) p. 1–24. http://doi.acm.org/10.1145/264842.264843 (Klasyczna teza ‘OHCO’, zgodnie z którą tekst jest zasadniczo uporządkowaną hierarchią treści; po angielsku.)
  8. Martin Holmes, Laurent Romary. Encoding models for scholarly literature. Publishing and digital libraries: Legal and organizational issues, IGI Global. 2010-00-00 pp. 88-110. http://hal.archives-ouvertes.fr/hal-00390966/PDF/romary_chap_iglezakis_book.pdf (Omówienie wykorzystania TEI do znakowania publikacji akadmieckich i zarządzania nimi.)
  9. Nancy Ide, Jean Veronis (eds.) The Text Encoding Initiative: Background and Contexts, 1995. Dordrecht, Boston: Kluwer Academic Publisher. (Podstawowy zbiór siedemnastu artykułów pierwotnie opublikowanych jako podwójny numer czasopisma "Computers and the Humanities" w 1994 roku. Najważniejsze osoby z pierwszej generacji TEI zamieściły tam przegląd podejścia TEI do znakowania konkretnych typów tekstów, czemu towarzyszą klasyczne artykuły na temat celów i budowy TEI, a także SGML. )
  10. Nancy Ide Laurent Romary A Registry of Standard Data Categories for Linguistic Annotation (4th International Conference on Language Resources and Evaluation - LREC'04) none Lisbon Portugal 2004-00-00 135-138 http://hal.inria.fr/inria-00099858 (Omówienie rozwoju DCR (Data Category Registry) dla LAF (Linguistic Annotation Framework); ważny dla znakowania analiz lingwistycznych standard ISO. )
  11. David Mertz. XML Matters: TEI — the Text Encoding Initiative, An XML Dialect for Archival and Complex Documents, http://www-106.ibm.com/developerworks/xml/library/x-matters30.html 2003. (Interesujące spojrzenie na TEI-XML Interesting spoza środowiska akademickiego.)
  12. Elli Mylonas, Allen Renear. The Text Encoding Initiative at 10: Not Just an Interchange Format Anymore — But a New Research Community. Computers and the Humanities 1999. 33 (1-2) . http://dx.doi.org/10.1023/A:1001832310939 (Wprowadzenie do retrospektywnego zbioru 12 wybranych artykułów powstałych na potrzeby TEI 10th Anniversary Conference, która miała miejsce w Brown University w listopadzie 1997. )
  13. Thomas Schmidt. A TEI-based Approach to Standardising Spoken Language Transcription. Journal of the Text Encoding Initiative 2011. (1) . http://jtei.revues.org/142 (Analiza istniejących schematów transkrypcji języka mówionego i możliwości wykorzystania TEI jako języka pośrednika.)
  14. C. Michael Sperberg-McQueen. Text in the Electronic Age: Textual Study and Text Encoding, with Examples from Medieval Texts. Literary & Linguistic Computing 1991. 6 (1) pp. 34-46. http://dx.doi.org/10.1093/llc/6.1.34 (Klasyczne przedstawienie teorii znakowania jako dotyczącej edycji tekstów źródłowych.)
  15. John Unsworth, Katherine O'BrienKatherine O'Keeffe, Lou Burnard (eds.) Electronic Textual Editing, 2006. New York: Modern Languages Association. (Zbiór artykułów 24 czołowych praktyków dotyczących wszystkich aspektów elektonicznej redakcji tekstów w ujęciu TEI. Wczesna wersja online jest dostępna pod adresem http://www.tei-c.org/Activities/ETE/.)
  16. Christian Wittern, Conal Tuohy, Arianna Ciula. The making of TEI P5. Literary and Linguistic Computing 2009. 24 (3) pp. 281-96. http://dx.doi.org/10.1093/llc/fqp017 (Szczegółowy raport z prac redakcyjnych prowadzących do powstania pierwszej edycji TEI P5.)

Appendix B Słowniczek

Notes
1
PUA jest skrótem nazwy Private Use Area, czyli Unicode'owego pomysłu na umożliwienie definicji prywatnych kodów dla znaków niewymiennych, w ramach tzw. przestrzeni prywatnej.
Lou Burnard. Date: 2015-10-26