Kleio - система обработки данных исторических источников (краткое изложение основных принципов).

KLEIO - это профессионально ориентированная система управления базами данных для исторических наук. KLEIO - центральный проект в рамках программы "Автоматизированное рабочее место историка".

Накопленный с 1978 г. опыт, позволил Институту истории общества Макса Планка (Геттинген, Германия) с 1986 г. развивать, исходя из потребностей исследовательской практики в рамках объединения проектов "Автоматизированное рабочее место историка", систему управления базами данных.

Профессиональная направленность системы заключается в:

• особом типе и гибкости структуры данных;

• особом типе и гибкости типов данных;

• специальном сервисе программного обеспечения.

Для того, чтобы применить компьютер в историческом исследовании, надо трансформировать исторический источник в машиночитаемую форму. При обработке данных в коммерческом программном обеспечении это, как правило, выглядит так:

... В году 1869 на Св.Татьяну преставился хозяин трактира на Пятницкой. Его все хорошо знали в Замоскворечье, покуда еще мальчиком торговал он тут пирожками, потом у дядьки своего ходил в приказчиках.

Он все пропил, и когда умер, у него не было ни копейки. Имя ему было Иван Ермолаев ...



date: 25.01.1869

place: Замоскворечье

profession: Хозяин

surname: Иван

name: Ермолаев

death: Алкоголь

Это в ряде случаев, безусловно, эффективно. Но исторические источники зачастую отражают такое положение вещей, что если вы хотите проникнуть в их суть, такая форма представления создает практические трудности. В системе KLEIO:

• поля могут иметь несколько равноправных записей (в нашем примере три профессии: хозяин, мальчик, приказчик);

• поля могут сильно отличаться по длине

• (в нашем примере причина смерти специально не упомянута, она является составной частью повествования).

Есть данные, которые с трудом можно занести в какое-либо из полей. В нашем примере: при чем здесь упомянутый трактир?

Перечисленным условиям удовлетворяет программное обеспечение KLEIO, в котором:

• длина полей может без ущерба для эффективности варьироваться в диапазоне от 1 до 2 000 000 символов;

• каждое поле может включать несколько записей; это значит, что поле - это вектор, в котором отдельные логически равноправные значения разделены точкой с запятой (;);

• каждое поле может включать "аспекты"; через управляющие символы "#" и "%" можно как бы ассоциативно объединять данные с основной информацией.

KLEIO позволяет проводить все преобразования на естественной длине текста источника без сокращений.

... В году 1869 на Св.Татьяну преставился хозяин трактира на Пятницкой. Его все хорошо знали в Замоскворечье, покуда еще мальчиком торговал он тут пирожками, потом у дядьки своего ходил в приказчиках.

Он все пропил, и когда умер, у него не было ни копейки. Имя ему было Иван Ермолаев ...



date=25.1.1869#день Св.Татьяны/р1асе=Замоскворечье/ ргоfеssion=хозяин#трактир на Пятницкой;

приказчик/ surname=Иван/name=Ермолаев/death=Он все пропил, и когда умер, у него не было ни копейки.

Введем термин: эквивалент "поля" в обычной системе управления базами данных называется в KLEIO элементарной информацией. Элементарная информация имеет следующие отличительные черты:

1. Длину полей можно не устанавливать - она не ограниченна.

ргоfеssion=ученый

- это такой же вид элементарной информации, как:

profession=B 1901 году поступил в Варшавский университет, где изучал историю и филологию. Закончил образование в Петербургском университете. Еще до Октября стихийно подошел к марксистскому пониманию исторического процесса

2. Поля могут - без дополнительных мероприятий - содержать большое количество логически равноправных записей, которые разделяются точкой с запятой.

professio=студент

- это такое же содержание элементарной информации, как: profession=доцент; научный сотрудник; профессор

3. Поля могут - без дополнительных мероприятий - иметь до двух "аспектов", в которые можно заносить любую информацию, дополняющую основную. В общепринятой терминологии "аспект" можно представить как "примечание" к определенному полю. Длина аспектов также не ограниченна.

profession=пекарь

- это такое же содержание элементарной информации как:

profession= пекарь% оригинал: лекарь??? #Внимание! Перед статистической обработкой проверить!!!

4. Число различных типов элементарных информаций в базе данных практически не ограниченно. На персональном компьютере можно объединить в базе около 32 000 различных типов элементарной информации.

