Часть 2. Управление знаниями в Obsidian. Базовый рабочий процесс. Журнал. Источники и их библиотеки. Пример

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

В любом случае, чтобы организовать долгоиграющий рабочий процесс в Obsidian, придется,

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

• Либо самому очень долго, методично и довольно нудно проверять разные гипотезы и способы ведения.

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

Из вышенаписанного, я думаю, можно сделать вывод, что все таки не проканает пользоваться Обсидианом просто тупо как заметочником с плагинами. Точнее проканает, но с таким отношением, наверное, стоит в целом использовать что-то попроще.

К теме GTD. Довольно странное у вас обоснование выбора. Obsidian: free + НЕ open source + с большой натяжкой cross-platform. Тот же todoist: free + НЕ open source + cross-platform + заточен изначально для управления делами и проектами.

Про журнал. Смею предположить, что многие вещи, которые сулят интересными результатами, даются лишь через жесткую дисциплину.

Ну и да... Какие советы субъективны то?

Про папки в общем и про папку для homepage. Сначала довольно трудно отлипнуть от папок. А в силу того, что в целом вообще очень трудно видоизменить свой привычный порядок и характер мыслей, я решил оставить именно такую логику. В своей голове я представил человека, который будет разбираться и проговаривать что-то в стиле "так, мне нужна стартовая страница... какой там хоткей? И команду что-то не помню... ладно, посмотрю по всем файлам. Ааа... Home... Ну, окей. (Жмак) Так, значит на неё нужно вытащить все свои библиотеки, да?.. создаю заметки...перенесу-ка мышкой пока что... блин, помню, он вообще сказал, что про папки я должен забыть и на панели у него их нет... придется всё же запомнить как сюда попадать по-другому". Очень, конечно, утрированно.

Теперь про хабы, про MOC, про категории и прочее подобное. Тут я вижу такую логику развития (подчеркну слово, что именно "развития"). Сначала ты делаешь для себя всё наглядным и всё в одном месте. Далее ты набираешь какую-то критическую массу заметок по разным источникам. По ходу у тебя должны созреть идеи о том как обобщить полученные знания и как их поместить поближе друг к другу. Так ты начинаешь формировать категории (или что-то похожее). Далее у тебя формируется следующий критический момент – появляется приличное количество каких-то суммирующих, мета-заметок, тех же самых категорий. Здесь ты начинаешь создавать более короткие пути к новым точкам входа. Между делом у тебя происходят процессы оптимизации, которые уменьшают количество кликов, блужданий глазами и прочих тупняков. По сути только тут начнут появляться ваши условные нули в поиске. Далее ты начинаешь думать о своей системе более глобально. Возможно начинаешь добавлять какие-то гибкие иерархии. Начинаешь заменять какие-то линейные отображения своих структур на визуальные. Начинаешь увеличивать глубину проработки разных своих ветвей знаний. Куда более интенсивно скрещиваешь ветви между собой.

Про порчу простой красоты Obsidian. Всё-таки есть решения и попроще. Например, Typora. В ней даже толком соблазна не появится что-то накручивать и что-то выдумывать с логикой.

Краткий ответ на ваш комментарий. Нет. Программы не должны быть предельно простыми, ибо всё зависит от глаз смотрящего и от того, что этим "глазам" нужно получить.

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

Теперь примерно та же логика в преломлении 1С. Разумно же подумать, что появление автоматизации документооборота или бухгалтерского учёта есть следствие того, что усложнились системы производственных отношений. Или иначе говоря – системы стали сложнее, поэтому и методы управления стали более продвинутыми, комплексными.

Я хочу сказать, что возможно вам кажется, что вы прочитали какой-то тяжеляк, потому что вам ещё не приходилось управлять большим количеством знаний. Представьте, такую ситуацию. Перед вами система в которой вам показываются разные мысли и вы их смахиваете вправо или влево как в Тиндере. Очень интуитивно понятная логика, да? Если у вас выпало совпадение с мыслью, то вы с ней идете на свидание, потом поцелуйчики-постель и всё. Дальше снова свайп-влево, свайп-вправо. Теперь риторический вопрос. Сможете ли вы с такой простой системой построить космический аппарат?

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

Структура директорий у меня получилась другая, поддиректории не использую (нейминг возможно не совсем правильный, но мне так привычней):

