О чем эта тема? Да о том, что я вдруг узнал, что я не один этим маюсь
Как вы сейчас в итоге ведете записи\заметки? И в чем?
Создание абсолютно новых моделей и подходов очень сложно и не всегда оправдано. Но наблюдать за этим как за процессом чистого созидания одно удовольствие. Особенно когда оттуда летят различные инсайды.
1 лайк
В чем угодно. Встраиваю процедуры чтения во все свои программы, за исключением вынужденных использовать чужие форматы. Родился-то мой “формат заметок” просто как более дружелюбная и компактная замена XML. А то, что в итоге получился ящик “с которым можно вести диалог” изначально не планировалось.
По указанной мной ссылке, например, описывается, как самому соорудить пригодный для ведения заметок инструментарий “на том, то есть” - от пустого DOS до JavaScript, живущего в пустом Windows или в любом браузере…
Я честно пытался осилить, но это очень сложно.
- потому что это язык разработчика
- потому что очень много абстрактных конструкций за которыми может стоять разный смысл и не понятно что именно имеется в виду
Поэтому и задал вопрос.
А можно несколько скринов ваших заметок?
А в идеале бы видео как вы добавляете или ищете какую либо заметку или ряд заметок.
Там по ссылке под первым же спойлером. Все не просто, а очень просто. Одна заметка состоит из идущих подряд “разделов”:
- одна - несколько строк ПУТЕЙ (как пути к файлам на компьютере),
- строка - указание типа ТЕКСТ, ЗАПИСИ или ТАБЛИЦА,
- один-два абзаца просто текста,
- если нужно строк-параметров.
Вся компьютерная ориентированность моего формата по сравнению, с бумажным состоит в том, что мне не нужно разделять физическое положение карточки, нумерацию, теги и ссылки. Это все равно прописывается в путях. Карточка в просмотрщике показывается по всем адресам, указанным в путях, как будто я поворачиваю ящик так, чтобы смотреть на него от текущей карточки.
Например, первая же карточка моего примера (под спойлером по ссылке) подписана двумя путями -
\Конденсаторы\Кривые от Пети\ELV
\Конденсаторы\Электролитические алюминиевые\Для поверхностного монтажа\ELV
Т.е. эти Конденсаторы я могу искать и по справочнику, идя от их типа, или по способу их получения - от Пети. В любой момент я могу дополнительно приписать путь-пометку
\Сегодня!\Надо купить\ELV
или
\Надо припаять\Люминевые
База-то чисто текстовая и вносить в нее правки я могу в любом текстовом редакторе, или легко написать свой (см. картинки по ссылке). Более того, я могу даже написать программу, которая будет свои результаты выдавать в виде готовых “карточек”.
Пример просмотра дерева карточек тоже болтается в теме, на которую я сослался. См. там после особо мерзкого куска кода ссылку “Кусок редактируемой БД в сыром виде” (в очень сыром и непричесанном виде, без картинок и с минимумом перекрестных ссылок, но все-таки можно понять, как перемещаться по ПУТЯМ “вдоль и поперек”).
Приношу свои извинения. Вбросил достаточно сырой кусок текста в расчете на технаря со схожими проблемами. Поэтому и не обозначил интересующие меня вопросы. Ну и черт с ними. Не берите в голову. Это не реклама и не предложение “царского пути в геометрию”.
Ну вот в этом то как раз таки вопросы и возникают. Даже если для вас это не сырой материал, для меня как для неразработчика и незнакомого с вашим образом мышления это сложно.
Я хотел бы понять принцип и реализацию.
Мое видение этого момента следующее.
Принцип важен потому что он стоит над методами и инструментами. Принципы не меняются или меняются мало, на принципах основаны методы и инструменты. Методы могут меняться часто и инструменты тоже, да они и зависят друг от друга. Принцип можно применять в разных методах и инструментах.
Я вроде бы начинаю понимать что вы имеете в виду. В связи с этим вопросы появились далее.
- Вы можете\делаете сраз карточек по промежуточным путям?
Для путя:
\Конденсаторы\Электролитические алюминиевые\Для поверхностного монтажа\ELV
Можете взять карточки в которых фигурирует “Электролитические алюминиевые”?
- Используете ли вы древо путей или по большей части поиск?
- Структура древа вообще важна для вас, или это просто возможный инструмент визуализации или упорядоченного хранения заметок, с помощью которого вы присваиваете заметки те или иные категории?
- Как формируется путь? Для одной заметки можно использовать несколько разных путей. Как вы понимаете и определяете для себя несколько разных путей? Они могут быть похожи или неочевидны. Например я недавно пытался определить древо для понятий знания, обучение, память, информация. Это рядом все, но что является частью чего определить сложно потому что это вопрос взгляда, и во вторых вопрос использования в дальнейшем.
Не особо технарь, но мне интересно разобраться с вопросом потому что озадачен таким же. Более того пояснение вашего подхода мне интересно потому что он выходит за рамки “стандартных цеттелей”, а то что за этой границей как раз может дать интересные плоды. Может дать а может и нет. В любом случае одна голова хорошо, а две хорошо хорошо если они не слепо копируют идеи друг друга. Поэтому если вам не скучно, я бы продолжил разбор. Не отвечал долго т.к. был не на связи, но интерес к теме не пропал.
Попробую сравнить ГЛЮКВУ с маршрутизацией Zettelkosten, насколько я понимаю последнюю. Еще раз подчеркну: “своеобразие” построения ГЛЮКВЫ не каких-то принципах, а чисто в реализации. Просто, компьютеру что-то проще, а что сложнее.
Во-первых, у бумажной карточки есть физическое место в ящике. И соответственно “главный путь доступа”. Для ГЛЮКВЫ он не особо важен, порядок карточек в файле произвольный, программы редактирования могут менять его как им удобнее. Например, вынести подходящие карточки в отдельный файл, а после обработки просто приписать в конец старого.
“Главный путь” обычно все же существует - чаще всего соответствуя оглавлению (“книга\часть\глава\раздел”) или дневнику (“год-месяц-день”). Зависит, скорее, от способа создания фрагмента, чем от его “смысла”.
Во-вторых, у бумажной карточки есть ее главный номер. В ГЛЮКВЕ таких номеров может быть много - это и есть пути. Любой опыт доступа к карточке может порождать новый путь. Вроде “\Не забыть пересмотреть.…” или “\Нашел интересное 2022.08.17.…”.
Другое отличие - ГЛЮКВА позволяет создавать карточки-потомки до карточки-родителя и карточки-братья вразброс. “Место под карточку” создается в момент потребности в ней, а не требует поиска “места” в уже готовой структуре.
В-третьих, ссылки одних карточек на другие. Это просто - к путям карточки, на которую ссылаются, добавляется путь, ведущий через ссылающуюся карточку. Тут можно найти проблему: какой из путей ссылающейся карточки взять для продолжения? Обычно я просто “беру по смыслу”. Или даже “добавляю по смыслу”, создавая специальное “поддерево” - “\Перекрестные ссылки.…” А, чтобы “не потерять связь” в просмотрщики вставляю механизм показа не только потомков на текущем пути просмотра, но потомков по всем путям карточки.
В-четвертых, теги. Вы, наверное, уже догадались. Да, это пути, начинающиеся с имени тега. По сути, ГЛЮКВА - это система тегов с их постоянно пополняющимся словарем.
Что забыл?
…
Как это удобнее просматривать? Во-первых, по “Содержанию” - всему дереву. Точнее, лесу. Уж какой-нибудь из путей карточки в данный момент кажется очевидным.
Во-вторых, “поперек дерева”. Для каждой карточки можно легко видеть
- путь, по которому в нее пришли от корня (и все карточки на этом пути, если они есть). Именно с этим путем я обычно связываю расчет/макроподстановку параметров. Например, придя к “Плоскогубцам” от “Фирменных” или от “От Пети”, я получаю разное значение параметра качества: “Хорошие” или “Дешевые”;
- ее “братьев” - потомков ее родителя на пути, по которому пришли;
- другие пути доступа к этой карточке (и карточки на них);
- ее потомков, на пути прихода и остальных.
В примере, который я выкладывал, оба этих способа показаны.
В-третьих, я могу в программе использовать дерево так, как это удобно. Работать только с частью дерева, создать специальные пути для нужд программы, сохранять историю поиска. Даже просто брать нужные данные из дерева, не показывая пользователю самого дерева. Причем, в силу устройства ГЛЮКВЫ, возможность добавления карточек в программе остается. Я могу даже создавать для каждого прогона программы карточку с результатами/статистикой ее прогона.
Нужен ли еще отдельный поиск? Это уже вопрос построения редактора ГЛЮКВЫ. Просто потому, что, что-то поискав, хочется это вырезать, отредактировать и засунуть обратно. Для этого даже не нужно “видеть дерево”, достаточно рассматривать файл-ящик как размеченный текст.
Если честно, то наибольшую часть ввода информации я проделал, правя текст базы в обычном текстовом редакторе и тут же просматривая результат в HTML-просмотрщике базы, на тот момент составляющем часть моей Интернет-Странички (и ее локальной копии).
Как-то так.
P.S. На самом деле, я, по сути, не придумал ничего нового. Именно так (один файл доступен по многим путям) работает ОС UNIX.
Правильно ли я понял что:
- при работе с одной и той же заметкой она может обрасти разными путями и тогда при построении дерева мы ее увидим в разных ветках? одна и та же заметка в разных ветках. но вас это не напрягает потому что выработаете или с частью дерева или с конкретной заметкой найдя ее по одному из логичных для поиска путей?
- каков шанс не найти вообще ранее созданную заметку по пути или поиску? что вы тогда делаете?
- правите ли вы заметки или просто создаете новые? навешивая подходящие пути?
- не путает ли то что 2 похожие заметки или как то связанные логически вообще никак не пересекаются путями? есть ли такое вообще?
При поиске наличие многих путей не напрягает потому, что все пути носят осмысленные имена. Просто, идя от корня “куда надо” я и прихожу “куда надо”.
Возможно даже, что, например, в одном настроении напишу \ФИЛЬМ\ЧУЖОЙ\МЕНЕЕ ИНТЕРЕСНЫЙ\ЛУНА-44, а в другом \ФИЛЬМ\ЧУЖОЙ\БОЛЕЕ ИНТЕРЕСНЫЙ\ЛУНА-44. Но, по какому бы пути я е пошел, я приду к той же заметке - фильма ЛУНА-44.
При просмотре же отдельной заметки просмотр всех путей к ней дает список всех возможных контекстов.
Не найти вообще ранее созданную заметку? Нет. Скорее существует страх случайно стереть ее, если программа редактирования сбойнет или найдется более старая копия заметки. Поэтому я обычно злоупотребляю написанием проверочных процедур в программах. Хотя, казалось бы, мозг и так многое забывает, программы страдают от этого реже. Что тут ловить-то?
Править ли вы заметки или просто создавать новые? Если есть желание сильнее формализовать, например, привести текст в табличную форму, обычно правлю, если меняю версию текста - создаю новую рядом. В тех системах, где подобные правки постоянно требуются по ходу работы, обычно пытаюсь привязать к системе параметров, чтобы по путям разных версий одна заметка имела бы разную сборку.
Две одинаковые заметки по разным путям? Дерево обычно делает это наглядным. Я даже иногда пишу редакторы, которые держат на экране два вида дерева рядом (как в старых DOS-навигаторах вроде Norton), для удобства копирования/клонирования.
Такой подход не мешает если нужно сформировать заметку на основе других заметок которые не всегда связаны напрямую а находятся например в разных путях.
Получается вы сделал нечто среднее между структурой и тегами. От тегов взяли вариативность набора, а от структуры взяли вложенность тегов.
В итоге у вас получилось многовариантное древо. Оно и структура и не структура одновременно. И срез и не срез одновременно.
Я просто выкинул из компьютерной модели все ограничения бумажной и размышляю, какие нужны ограничения, чтобы от “возможности сделать все” перейти к “методике делания нужного”.
У вас нет необходимости помнить что вы записываете, структуру путей и для чего эта информация? Вы используете свою модель просто как внешнюю память, что-то сохраняя или восстанавливая, правильно?
Я почему спрашиваю. Одна из задач моего архива это обучение. А для этого нужно очень хорошо понимать что за информация которую я хочу понять изучить, к чему она относится и с чем связана, почему она в тех или иных ветках. Если я условно “пойму суть” этой информации я ее точно запомню а так же то с чем она связана а заодно и тип связи и все что рядом. Поэтому у меня тоже может быть несколько путей, но к их выбору я достаточно жестко подхожу. Это и плюс и минус. Если я начну заметке приписывать пути фривольно, их будет много и это начнет запутывать в плане понимания структуры. По сути это основная причина почему я отторг всеми любимый цеттель.
Запоминанию “структуры” или “семантики” Баз Знаний в самих Базах Знаний есть предел. С одной стороны, полная аксиоматика согласно теореме Геделя невозможна, с другой, процедурная реализация какой-либо семантической обработки рано или поздно становится проще ее описания. Мы же пользуемся, например, “сложением чисел”, а не требуем каждый раз применения описывающей его рекурсивной функции.
По сути, единственная операция на которую способна структура данных “сама по себе”, это операция унификации. Т.е. мы находим, что, в каком-то смысле, одна заметка идентична другой заметке. Например, одна записывает диалог персонажей, а другая - формальное определение купли-продажи. В случае их удачной унификации мы узнаем в диалоге торг, выясняем, кто из участников диалога является продавцом, что продают, свершилась ли сделка… В Zettelkosten унификация производится единственным способом - проверкой, встречаются ли две карточки в одном контексте. Что и реализуется путем связывания их ссылками, тегами, наследованием…
Однако, вести “разумный” диалог ящик может, даже не выдавая ответов на интересующие нас вопросы. Для этого надо лишь добиться, чтобы ответы были ожидаемы и неожиданны в некоторой зависящей от нашего настроения пропорции. Этому ящик “учится” быстро, по мере накопления карточек и связей между ними. Было бы настроение…
Это наталкивает меня на мысль что такой подход стимулирует нас к тому что:
- нет смысла париться о структуре или качестве заметки, добавляй по смыслу и как хочешь, и со временем сможешь к этому смыслу привыкнуть так что большая часть вопросов и ответов будет найдена потому что привыкнешь к одним и тем же моделям применения
- нет смысла что-то запомнить, что запомнилось то запомнилось, остальное найдется в базе
в соответствии с текущим миропониманием и настроением
Похоже на набор старых дневников лежащих всегда в одном угу. Что-то где-то написал когда-то. Можешь посмотреть если что. Что нашел то нашел, что запомнил то запомнил. Не вспомнил или не нашел, ну значит и не особо нужно. Только в случае электронной записульки, находить проще. Ну во всяком случае так показалось. БЗ на расслабоне.
Да.
Меня, например, насторожила рекомендация выбрасывать карточки, относящиеся к законченным проектам. Значит, автор сам признает, что все его труды чисто спекулятивны?
Очевидно, что, если я хочу применять Zettelkosten разумно, этот разум я должен привнести в него извне. Например, как Вы говорите, наложив на эту сеть жесткую структуру (т.е. проведя унификацию большинства данных заранее и вручную).
Я думаю тут могут быть причины следующие:
- информация уже устарела или настолько изменена что хранить ее смысла нет
- автор взял от информации все что хотел и в дальнейшем она ему не понадобится, а информационный мусор вносит (работал над клиентских проектом, прошло 10 лет, проекту же никому не нужен даже как кейс)
- есть желание поддерживать только кратковременный актуальный слепок базы, то чем пользуемся сейчас
Сам я так не делаю, но вроде логика есть.
Есть и обратная ситуация когда человек хомячит в базу а никак это не использует, потому что даже банально забывает что есть что нет.
Ну вот это один из вопросов. С подходом цеттеля мы получаем что по какому-то запросу или карточке у нас ссылка на 100 других карточек которые как-то возможно связаны, но связь эта непонятна и не очевидна. И получается чтоб восстановить в памяти или сознании какой-то кусок древа, нам приходится пересматривать кучу других веток никак не относящихся к теме текущего запроса или относящихся оч косвенно.
В вашем случае как я понял это решается все же тем что вы не ссылаетесь все на все, и есть некое видение структуры. Просто к ведению этому у вас более расслабленное отношение чем например у меня.
Но тогда имело бы смысл, наоборот, оставить свои карточки и выбросить цитируемые первоисточники? Нет?
Да, кучу имеет смысл ограничивать. В мозгу этот вопрос решается чисто энергетически. В ГЛЮКВЕ я просто переключаюсь с вертикального просмотра (по одной ветви дереву) на поперечный (по другим контекстам) и обратно.
Когда появляются идеи разумного ограничения поля зрения, пишу программу. Например, в последнее время экспериментирую с программами, которые сначала выдают только безусловно полезную информацию, затем связанную с ней и т.д. до полного справочного описания вселенной. Пользователь просто останавливает вывод, когда понимает, что ему для принятия решения уже хватит. Таким образом, чисто текстовый вывод вполне заменяет графический…
Или, наоборот, для переноса материалов со своей старой подохшей интернет-странички в новую, я просто поставил выдачу случайного раздела из полного списка. Что сегодня выдаст, то и попробую перенести…