Комментарии 65
Вроде как на этом сайте сидят люди, которым часто приходится во всяких разных штуках разбираться. Думаю ничего удивительного, что и сейчас им придётся немного попыхтеть и над этой статьей.
В любом случае, чтобы организовать долгоиграющий рабочий процесс в Obsidian, придется,
либо десяток другой прочитать/посмотреть разных источников, которые решают местечковые проблемы. Потом всё это как-то в голове (что крайне ненадёжно) попытаться совместить в систему.
Либо самому очень долго, методично и довольно нудно проверять разные гипотезы и способы ведения.
Либо придется попытаться скопировать чей-то чужой процесс, с чужой логикой от которого можно оттолкнуться – в этой статье реализуется именно этот путь.
Из вышенаписанного, я думаю, можно сделать вывод, что все таки не проканает пользоваться Обсидианом просто тупо как заметочником с плагинами. Точнее проканает, но с таким отношением, наверное, стоит в целом использовать что-то попроще.
К теме GTD. Довольно странное у вас обоснование выбора. Obsidian: free + НЕ open source + с большой натяжкой cross-platform. Тот же todoist: free + НЕ open source + cross-platform + заточен изначально для управления делами и проектами.
Про журнал. Смею предположить, что многие вещи, которые сулят интересными результатами, даются лишь через жесткую дисциплину.
Ну и да... Какие советы субъективны то?
Папок должно быть как можно меньше, но для стартовой страницы мы выделим целую отдельную папку. XD
В целом, какая то стартовая страница, если она есть то и пусть будет, но навигация через нее одну так себе затея. Навигация через "страницы-хабы" по темам с названием начинающимся с нулей куда продуктивнее, вбив нули в поиск можно получить сразу все хабы. Поиск по хабам куда удобнее чем один единственный хоумпейдж где надо что то там искать глазами и тыкать мышкой.
Что касается "впихивания" ссылок, то несомненно их конечно надо как то проставлять. На них все и держится. Но причина по которой ссылка была проставлена, должна быть либо 100% очевидна по тексту, либо отдельно описана благодаря какой логике такая связь образовалась. Иначе разобраться в этом хитросплетении будет не легко в последствии. То что очевидно сегодня, не факт что будет очевидно через год.
Обсидиан хорош тем, что дает своему пользователю полную власть над данными. Так что паранойя может сладко спать. Да и к китайцам в нынешних условиях поди доверия то побольше будет. Они по крайней мере пока еще никого не прокидывали на ровном месте, не потому что кто то персонально плохой, а просто за факт рождения на определенной територии и обладания "неправильным" паспортом. Это что то непостижимо новое в институте права. Ну да ладно, в случае с обсидианом, если завтра земля налетит на небесную ось и разработчики сгинут в пучине морской, найти и прочитать нужную заметку можно штатными средствами любой ОС без дополнительных программ вообще. Да и распарсить содержимое обсидиана можно буквально на коленках, в том числе реализовав логику того же dataview. Обсидиан прост как три копейки и в этом его прелесть, даже не смотря на все очевидные проблемы вытекающие из этой простоты типа отсуствия шифрования. Именно поэтому эта проприетарщина и получила большое сообщество. Не стоит перегружать его сильно сторонними плагинами. Это портит его прекрасную простоту.
Про папки в общем и про папку для homepage. Сначала довольно трудно отлипнуть от папок. А в силу того, что в целом вообще очень трудно видоизменить свой привычный порядок и характер мыслей, я решил оставить именно такую логику. В своей голове я представил человека, который будет разбираться и проговаривать что-то в стиле "так, мне нужна стартовая страница... какой там хоткей? И команду что-то не помню... ладно, посмотрю по всем файлам. Ааа... Home... Ну, окей. (Жмак) Так, значит на неё нужно вытащить все свои библиотеки, да?.. создаю заметки...перенесу-ка мышкой пока что... блин, помню, он вообще сказал, что про папки я должен забыть и на панели у него их нет... придется всё же запомнить как сюда попадать по-другому". Очень, конечно, утрированно.
Теперь про хабы, про MOC, про категории и прочее подобное. Тут я вижу такую логику развития (подчеркну слово, что именно "развития"). Сначала ты делаешь для себя всё наглядным и всё в одном месте. Далее ты набираешь какую-то критическую массу заметок по разным источникам. По ходу у тебя должны созреть идеи о том как обобщить полученные знания и как их поместить поближе друг к другу. Так ты начинаешь формировать категории (или что-то похожее). Далее у тебя формируется следующий критический момент – появляется приличное количество каких-то суммирующих, мета-заметок, тех же самых категорий. Здесь ты начинаешь создавать более короткие пути к новым точкам входа. Между делом у тебя происходят процессы оптимизации, которые уменьшают количество кликов, блужданий глазами и прочих тупняков. По сути только тут начнут появляться ваши условные нули в поиске. Далее ты начинаешь думать о своей системе более глобально. Возможно начинаешь добавлять какие-то гибкие иерархии. Начинаешь заменять какие-то линейные отображения своих структур на визуальные. Начинаешь увеличивать глубину проработки разных своих ветвей знаний. Куда более интенсивно скрещиваешь ветви между собой.
Про порчу простой красоты Obsidian. Всё-таки есть решения и попроще. Например, Typora. В ней даже толком соблазна не появится что-то накручивать и что-то выдумывать с логикой.
Я положил Homepage в избранное, довольно удобно.
Подумал о том, что вы можете ещё немного добавить удобства. Если поставить плагин Another Quick Switcher, то у вас появится команда, которая будет вызывать (свою) панель с избранными заметками. Её можно назначить на какой-нибудь хоткей.
Картинка с командой
![](https://habrastorage.org/getpro/habr/upload_files/419/2f8/7f6/4192f87f606b3e8bde40116a0fb25a0a.png)
Да и к китайцам в нынешних условиях поди доверия то побольше будет. Они по крайней мере пока еще никого не прокидывали на ровном месте, не потому что кто то персонально плохой, а просто за факт рождения на определенной территории и обладания «неправильным» паспортомДа бросьте вы, здесь скорее проще смотреть на коммерческую заинтересованность, то есть что выгодно конкретному владельцу софта в текущем моменте (выгодно набрать базу пользователей — добрый и пушистый, но когда пользователей набрали, то плюшки постепенно исчезают — это уже проходили с Evernote), а у доброго Китая даже в учебниках упоминают территориальные претензии на российские территории (к примеру некоторая территория уже была передана в 2004). Да и таких же или даже более заметных охлаждений отношений с Китаем в нашей истории хватало, что сказать, даже в культуре это отражено, к примеру, китайца в «неуловимых мстителях» последовательно заменили на американского негритенка, а потом на цыгана. По теории для китайцев, как некитаец, вы всегда второсортны, даже если получить гражданство, что на деле практически нереально. Что-то похожее есть у индийцев, но там скорее сложности с религией (ями). По факту сказки про запад меняются на сказки про добрый восток, хотя оснований, кроме коммерции нет (Китаю выгодно получать ресурсы, огромная часть их успеха — за счет выдаивания бывших советских технологий, специалистов и ресурсов), да и потом будут заново целоваться по принципу выгоды с любыми другими странами.
Typora это редактор, а обсидиан — база знаний. Но, имхо, вы правы, что все превращается в самоцель и вместо решения проблем, создается прокрастинационная ловушка суперусложненных систем. Вероятно, для определенных пользователей сложные системы имеют смысл, например для профессиональных писателей или тех, кто занимается сопровождением каких-то больших коммерческих проектов. Для многих остальных прелести персональных баз знаний с Цеттелькастенами и текстовыми файлами — неочевидны. Плюс обсидиана — в том, что какие-то интересные решения из других программ становятся доступны (пример, миро) в одном месте бесплатно и потенциально более открыты (текст, json и т.д.) напрямую или через плагины. Хотя и раньше были похожие решения (по-моему, zim очень старый и идейно довольно близкий пример), но пока маркдаун заметочники/базы данных на пике неожиданной популярности, может быть будет развитие в этой, имхо, стагнирующей области.
Боже, какой тяжелый лонгрид о том, как делать записи. Кажется, что программы должны быть предельно простыми и инструкции по работе с ними в идеале должны отсутствовать (все понятно интуитивно) или помещаться в один короткий абзац. Здесь же ощущение, что читаешь какую-нибудь инструкцию по пользованию какой-нибудь 1С документооборот. Не знаю, как это может упростить жизнь, но такой подход противоречит простоте и эффективности.
Краткий ответ на ваш комментарий. Нет. Программы не должны быть предельно простыми, ибо всё зависит от глаз смотрящего и от того, что этим "глазам" нужно получить.
Ответ подлиннее. Наверняка, вы замечали, что когда вы в чем-то достаточно хорошо разберетесь, то для вас многие вещи начинают становиться самоочевидными. Причем, если вы ретроспективно попробуете посмотреть на этот процесс, то окажется, что виной тому – ваше развитие. Вы развились, поэтому вещи и стали такими очевидными.
Теперь примерно та же логика в преломлении 1С. Разумно же подумать, что появление автоматизации документооборота или бухгалтерского учёта есть следствие того, что усложнились системы производственных отношений. Или иначе говоря – системы стали сложнее, поэтому и методы управления стали более продвинутыми, комплексными.
Я хочу сказать, что возможно вам кажется, что вы прочитали какой-то тяжеляк, потому что вам ещё не приходилось управлять большим количеством знаний. Представьте, такую ситуацию. Перед вами система в которой вам показываются разные мысли и вы их смахиваете вправо или влево как в Тиндере. Очень интуитивно понятная логика, да? Если у вас выпало совпадение с мыслью, то вы с ней идете на свидание, потом поцелуйчики-постель и всё. Дальше снова свайп-влево, свайп-вправо. Теперь риторический вопрос. Сможете ли вы с такой простой системой построить космический аппарат?
Нет. Программы не должны быть предельно простыми, ибо всё зависит от глаз смотрящего и от того, что этим "глазам" нужно получить.
Аргументация на 2, демагогия на 5.
вам кажется, что вы прочитали какой-то тяжеляк, потому что вам ещё не приходилось управлять большим количеством знаний
Для ясности, не могли бы разъяснить, что такое «управлять большим количеством знаний»? Зачем им управлять? То есть как это управление улучшает жизнь? И что такое знание для вас? И где оно находится? Мы ведь говорим про ведение личных записей, верно? Мне кажется тут работает простой механизм: нужно что-то записать — просто запиши это. Всё. Потом, если потребуется, вспомнишь или найдешь поиском, а если не найдешь и не вспомнишь, то загуглишь и найдешь ответ в интернете. Использовать тяжелую, многоуровневую систему заметок, настолько сложную, что на ее освоение потребуется месяцы, мне кажется неэффективно.
Кстати я тоже когда-то был в плену идеи, что вокруг много ценной информации, и если ее как-то хитро сортировать и накапливать, это даст мне какие-то преимущества. В реальности это не так и зачастую ручка и лист бумаги гораздо эффективнее для мозгов и результата, чем сложная информационно-заметочная система.
Странно, что вы считаете систему тяжёлой и многоуровневой.
Так-то я предложил не так уж и много "уровней":
по сути создать первую точку входа,
библиотеки источников
журнал (который у вас является в большей степени личным дневником).
Рабочий процесс строится ровно же на этих трех вещах:
юзаете дневник
заходите на первую точку входа и выбираете чем заняться
работаете по тому, что уже добавили (книги, статьи, подкасты...)
создаете новый источник и начинаете работу по нему
Всё остальное, что я написал это идеи как можно автоматизировать работу с источниками возможностями Obsidian или некоторыми плагинами; идеи как можно улучшить (оптимизировать, ускорить) рабочий процесс за счёт разных мелких приемов.
Про управление большим количеством знаний. Управление начинается с момента исследования каких-то вещей, извлечения из них знания и заканчивается тем, что знания делаются переиспользуемыми, склеиваются с другими знаниями при необходимости и используются в нужных местах. Если то же самое, но более формально, то управление знаниями – это деятельность, которая направлена на совокупное упорядочивание и(или) систематизацию следующих процессов:
поиск источников
изъятие знаний
переработка (интерпретирование, атомизация и прочее) идей
синтез с другими идеями
использование своих наработок
Зачем им управлять? Ровно по тем же причинам по которым вы пытаетесь управлять своей жизнью – чтобы доходить туда, куда вам нужно, чтобы закреплять и не терять то, что чего вы добились, чтобы в целом мочь двигаться вперед.
Как это управление улучшает жизнь? Попробуйте на основе абзаца выше сами дать ответ.
Что такое знание для вас? И где оно находится? Знание – это теоретическое сведение, полученное из другого теоретического сведения или опыта, которое так или иначе где-то уже используется или впоследствии будет использоваться. Знание находится там, где оно формально отражено.
Тоже не до конца понял, сможет ли кто-то воспользоваться описанным методом ведения заметок, с учетом такого количества деталей. Но какие-то отдельные куски статьи точно могут пригодиться. Я начал вести заметки в Obsidian полгода назад, за это время какой-то подход сформировался. Плагинами не пользуюсь. По сути просто пишу туда все, что захочу.
Структура директорий у меня получилась другая, поддиректории не использую (нейминг возможно не совсем правильный, но мне так привычней):
data - для файлов
personal - все про меня: дневник, CV, планы, идеи, заметки про хобби, спорт и тд
tech - технические заметки, что-то типа локального stackoverflow с проверенными решениями. каждая заметка про какой-то софт или пакет, например, grafana, pandas или postgresql
projects - заметки про личные проекты, которые веду в процессе. одна заметка - один проект
info - все подряд, одна заметка - одна тема, всегда можно разделить или объединить при необходимости, но главное, чтобы можно было найти в поиске
notes - компиляции материалов в нормальные заметки, статьи для блога
В итоге легко писать заметки, всегда понятно куда их положить. А искать информацию еще легче. Workflow тоже предельно прост: если в голове появилась какая-то мысль или информация, которую нужно зафиксировать - пишу в заметку.
Тоже неплохой подход вы описали.
К теме сможет ли кто-нибудь воспользоваться. Я не знаю... У меня не было рандомизированой выборки, чтобы это как-то проверить. Поэтому всяк кто будет пытаться повторить гайд, так или иначе должен к каждой идее и практике отнестись критически, т.е. взвешивать и оценивать уровень уместности и прагматичности того или иного подхода. Однако так, конечно, должно быть в идеале. По факту же, не попробуешь, не поэкспериментируешь – не появится опыта, не поймешь.
Я попробую уточнить сказанную мысль. Речь идёт скорее всего о том, что этот гайд требует своего рода "атомизации" на несколько этапов настройки, каждый из которых будет наращивать систему, и при этом отдельно являться не очень сложным (долгим) в настройке и понимании. Первый заход - минимально рабочая система (mvp) Вторая итерация - кастомизация с шаблонами (например). Третья итерация - докручивание до состояния финала этой статьи.
При этом, большое спасибо за труд!
Лично моя обезьянка начала ныть и проситься за штурвал срочно бежать смотреть котиков где-то на середине текста))))
Вы прям чётко уловили логику построения системы по этой статье.
Вообще говоря, эту логику можно также легко уловить, если просто немного более вдумчиво глянуть на содержание в самом начале.
Хотел бы ещё добавить то, что база знаний – это накопительная система. Причем её "накопительность" реализуется на двух этапах:
при её построении (именно поэтому нужно выбрать изначально набор каких-то хороших, долгоиграющих решений)
при её ведении (об этом дальше)
Если в базе будет 200 заметок, то толку от неё мало. Если в ней будет 1000 заметок, то толку всё ещё мало, но зато уже можно как-то попробовать покрутиться, поэкспериментировать и понять, что значит управлять знаниями. Когда заметок будет 5000 и при этом не будет какой-то вменяемой системы управления (с автоматизациями или с какой-то иной довольно жесткой, но долгоиграющей логикой), то считай можешь начинать сначала – выжать пользы из такой системы не получится в силу её беспорядочности. В ином же благоприятном случае, с таким количеством заметок можно уже прям на серьезном уровне начинать что-то строить, создавать, прототипировать, можно уже создавать длинные и комплексные цепочки аргументов в защиту того или иного решения. В целом можно создавать какие-то обоснованные решения. Дальше не буду продолжать, чтобы не начать кого-то стращать или давать ложные надежды.
Мне, как технарю, эта логика ясна интуитивно и я могу самостоятельно выделить все "слои" и постепенно добавлять сложность и детализацию, возможно, что-то улучшая или настраивая лично под себя какие-то тонкости.
Гуманитарий же, скорее всего, воспримет это как TD;DR и потеряет энтузиазм на середине чтения, но это мое имхо)
Но таков путь обсидианщика)
Список в списке, в списке, в подсписке, в списке, в списке, в подсписке, в списке... прямо, ОКР какое-то :)
Вот не туда разработчики всяких ЧатГПТ работают, давно бы уже нужно систему, в которую просто "валишь всё в кучу" (ссылки, мысли, тексты, картинки и т.п.), а потом просто "а вот дай ка мне подборочку по такой-то теме из сохранённого", и система такаям " а вот, пожалуйте, вот тут статейка была с вот такими ключевыми мыслями; вот тут вы свои соображения писали; а тут в комментарии развили "мыслю"; а вот что нового в сети появилось; а еще можно с другой темой вот по таким ключам/смыслам связать..."
Согласен.
Думаю, что в каком-то зародыше можно найти такую рекомендательную систему в плагине Graph Analysis. Он с помощью разных алгоритмов анализирует, либо ваш граф, либо сами тексты. Результатом выдает иерархический список заметок, которые по мнению того или иного алгоритма наиболее релевантно связаны или могут быть связаны с текущей заметкой. Конечно это даже близко не искусственный интеллект, но хотя бы так.
Спасибо за такую монументальную статью (первая для меня оказалась не на столько интересной, но висит у меня в read later), а так же отдельное спасибо за упоминание моей статьи.
Выписал себе интересные плагины, которые сам не юзал: Banners, Projects, DB folder, Commander, Editing Toolbar, Supercharged Links, Style Settings, Paste image rename. На досуге покопаюсь в них.
У меня к вам есть несколько вопросов про сам процесс написания данной статьи, я спрашиваю, потому что сам хотел написать что-то подобное, но прикинув понял, что внутренний перфекционист-прокастинатор не даст мне этого сделать и решил писать почучуть, но с большей периодичностью. Мне больше по душе относится к написанию статей на хабр как к марафону, а не как к спринту.
Что послужило триггером\драйвером для написания статьи? Цель на 23 год?
Сколько времени заняло написание статьи?
Что помогло довести дело до конца азарт\муза\вдохновение\отпуск?
Сам отвечу на свои же вопросы для вас:
В процессе планирования целей на 23 год я понял, что в 100+ вещей, которые я хочу сделать в 23 году, надо обязательно включить написание статьи на хабр.
У меня где-то суммарно 10 часов, 4-5 дней по 2-3 часа.
Мне помогло разбираение кейсов, которые я сам не использую у себя. Было интересно узнавать что-то новое.
Не переставайте писать, пишите дальше, спасибо ещё раз.
Круто и ясно мыслите.
Ответ на первый вопрос.
Я хотел, чтобы у меня появился текст, который бы я мог скидывать всем, кто мне интересен и симпатичен, чтобы в довольно структурированной форме сказать что-то в стиле
смотри, вот так я думаю и вот так я отношусь к процессам познания и роста
в рамках вот такой системы я обрабатываю информацию и в целом именно так мыслю все какие-то приходящие в мою голову потоки мыслей и идей
если хочешь, то попробуй также. вот инструкция
Мне хотелось получить какую-то внешнюю критику, чтобы попытаться сквозь неё посмотреть на свою систему и тем самым как-то её исправить, переделать или просто дошлифовать
Ответ на второй вопрос.
на эту статью ушло ровно столько сколько прошло между этой и прошлой публикациями (т.е. около 6-7 дней)
к сожалению сколько на прошлую статью ушло, я не могу сказать точно
я уделял примерно по 3-4 часа в день
мало это или много, не знаю
всё таки я не исследование написал, а перечислил конкретные практики, которые уже находились в моей голове
но с другой стороны, я попытался снабдить текст (в каком-то смысле, с особым фанатизмом) обилием мыслей и идей, которые так или иначе могут пригодиться при построении системы
Ответ на третий вопрос.
Самое первое, что я сделал, это разметил структуру заголовками
Далее я писал только по тем заголовками, которые мне были интереснее всего
После по инерции дописал все самые скучные
С помощью статьи я попытался сбросить свой интеллектуальный груз
В целом неплохо подпитывала мысль, что я реализовываю именно своё видение, которое возможно кому-то пригодится
Спасиобо за ответы. не бросайте это дело, пишите дальше, не смотря на обилие каментов TLDR и "Ойсложнааааа\нужнооо" имейте в виду, что есть большое кол-во людей readonly, которые читают и не комментируют и вдохновляются написанным, выдёргивают из вашего подхода фишечки и применяют их в отдельности от остальной методолгии.
Еще после написания моей статьи меня посетила мысль, что неплохо бы выложить готовый сетап базы куда-нибудь на гитхаб, чтобы люди могли легко пощупать то, о чём и вы и я пишу.
Сейчас я как раз в процессе написания статьи про задачи в Dataview и как раз там я планирую сразу выложить линк на готовый сетап.
К теме комментов.
Комменты обычно являются реакциями на увиденное, прочитанное или в целом узнанное. Т.е. комменты часто строятся не от результатов вдумчивого анализа, а от эмоций. Если у какого-то человека сегодня одна реакция, то завтра может быть уже другой. Я даю себе в этом в отчёт, поэтому с достаточной осознанностью и отстраненностью читаю комментарии. Хотя опять же, с другой стороны, естественно, приятнее читать комментарии, которые как-то поддерживают меня как автора или расширяют сам материал. Поэтому благодарю вас.
Про демонстрационную базу.
Идея шикарная. Но, например, я её не потяну. Все же моей основной областью интересов является не базы знаний (быть может, будет понятнее по хабам в профиле, что меня интересует в первую очередь). К тому же какие-то демонстрационные сетапы нужно поддерживать, постоянно как-то шлифовать и главное, что нужно позволять другим вносить какие-то изменения. Думаю, что только (или вдобавок) с такими установками получиться принести максимально пользы аудитории. Эту же мысль можно интерпретировать как то, что создание такой демонстрации, может стать хорошей отправной точкой, чтобы сформировать вокруг себя сообщество.
К теме бросания. Я напишу по Obsidian следующую статью и вероятно надолго охладею к этой теме (естественно, что в контексте написания статей, а не целиком ко всей теме). Опять же, базы знаний не моя основная сфера интересов, чтобы в ней настолько подробно копаться. Быть может, позже напишу что-нибудь и про более профильное, про какую-нибудь жесткую математику каких-нибудь игровых статистик. Хотя скорее всего, я сначала напишу огромную статью про tiling-mangers – их философию, сравнение с обычными DE и опишу длиннющий путь по тому как можно организовать рабочий процесс. Но это всё неточно. Прям вообще неточно.
Про задачи в Dataview. У меня лично имеются в голове только какой-то сомнительной надежности практики о том как можно вести задачи в Obsidian. (Сам я использую GTD в todoist) Возможно у вас получится сделать что-то крутое и мощное. Кстати, редко наблюдал, чтобы Dataview использовали для списков задач. Так что спешу узнать от вас что-нибудь новенькое.
Крутые статьи, огромное спасибо!! Почерпнул массу интересного и полезного, жду продолжения!
Привет. Я как раз один из тех readonly которые читают и не пишут. Тут решил что нужно.
Огромное спасибо за Ваши статьи по Obsidian они вдохновляют и мотивируют. Мои попытки управлять знаниями привели меня в Notion, но мне не нравится что в итоге получилось. Ваш туториал определенно будет в закладках и я надеюсь поможет сделать что то лучшее.
делать основную свою деятельность, т.е. читать, думать, создавать идеи, понимать и осознавать, учиться и т.д.
После такой фразы возникают сомнения, а поможет ли это, если основная деятельность - это работа, например разработка ПО или дата инженеринг.
Не знаю. Я не смогу конкретно для вас вынести железобетонный вердикт в стиле "именно с такой базой знаний вы обязательно станете успешным, богатым и с большим агрегатом". (По правде говоря, ни для кого не смогу...)
Я не ехидничаю. Скорее просто вам намекаю на то, что вам нужно самому взвесить все "за" и "против". Поэтому попробуйте в голове промоделировать то, как будет выглядеть ваша база знаний, как вы ей будете пользоваться. Попробуйте представить рабочий процесс и предположительные суммарные результаты от этого процесса, которые у вас появятся через какой-то промежуток времени.
Как вариант вам нужно поискать конкретных "живых" людей разработчиков ПО, которые ведут базу знаний. Ну, и естественно вам нужно подоканывать их своими самыми разнообразными вопросами.
Попалось видео разработчика. Популярность у канала никакущая, но зато парень очень кратко объясняет смысл ведения базы знаний. У него к сожалению подход строится на использовании изолированных инструментов, но суть остается прежняя – формируются мимолётные заметки (типа inbox-a), агрегируются источники, самостоятельно пишутся и связываются постоянные заметки и над всем этим кружится длиннющий классификатор (который поначалу нереально сделать, а потом, когда он разрастется нереально использовать без справки или какой-то хорошей логически обоснованной системы). Не уверен, что это вам прям поможет, но хотя бы для примера.
Думаю большинство комментариев выше в ключе "не понимаю зачем так сложно" связаны с тем, что каждый по своему понимает "управление знаниями", "база знаний". А в статье не описывается это.
Для меня, как кажется и всех "не понимающих", это просто записная книжка в стиле how-to, project , и ведения списка активов/пассивов. Не предполагает построения связей, озарений от пересмотра заметок. Для IT-шника скорее всего это так и будет.
Автору спасибо за проделанный труд. Монументально, полезно. Набор плагинов в первой и второй статье помог.
Разделяю ваше мнение.
Только сейчас подумал о том, что я и взаправду не шибко точно объяснил, что же такое "база знаний". Наверное, такое "недоразумение" проистекает из моей мысли (кой я придерживаюсь) о том, что каждый сам должен понимать зачем ему нужно использовать те или иные практики. Ну и отсюда же мысль, что каждый сам должен выбирать – тратить свое время ему на какие-то исследования или какие-то эксперименты или не тратить.
Давно хочу подступиться к созданию своей базы знаний, но неизменно натыкаюсь на проблему множества языков. Родной -- русский, на нем много читаю нон-фикшн, в работе использую на 99% английский, а страна проживания -- немецкоговорящая. Соответственно идеи и мысли на немецком тоже должны найти отражания в базе.
Есть ли какой-то разумный и вашем стиле, т.е. без лишних усложнений, workflow для таких мультиязыковых ситуаций?
Два языка ещё ладно, но вот три... Тут я не шибко могу что-то прям очень весомое подсказать. Однако попробую подкинуть пару идей.
Вы можете добавлять к заметкам aliases. Возможно, чтобы немного упростить этот процесс (т.е. не делать для всех заметок сразу), можете добавлять aliases по мере того как вы вспоминаете о заметке: вспоминаете на русском – добавляете русский вариант названия заметки; на английском – английский; на немецком – немецкий. Естественно, поначалу придётся как-то добраться до нужной заметки (т.е. поперебирать языки и варианты ключевых слов). Но со временем, я думаю, у вас получится большую часть своей базы хорошо зашлифовать.
Если говорить в контексте какой-то определенной ветви вашей базы знаний. Например, в контексте ветви, которая у вас порождена какой-то определенной книгой. То разумнее всего делать все связанные заметки на одном языке. Т.е. если книга на немецком, то вы делаете все заметки по ней на немецком. Позже книга у вас отнесется к какой-то категории. И скорее всего, в будущем вы будете искать сначала именно с помощью категорий то, как у вас могут быть связаны источники и заметки в них. А там думаю не должно появиться каких-то больших проблем в том, чтобы быстро понять как можно связать разные заметки из разных источников – даже, если заметки будут на разных языках. Давайте на примере для простоты. Допустим у вас образовалась категория "кулинария", к ней у вас будут относиться вероятно книги по готовке. В самих же книгах, скорее всего, будут рецепты. Пусть, например, мы хотим из всех наших книг по кулинарии достать и свести в одну заметку все рецепты по приготовлению "мяса". Разве будет какой-то сложностью найти во всех книгах заметки с упоминанием "мясо...", "fleisch..." и "meat..."? Думаю не особо. Другое дело, что вам просто придется искать сразу 3 одинаковых по сути слова. Но тут уж ничего не поделать.
Вообще рекомендую глянуть вот это видео. Там будет парень немец со вторым английским языком (ролик на английском). У него в базе сразу два языка – английский и немецкий. Сама же база у него строится очень минималистично, но не с точки зрения технической, а именно как рабочий процесс (у него он прям чёткий, гладкий, без излишеств, хорошо автоматизированный). Возможно этот ролик будет не столь полезен вам для построения собственной базы знаний, сколько для того, чтобы понять как люди могут жить с двумя языками в контексте базы знаний (спойлер – не так уж просто, но все равно неплохо).
Возможно это будет кому-то полезно.
В Minimal Theme есть cssclass под названием cards. Его можно использовать, например, для красивого отображения фильмов в своей библиотеке. Однако, если вы используете другую тему, то можете добавить вот такой сниппет, чтобы у вас появился этот класс:
Hidden text
/* MIT License | Copyright (c) Stephan Ango (@kepano)
Cards snippet for Obsidian
author: @kepano
version: 2.0.0
Support my work:
https://github.com/sponsors/kepano
*/
:root {
--cards-min-width: 180px;
--cards-max-width: 1fr;
--cards-mobile-width: 120px;
--cards-image-height: 400px;
--cards-padding: 1.2em;
--cards-image-fit: contain;
--cards-background: transparent;
--cards-border-width: 1px;
--cards-aspect-ratio: auto;
--cards-columns: repeat(auto-fit, minmax(var(--cards-min-width), var(--cards-max-width))); }
@media (max-width: 400pt) {
:root {
--cards-min-width:var(--cards-mobile-width); } }
.cards.table-100 table.dataview tbody,
.table-100 .cards table.dataview tbody {
padding: 0.25rem 0.75rem; }
.cards table.dataview tbody {
clear: both;
padding: 0.5rem 0;
display: grid;
grid-template-columns: var(--cards-columns);
grid-column-gap: 0.75rem;
grid-row-gap: 0.75rem; }
.cards table.dataview > tbody > tr {
background-color: var(--cards-background);
border: var(--cards-border-width) solid var(--background-modifier-border);
display: flex;
flex-direction: column;
margin: 0;
padding: 0 0 calc(var(--cards-padding)/3) 0;
border-radius: 6px;
overflow: hidden;
transition: box-shadow 0.15s linear;
max-width: var(--cards-max-width); }
.cards table.dataview > tbody > tr:hover {
border: var(--cards-border-width) solid var(--background-modifier-border-hover);
box-shadow: 0 4px 6px 0px rgba(0, 0, 0, 0.05), 0 1px 3px 1px rgba(0, 0, 0, 0.025);
transition: box-shadow 0.15s linear; }
.cards table.dataview tbody > tr > td {
/* Paragraphs */
/* Links */
/* Buttons */
/* Lists */
/* Images */ }
.cards table.dataview tbody > tr > td:first-child {
font-weight: var(--bold-weight); }
.cards table.dataview tbody > tr > td:first-child a {
padding: 0 0 calc(var(--cards-padding)/3);
display: block; }
.cards table.dataview tbody > tr > td:not(:first-child) {
font-size: 90%;
color: var(--text-muted); }
.cards table.dataview tbody > tr > td .el-p {
display: block;
width: 100%; }
.cards table.dataview tbody > tr > td > *:not(.el-embed-image) {
padding: calc(var(--cards-padding)/3) 0; }
.cards table.dataview tbody > tr > td:not(:last-child):not(:first-child) > .el-p:not(.el-embed-image) {
border-bottom: 1px solid var(--background-modifier-border);
width: 100%; }
.cards table.dataview tbody > tr > td a {
text-decoration: none; }
.cards table.dataview tbody > tr > td > button {
width: 100%;
margin: calc(var(--cards-padding)/2) 0; }
.cards table.dataview tbody > tr > td:last-child > button {
margin-bottom: calc(var(--cards-padding)/6); }
.cards table.dataview tbody > tr > td > ul {
width: 100%;
padding: 0.25em 0 !important;
margin: 0 auto !important; }
.cards table.dataview tbody > tr > td:not(:last-child) > ul {
border-bottom: 1px solid var(--background-modifier-border); }
.cards table.dataview tbody > tr > td .el-embed-image {
background-color: var(--background-secondary);
display: block;
margin: 0 calc(var(--cards-padding)/-2) 0 calc(var(--cards-padding)/-2);
width: calc(100% + var(--cards-padding)); }
.cards table.dataview tbody > tr > td img {
aspect-ratio: var(--cards-aspect-ratio);
width: 100%;
object-fit: var(--cards-image-fit);
max-height: var(--cards-image-height);
background-color: var(--background-secondary);
vertical-align: bottom; }
.markdown-source-view.mod-cm6.cards .dataview.table-view-table > tbody > tr > td,
.trim-cols .cards table.dataview tbody > tr > td {
white-space: normal; }
.cards .dataview.table-view-table > tbody > tr > td,
.cards table.dataview tbody > tr > td,
.markdown-source-view.mod-cm6.cards .dataview.table-view-table > tbody > tr > td,
.markdown-source-view.mod-cm6.cards table.dataview tbody > tr > td {
border-bottom: none;
padding: 0 !important;
line-height: 1.2;
width: calc(100% - var(--cards-padding));
margin: 0 auto;
overflow: visible !important;
max-width: 100%;
display: flex; }
.links-int-on .cards table.dataview tbody > tr > td a {
text-decoration: none; }
/* Block button */
.markdown-source-view.mod-cm6.cards .edit-block-button {
top: 0px; }
/* ------------------- */
/* Sorting menu */
.cards.table-100 table.dataview thead > tr,
.table-100 .cards table.dataview thead > tr {
right: 0.75rem; }
.table-100 .cards table.dataview thead:before,
.cards.table-100 table.dataview thead:before {
margin-right: 0.75rem; }
.theme-light .cards table.dataview thead:before {
background-image: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 100 100"><path fill="black" d="M49.792 33.125l-5.892 5.892L33.333 28.45V83.333H25V28.45L14.438 39.017L8.542 33.125L29.167 12.5l20.625 20.625zm41.667 33.75L70.833 87.5l-20.625 -20.625l5.892 -5.892l10.571 10.567L66.667 16.667h8.333v54.883l10.567 -10.567l5.892 5.892z"></path></svg>'); }
.cards .el-pre + .el-lang-dataview .table-view-thead {
padding-top: 8px; }
.cards table.dataview thead {
user-select: none;
width: 180px;
display: block;
float: right;
position: relative;
text-align: right;
height: 24px;
padding-bottom: 4px; }
.cards table.dataview thead:hover:before {
opacity: 0.5;
background-color: var(--background-modifier-hover); }
.cards table.dataview thead:before {
content: '';
position: absolute;
right: 0;
top: 0;
width: 10px;
height: 16px;
background-repeat: no-repeat;
cursor: var(--cursor);
text-align: right;
padding: var(--size-4-1) var(--size-4-2);
margin-bottom: 2px;
border-radius: var(--radius-s);
font-weight: 500;
font-size: var(--font-adaptive-small);
opacity: 0.25;
background-position: center center;
background-size: 16px;
background-image: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 100 100"><path fill="white" d="M49.792 33.125l-5.892 5.892L33.333 28.45V83.333H25V28.45L14.438 39.017L8.542 33.125L29.167 12.5l20.625 20.625zm41.667 33.75L70.833 87.5l-20.625 -20.625l5.892 -5.892l10.571 10.567L66.667 16.667h8.333v54.883l10.567 -10.567l5.892 5.892z"></path></svg>'); }
.cards table.dataview thead > tr {
top: -1px;
position: absolute;
display: none;
z-index: 9;
border: 1px solid var(--background-modifier-border-hover);
background-color: var(--background-secondary);
box-shadow: var(--shadow-s);
padding: 6px;
border-radius: var(--radius-m);
flex-direction: column;
margin: 26px 0 0 0;
width: 100%; }
.cards table.dataview thead:hover > tr {
display: flex; }
.cards table.dataview thead > tr > th {
display: block;
padding: 3px 30px 3px 6px !important;
border-radius: var(--radius-s);
width: 100%;
font-weight: 400;
color: var(--text-normal);
cursor: var(--cursor);
border: none;
font-size: var(--font-ui-small); }
.cards table.dataview thead > tr > th[sortable-style="sortable-asc"],
.cards table.dataview thead > tr > th[sortable-style="sortable-desc"] {
color: var(--text-normal); }
.cards table.dataview thead > tr > th:hover {
color: var(--text-normal);
background-color: var(--background-modifier-hover); }
/* ------------------- */
/* Helper classes */
.cards.cards-16-9 {
--cards-aspect-ratio: 16/9; }
.cards.cards-1-1 {
--cards-aspect-ratio: 1/1; }
.cards.cards-2-1 {
--cards-aspect-ratio: 2/1; }
.cards.cards-2-3 {
--cards-aspect-ratio: 2/3; }
.cards.cards-cols-1 {
--cards-columns: repeat(1, minmax(0, 1fr)); }
.cards.cards-cols-2 {
--cards-columns: repeat(2, minmax(0, 1fr)); }
.cards.cards-cover table.dataview tbody > tr > td img {
object-fit: cover; }
.cards.cards-align-bottom table.dataview tbody > tr > td:last-child {
align-items: flex-end;
flex-grow: 1; }
@media (max-width: 400pt) {
.cards table.dataview tbody > tr > td:not(:first-child) {
font-size: 80%; } }
@media (min-width: 400pt) {
.cards-cols-3 {
--cards-columns: repeat(3, minmax(0, 1fr)); }
.cards-cols-4 {
--cards-columns: repeat(4, minmax(0, 1fr)); }
.cards-cols-5 {
--cards-columns: repeat(5, minmax(0, 1fr)); }
.cards-cols-6 {
--cards-columns: repeat(6, minmax(0, 1fr)); }
.cards-cols-7 {
--cards-columns: repeat(7, minmax(0, 1fr)); }
.cards-cols-8 {
--cards-columns: repeat(8, minmax(0, 1fr)); } }
Если вы хотите, чтобы определенные заметки растягивались на весь экран при их просмотре, то можете добавить cssclass под названием full-width. Это реализуется вот в таком сниппете:
Hidden text
.CodeMirror-lines, .CodeMirror-selected, .markdown-preview-section {
max-width: 700px;
margin: auto;
}
.full-width .markdown-preview-section {
max-width: 100% !important;
}
Также если вы хотите, чтобы при переходе на определенную заметку включался автоматически, например, режим просмотра, то можете поставить плагин Obsidian force note view mode. Вам нужно будет добавить в заметку вот такие мета-данные:
Hidden text
---
obsidianUIMode: preview
---
Вы можете все 3 фишки использовать сразу:
Hidden text
---
cssclass: full-width, cards
obsidianUIMode: preview
---
Больше 2-ух лет пользуюсь Obsidian. В итоге остановился на отказе от названий заметок по имени файла. Файловый менеджер вообще отключил. @mnaoumov помог с шаблоном для плагина темплэйтер. Сейчас каждая новая заметка создается в формате YYYYMMDDhhmmss.md с автоматическим добавлением и переходом курсора на блок фронтматтер с aliases. При создании заметки из выделенного текста, выделенный текст автоматически добавляется в aliases. Небольшое количество тегов для статуса заметок (входящие, пересмотреть) Для быстрой навигации, на боковой панели запинена заметка со ссылками на постоянные заметки homepage, help, todo. Метод описанный автором статьи рабочий, пишешь заметку, потом дробишь ее на атомарные куски. Итоговая заметка получается состоит из вложенных заметок, которые благодаря разным названиям можно вложить и в другие. Таким образом вся база получается рекомбинацией вложенных атомарных заметок с одной уникальной информацией и крепкую связь между ними.
Спасибо за подробный гайд. Уточните пожалуйста два момента.
1. У меня есть TOC и заметки, относящиеся к нему. Где правильно ставить ссылки друг на друга:
TOC -> note
note -> TOC
TOC <-> note
2. У меня в базе сейчас смешаны заметки двух видов. Первые - это некое подобие цеттелькастена, где я пишу своими словами выжимки из чужих мыслей. Вторые - чтото типа вики, где собираю технические инструкции, HowTo. Я хочу с помощью плагина RandomNote периодически просматривать первые, но не вторые. Можно ли так сделать?
Ответ на 1-ый вопрос.
Не знаю как правильнее будет для вас. Вам нужно сначала понять какую пользу вы хотите получить, а потом представить в голове некоторую эмуляцию рабочего процесса, который будет извлекать эту самую пользу. Так вы можете позадавать себе вопросы в стиле:
Я буду искать сначала конкретную заметку, а потом переходить на классификатор, который подскажет, что еще есть по этой теме?
Я буду искать сначала классификатор, а потом все связанные заметки?
Я буду искать и заметку, и классификатор?
Каким образом я собираюсь в целом навигироваться по заметкам: мне важно есть ли направление связи или я вообще могу по локальному графу всё понять?
Собираюсь ли я делать какие-то автоматизации и будет ли для них (автоматизаций) разница в какую сторону идет связь и вообще должна ли обеспечиваться связь именно через заметки (а не например теги или метаданные)?
Стоит также помнить, что могут образовываться заметки, которые напрямую у вас не относятся к определенной категории. Логику работы с ними тоже нужно как-то в своей голове обозначить.
Короче говоря, на мой взгляд будет правильнее так, как вы моделируете рабочий процесс. Если модель окажется такой себе, то просто оставьте себе достаточно "пространства", чтобы как-то модифицировать своё решение.
Что-то конкретнее не могу сказать, т.к. мне не хватает конкретного примера.
Ответ на 2-ой вопрос.
Если у вас нет никакого формального разделения между этими двумя типами заметок (с помощью метаданных, папок, тегов, с помощью хотя бы какого-то однозначно определяющего ключевого слова(ов) и прочего), то я не знаю как их разделить.
Если у вас есть хоть что-то классифицирующее, то можно поставить более продвинутый аналог рандомных заметок, который будет выдавать вам случайные заметки из вами составленного поискового запроса (а его уже можно накрутить как вам будет душе угодно).
Про первый вопрос, для истории. Я решил делать ссылки из notes в TOC, а проблему пустого TOC решаю вот так
LIST
FROM "Wiki"
WHERE contains(this.file.inlinks, file.link)
SORT date desc
Я использую своего рода MOC. В заметках, которые к нему принадлежат, у меня сделано так, чтобы там тоже не было пустоты. Шаблон у меня несколько более замысловатый. Возможно, вам будет интересно что-то из него подчерпнуть.
Шаблон категориальной заметки
<%*
let title = tp.file.title
if (title.startsWith("Untitled")) {
title = await tp.system.prompt("Title");
}
await tp.file.rename(title)
-%>---
aliases<%* -%>:
- "! <%* tR += title %>"
cssclass<%* -%>: full-width
obsidianUIMode<%* -%>: preview
tags<%* -%>: ?️
---
# Порожденные категории
# Иерархии
![[<%* tR += title %> hierarchy]]
# Мета-заметки, черновики и прочее
```dataview
LIST
FROM
!#?️
AND
!#?️/?
AND
!"projects"
WHERE
contains(file.outlinks, [[]]) OR contains(category, [[]])
AND
!type
AND
file.link != [[homepage]]
SORT file.name ASC
```
# Проектные заметки
```dataview
TABLE WITHOUT ID
file.link AS "Проект",
category AS "Категории",
status AS "Статус",
platform AS "Платформа"
FROM "projects"
WHERE
contains(file.outlinks, [[]]) OR contains(category, [[]])
AND
!type
SORT choice(status = "?", "1", choice(status = "?", "2", choice(status = "?", "3", ""))) ASC
```
# Источники
```dataview
TABLE WITHOUT ID
file.link AS "Источник",
type AS "Тип",
status AS "Статус",
category AS "Категории",
author AS "Автор(ы)",
children AS "Конспекты, PDF",
url AS "url"
WHERE
contains(category, [[]])
AND
type
SORT choice(status = "?", "1", choice(status = "⚛️", "2", choice(status = "?", "3", choice(status = "?", "4", "")))) ASC
```
%%
next:<%* -%>: [[<%* tR += title %> hierarchy]]
%%
после
---
cssclass: dashboard
---
что я еще должен сделать в теле заметки чтобы увидеть то что у вас на скрине ?
Например, что-то такое. Немного отличается от скрина, но суть та же.
homepage
---
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]]
А можете еще объяснить что тут происходит чтобы потом можно было свои конструкции строить, тут же все программисты чего стесняться. Конструкция которая начинается и заканчивается --- это что где файлы подключаются и теги пишутся? теги понятно, а файлы какие только css или еще что то ?
И вот в вашем примере непонятно а где вызов классов css которые подключены там же название .dashboard а его нигде нет
Более того я убираю из обсидиан запись cssclass: dashboard и в вашем примере ничего не меняется, зачем тогда было городить все эти css и какие то непонятные сниппеты ?
Не шибко врубаюсь о чём вы конкретно спрашиваете, поэтому отвечу в меру своего понимания.
Для того, чтобы удобно навигироваться по своим заметкам создается стартовая (начальная) страница. Способов её организовать множество. Однако в статье я предлагаю сделать отображение начальной страницы с помощью Dashboard.
Суть Dashboard в том, что эта штука позволяет в режиме preview отображать списки в несколько столбцов (в зависимости от свободного места по горизонтали).
То, что выделяется с помощью "---" является областью метаданных, которыми можно эффективно размечать (категоризировать) заметки.
В метаданных можно использовать:
свои какие-то ключи
например, можно использовать ключ type, чтобы выделить разные типы заметок
ключи предопределенные Obsidian
к таким относятся
aliases – задает альтернативные наименования для заметки
tag – задает тег для заметки
cssclass – применяет заданные (сгруппированные) изменения к заметке
также бывают ключи, которые задаются определенными плагинами и механику которых будет отрабатывать именно плагин
например, это может быть obsidianUIMode (суть которого изложена чуть выше в комментариях)
Если говорить в преломлении Dashboard, то он, условно говоря,создает новое значение для ключа cssclass (если же точнее, то Dashboard просто создает набор сгруппированных css изменений, который впоследствии может быть также сгруппировано применен). Когда вы указываете это значение в заметке, то Obsidian распознает и применяет отображение в соответствии с кодом (в нашем случае из сниппета).
Сниппет для отображения в виде Dashboard создается по той причине, что Obsidian решил именно так отрабатывать механику внесения постоянных и небольших пользовательских изменений в css код.
Если же вы хотите писать код как в конструкциях по типу Dashboard, то это не ко мне.
Хотелось бы понять общую схему работы для определенной темы, я начал делать заметки с тегами, а потом с помощью запроса dataview в итоговой заметке объединять их, как понимаю это не лучший способ, ссылок не образуется, в локальном графе пусто, правильно понимаю что лучше в отдельной заметке делать ссылку на итоговую заметку, а в итоговой заметке уже запросами dataview формировать списки? и такой способ применять для всех тем или проектов ?
Перенес ваш пример для книг, добавления книги плагином который запрашивает все данные из интернета это прекрасно, а что насчет сортировки в итоговой заметке, то есть нажал на колонку создания все книги отсортировались по дате, или меню с категориями выбрал что то и остались книги только из этой категории, такого функционала не бывает ?
Как проще сделать добавление даты когда начал читать книгу, когда закончил, пока придумал сделать шаблон {{date:DD/MM/YYYY}} вставляя который получаю дату, но может есть способ проще?
Хочу перенести в обсидиан хорошо структурируемую тему которая врядли будет меняться(с нее проще начать что то делать), например сделать базу Инструкций к технике, мебели и разным вещам чтобы потом быстро их найти, схема такая: 1) В отдельной папке собираю все pdf с инструкциями. 2) Создаю шаблон для инструкций с полем для тегов, статусом, ссылкой на pdf и ссылкой на итоговый файл с инструкциями 3) В отдельном файле с инструкцией после вставки шаблона делаю свои заметки если они есть касаемые использования или сборки 4) В итоговом файле делаю dataview запрос и как то их сортирую например по статусу. Верная схема? или может что то не так? понятно что каждый делает как ему удобней, но для начала лучше послушать человека с опытом, тем более тема с инструкциями как мне кажется простая
Первый вопрос. Про темы
Немного про категоризацию я вот тут написал. К этому могу разве что ещё немного объяснений добавить.
Вы добавляете в систему, допустим, 10-15 каких-то источников. Работаете с ними. В какой-то момент, вам может показаться, что эти источники сильно тематически друг с другом связаны. Вы думаете как их можно связать друг с другом.
Связь можно сделать через категорию. Пусть это, например, будет категория "furniture assembly instructions" (инструкции по сборке мебели). Создаёте заметку с одноименным названием (помечаете её тегом ?️ или каким-то иным вам привлекательным образом). Далее пробегаетесь по своим источникам, находите все те самые 10-15 связанных по тематике источников и категоризируете их. В статье я это сделал через поле "category". Можете ещё раз глянуть на пример книжной заметки в статье.
Если вы заранее знаете какая у вас может появиться категория, то можно в заметках-источниках проставить призрак заметки. Когда необходимость в категории появится, то вы просто создадите заметку и оформите её как надо.
Можно ещё через inbox аккумулировать источники. Это скорее можно использовать для того, чтобы не приходилось вручную проходиться по всем источникам в поисках нужного. Т.е. вы создаете заметку и в ней перечисляете все нужные вам ссылки и материалы по ходу работы или исследования, а потом со временем преобразуете её во что-то более постоянное (например, мета-заметку).
Далее, можно в заметке-категории сделать dataview-запрос на то, чтобы был сделан показ заметок относящихся к именно текущей категории. Это можно сделать, например, так:
dataview
```dataview
LIST
WHERE contains(category, [[]])
```
Если ссылку оставить пустой, то она автоматически будет расцениваться как ссылка на текущую заметку.
Можно ещё более точечно сгруппировать источники или просто заметки. В таком случае вы создаете мета-заметку и в ней перечисляете всё, что вам нужно. Мета-заметку также стоит отнести к какой-то категории. Возможно будет что-то такое (первая строчка – это название заметки):
пример мета-заметки
инструкции для сборки шкафов диванов кресел
category:: [[furniture assembly instructions]]
# Инструкции для шкафов
- угловые шкафы
- [[инструкция по сборке какого-то углового шкафа]]
- ...
- встроенные шкафы
- [[инструкция по сборке какого-то встроенного шкафа]]...
# Инструкции для кресел и диванов
## Инструкции для кресел
...
## Инструкции для диванов
...
Небольшое дополнение. Чтобы категориальные заметки не были подвешены в воздухе стоит их все создавать в какой-то индексной заметке (в статье я эту заметку так и называл "index"). Саму же индексную заметку стоит вынести, например, на dashboard. Это нужно для того, чтобы можно было легко искать все нужные темы и в целом понимать какие категории есть в системе. А вот сразу пример dataview-запроса, который отобразит вложенные категории, если у вас таковые появятся:
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.
Ещё вариант это предварительно добавлять в шаблоны дату с помощью конструкции:
templater
<% tp.date.now() %>
Можно немного усложнить логику. Так можно добавить меню, которое при создании заметки будет спрашивать "Вы сегодня начали?". Если ответ "да", то он проставит сам дату в указанном месте:
templater
<%* let start = await tp.system.suggester(["Нет", "Да"], ["", " " + tp.date.now()] , false, "Вы сегодня начали?") _%>
start:<% start %>
Четвёртый вопрос. Про верность схемы работы с источниками
Да, схема, которую вы привели верная.
В целом могу разве, что ещё подкинуть идею. Помимо того, что есть категории, можно расширить также количество типов источников. Так, если у вас в базе знаний много именно инструкций, то почему бы не выделить их отдельно:
yaml
type: instruction
Но так лучше не делать, если нет уверенности в том, что это действительно нужно и это действительно принесёт пользу.
Пятый пункт, но не вопрос.
Довольно трудно выдать целиком всё видение про упорядочивание базы знаний, да ещё и в рамках комментариев. Более того, способов сгруппировать как-то знания довольно много и все они нуждаются в персональном рассмотрении. Чтобы у вас появилось более объемное видение того как всё это можно устроить, стоит глянуть или даже помучить своими вопросами других обсидианщиков.
а в чем разница между
type: instruction
tag: instruction
category: instruction
зачем так много разновидностей, если по сути это все теги (ну или выбрать type или category и использовать их, смысл же один)?
Ммм, наверное, можно сказать, что разница в разделенности.
tag – это внутренний функционал Obsidian. Логика тегов расширяется только за счёт вложенности. Например
tag
#instruction/furniture/sofa
type и category – это заданные пользователем метаданные. Тут, наверное, стоит особенно подчеркнуть, что именно пользователем.
Логику метаданных можно расширять также за счёт вложенности, но только уже более прозрачно:
yaml
---
type:
class: "instruction"
variety: "furniture"
object: "sofa"
---
Пример того как можно достать данные:
dataview
```dataview
LIST
WHERE contains(type.class, "instruction")
```
Ещё, наверное, стоит отметить возможность использовать в качестве метаданных заметки. Это по сути значит, что можно будет получить пользу как от использования метаданных, так и от самой заметки, а именно от её связей.
yaml
---
category: [[instruction]]
---
но лучше всё же такое делать в самой заметке, чтобы ссылки были клибельными и Obsidian их исправлял автоматически при переименовании
category:: [[instruction]]
Отсюда рождается возможность использовать иные механики взаимодействия с заметками. Так в следующей статье будет, например, про одну из таких механик – про иерархические заметки.
Теги, к сожалению, не подразумевают, что между ними можно делать какие-то связи.
Возможно есть ещё какие-то различия, которые я не вспомнил. Можете вот эту статью глянуть для большего углубления.
не могу понять почему код для плагина templater где то работает где то нет, создал шаблон для добавления книг из вашего примера все работает, а если я добавляют любой код в свой шаблон например <% tp.file.cursor(0) %>
то курсор я не получаю, а просто буквально этот текст в заметке <% tp.file.cursor(0) %> после добавления шаблона, папка где находятся шаблон для книг и мой шаблон одна и та же
Я не знаю почему у вас так. Проверьте документацию.
Разобрался надо нажимать в меню < % а потом добавлять шаблон. Добавил ваш шаблон про статью, в название категории вставил ссылку на файл, очень удобно. Теперь не могу сообразить как лучше все организовать. На примере этой статьи где пишу коментарий
В заметке про статью написал какие плагины или шаблоны я поставил узнав их статьи, возможно добавлю код шаблонов. Нужно ли как то разделять инфу полученную из статьи на отдельные заметки? если да то как?
Что писать в tags:: children:: если эта статья их не предполагает, то что вы обычно пишите ?
Что делать если статья по статусу вроде бы еще не done но висит в wip уже очень долго, предполагаю что такие будут
https://www.youtube.com/watch?v=7cqHhOcz6dY&ab_channel=qnnnp тут говориться о том что для учебы нужна структура wiki для базы знаний, а для творчества Zettelkasten, то есть в обсидиан сразу лучше завести два отдельных хранилища для этого ?
Ядрёные (в смысле непростые) вопросы, хах.
Немного не понял, что вы имеете в виду:
...в название категории вставил ссылку на файл...
Первый вопрос. Про атомизацию
Почти философский вопрос.
Я сторонник атомизации мыслей. Мне кажется, что это добавляет больше возможностей
в улучшении понимания идей
благодаря самому процессу разбиения
за счёт нахождения их места в других местах/контекстах или иерархиях
в последующем использовании
в прикладном смысле (создание прототипов, продуктов, сложных систем, концепций, алгоритмов и прочего)
в создании более точных, ясных и понятных ссылок внутри системы
Атомизация довольно интеллектуально затратный процесс. Поэтому, я думаю, что не стоит растрачивать силы тогда, когда атомные заметки потом не получится толком нигде использовать.
В преломлении этой статьи. Она уже сама по себе является приложением. Вы её читаете и что-то внедряете. Несомненно есть большой смысл в том, чтобы как-то залогировать свой процесс вникания. Я, например, системы других обсидианщиков порой вообще не могу распарсить без ведения записей по ходу дела. Однако эти записи позже я не атомизирую, ибо достаточно и лога, который я сделал (по сути эти записи остаются просто как справочная страница).
Наверное, стоит привести пример, когда атомизация имеет смысл.
Представьте, что вы занимаетесь спортивной медициной. Допустим вам попалась статья, которая говорит о влиянии гипертермического закаливания (по простому сауны) на выделение гормона роста. Для вас это важная информация, потому что гормон роста влияет на регенерацию тканей. Вы добавляете эту статью в вашу базу знаний и начинаете её обрабатывать – выделяете важные моменты, записываете свои мысли, ведете в целом конспект, дописываете уточнения и расширения при необходимости, может быть иллюстрации какие-то рисуете, выделяете основные факторы и условия, проверяете на статистическую достоверность и всё в таком духе. Далее из статьи нужно вынести какую-то пользу. Это можно сделать в том числе за счёт атомной заметки.
Так вы можете выделить из своих записей основную суть (например, что гипертермическое закаливание повышает выносливость и гормон роста), добавить к этой сути конкретное перечисление условий (повышает на столько-то процентов гормон роста, в такой-то возрастной группе, при таких-то параметрах влажности и температуры, при таком-то времени и прочее) и всё это превратить в атомную заметку. Саму же атомную заметку далее стоит связать с заметками "гормон роста", "гипертемическое закаливание" и поместить её, например, в мета-заметку "факторы влияющие на гормон роста".
Что это всё даёт на практике? В следующий раз, когда вам, например, будет нужно повлиять на гормон роста спортсмена (в силу, например, его недостатка), вы, например, откроете поиск в базе знаний и напишете "гормон роста". По связям вы найдете и мета-заметку (где будут явно перечислены все факторы и все известные в целом вам способы), и соответственно при необходимости можете найти все подтверждающие исследования (которые тоже не подвешены в воздухе, ибо снабжены вашими размышлениями, акцентами, уточнениями и всем, что вы там написали, пока изучали статьи).
Надеюсь такой занудный и объемный пример более-менее прояснил картину. Как технически это все сделать есть в самой статье: можете открыть алгоритм, который в конце на блоке "атомизация (рефакторинг)" и последующий за ним "Связывание".
Второй вопрос. Про метаданные
Если в них нечего поместить в соответствии с их логикой, то ничего. Просто остаются пустыми.
На всякий случай уточню и расширю немного понимание:
tag – если исходить из логики статьи, то сюда можно поместить тег атомизации ⚛ и возможно тег для пересмотра заметки⏳, если есть плагин spaced repetition
children – здесь можно сделать ссылки на конспекты и в целом что-то порожденное источником (например, если это книга, то могут быть "проекты по книге...", "практическая работа по книге...", "прототипы по книге...", "мои статьи по книге...", "методические пособия по книге...", "результаты испытания по книге..." и прочее подобное), а также можно добавить сюда же ссылку на pdf-файл (что, наверное, даже будет немного практичнее, чем тот способ, который я указал в статье)
Третий вопрос. Про статусы
Работа с базой знаний – это марафон. Если в базе что-то очень долго обрабатывается, то ничего страшного. Никто никуда не должен торопить.
Возможно, чтобы у вас появилось более чёткое разграничение, стоит немного расширить количество статусов. Например, вот так:
todo - ожидающие обработки
Нигде ещё не упоминал, стоит, пожалуй, хоть тут сказать. Не стоит использовать базу знаний как агрегатор для read later. Ибо это может создать огромное количество бесполезных ссылок и создать длиннющие и совершенно неинформативные списки с источниками (типа какой смысл источника, если в нём нет вообще ничего?)
Статус todo стоит расценивать как прямое намерение в ближайшем будущем разобрать источник, потому что он, например, нужен для какого-то проекта
wip - в процессе работы
atom - ждёт разбиения (вариант, чтобы не использовать тег ⚛️ на источнике, а только на конспектах или где-то ещё)
abandoned - заброшенный источник (не приходит, к сожалению, в голову какое-то короткое слово)
done - обработанный источник
Четвертый вопрос. Про разные хранилища
Идея хорошая. Обоснование вполне себе нормальное. Но я, наверное, лучше бы так не рекомендовал делать.
Если достаточно точно проработать рабочий процесс, то путаницы не появится, а возможность использовать заметки и как справочные страницы, и как атомные останется.
Честно говоря, я так сейчас подумал... И понял, что у меня начинает голова пухнуть из-за того, что я не шибко могу представить как вообще должна работать разделённая на разные хранилища организация вики-стиля и zettelkasten-стиля.
Наверное, стоит ещё немного пояснений добавить. Если есть необходимость создать какой-то опорный текст или узконаправленную структуру, то можно пользоваться механизмом мета-заметок. (Для организации больших структур всё так же остаются категории.) Если нужно сделать что-то в обучающих целях или в качестве прикладной работы, то тут через механизм проектов. Если есть нужда создать какие-то иерархические структуры, то через механизм соответственно иерархических заметок. Вдобавок можно смазывать рабочие процессы с помощью вечнозеленых заметок и с помощью различных алгоритмов по типу ENCODE.
Надеюсь, что я ответил на ваши вопросы, ну и надеюсь, что покрыл большинство других потенциальных, хех.
...в название категории вставил ссылку на файл..
я имею ввиду что писать название категории в виде ссылки типо [[obsidian]] чтобы к примеру при запросе dataview категория была кликабельна
Под конспектом статьи и логированием процесса вникания, вы имеете ввиду одно и тоже? просто список по пунктам информации которая показалась важной?
Как сделать такие же как у вас аватары папок periodic home files итд ?
В папке projects есть подпапка статьи, почему они в этой папке, а не в общем списке обсидиан, статьи же могут быть по любой теме
Какой шаблон использовать для обычной заметке, что вы используете ? как понимаю какие то мета данные котрые всегда нужны например нашел где то такой
UId: {{date:YYYYMMDDHHmm}} tags: [] aliases: []
Или надо будет разрабатывать свой шаблон под каждую ситуацию, как вот с книгами, статьями итд и что то универсальное особо и не нужно ?
Почему картинки которые перетаскиваю в обсидиан копируются в общий список, а не в паку ресурсы указанную в настройках ?
Что должно быть в общем списке файлов?, хорошо структурированные темы например пдф инструкции для техники или инструкции по настройке чего либо храним в отдельных папках ?
Не очень понятно по работе например со статьей, я обнаружил что сначала у меня появляется некий черновик в который я выписываю какие то тезисы из статьи, свои вопросы по статье, заметки на что обратить внимание и проработать подробней из других источников информации, а потом уже формирую чистовик где списком выписываю все полезное по статье, ну и может потом выделяю что то очень умное в отдельные заметки, так а черновик как создавать и хранить в обсидиан, вот я создал по шаблону(из вашей статьи) заметку на статью я туда и начинаю писать все сразу, как лучше делать может тогда две заметки создавать одна это та что по шаблону, а вторая это черновик и ссылка только на главную заметку по статье, если так то как это автоматизировать ? Ну или может черновик не нужен совсем ? куда тогда помещать и как потом хранить весь этот поток первичных мыслей по статье ? И это относиться не только к статьям, вот я недавно проработал одну сложную тему по настройке оборудования, сначала было все в кучу статьи которые я изучил по настройке, порядок действий который я делал, вопросы на форумах, то есть черновик в котором мало что понятно если открыть его через год и потом я сделал отдельную заметку где без лишних слов по пунктам все расписал, чистовую заметку более менее понятно как оформлять, но чистовые заметки у меня например просто так не появляются, а про черновики что то как то я не увидел описания как с ними работать, не писать же их в другом софте каком то.
Как сделать запрос на dataview если допустим заметка имеет две категории например так category:: [[obsidian]], [[Бег]] чтобы после запроса выдавались заметки которые соответствуют хотя бы одной из категорий, как понимаю с тегами dataview так может, а с другими полями не нашел как реализовать
Про конспекты
Можно сказать, что в грубом приближении это одно и тоже. В более же тонком всё сильно разнится. Логирование процесса своего вникания – это прямолинейный способ в чём-то разобраться за счёт, условно говоря, "подражания" какому-то источнику на бумаге. Конспектирование – это процесс формирование сжатого пересказа самых главных идей, которые впоследствии будут где-то использоваться и переиспользоваться. Лог остается как есть. Конспект доделывается и шлифуется до адекватного уровня читаемости.
Про иконки
С помощью плагина Icon folder.
Про подпапки в projects
Можете сделать плоскую структуру.
Однако я решил, что плагин projects довольно прост в освоении и весьма функционален. Но, чтобы в нём разделить чётенько на направления, нужно использовать именно подпапки.
Я лично юзаю плагин db-folder (его можно юзать из самого projects) и он мне немного больше нравится в плане конфигурирования. Сами файлы проектов у меня лежат в плоской структуре. Проекты же организуются сущностно также как и источники, т.е. через метаданные и ссылки.
Про шаблон для дефолтной заметки
Довольно трудный вопрос.
С одной стороны, хорошей мыслью будет добавить какой-то шаблон для дефолтной заметки. Возможно, даже из метаданных можно будет в будущем какую-то пользу получить.
Но с другой стороны, скорее всего дефолтные данные будут в большинство своём не более, чем информационным шумом. Хуже того, если вдруг появятся какие-то новые идеи о том как организовать шаблон обычной заметки, то, вероятно, придется переделывать все старые заметки. А это очень занудно и по сути опять же может ничего не дать.
Лично для себя я нашёл компромиссное решение. Я сделал такой дефолтный шаблон:
yaml
---
tags<%* -%>: ⏳
sr-due<%* -%>: <% tp.date.tomorrow("YYYY-MM-DD") %>
sr-interval<%* -%>: 1
sr-ease<%* -%>: 230
---
<% tp.file.cursor(0) %>
<%* -%> - эта штука нужна, чтобы "сломать" метаданные и шаблон перестал выдаваться при запросах
Он построен на использовании плагина для интервальных повторений. Как мне кажется, это более разумное решение, которое заменяет простой перебор своей базы в случайном порядке (так или иначе перебирать свою базу знаний всё равно дело полезное).
В остальном же обычные заметки у меня используются в виде ссылок в мета-заметках, в иерархиях, в проектах, в других заметках и этого более или чем достаточно. Периодически я использую логику вечнозелёных заметок, но делаю это вручную и когда я действительно понимаю, что это принесёт пользу. Можно сказать, что я наращиваю сложность точечно в конкретных случаях и только там, где она реально нужна. Иначе говоря, сложность достигается не за счёт сложной структуры самих заметок, а скорее за счёт сконцентрированного использования множества разных заметок в конкретном месте.
(Ну, и кстати, да... Стоит уточнить, что в системе у меня больше всего атомных заметок, поэтому дефолтные заметки у меня именно они.)
Источники унифицируются потому что они унифицируемы. Как бы это не тавтологично звучало. Также проекты, мета-заметки, периодические заметки, цитаты, заметки по авторам, иерархии и схожее тоже унифицируются, так как понятно, что в них должно быть. Но вот в обычной заметке трудно предсказать, что будет написано и как это можно заранее упорядочить. Поэтому лучше не тратить силы на гадания и тем более не подписываться на потенциальные последующие исправления.
Про картинки
Не знаю в чём причина. Должно всё чётко отрабатываться.
Про структуры в папке files
В ней лежит всё, что не является заметкой. Все структуры и перечисления нужных файлов мы делаем в заметках.
Хотя, наверное, всё же стоит отметить, что в моей логике, работа с файлами – это единоразовое мероприятие. Так в заметку добавляется какой-то документ, pdf, картинка и прочее, а в остальных же случаях делается ссылка именно на заметку, а не на файл.
Про обработку информации
Тоже сложный вопрос, хех.
Управление знаниями не шибко лёгкий процесс. То, о чём вы говорите не совсем относится к базам знаний.
Если уж совсем кратко, то у вас крайне короткий цикл работы со знаниями: черновик -> обработка -> чистовик.
Вам стоит прежде вот этот небольшой блок прочитать.
Как вы из него поняли, между сбором информации и её применением лежит довольно много других этапов. База знаний существует для того, чтобы голова не лопнула от натуга держать внутри все эти процессы, переходы и отношения.
Короче говоря, вам нужно порядок проблемы повысить, чтобы понять как поступить правильно. Этого можно, в первую очередь, добиться за счёт довольно прямолинейного способа – просто копить данные в базе знаний и ждать, пока не начнут проявляться систематические ошибки, мешающие дальнейшему эффективному накоплению и изъятию информации. Далее же анализировать эти ошибки, искать решения и их внедрять.
Менее прямолинейный способ, но более разумный заключается в следующем. Вам, например, нужно нарисовать подробную схему всех рабочих процессов в базе знаний (как знаете, как понимаете). Далее эту схему вам нужно улучшать по мере изучения каких-то источников про базы знаний (данных), про разные способы обработки информации, источники про работу мозга и обучение, про создание всяких разных сложных систем, про работу с проектами и т.д. Улучшаете схему -> улучшаете базу знаний.
Я понимаю, что таким ответом не решаю вашу проблему напрямую. Но, с другой стороны, я могу, конечно, теоретически (т.е. так я делать всё равно не буду) просто вам вывалить все решения и их обоснования, которые я принял в своей базе знаний. Но толку, как по мне, от этого не будет, так как вы просто будете примерять разные решения, вместо того, что напрямую реализовывать возможности уже имеющихся у вас инструментов в соответствии с вашими нуждами.
В общем моё предложение в том, что, либо подождите, пока решение родится из возникающих проблем, либо нарисуйте схему вашей базы и пытайтесь её улучшать за счёт её регулярного обдумывания (модификации) и новых знаний.
Запрос на две категории
dataview
```dataview
LIST
WHERE
contains(category, [[obsidian]])
OR
contains(category, [[Бег]])
``
Логика contains как раз решает вашу проблему.
По книгам правильно понимаю что схема работы такая, если книга в пдф при чтении в проге (например в goodnotes или аналогичной) делаются всякие подчеркивания маркером возможно мелкие заметки на полях, потом импорт файла из формата проги обратно в пдф но уже с заметками и потом синхронизация с папкой из которой она будет доступна для обсидиан ? то есть кроме заметок в самом обсидиан будет еще проработаный пдф. Или если все в обсидиан то в пдф нет смысла что то помечать для себя ?
И если по книгам схема работы правильная, то что делать со статьями из браузера, есть какой то способ их так же прорабатывать с рукописными заметками на полях, потому что нормальнрго способа конвертить их в пдф не нашел
Разобрался к копочками плагина buttons очень удобно, а есть способ как то их помещать в строку, а не друг под другом ?
Обработка книг
Не совсем так как вы описываете.
В заметке-источнике есть ссылка на PDF-файл (или на djvu, или epub или любой другой подобный). Именно на него мы нажимаем и именно его мы аннотируем.
Пример
![](https://habrastorage.org/getpro/habr/upload_files/438/0ac/c01/4380acc01b3c8ca62dd2fdd350bc0799.png)
Жмёте на ссылку PDF-файла правой кнопкой мыши, потом "Open in default app". PDF-файл откроется в вашей стандартной читалке.
Этот способ подразумевает, что вы источниками управляете в самом Obsidian. В целом этот способ вполне себе самодостаточный.
Но с другой стороны, есть большой смысл в том, чтобы разделить управление источниками и управление знаниями. В таком случае стоит использовать что-то типа Zotero. Однако пихать ещё и его в гайд было бы чересчур жестоко. Да и не всем это нужно.
Обработка статей
Я тоже не нашёл хороший способ конвертировать статьи в PDF. Поэтому пользуюсь расширением, которое включает режим чтения и из него уже конвертирую в PDF. Проблему это не шибко решает, но по крайней мере статьи получаются более-менее читаемыми.
Про buttons
Можно сделать их в одну линию, но они будут не всегда корректно работать (если вообще заработают).
Пример
![](https://habrastorage.org/getpro/habr/upload_files/965/25f/d91/96525fd9162f2b9ded1d8fe6862bfbfe.png)
Вот тут, например, проекты будут открываться (плагин Projects), а из Templater шаблон не создастся. А вот, если создавать шаблон из QuickAdd, то всё будет окей.
Немного ещё про обработку (текстовых) источников
Я, пожалуй, сокращу алгоритм, который привёл в статье до более читаемого, хах. Ну, и немного его расширю. Возможно, что так я смогу показать какая схема, на мой взгляд, является "правильной" и возможно это вам поможет как-то получше и поточнее настроить и структурировать ваш рабочий процесс.
Общий алгоритм такой:
Быстрое чтение источника (выявление основной сути и обозначения для себя, что нужно ли в принципе дальше изучать текст)
Чтение с аннотированием (выделение опорных моментов, возможно написание по ходу дела комментариев, визуальные какие-то дорисовывания; этот этап нужен для того, чтобы чётко разметить текст, который мы собираемся обрабатывать)
На основе аннотаций формирование конспекта (отражение своего понимания текста; только тут начинается использоваться Obsidian)
Разбиение конспекта на атомные заметки (создание заметок, которые будут независимы и которые будут нести какую-то полезную, значимую информацию)
Вынесение атомных заметок в заметку-источник и приведение их в некую первичную плюс-минус читаемую структуру (частенько именно из заметок-источников будут набираться заметки для дальнейшего использования; выносить атомные заметки можно сразу после того как был атомизирован конспект по, например, какой-то главе книги)
Дальше уже на выбор
Создание мета-заметки, которая будет объединять какие-то определённые идеи из разных источников в одну "кучу"
Создание иерархии, которая будет предельно чётко показывать как идеи (заметки) друг к другу относятся (т.е. создание эдаких справочных страниц)
Создание проекта, который будет уже напрямую использовать заметки, которые были намайнены из различных источников
Создание прочих структур, которые могут, например, реализовывать какие-то иные алгоритмы обработки информации
Связывание заметок между собой – развитие сети взаимосвязанных мыслей (вообще говоря, этот процесс можно делать когда угодно – можно во время конспектирования, можно во время проектов, а можно напрямую заниматься перебором заметок)
Важно заметить, что не обязательно именно в таком жёстком виде использовать алгоритм. Да, и вообще мета-заметки и иерархии – это структуры, которые удобны, логичны и понятны именно мне (это стоит учитывать... хотя, вообще говоря, если почитать того же Зонке Аренса, то у него подобное также можно вполне себе найти).
Можно, например, начать с создания проекта, а потом под этот проект набирать источники, их обрабатывать и тем самым прогрессировать (решать поставленные задачи).
Можно сначала создать мета-заметку и вести в каком-то смысле исследование: ставить гипотезу, искать и обрабатывать источники, находить всё более сложные и точные вопросы, играть с мыслями. Потом, когда исследование куда-то наконец-то приведёт, то можно подрихтовать мета-заметку и сделать из неё нечто похожее на манускрипт (прообраз статьи, книги или чего-то похожего).
Иерархии же обычно выступают как служебная структура. Так, например, её довольно легко сделать когда мы изучаем что-то последовательно и в таком случае она выступает скорее просто как помогающая обучению. Но куда более интересны иерархии, когда мы их делаем по сложным и запутанным источникам или когда их в целом собираем из разрозненных источников (по сути через своего рода инсайты). В этом случае иерархии будут выступать скорее как хорошая интеллектуальная опора.
Наверное, даже будет разумнее начать именно с волнующих проблем, а не пытаться заниматься упорядочиванием всей поступающей информацией. Иначе говоря, стоит сначала создать потребность (смысл), а потом уже её пытаться удовлетворять за счёт изучения источников и обработки их в Obsidian.
***
Я уже начал писать статейку про все эти мета-заметки, иерархии и прочее, но с ней меня пока что разбирает прокрастинация. Так что надеюсь, что такие мои не шибко обогащенные примерами, и не очень структурированные комментарии как-то вам помогают.
Да ваши комментарии очень помогают, просто весь алгоритм обработки источников раскидан по нескольким статьям и уже половина забывается когда приступаешь к работе, если будет новая статья то нужно только про алгоритм от начала и до конца, чтобы можно было обращаться как к справке в одно место. Книги, статьи, видео(аудио подкасты тоже самое что и видео) это самое важное, фильмы это уже чистое развлечение не очень интересно.
1) По дефолтному приложению для работы с пдф, а что это за приложение? рисовать в пдф удобнее на планшете как понимаю, потому что там же читаешь и сразу рисуешь или есть какой то другой порядок действий? я засинхронизировал обисидиан на Iphone, ipdad, macbook и windows комп, пока что он везде нужен, и по планшету пока не нашел удобной проги редактирования пдф, только как я описал сначала редактирование потом конвертация и отправка в нужную папку.
2) И по обработке информации с одной книгой не получилось бегло прочитать и уже потом что то делать, читал одну главу и выписывал сразу в обсидиан в виде конспекта, каждое определение искал в гугле другими словами и тогда более менее начинало все проясняться о чем вообще говориться в книге, а вот следующую книгу ну вроде как получается примерно по вашему алгоритмну, то есть алгоритм должен подстраиваться под источник, потому что если я читал бы первую книгу подряд до конца я бы просто уснул, не понятно абсолютно ничего.
По дефолтному приложению для работы с пдф, а что это за приложение?
Не знаю какое у вас приложение по дефолту. Если Windows, то может быть Foxit reader. Если macOS, то видимо встроенная читалка.
Решил проблема конвертирования статей в PDF
Нашел плагин для сохранения статей в obsidian ReaditLater.
Принцип простой нужно скопировать ссылку на статью в буфер обмена, а потом нажать кнопку от плагина в обсидиан и он сам создаст новую заметку с названием таким же как статья, для видео тоже подходит, так как сразу вставляет ссылку на видео в заметку и название в заголовок заметки.
По статьям для себя определил такой алгоритм работы, 1) С помощью ReaditLater сохраняют в обсидиан и экспортирую в pdf 2) Потом в pdf читаю подчеркиваю важное и заношу страницы где есть мои подчеркивания в закладки 3) Потом пролистываю свои подчеркивания и пишу резюме в обсидиан
И сейчас прихожу к выводу что сам текст статьи в обсидиан не очень то и нужен, но без него не сделать нормальный экспорт в пдф, чтобы потом нормально поработать над статьей.
Может у вас будут другие мысли, по какому алгоритму работать над статьей из интернета ?
вот настройки для плагина ReaditLater которые повторяют структуру которая у вас в статье, тестировал на хабре, даже автора корректно сохраняет, помоему все идеально и работает лучше чем метод из вашей статьи потому что все автоматизировано, не надо писать заголовок и ссылку. Теги templater в плагине не поддерживаются, но вроде и так все хорошо.
type: article
status: todo
recommendedby:
tags::
prev:: [[articles|назад в библиотеку]]
category::
url::[>>>] (%articleURL%)
children::
author:: %author%
%articleContent%
Давайте немного поговорим о целях, которые преследуют pdf-файл и заметка-источник.
Начнём с pdf-файла. Итак он нужен для следующего
чтобы надёжным образом сохранить материал первоисточника
это нужно для того, чтобы мочь продолжить чтение с места на котором остановились
также это нужно, чтобы просто мочь прочитать какой-то материал, если вдруг к нему пропадёт доступ в интернете
ещё это нужно, если вдруг появятся какие-то сомнения в сделанных заметках
т.е. чтобы можно было ещё раз проверить, например, какую-то фактическую или справочную информацию
чтобы была возможность проаннотировать текст
само аннотирование нужно, чтобы расставить для себя метки по которым потом будут формироваться заметки
иначе можно сказать, что выделения в тексте нужны для того, чтобы обозначить наиболее ценные в нём мысли
Теперь заметка-источник. Она нужна для следующего
чтобы агрегировать в себе служебную информацию о самом источнике
в основном это нужно, чтобы вы потом этот источник смогли найти в своей базе знаний (например, для того, чтобы продолжить его исследовать или продолжить формирование заметок, или непосредственно использовать мысли из него по назначению)
чтобы агрегировать в себе полезную информацию, которую вы добыли из источника
это могут быть какие-то полезные идеи, иллюстрации, код, схемы, формулы и прочее
всё названное выше может быть превращено в атомные заметки и отправлено в какое-то иное место в системе (например, в какие-то определённые проекты)
также заметка-источник нужна для того, чтобы можно были отследить по обратным ссылкам источник из которого появились те или иные атомные заметки
Вроде как все цели обозначил. Попробуйте на них опереться, чтобы как-то разделить логику для пдфки и заметки-источника. Возможно вы вообще зря мучаетесь с pdf-ками, ибо они вам по факту раз через раз нужны.
Теперь немного про ваши улучшения.
Я вас поддержу в этой мысли
сам текст статьи в обсидиан не очень то и нужен
Так что строчка "%articleContent%" в шаблоне лишняя. Поэтому лучше, наверное, поискать какие-то иные альтернативы (костыли) для сохранения интернет статей в pdf-формате. Я не шибко сильно узнавал возможности по тому как это можно сделать эффективно, поэтому что-то лучше того, что упомянул в позапрошлом комменте не смогу посоветовать.
Но в общем с ReaditLater у вас хорошая идея. Этот плагин можно, кстати, на button повесить.
button
```button
name ? article
type command
action ReadItLater: Save clipboard
```
Я щас подумал что идеально было бы чтобы вызывая ReadItLater был выбор сохранять ли текст статьи в заметку или просто создавать заметку без копирования статьи, не нашел, но может быть есть такое ? с помощью функционала button это как то организовать ?
Честно говоря, что-то не приходит в голову какого-то решения. Возможно, вам вот это видео как-то поможет.
удалено
Часть 2. Управление знаниями в Obsidian. Базовый рабочий процесс. Журнал. Источники и их библиотеки. Пример