• data - для файлов

• personal - все про меня: дневник, CV, планы, идеи, заметки про хобби, спорт и тд

• tech - технические заметки, что-то типа локального stackoverflow с проверенными решениями. каждая заметка про какой-то софт или пакет, например, grafana, pandas или postgresql

• projects - заметки про личные проекты, которые веду в процессе. одна заметка - один проект

• info - все подряд, одна заметка - одна тема, всегда можно разделить или объединить при необходимости, но главное, чтобы можно было найти в поиске

• notes - компиляции материалов в нормальные заметки, статьи для блога

В итоге легко писать заметки, всегда понятно куда их положить. А искать информацию еще легче. Workflow тоже предельно прост: если в голове появилась какая-то мысль или информация, которую нужно зафиксировать - пишу в заметку.

Согласен.

Думаю, что в каком-то зародыше можно найти такую рекомендательную систему в плагине Graph Analysis. Он с помощью разных алгоритмов анализирует, либо ваш граф, либо сами тексты. Результатом выдает иерархический список заметок, которые по мнению того или иного алгоритма наиболее релевантно связаны или могут быть связаны с текущей заметкой. Конечно это даже близко не искусственный интеллект, но хотя бы так.

Круто и ясно мыслите.

Ответ на первый вопрос.

• Я хотел, чтобы у меня появился текст, который бы я мог скидывать всем, кто мне интересен и симпатичен, чтобы в довольно структурированной форме сказать что-то в стиле

  • смотри, вот так я думаю и вот так я отношусь к процессам познания и роста

  • в рамках вот такой системы я обрабатываю информацию и в целом именно так мыслю все какие-то приходящие в мою голову потоки мыслей и идей

    • если хочешь, то попробуй также. вот инструкция

• Мне хотелось получить какую-то внешнюю критику, чтобы попытаться сквозь неё посмотреть на свою систему и тем самым как-то её исправить, переделать или просто дошлифовать

Ответ на второй вопрос.

• на эту статью ушло ровно столько сколько прошло между этой и прошлой публикациями (т.е. около 6-7 дней)

  • к сожалению сколько на прошлую статью ушло, я не могу сказать точно

  • я уделял примерно по 3-4 часа в день

    • мало это или много, не знаю

      • всё таки я не исследование написал, а перечислил конкретные практики, которые уже находились в моей голове

      • но с другой стороны, я попытался снабдить текст (в каком-то смысле, с особым фанатизмом) обилием мыслей и идей, которые так или иначе могут пригодиться при построении системы

Ответ на третий вопрос.

• Самое первое, что я сделал, это разметил структуру заголовками

  • Далее я писал только по тем заголовками, которые мне были интереснее всего

  • После по инерции дописал все самые скучные

• С помощью статьи я попытался сбросить свой интеллектуальный груз

• В целом неплохо подпитывала мысль, что я реализовываю именно своё видение, которое возможно кому-то пригодится

Не знаю. Я не смогу конкретно для вас вынести железобетонный вердикт в стиле "именно с такой базой знаний вы обязательно станете успешным, богатым и с большим агрегатом". (По правде говоря, ни для кого не смогу...)

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

Как вариант вам нужно поискать конкретных "живых" людей разработчиков ПО, которые ведут базу знаний. Ну, и естественно вам нужно подоканывать их своими самыми разнообразными вопросами.

Попалось видео разработчика. Популярность у канала никакущая, но зато парень очень кратко объясняет смысл ведения базы знаний. У него к сожалению подход строится на использовании изолированных инструментов, но суть остается прежняя – формируются мимолётные заметки (типа inbox-a), агрегируются источники, самостоятельно пишутся и связываются постоянные заметки и над всем этим кружится длиннющий классификатор (который поначалу нереально сделать, а потом, когда он разрастется нереально использовать без справки или какой-то хорошей логически обоснованной системы). Не уверен, что это вам прям поможет, но хотя бы для примера.

Разделяю ваше мнение.

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

Два языка ещё ладно, но вот три... Тут я не шибко могу что-то прям очень весомое подсказать. Однако попробую подкинуть пару идей.

