Comments 14
Статья весьма неплохая. Однако сама предложенная структура даже близко не гибридная. Это всё ещё жёсткая иерархическая система (примерно такая же, как Johnny.Decimal).
Это всего лишь образец для адаптации совмещающий в себе элементы классики и Zettelkasten, а также "отправная точка", как и написано в статье. Например, сейчас у меня в основном рабочем хранилище сокращенное количество каталогов, согласно требованиям стандарта, а также не используются числовые префиксы и заглавные буквы, согласно требованиям для автоматизации. Мне бы очень хотелось вместить все эти, и ещё кучу других нюансов в статью, но тогда бы она превратилась в энциклопедию. Увы...
Настоящий Цеттелькастен и есть такая гибридная иерархическая система с небольшим облаком случайных ассоциативных связей. Иерархия обеспечивается нумерацией, но можно все заменить деревом из папок при желании - правда при наличии связей это бессмысленно. Другое дело, что в ЦК эти связи различаются принципиально - структурные задаются нумерацией, определяя место в иерархии, а ассоциативные - вот теми самыми гипертекстовыми ссылками.
Занимаюсь погружение в Obsidian, спасибо за статья. По немного из каждой статьи черпаю для себя полезные инструменты, навыки, методы.
Я тоже изначально начал просто писать в обсидиан, потом начал раскладывать по папкам. Потом создал шаблон для заметки, каждый день создаю новую заметку с датой в теме (с помощью плагина), в заметке пишу все в течение дня и ставлю теги (линукс, еластиксерч, кейс, факап и тд). В конце дня стараюсь (но не всегда получается) делаю ревизию и добавляю теги, кладу в папку "работы". Отдельные заметки со своими темами создаю с тегами и раскладывать по папкам. Стараюсь не усложнять схему, все работает интуитивно...
поддерживаю, я делал практически то же самое, только что то новое у меня идёт в гтд канбан плагин или специальную заметку с неотсортированными заметками по всем техническим заметкам, коих потом сортирую. а насколько теги удобны в этом плане?
Веду такой дневник в чатботе. Потом можно разные выгрузки просить сделать.
Но вероятно через ии-плангины к обсидиан тоже можно
Вы совершенно неправильно воспринимаете Zettelkasten - и я вас даже не виню, это устоявшаяся ошибка всех, кто читал о нём в пересказе. Zettelkasten никогда не был сетевой системой. У меня даже лежит на эту тему недописанная пара статей, надо будет заняться.
Если коротко - Zettelkasten иерархичен, причем строго, по определению - у каждой заметки есть предок. Сама система нумерации позволяла вставку любой заметки в любом месте как категорию предыдущей или как продолжение какой-то мысли, ветвление. Это были не рандомные уникальные ID типа временной метки, как это принято показывать сейчас, а что-то типа 1/23a/7b55 - начинались с какой-то базовой темы (что уже предполагало базовую иерархию, Луман был академическим ученым все же), но не очень строгую. И дальше по цепочке рассуждений. По сути Луман хранил в своих ящиках деревья, которые можно было легко отсортировать по порядку и найти нужную последовательность. Последовательностями он и мыслил - каждая мысль крепко "сидела" в каком-то конкретном месте - что-то придумал - записал как аргумент, пример, контраргумент, замечание. Он всегда знал что куда "вставить".
Слой случайных, ассоциативных связей, которым так восхищаются "сетевики" был очень редким, множество заметок вообще не ссылалось на другие просто потому, что их позиция в иерархии задавалась номером - мы всегда могли знать кто предок заметки по ее номеру и кто ее потомки. Весьма вероятно, что вот эти "блуждания", "прогулки" Лумана были именно походами по цепочке рассуждений. Фактически, он конспектировал свои заметки не просто как конспекты, а как рассуждения, элементы будущей книги, которые ему достаточно было просто переносить на бумагу - это не очень удобно для тех, кто ничего не публикует, но все же может быть полезно.
Я много думал на эту тему и достаточно много читал - это популярные дискуссии среди поклонников Цеттелькастена, но пришел к выводу, что именно такая система должна работать. Просто случайный граф превращает систему в дурацкую википедию, которая будет хуже по качеству, чем настоящая, не дает возможности ничего найти или "вставить" пришедшую мысль. Луман гордился гипертекстововстью, потому что для него она была уникальной, новой, не замечая от рождения присущую его системе очень строгую иерархичность.
Вы описываете классический подход Zettelkasten, но ведь он не может работать в любой структуре одинаково эффективно. Всё зависит от конкретных задач. Поэтому каждый ищет для себя именно свой вариант, в том числе, используя некоторые принципы Zettelkasten. Причём не универсальный вариант, а для конкретной задачи, например рабочее хранилище может совершенно отличаться от домашнего по структуре и принципам связей. Более того, подходы могут быть по разному эффективны для разных типов личностей и типов мышления. Поэтому каждый строит структуру именно под себя, и это, я считаю - прекрасно.
Ну как бы сам по себе Zettelkasten - это способ организации карточек с атомарными заметками, обеспечивающий определенные свойства такой системы. У Лумана не было нашего полнотекстового поиска, но зато у него был контекст. И этот контекст "сетевики" упускают, а без него все превращается в неструктурированный гипертекст. Связи становятся натужными и лишними, к тому же по мере эволюции системы ни связи, ни теги не работают - нужно поддерживать какие-то карты знаний и обновлять теги по имеющимся карточкам регулярно - это адский труд, который мы себе добавили сами.
Кстати, я не совсем понял почему вы организацию тикетов называете ZK? Это обычные атомарные заметки с тегами, в вашем примере есть только внешние ссылки. Полноценным ZK они бы стали, если бы у вас была собственная база знаний или хотя бы ее имитация с минимальными описаниями и заглушками, типа Linux - подсистемы, отдельные пакеты, классы софта - связное дерево, на которое вы сажаете тикеты, которые благодаря наличию родительских связей могут лежать в папке свободно. Все равно основным инструментом остается полнотекстовый поиск, но появляется приятный бонус в виде контекста, можно посмотреть какие тикеты находятся по соседству, если решение из тикета не подходит - иногда это наводит на мысль.
Но в целом Луман решал свои очень специфические задачи, он работал в науке, отдельные области которой сам же и создавал. Для него этот контекст был принципиально важен, взяв любую карточку он мог пробежаться от корня или от любой вышестоящей карточки и проугляться по цепочке рассуждений, уйти в ответвления и пройти по цепочке там - это все работало на массивах от 20 - 30 000 карточек.
Я не представляю как обычный граф с рандомно расставленными связями позволит хоть чем-то помочь. Но у тикетов нет и этих связей, ни места в системе кроме тегов. Луман жил в мире иерархии не придавая этому значения. Мы же почему-то считаем иерархию злом, подсознательно к ней стремясь. Просто если до Лумана картотеки представляли собой массивы неравной длины с редкими отсылками на другие отделы (Кристи такую описывала у мисс Лемон в рассказах о Пуаро), то Луман научился укладывать в картотеки деревья. А мы эти деревья убираем, в результате пытаясь придумать что-то не очень рабочее взамен.
Отвечу на вопрос. В каждом тикете именно в моём случае имеются ссылки на соответствующие элементы базы знаний и т.д. и т.п. Однако статья не посвящена эффективному управлению инцидентами в IT. К сожалению я не могу в таком коротком формате предусмотреть все варианты использования и построить на каждый из них пример структуры. В статье я привёл лишь некий "шаблон", как один из вариантов для отправной точки, чтобы читатели, особенно начинающие пользователи Obsidian, могли ухватить принцип и на его основании строить своё хранилище.
Ну видите, а в результате начинающие пользователи воспринимают ЦК чисто как сетевую структуру с ассоциативными связями, совершенно упуская из вида его гибридность. У Лумана классическая иерархия была изначально и она обеспечивалась нумерацией. Вы можете обеспечить ее очень простым способом - кроме некоторых "корневых", "входных" карточек, список которых вы можете держать в системе, используйте в своих шаблонах поле parent или как-то так, обязательно помещая туда ссылку на родительскую заметку. Я использую up, например. Если такой родительской заметки нет - пусть будет висячая ссылка. Но до тех пор, пока заметка не доходит до корня, я не бросаю ее в папку физически, они лежат во временной папке-отстойнике, пока я эту структуру не сформирую.
В результате вместо физических папок можно обойтись такой структурой, которая элементарно отрисовывается тем же dataview - я написал функцию, которая рисует мне дерево заметок начиная от нужной мне на определенную глубину. Там же можно настроить фильтрацию по тегам, например. Главная задача - знать куда "посадить" каждую заметку, чтобы у нее обязательно был родитель, как полка для книги - тогда эта система начинает работать как надо, а не затыкается на паре сотен заметок, заброшенных в сеть. Попробуй их потом найди, если не помнишь ключевых слов, а заметок тысячи.
Статья не плохая, но явно не для профессионалов, а просто про костяк структуры.
Как и во многих других статьях, очень мало практических советов, например по шаблонам. Какие-то фичи приходится придумывать самому, что не всегда просто из-за отсутствия глубоких познаний, а также из-за того что на практике Obsidian не все поддерживает из фунционала Markdown. Не хватает и экспертизы в части плагинов, уоторые существенно расширяют фунционал.
Раз уж на то пошло, напишите конкретно, какие бы вы хотели практические советы из реального применения. Например поподробней, что именно "по шаблонам"? На основании ваших замечаний, и других, если кто-то пожелает присоединиться, я готов написать статью или цикл статей. Опишите подробней в каком виде и формате вы бы хотели это видеть.
Obsidian для профессионалов: рабочая система заметок на стыке подходов