ADDED DESCRIPTION.md Index: DESCRIPTION.md ================================================================== --- /dev/null +++ DESCRIPTION.md @@ -0,0 +1,62 @@ +"Проект посвящен сбору и структурированию данных о топонимике Чувашии и сопредельных территорий" -- в этом документе мы постараемся ответить на вопросы, которые могут появиться к формулировке проекта. + +Зачем? +Работа над сбором чувашской топонимики заинтересовала нас в контексте решения задач более высокого уровня -- реконструкции языковой и этнической истории Поволжья и Прикамья. Это накладывает отпечаток на выбор источников данных, технические и прочие решения. Мы стремимся учесть доступные топонимические данные всех релевантных языков и временных срезов, что могут быть полезными для решения конечных задач. + +Что за источники данных? +Для сбора данных мы хотим инвентаризировать доступные источники: +- книги +- карты +- данные Росреестра +- прочее? + +Как планируется структурировать данные? +Пока неясно, что должно быть базовой единицей документации топонимики. Мне (RI) думается, что для базовой единицы достаточно названия (на любом релевантном языке), типа сущности и временной метки. В идеале же, если думать про данные и метаданные, может быть оправдана, например, такая структура: +уникальный человекочитаемый идентификатор +тип топонима (село, город, деревня, река, микротопоним...) +название на русском языке +название на чувашском языке +названия на прочих языках... +дата создания источника данных +дата заполнения базы данных +кем заполнено поле +и так далее + +Не слишком ли много труда по структурированию информации для второстепенного проекта? +Ну... Да, много. Но. +В начале проекта обычно не очень понятно, какой объем внутренней бюрократии достаточен для достижения целей. Мои (RI) представления о полезном и прекрасном базируются на опыте участия в долгосрочном лексикографическом проекте: словарь бесермянского диалекта удмуртского языка. Словарю на текущий день 21 год, я участвовал в проекте примерно треть этого времени и имел возможность увидеть последствия продвигаемых мной технических и организационных решений. +В глоссарии проекта Fossil (https://www.fossil-scm.org) дано такое определение проекта -- "A collection of one or more computer files that serve some conceptually unified purpose, which purpose changes and evolves over time, with the history of that project being a valuable record". +Мы не может наперед знать, что именно окажется важным для проекта в будущем, поэтому мы храним подробную историю изменений проекта. + +То есть, на самом деле бюрократии еще больше, чем казалось вначале? +Да, именно так! Но без некоторого технического усложнения невозможно достичь плюсов, которые эта бюрократия дает, поэтому это усложнение оправданно. + +Какие плюсы дает вся эта бюрократия? +TLDR: информация не теряется. +Если более подробно, то бюрократия нужна, потому что 1) люди совершают ошибки, 2) человеческая память несовершенна. +Хранение всех изменений долговременного проекта в системе контроля версий позволяет всем участникам: +1) иметь полный доступ к истории проекта +2) быть уверенными, что они помнят одно и то же и говорят об одном и том же, будь то мельчайшее изменение или общая картина +3) исправлять случайные ошибки +4) понимать, кто является ответственным за любое изменение +5) не делать одну и ту же работу несколько раз +6) всегда иметь доступ к свежей версии файлов проекта и т.д. + +ОК, как устроен проект с технической и организационной точки зрения? +Для организации хранения информации о проекте, включая полную историю проекта, используется уже упомянутый Fossil (https://www.fossil-scm.org). +Fossil это продвинутое средство управления программными проектами, он включает в себя: +- систему контроля версий +- вики +- баг-трекер +- форум и прочее +Ко всему этому прилагается веб-интерфейс и CLI (подробнее см. https://www.fossil-scm.org/home/doc/trunk/www/quickstart.wiki). +Что касается организационного устройства, то для начала стоит обсудить роли. +Моя точка зрения такая, что у топонимических данных есть жизненный цикл и устроен он вот таким образом: +- ввод данных (data entry) +- обзор данных (data review) +- редактирование данных (data editing) +- анализ данных (data analysis) +- публикация данных (data publishing) +- еще что-то? +В роли data entry person может выступать кто угодно после первичного обучения, а последующие роли (reviewer, editor, analyst, publisher) требуют большей экспертизы. +Поэтому интерфейс ввода данных может отличаться от интерфейсов для остальных ролей, например, результат обработки первичных данных мы вводим в Google Sheets, далее там же проводим этап review и этап editing. Затем импортируем в Fossil эти табличные данные, скажем, в CSV или TSV формате, с прикрепленными метаданными, типа, кто вбивал исходные данные, кто выступал ревьюером, кто редактором, когда это было и т.д. Затем в какой-то момент экспортируем из fossil-репозитория некоторое подмножество данных для анализа, преобразуя при этом хранящийся в репозитории CSV в базу данных (PostGres, sqlite3 etc). Естественно, текстовые данные, хранящиеся в репозитории, можно редактировать в любой момент, например, по итогам какого-то анализа или после более глубокого ревью. ADDED README.md Index: README.md ================================================================== --- /dev/null +++ README.md @@ -0,0 +1,9 @@ +# Chuvash_Toponymy_1 # + +Проект посвящен сбору и структурированию данных о топонимике Чувашии и сопредельных территорий. + +Цели: +- сбор данных о топонимике Чувашии +- сбор данных о сопредельных территориях +- структурирование данных и создание машиночитаемых датасетов +- визуализация датасетов с помощью картографических и прочих методов