| ivanru Новичок
Сообщений: 13
На сайте с 2019 г.
Рейтинг: 14 | Наверх ##
24 марта 2022 22:03 24 марта 2022 22:06 Прочитал тему целиком, взялся за работу, могу сообщить предварительные выводы.
1. Проектов высокой степени готовности не нашел. То что есть обычно имеет ограниченный функционал. О своей работе рассказывал пользователь Rychagov, но до концовки и образца дело не дошло, на форуме его давно нет (
2. Excel, макросы VBA стал бы использовать только для маленьких проектов. Сам я этот вариант пробовал, - уже на нескольких сотнях фамилий понимаешь, что это абсолютно негодные инструменты для построения реляционной базы данных и ее анализа. Ну то есть в принципе делать что-то можно, но это как строить небоскреб из мусора в гараже...
Для первого подхода я выбрал Python + sqllite, т.е. реляционная БД, которая хорошо подходит для наших целей.
3. Существующие решения по распознаванию рукописного текста на текущем этапе не годятся для большинства задач. Ошибок слишком много, причем они концентрируются в критических местах (фамилии, названия населенных пунктов), так что их вычистка обесценивает выигрыш времени от автоматизации распознавания. Их можно использовать для индексации больших массивов (да и то, при условии качественного сканирования) и последующего сервиса первичного поиска по ним. Но для целевой работы отдельных исследователей над "своими" приходами требуется ручной ввод данных. Соответственно основной функционал программы а) ускоренный полуавтоматизированный ввод. б) выстраивание связей и формирование личностей на основе БД.
4. Проблема определения человека по ФИО , в том виде как это обсуждалось в данной теме, по большому счету отсутствует.
Основным структурным элементом базы является запись в метрической книге. Личность должна "создаваться" в результате анализа базы данных, после ее создания. Причем, каждый раз результат может быть иным, т.к. базу можно изменять (уточнять, исправлять ошибки) и дополнять. Выявление однофамильцев, ошибок присущих самим данным - это вопрос качества алгоритма анализа, но не ввода и хранения данных.
5. Ключевая проблема - структуризация или семантический анализ отдельных блоков данных при их вводе.
Например, в Книге рождений достаточно просто структурировать данные о дате и порядковом номере рождения, имени т.к. тут вариаций связанных с формой ввода и положением элемента в последовательности практически нет. Иное дело - текст записи о родителях и крестных, который весьма вариативен.
Сейчас вижу два основных способа решения задачи по разбиению этих блоков на структурные единицы (ФИО отца + его сословие и место жительства, религия, ФИО матери и т.п.).
№1 - структурированный ввод, с оригинальным для программы многовариантным алгоритмом разбиения на структурные единицы, с использованием оговоренных сокращений
№2 - использование готовых модулей семантического анализа, например, Natasha. Это более гибкий инструмент, но полученный результат все-равно нуждается в оригинальной переработке + доп вес программе.
Способы №1,2 можно комбинировать. Но легкого решения нет. Гарантированно будут ошибки для специфичных случаев, но продумал способ с ними бороться: программа на лету разбирает вводимый текст, демонстрируя пользователю "разобранный" вариант и сигнализирует об ошибках и несоответствиях, которые можно будет исправить в отдельных формах заготовленных под каждый структурный элемент.
В моем случае легкораспознаваемый шаблон ручного ввода записи, например, о рождении, может выглядеть так (структурные элементы определяются пробелами и переносом строки при вводе):
3 28 1 март евдокия (РОЖДЕНИЕ - №3 за год рождение (женщины) 28 февраля, крещенной 1 марта)
д полюбово к поликарп тимофеев лазарев васса борисова п (РОДИТЕЛИ: отец - деревни полюбово крестьянин Поликарп Тимофеевич Лазарев...
д починок к иван минаев макашенков д полюбово к евдокия пименова лазарева" (КРЕСТНЫЕ: крестный - деревни Починок крестьянин...
Следует заметить, что часть формируемых данных записи, которая будет сохранена в БД, например пол ребенка, фамилия жены, может определяться программно, после семантического распознавания, а также с учетом значений других структурных элементов (месяц рождения/крещения, лист, информация о священниках исполнявших обряд).
6. Для более качественного анализа и поиска связей потребуется создание нескольких библиотек. В их числе - перечень имен и их вариаций, например: Иван, пол - муж, вариации - Иоан, Иоанн и т.п..
7. Вопросы общей базы и доступности. Один из вариантов -- создание онлайн версии программы, которая бесплатно предоставляет базовый функционал пользователю, взамен на право доступа к введенным им данным (100 и более летней давности - под жесткие ограничения персональных данных не попадаем). Они, очевидно, имеют самостоятельную немалую ценность.
|