5. Новый тип элементарной информации можно легко добавить в базу во время ввода данных: tоwn=Новгород

Такая конструкция приводит к дополнительному вводу элементарной информации town, даже если это не было предусмотрено в первоначальной структуре.

KLEIO не только позволяет точно ввести все части текста, но и старается понять" текст так же, как он расположен в источнике.

... Во Франкфурте купили ткани на сумму 182 рейнских гульдена



l82 г_p

Конечно, "Во Франкфурте купили ткани на сумму 182 рейнских гульдена" не такой текст как "182 г_р". Но здесь сохраняется не только соотношение между структурными частями текста, но также и значение денежной единицы (рейнский гульден отличается, например, от старого и нового венгерского гульдена).

Означает ли это, что KLEIO знает переводные курсы всех денежных единиц, известных в истории?

Вовсе нет. KLEIO знает в этом и подобных случаях общие синтаксические условия, значения которых пользователь должен ввести сам. Система узнает около сорока различных форм представления чисел. В данном случае используется форма:

<Число> <Квалификатор> <Связующий оператор> <Квалификатор_2>

Установить, какие операторы допустимы, сколько символов будет использоваться в качестве связующего оператора и что означает оператор в количественном отношении, должен сам пользователь.

На практике для этого используются следующие команды KLEIO (сначала KLEIO понимала только латинские команды, теперь она понимает и латинские, и английские):

ternimus nomen=sum;modus=numerus:numerus=currency

Эти команды устанавливают вид цифровых полей, чтобы преобразовать содержащиеся в них данные в десятичные числа. Они интерпретируются следующим образом:

Вначале договоримся, что будем понимать под именем "currency" и как трактовать числа.	item nomen=currency; usus=numerus
Установим значения специальных символов.	signa plures=_
Установим значения сокращений.	lingua nomen="r';numerus=240
Эти значения определяются числами.	lingua nomen="p";numerus-1.25; plures=sic
	exitus nomen=currency

Важнее, конечно, чем синтаксические детали, лежащая в основе концепция. Ее суть в том, что KLEIO позволяет самому пользователю не только определить тип данных, а исходит из того, что каждый историк о своем источнике, из которого он формирует базу данных, имеет целый ряд рабочих гипотез, которые концептуально отличаются от данных в базе, но без которых данные обработать нельзя. Гипотезы представляют собой так называемую логическую среду базы данных.

Рассмотрим более подробно представление о работе историка: он прикладывает много усилий к тому, чтобы проникнуть в суть источника и черпает все свои знания из источников. В отличии от физика или математика он не может планировать никаких экспериментов и изменить свои источники. Историк получает цепь выводов только из данных источников, которые не могут изменяться.

Поэтому свои размышления об источнике историк обычно хранит в картотеке отдельно от данных. Картотеку он регулярно пополняет и редактирует, если ему удается проникнуть глубже в содержание источника и расширить свои знания о нем.

Этой основополагающей логике непозволительно меняться и тогда, когда источник хранится не только в книге, но и в базе данных. Поэтому KLEIO не пытается самостоятельно передавать запрос пользователя прямо в базу.

В качестве первого шага KLEIO всегда консультирует рабочие гипотезы историка о данных и проводит интерпретацию запроса пользователя по соответствующим правилам.

Рассмотрим, как этот принцип реализуется на практике. Одна из сложностей при обработке массовых источников, с которой тотчас же сталкивается начинающий, существенные расхождения при написании имен.

KLEIO в состоянии найти имя даже тогда, когда оно лишь "похоже" на искомое.

KLEIO: quaero nоmеn=жители;

KLEIO:pars nomen=repertorium[фaмилии,algorithmus,"Kaзaнникoв"]; KLEIO: scribe pars=totum[]; KLEIO: KLEIO:

