Index: DESCRIPTION.md ================================================================== --- DESCRIPTION.md +++ DESCRIPTION.md @@ -1,6 +1,6 @@ -"Проект посвящен сбору и структурированию данных о топонимике Чувашии и сопредельных территорий" -- в этом документе мы постараемся ответить на вопросы, которые могут появиться к формулировке проекта. +"Проект посвящен сбору и структурированию данных о топонимике Чувашии и сопредельных территорий" -- в этом документе мы постараемся ответить на некоторые вопросы, которые могут появиться к формулировке проекта. Зачем? Работа над сбором чувашской топонимики заинтересовала нас в контексте решения задач более высокого уровня -- реконструкции языковой и этнической истории Поволжья и Прикамья. Это накладывает отпечаток на выбор источников данных, технические и прочие решения. Мы стремимся учесть доступные топонимические данные всех релевантных языков и временных срезов, что могут быть полезными для решения конечных задач. Что за источники данных? @@ -8,55 +8,93 @@ - книги - карты - данные Росреестра - прочее? -Как планируется структурировать данные? -Пока неясно, что должно быть базовой единицей документации топонимики. Мне (RI) думается, что для базовой единицы достаточно названия (на любом релевантном языке), типа сущности и временной метки. В идеале же, если думать про данные и метаданные, может быть оправдана, например, такая структура: -уникальный человекочитаемый идентификатор -тип топонима (село, город, деревня, река, микротопоним...) -название на русском языке -название на чувашском языке -названия на прочих языках... -дата создания источника данных -дата заполнения базы данных -кем заполнено поле -и так далее - -Не слишком ли много труда по структурированию информации для второстепенного проекта? -Ну... Да, много. Но. -В начале проекта обычно не очень понятно, какой объем внутренней бюрократии достаточен для достижения целей. Мои (RI) представления о полезном и прекрасном базируются на опыте участия в долгосрочном лексикографическом проекте: словарь бесермянского диалекта удмуртского языка. Словарю на текущий день 21 год, я участвовал в проекте примерно треть этого времени и имел возможность увидеть последствия продвигаемых мной технических и организационных решений. +Как планируется структурировать получаемые данные? +Навскидку, работа видится примерно так: +- есть сводная таблица найденных источников +- для каждого источника составляется таблица с упомянутыми в нем топонимами +- составляется общая таблица топонимов и общая таблица объектов (города, реки, деревни, урочища, ручьи и т.д.), которые можно восстановить по имеющимся данным +- для объектов даются ссылки на все их известные названия (собственно, топонимы) на всех языках в общей таблице топонимов +- в таблице объектов кроме названий дается информация о их местонахождении (координаты и пр.), времени бытования топонима и т.д. +- отдельно идет работа над таблицей с метаданными о топонимах: этимология, комментарии, прочее + +Итого 4 таблицы (источники, топонимы, объекты, метаданные) + по 1 таблице на каждый источник данных. + +Как все это будет организовано с технической точки зрения? +На данном этапе вопросов больше, чем ответов. Тем более, что в начале проекта обычно не очень понятно, какой объем внутренней бюрократии достаточен для достижения целей. +Мои (RI) представления о полезном и прекрасном базируются на опыте участия в долгосрочном лексикографическом проекте: словарь бесермянского диалекта удмуртского языка, http://beserman.ru/ -- если сайт в данный момент не открывается, то это очередное напоминание о рисках, связанных с чужими серверами. +Словарному проекту на текущий день 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) человеческая память несовершенна. -Хранение всех изменений долговременного проекта в системе контроля версий позволяет всем участникам: +Я не могу наперед знать, что именно окажется важным для проекта в будущем, поэтому я хочу хранить подробную историю изменений проекта и я готов жертвовать своим удобством ради доступа к истории. +Отступление про удобство VS бюрократию. +TLDR: информация не должна теряться. +Если более подробно, то бюрократия в долгом проекте необходима, потому что 1) люди совершают ошибки, 2) человеческая память несовершенна. +Хранение всех изменений в системе контроля версий позволяет всем участникам: 1) иметь полный доступ к истории проекта 2) быть уверенными, что они помнят одно и то же и говорят об одном и том же, будь то мельчайшее изменение или общая картина 3) исправлять случайные ошибки 4) понимать, кто является ответственным за любое изменение 5) не делать одну и ту же работу несколько раз 6) всегда иметь доступ к свежей версии файлов проекта и т.д. -ОК, как устроен проект с технической и организационной точки зрения? -Для организации хранения информации о проекте, включая полную историю проекта, используется уже упомянутый Fossil (https://www.fossil-scm.org). +Более конкретно о том, как может быть устроен проект с технической и организационной точки зрения. +Технические решения, принятые в начале работы, сильно влияют на возможную схему организации проекта. +Так, работу над таблицами можно вести в: +- MS Excel. Файлы .xlsx вполне можно хранить в fossil- или git-репозитории и тогда всегда будет ясно, кто над какой версией файла работал. Это не очень удобная схема, но возможная. +- Google Sheets. Все причастные сразу видят все внесенные изменения, история проекта, пусть и не в самом удобном виде, тоже доступна. Это самая удобная схема для повседневной работы. +- базе данных Sqlite или Postgres. Их тоже можно версионировать, например, с помощью софта типа https://github.com/dolthub/dolt Но это повышает требования к технической экспертизе участников и привязывает к сложным посторонним программам, будущее которых туманно. +- csv-файлах. Их можно редактировать с помощью Excel, Google Sheets, плагинов к популярным текстовым редакторам типа https://marketplace.visualstudio.com/items?itemName=janisdd.vscode-edit-csv или специальных текстовых редакторов типа http://home.hccnet.nl/s.j.francke/csved/unicsvedsetup.exe Это, по моему мнению, самая удобная схема с точки зрения простоты доступа к полной истории проекта, хотя и не самая удобная для повседневного редактирования таблиц. +Схемы можно комбинировать, например, никто не мешает держать регулярно обновляемую read-only версию всех таблиц на Google Sheets и вести основную работу в csv-файлах. +За кадром остаётся куча всяких более мелких вопросов, типа того, например, как в каждом случае можно организовать проверку на уникальность объектов в таблице, чтобы не возникало повторов и прочее в том же роде. Их тоже стоит в какой-то момент обсудить. +Для организации хранения информации о проекте, включая полную историю проекта, предлагаю использовать уже упомянутый Fossil (https://www.fossil-scm.org). Fossil это продвинутое средство управления программными проектами, он включает в себя: - систему контроля версий - вики - баг-трекер - форум и прочее Ко всему этому прилагается веб-интерфейс и CLI (подробнее см. https://www.fossil-scm.org/home/doc/trunk/www/quickstart.wiki). -Что касается организационного устройства, то для начала стоит обсудить роли. -Моя точка зрения такая, что у топонимических данных есть жизненный цикл и устроен он вот таким образом: -- ввод данных (data entry) + +Какие возможны роли у участников проекта? +Моя (RI) точка зрения такая, что у топонимических данных есть жизненный цикл и устроен он примерно таким образом: +- поиск и ввод данных (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). Естественно, текстовые данные, хранящиеся в репозитории, можно редактировать в любой момент, например, по итогам какого-то анализа или после более глубокого ревью. +Поэтому интерфейс ввода данных может отличаться от интерфейсов для остальных ролей, например, результат обработки первичных данных мы вводим в Google Sheets, далее там же проводим этап review и этап editing. Затем импортируем в Fossil эти табличные данные, скажем, в CSV или TSV формате, с прикрепленными метаданными, типа, кто вбивал исходные данные, кто выступал ревьюером, кто редактором, когда это было и т.д. Затем в какой-то момент экспортируем из fossil-репозитория некоторое подмножество данных для анализа, преобразуя при этом хранящийся в репозитории CSV-файл в какую-то базу данных (Postgres, sqlite3 etc). Естественно, текстовые данные, хранящиеся в репозитории, можно редактировать в любой момент, например, по итогам какого-то анализа или после более глубокого ревью. + +Как работать в fossil? +Сейчас файл репозитория проекта доступен по адресу: https://sjyrmi.ru/myfossil/chu_toponymy_1 +После установки fossil на свой рабочий компьютер, можно клонировать этот репозиторий с помощью команды clone: +fossil clone https://<имя пользователя>@<имя сервера>/<путь>/<к файлу>/<репозитория> ./<локальное имя файла репозитория>.fossil + +При этом лучше сразу создать директорию для последующей работы: +mkdir top_fossil_repos +cd ./top_fossil_repos + +Обычно при клонировании надо указывать имя пользователя (и сразу после этого пароль), например, так: +fossil clone https://santor@sjyrmi.ru/myfossil/chu_toponymy_1 ./chu_top_fossil_repo.fossil + +Если всё прошло удачно, то после этого можно открыть файлы из репозитория: +fossil open ./chu_top_fossil_repo.fossil + +То, что показано выше, распаковывает файлы проекта прямо в текущую папку. Это не всегда удобно, можно организовать работу иначе. +Например, можно создавать для работы над разными файлами разные папки: +mkdir ./data_entry +cd ./data_entry +fossil open ../chu_top_fossil_repo.fossil +cd .. +mkdir ./data_analysis +cd ./data_analysis +fossil open ../chu_top_fossil_repo.fossil + +После окончания редактирования файлов надо добавить все файлы, изменения в которых важны: +fossil add ./file_1.csv ./file_2.csv +и сделать коммит с описанием сделанных изменений: +fossil commit -m "add ~360 new river entries from ru.chuvash.org" + +После этого информация о том, кто, когда и какие изменения внес в файлы проекта, будет сохранена и в локальную версию репозитория, и на сайт, откуда был склонирован репозиторий.