Идея для организации структуры в папке db

[scsmash3r]

Сейчас структура - это чисто набор .md файлов, что не имеет значения для Обсидиана, однако играет роль при обзорном взгляде на информацию (если, например, человек хочет что-то найти без Обсидиана).

Есть вот такая штука, и можно попробовать использовать её: https://johnnydecimal.com

[scsmash3r]

Сделав форк оригинального репозитория, я немного поразмыслил над тем, насколько "всё это" (содержимое папки /db) будет удобно для конечного пользователя.

Необходимо помнить, что мы работаем не с репозиторием де-факто как таковым, а с vault-ом Обсидиана (сторонней программы). Vault - это отдельная сущность в Обсидиане; по сути это папка с файлами/структурой/связями и т.д. Представьте, что мы хотим интегрировать уже имеющиеся у разных пользователей vault'ы в нашу базу знаний, причём таким образом, чтобы можно было выбрать, что именно "подключить" к основной базе.

В чём суть проблемы

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

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

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

Возможное решение

Вместо фактического создания форков и строгой проверки пушей (вручную) у git'а есть вот такая штука, которая называется подмодули.

Подмодули решают такие проблемы:

• основной репозиторий не нужно форкать, а значит не нужно "плодить сущности" и дублировать кучу файлов из assets/. Необходимо беречь байты =)
• основной репозиторий задаёт только базовую структуру и может служить примером для организации других vaultов (которые представлены именно как подмодули).
• другие vaultы пользователей - это независимые digital gardens, которые любой другой юзер (или владельцы основного репозитория) могут подключать с помощью файла .gitmodules.

В сухом остатке: вместо форков и полного строгого дублирования всей структуры мы можем обходиться "мягким" подключением подмодулей (других репозиториев), которые будут представлены как vaultы пользователей в нашей основной папке db/. В итоге это будет выглядеть как-то так:

Основной репозиторий без подмодулей:

db/00 Книги.md
db/00 Наука.md
[...]
Zettelkasten Цеттелькастен.md

Затем, если мы решили добавить подмодуль (репозиторий) другого пользователя scsmash3r, который также ведёт какую-то базу материалов (это делается с помощью .gitmodules), то структура будет следующей:

db/scsmash3r/00 Общая семантика.md
db/scsmash3r/someotherstuff.md
db/00 Книги.md
db/00 Наука.md
[...]
Zettelkasten Цеттелькастен.md

Таким образом, можно будет не только работать с форком и менять основную базу (мало кто будет заниматься изменением существующей структуры, т.к. необходимо ждать пул и решать возможные конфликты), но и подключать базы данных (vaults) других пользователей, которые могут быть даже не знакомы с основным репозиторием (что будет проще для многих пользователей и также позволит формировать свои базы данных на основании того, интересует ли их digital garden другого пользователя или нет).

[scsmash3r]

Заметка: assets папку всё-таки тоже стоит держать в db/, если будет структура с подпапками. Вменяемые имена для картинок также дадут возможность обсидиану искать и по именам картинок + в github имеет ограничение на размер репозитория, поэтому лучше каждому отдельному пользователю организовывать свои картинки в своём digital garden, нежели всё заливать в один главный репо. Надо подумать, как вообще быть с картинками... С медиа-файлами есть определённые сложности.

[syeysk]

Плюсы:

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

Вопросы:

1. Есть ли в варинате с субмодулями подводные камни, которые могут привести к проблемам?
2. Есть ли смысл подумать о механизме, которые после объедиения нескольких баз выполнит проверку на дублирование информации?
3. Нужны ли дополнительные рекомендации к структуре базы/информации, которые позволили бы сделать слияние баз качественным?

[scsmash3r]

1. Могут. Например, проблема со связями: если у каждого пользователя своя база, то выстраивать связи (ссылки на другие материалы) с материалами из других баз станет на порядок сложнее или даже невозможно.
2. Смысла нет, т.к. учитывая "сохранение индивидуализма", дублей не будет - разве что по количеству ключевых слов и по близости темы. Но затраты на реализацию не будут того стоить.
3. Тут стоит подумать. Возможно, если создать какой-то общий structural styleguide, то совмещать базы разных пользователей было бы легче.

Так или иначе, пока что работа ведётся с одним репозиторием + форки.

[syeysk]

1. Файл requirements.txt поможет решить проблему? Например, в файле указывать, нужно ли подключать базы из подключаемого репозитория. Но потребуется подобие менеджера пакетов, который попробовать сделать в составе Obsidian'а. Да и субмодули, кто хочет - может же в своих репозиториях использовать, подключая основной и остальные, так как иерархий нет у нас.

Получается, пункты 2 и 3 неактуальны. По 3-му пункту - достаточно подмечать какие-то моменты.

Я начал формировать свою базу сразу, как узнал об Обсидиане, потому что имел кучу записок по разным папкам, устройствам, облакам. Сейчас почти всё объединил, структурировал. Я бы хотел встроить свою базу локально. А часть информации можно и в общий репозиторий предложить. Так что, я бы поэкспериментировал :)

[syeysk]

Предлагаю составить некую инструкцию, как человек сможет подключить в свою базудругие базы. Думаю, твоё предложение использования пути /db/имя_пользователя/ является первым пунктом в structural styleguide.

У нас получится обсудить johnnydecimal в голосовм чате с другими участниками? Хочется кратко ознакомиться с ней и обсудить, как её эффективно применить.

[scsmash3r]

Касательно инструкции и подключения: идея была в том, что ссылки на все другие дополнительные git-репозитории, которые можно было бы подключить, находились в файле .gitmodules. Пользователи, которые не умеют работать с гитом, заглядывали бы в этот файл и просто переходили в нужный репозиторий, скачивая его как .zip архив и добавляя локально в свою базу как им угодно. Те, кто работает с git, могли бы запрашивать те базы, которые посчитают нужным, посредством самого git. В перспективе можно было бы отдельный сайт сделать, где можно было бы подключать и собирать любые базы, сделав пользователям какой-нибудь простой UI.

Касательно johhnydecimal: это лишь подход касательно структуры и упорядочивания. И этот подход является опциональным. Каждый отдельный пользователь, если он работает с Обсидианом, как-то по-своему уникально хранит и структурирует информацию. Поэтому привести её к какому-то одному виду, если пользователь работает со своей базой отдельно, всё равно не получится. Главный репозиторий мог бы взять эту структуру и показывать её в качестве примера, но пока что мы обусловились "не усложнять" и обойтись без папок и подпапок =)

[redboo]

Почему все файлы в одной папке?

Первоначально было задумано использовать систему ведения заметок Zettelkasten, подробнее в статье.

Как добавить свою базу?

Для начала стоит определиться, хотите ли вы делиться публично своими заметками? Если ответ утвердительный, то рассмотрите возможность пересмотра структуры своей бызы в сторону Zettelkasten.
Если пользователь хочет вести приватные заметки (т.е.: "моя, структурированная по-моему база, никому не покажу"), то достаточно создать свою папку и добавить её в исключение файла .gitignore или воспользоваться уже существующими daily (для ежедневных быстрых заметок) и ideas (заметки на тему ИДЕЯ!).