Вы можете добавлять к заметкам aliases. Возможно, чтобы немного упростить этот процесс (т.е. не делать для всех заметок сразу), можете добавлять aliases по мере того как вы вспоминаете о заметке: вспоминаете на русском – добавляете русский вариант названия заметки; на английском – английский; на немецком – немецкий. Естественно, поначалу придётся как-то добраться до нужной заметки (т.е. поперебирать языки и варианты ключевых слов). Но со временем, я думаю, у вас получится большую часть своей базы хорошо зашлифовать.

Если говорить в контексте какой-то определенной ветви вашей базы знаний. Например, в контексте ветви, которая у вас порождена какой-то определенной книгой. То разумнее всего делать все связанные заметки на одном языке. Т.е. если книга на немецком, то вы делаете все заметки по ней на немецком. Позже книга у вас отнесется к какой-то категории. И скорее всего, в будущем вы будете искать сначала именно с помощью категорий то, как у вас могут быть связаны источники и заметки в них. А там думаю не должно появиться каких-то больших проблем в том, чтобы быстро понять как можно связать разные заметки из разных источников – даже, если заметки будут на разных языках. Давайте на примере для простоты. Допустим у вас образовалась категория "кулинария", к ней у вас будут относиться вероятно книги по готовке. В самих же книгах, скорее всего, будут рецепты. Пусть, например, мы хотим из всех наших книг по кулинарии достать и свести в одну заметку все рецепты по приготовлению "мяса". Разве будет какой-то сложностью найти во всех книгах заметки с упоминанием "мясо...", "fleisch..." и "meat..."? Думаю не особо. Другое дело, что вам просто придется искать сразу 3 одинаковых по сути слова. Но тут уж ничего не поделать.

Вообще рекомендую глянуть вот это видео. Там будет парень немец со вторым английским языком (ролик на английском). У него в базе сразу два языка – английский и немецкий. Сама же база у него строится очень минималистично, но не с точки зрения технической, а именно как рабочий процесс (у него он прям чёткий, гладкий, без излишеств, хорошо автоматизированный). Возможно этот ролик будет не столь полезен вам для построения собственной базы знаний, сколько для того, чтобы понять как люди могут жить с двумя языками в контексте базы знаний (спойлер – не так уж просто, но все равно неплохо).

Ответ на 1-ый вопрос.
Не знаю как правильнее будет для вас. Вам нужно сначала понять какую пользу вы хотите получить, а потом представить в голове некоторую эмуляцию рабочего процесса, который будет извлекать эту самую пользу. Так вы можете позадавать себе вопросы в стиле:

• Я буду искать сначала конкретную заметку, а потом переходить на классификатор, который подскажет, что еще есть по этой теме?

• Я буду искать сначала классификатор, а потом все связанные заметки?

• Я буду искать и заметку, и классификатор?

• Каким образом я собираюсь в целом навигироваться по заметкам: мне важно есть ли направление связи или я вообще могу по локальному графу всё понять?

• Собираюсь ли я делать какие-то автоматизации и будет ли для них (автоматизаций) разница в какую сторону идет связь и вообще должна ли обеспечиваться связь именно через заметки (а не например теги или метаданные)?

Стоит также помнить, что могут образовываться заметки, которые напрямую у вас не относятся к определенной категории. Логику работы с ними тоже нужно как-то в своей голове обозначить.

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

Что-то конкретнее не могу сказать, т.к. мне не хватает конкретного примера.

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

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

Например, что-то такое. Немного отличается от скрина, но суть та же.

---
cssclass: dashboard
---
## 🚪 Входы

- ➡ [[index]]
	- 📅 [[tasks and ideas from daily journal|свод по дням]]
	- 🗓️ [[tasks and ideas from weekly journal|свод по неделям]]
	- [[help]]

- <mark style="background: #FFB8EBA6;">👀content</mark>
	- [[articles]]
	- [[videos]]
	- [[courses]]
- <mark style="background: #FFB8EBA6;">👀content</mark>
	- [[books]]
	- [[movies]]
	- [[podcasts]]

- <mark style="background: #D2B3FFA6;">🕳others</mark>
	- [[inbox and pending and orphan notes]]

Попробуйте посмотреть этот видос

Первый вопрос. Про темы

Немного про категоризацию я вот тут написал. К этому могу разве что ещё немного объяснений добавить.

Вы добавляете в систему, допустим, 10-15 каких-то источников. Работаете с ними. В какой-то момент, вам может показаться, что эти источники сильно тематически друг с другом связаны. Вы думаете как их можно связать друг с другом.

Связь можно сделать через категорию. Пусть это, например, будет категория "furniture assembly instructions" (инструкции по сборке мебели). Создаёте заметку с одноименным названием (помечаете её тегом 🗺️ или каким-то иным вам привлекательным образом). Далее пробегаетесь по своим источникам, находите все те самые 10-15 связанных по тематике источников и категоризируете их. В статье я это сделал через поле "category". Можете ещё раз глянуть на пример книжной заметки в статье.

Если вы заранее знаете какая у вас может появиться категория, то можно в заметках-источниках проставить призрак заметки. Когда необходимость в категории появится, то вы просто создадите заметку и оформите её как надо.

Можно ещё через inbox аккумулировать источники. Это скорее можно использовать для того, чтобы не приходилось вручную проходиться по всем источникам в поисках нужного. Т.е. вы создаете заметку и в ней перечисляете все нужные вам ссылки и материалы по ходу работы или исследования, а потом со временем преобразуете её во что-то более постоянное (например, мета-заметку).

Далее, можно в заметке-категории сделать dataview-запрос на то, чтобы был сделан показ заметок относящихся к именно текущей категории. Это можно сделать, например, так:

```dataview
LIST
WHERE contains(category, [[]])
```

Можно ещё более точечно сгруппировать источники или просто заметки. В таком случае вы создаете мета-заметку и в ней перечисляете всё, что вам нужно. Мета-заметку также стоит отнести к какой-то категории. Возможно будет что-то такое (первая строчка – это название заметки):

инструкции для сборки шкафов диванов кресел
category:: [[furniture assembly instructions]]

# Инструкции для шкафов

- угловые шкафы
  - [[инструкция по сборке какого-то углового шкафа]]
  - ...
- встроенные шкафы
  - [[инструкция по сборке какого-то встроенного шкафа]]...


# Инструкции для кресел и диванов

## Инструкции для кресел 
...
## Инструкции для диванов 
...

Небольшое дополнение. Чтобы категориальные заметки не были подвешены в воздухе стоит их все создавать в какой-то индексной заметке (в статье я эту заметку так и называл "index"). Саму же индексную заметку стоит вынести, например, на dashboard. Это нужно для того, чтобы можно было легко искать все нужные темы и в целом понимать какие категории есть в системе. А вот сразу пример dataview-запроса, который отобразит вложенные категории, если у вас таковые появятся:

```dataview
LIST
FROM #🗺️
WHERE 
	!contains(file.inlinks, this.file.link)
	AND
	file.link != [[]]
SORT file.name ASC
```

Второй вопрос. Про сортировки

Можно плагин sortable добавить. Он позволит нажимать на колонки таблиц dataview и менять порядок сортировки.

В остальном же сортировку и фильтры в dataview можно сделать только вручную, т.е. делать отдельные запросы. Например, категориальная заметка является примером отдельного фильтра.

Если вам нужны прям какие-то продвинутые (более автоматизированные) возможности в сортировке и фильтрации, то стоит поставить плагин db-folder.

Третий вопрос. Про даты

Наверное, самый простой способ, это использовать плагин natural language dates.

Ещё вариант это предварительно добавлять в шаблоны дату с помощью конструкции:

<% tp.date.now() %>

Можно немного усложнить логику. Так можно добавить меню, которое при создании заметки будет спрашивать "Вы сегодня начали?". Если ответ "да", то он проставит сам дату в указанном месте:

<%* let start = await tp.system.suggester(["Нет", "Да"], ["", " " + tp.date.now()] , false, "Вы сегодня начали?") _%>
start:<% start %>

Четвёртый вопрос. Про верность схемы работы с источниками

Да, схема, которую вы привели верная.

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

type: instruction

Но так лучше не делать, если нет уверенности в том, что это действительно нужно и это действительно принесёт пользу.

Пятый пункт, но не вопрос.

Довольно трудно выдать целиком всё видение про упорядочивание базы знаний, да ещё и в рамках комментариев. Более того, способов сгруппировать как-то знания довольно много и все они нуждаются в персональном рассмотрении. Чтобы у вас появилось более объемное видение того как всё это можно устроить, стоит глянуть или даже помучить своими вопросами других обсидианщиков.

Я не знаю почему у вас так. Проверьте документацию.