Выполнение поставленной Вами задачи началось е(7="п1-7) sex м

date 27.7.1899 id п1-7

surname Казанков name Михаил

е(8="п1-8) sex м

date 13.1.1905 id п1-7

surname Косенков name Игорь

Что происходит в этом случае? Следуя принципу, что источник всегда прав, имя сначала заносится в компьютер в том виде, как оно сохранилось в источнике. Казанников Казанков Косенков.

Одновременно с вводом данных историк имеет обработанный и осмысленный материал об особенностях источника, он уже кое-что понял об основных закономерностях написания имен и сделал важные пометки в своей картотеке.

3 = С

Аналогичным образом, вы вводите в базу данных, управляемую KLEIO, точное написание оригинала. После этого вы устанавливаете свои предположения о частных орфографических правилах через соответствующие команды или - в терминологии системы - вводите логический объект, который сравнивает варианты написания имен в логической среде банка данных и как бы "сглаживает" расхождения.

Установим правила сглаживания расхождений	item nomen=kodierung;usus=soundex
Игнорируем все гласные	conversio sine="аеёиоуыэюя"pars signa="3C"
"з" и "с" сглаживаются	pars signa="H"
"н " и "нн " уравниваются	pars signa="K"
"к" остается неизменной	pars signa="в"
"в" остается неизменной	exitus nomen=kodierung
Заканчиваем устанавливать правила.

KLEIO сама отслеживает большое число нюансов, которые существенно влияют на содержание базы данных.

Следует также дополнительно подчеркнуть возможность изменять наши предположения об орфографии. Мы можем свободно изменять и логическую среду нашей базы данных, данные при этом будут оставаться неизменными.

Этот алгоритм будет давать хорошие результаты в зависимости от того, насколько корректно вы установили предположения. Так, например, можно работать с несколькими группами предположений - одна будет включать закономерности возникновения ошибок при написании на слух, другая - при переписывании из одного документа в другой. Или, например, одна группа предположений может включать правила сглаживания расхождений при написании немецких фамилий в русских источниках, другая - работать с парой польский-русский, третья - чешский-русский и т.д.

Это очень мощный принцип - обрабатывать данные через комплекс рабочих предположений. Посмотрите на следующий пример - как происходит поиск в полном тексте источника неправильных латинских глаголов. После того, как был сформирован запрос о том, что нас интересует латинский глагол "aufero" и его контекст в источнике, KLEIO дает следующие результаты:

Document (116="UHSI*116*130)

Decernimus ergo, ut nulli omnino hominum liceat

monasterium temere pertubare aut eius possessiones

*** auferre *** uel ablatas retinere, minuere uel

temerariis ilexationibus fatigare

Document (116="UHSI*116*130)

Decernimus ergo, ut nulli omnino hominum liceat

monasterium temere pertubare aut eius possessiones

auferre uel *** ablatas *** retinere, minuere uel

temerariis uexationibus fatigare

Document (119="UHSI*119*134)

Que iugera *** abstulit *** inde index civitatis cum

voluntate et concessione Romani episcopi.

Система ищет не одну форму глагола, а выдает все формы, которые встречаются в тексте.

В то время, как историк сам должен ломать голову по поводу фамилий и орфографии, в KLEIO в его распоряжение предоставляется готовая система лемматизации.

Другими словами, KLEIO даже не ждет, чтобы каждый пользователь различал правила латинской грамматики; он только должен установить их через интерфейс.

Тут может возникнуть вопрос: наш пример с именами исходит из работы с сильно структурированными данными, тогда как пример с лемматизацией латыни рассчитан на обработку полного текста. Что же такое все-таки KLEIO? И в какой модели это реализуется?

В принципе KLEIO - система управления структурированными, формализованными данными; однако благодаря неограниченной длине полей можно расширить область применения KLEIO до баз данных, содержащих полные тексты.

KLEIO не следует традиционным моделям данных, в особенности реляционным. Она использует особую модель, которая исходит из идеи семантической сети.

Конечно, в KLEIO тоже устанавливаются поля, которые, как мы помним, называются элементарными информациями. Объединяясь в объекты, они составляют информационную группу. Между информационными группами устанавливаются связи. Так, следующая информационная группа "person" состоит из четырех элементарных информаций (фамилия, имя, профессия, дата рождения):

рсгsоп$Иванов/Иван/кузнец/13.1.1966

Между информационными группами могут быть установлены, например, иерархические отношения. В самом деле, подобные структуры очень часто встречаются в исторических источниках. Какие же ограничения устанавливает KLEIO для отдельного понятия?

Максимальное число объектов типа "дом" около 250 000

Максимальное число квартир/дом около 250 000

Максимальное число семей/ квартира около 250 000

Максимальное число типов объектов, которые могут зависеть от предыдущего около 250 000

Максимальное число иерархических уровней около 250 000

KLEIO сама переводит иерархические структуры в сеть, устанавливая связи между отдельными объектами и между отдельными полями. Так из исходных данных возникает, в сильно упрощенном виде, следующая структура: