Chuvash Toponymy Database v.0.1

Artifact [0695dd8ca4]
Login

Artifact [0695dd8ca4]

Artifact 0695dd8ca4d5421ac4d61fa697cfa945940a566b7c2f665bc6046ed4bf5202f1:


Текстовый лог встречи 28 марта 2025 года

1) стоит ввести в temporal отдельную колонку для фильтрации, чтобы можно было при работе видеть только связанные друг с другом топонимы (например, главную деревню и все поглощенные ею когда-либо), назвать эту колонку можно, например, NEST -- в этой колонке пусть значится temporal.ID наиболее близкого к современности русского топонима, представляющего, по мнению исполнителя, всё гнездо связанных между собой названий -- DONE

2) всем причастным стоит, наконец, разобраться, как устроена сортировка по нескольким столбцам в Google Sheets

3) Мы с Юлей ждем от Саши папку с дополнительными источниками, наводим там порядок, присваиваем им ID и т. д. -- DONE "https://disk.yandex.ru/client/disk/Топонимическая литература"

4) После заполнения вкладки experiments для первых нескольких десятков топонимов, решаем, стоит ли делать отдельную таблицу для истории фиксаций каждого топонима (со ссылками на карты и прочие источники) или достаточно будет ввести под это еще одну колонку в temporal

5) Нынешние тесты структуры БД стоит перенести из репозитория прямо в Google.Sheets, чтобы они происходили не постфактум, а в реальном времени -- стоит вложиться в уменьшение временного зазаора между работой и архивированием проделанной работы

6) Для истории: составить список ключевых дат проекта. Начало, кажется, было примерно в середине апреля 2023 года, но я потом посмотрю точнее по своим записям

7) Проблема микротопонимов:
- мы предполагаем, что большинство микротопонимов не живет долго (пара веков)
- мы предполагаем, что этимология большинства микротопонимов бесполезна для заявленных историко-лингвистических целей нашего проекта
- мы предполагаем, что точно картографировать абсолютное большинство микротопонимов невозможно без поездок "в поле"
- на подобные поездки по Чувашии ресурсов у нас нет и не планируется
- поэтому мы считаем, что не стоит стремиться к тому, чтобы на итоговой карте были отображены все микротопонимы, содержащиеся в базе
- микротопонимы а) стоит картографировать только после какой-то разумной селекции и б) стоит картографировать не точно, а приблизительно, с привязкой к ближайшему ойкониму, например (эта информация у нас есть из книги Дубанова)
- те микротопонимы, которые уже есть в базе, должны в ней остаться, они с большой вероятностью принесут хотя бы косвенную пользу, но полноценно картографировать стоит только те, для которых @AlexanderSavelyev предполагает марийскую этимологию
- даже для прошедших такую префильтрацию микротопонимов стоит иметь в виду какое-нибудь ограничение типа "не более 6 микротопонимов, привязанных к одному и тому же ориентиру"
- конкретное техническое соглашение для приблизительного отображения координат миротопонимов обсудим в будущем (например "не более 6 маркеров по часовой стрелке вокруг топонима-ориентира" и прочее в том же роде)

8) continuity -- процесс определения преемственности между топонимами в условном 17 веке и в современности мы сейчас представляем себе слабо. Поэтому сейчас закладываемся на примерно такой ход работы: сначала обработка источников XVIII-XX вв. для территории Чувашии, затем расширение географии на Марий Эл и Татарстан, а затем, если будет на то воля божья, работа с более ранними источниками. В приоритетах сделать minimum viable product для демонстрации возможностей создаваемого инструмента, затем расширение географии, затем углубление в хронологию

9) Продукт, о котором идет речь -- этимологизированные топонимы, визуализируемые на протяжении XVIII-XX вв. на территории Чувашии:
- этимологический аспект -- Саша
- географический -- Матвей
- временной -- Юля и Руслан
- технический -- Руслан

MironovaYuliya — 29.03.2025 14:21
По поводу пункта 5 добавлю: Сейчас Руслан, фактически, вручную делает проверку, например, дублей в таблицах (со скриптом, понятно, но все же это занимает время и голову). На этом моменте у меня возникла мысль, что в керамике у Ани Гирич табличка настроена так, чтобы дублируемые номера сразу высвечивались. Я честно не узнавала и слабо представляю, как это было реализовано и как это можно сделать у нас, но мне кажется, имеет смысл утащить эту технологию и сюда. Однако, я сейчас в процессе поняла, что, если мы говорим, о дублировании ID, то они у нас и так дублируются по причине того, что одно ID для ойконимов на двух (и, может, трех) языках.... В общем, это надо обдумать. Я спрошу у Ани общую картину и, может, тонкости

По поводу 1 и 2: сейчас мы имеем очень немного строк в таблице temporal, но уже имеем некоторый шанс запутаться между связями ойконимов, потому актуален вопрос фильтрации и сортировки. Пока решили ввести доп. столбец и фильтровать эти связи ойконимов по нему. И внутри этой фильтрации сортировать по годам так, чтобы можно было наглядно увидеть хронологию смены ойконимов. Но я думаю, это можно сделать удобнее, тоже пока буду разбираться/осмысливать

Сюда же - пришла сейчас оформившаяся мысль, что, вероятно, стоит переработать принцип присваивания ID. Сейчас мы имеем бесконечное количество цифр, и надо потратить секундочки, чтобы понять, откуда эти цифры берутся. Да, это прописано в названии столбца, но, возможно, стоит добавить буквенных обозначений, по аналогии с руникой, например. Тогда это будет более человекочитабельно. Но вопрос к Руслану: насколько машиночитабельно? 

Ruslan Idrisov — 29.03.2025 15:09
"о дублировании ID, то они у нас и так дублируются по причине того, что одно ID для ойконимов на двух (и, может, трех) языках" -- не, ID не дублируются, они уникальны для каждого входа в таблице linguistics, там, где похоже на дублирование, это на самом деле указание на номер той сущности, которая среди них главная

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

"возможно, стоит добавить буквенных обозначений, по аналогии с руникой, например. Тогда это будет более человекочитабельно" -- добавление букв в айдишники добавит человекочитабельности, если в нашей модели данных относительно мало типов сущностей с ID. Тут стоит подумать, стоит ли оно того или этих типов и связей слишком много с самого начала и лучше как-то иначе подсвечивать связи. Не знаю пока, буду думать

"о дублировании ID, то они у нас и так дублируются по причине того, что одно ID для ойконимов на двух (и, может, трех) языках" -- не, ID не дублируются, они уникальны для каждого входа в таблице linguistics

AlexanderSavelyev — 01.04.2025 19:59
Идея в том, что наш топонимический проект может и должен расширяться не только в географическом отношении (от Чувашии к соседним регионам) и не только в хронологическом (от современности к более ранним топонимическим источникам). Следует понимать выполняемое сейчас как создание пространственно-временного фреймворка для изучения этноязыковой и культурной истории посредством преобразования хаотично структурированной информации в табличную форму (базы данных). Потенциально интегрирована в систему может быть не только топонимическая и шире лингвистическая информация: это и археология, и данные письменных источников. В частности, я продумывал, как могут быть таблично обработаны источники типа «Записки» ибн Фадлана о путешествии в Волжскую Булгарию. Её содержание может быть описано в таблицах: упоминаемые топонимы, этнонимы, индивиды, объекты материальной культуры, объекты нематериальной культуры. Связность системы будет обеспечена отсылками к другим её элементам: напр., от упоминаемых ибн Фадланом топонимов будут идти ссылки к соответствующим вхождениям топонимической базы, ежели тождество считается установленным. Это общая идея, детали нуждаются в проработке.