Чем я в данный момент занимаюсь. Monster Book.
Введение.
У каждого наверное есть дома архив. У кого-то большой, у кого-то маленький. Кто-то собирает музыку, фильмы, и игрушки, кто-то порнуху, а я вот собираю знания.
Что такое знание, и чем оно отличается от обычной информации? Информация буквально есть то, что содержится в форме. Форма, цвет, запах... Белый шум тоже вполне себе является информацией, поскольку имеет форму. Но белый шум вряд ли кому интересен, не так ли? Человеку нужна не информация, человеку нужны именно что знания.
Грубо говоря, знания являются информацией, которую можно использовать. Это проявляется не только в особом структурировании, в классифицировании и каталогизировании информации. Это проявляется в первую очередь в заточке собираемой информации под конкретные задачи. Знания, это всегда ответы на вопросы.
Итак, знания представляют собой ответы на вопросы. Тут-то и начинаются сложности. При грамотном подходе комплекс вопросов избыточен, и предметы знаний зачастую являются ответами сразу на многие вопросы. Таким образом, ни одна простая классификация не делает из информации знаний. Нет, конечно же можно создать отдельную классификацию по каждому интересующему вопросу, продублировав элементы нужное число раз, но это несерьёзно. Знания всегда находятся в состоянии уточнения, их нужно постоянно изменять. А изменять копии этих знаний в множестве классификаций, это адский труд.
Нет, дублирования знаний быть не должно, предметы знаний должны иметь возможность сразу входить в множество классификаций. Реляционный подход отпадает, и вместе с ним отпадает и практически весь набор методов работы с данными, который наработан к нашим дням. Технологии работы с нереляционными данными можно сказать что нет. Это прорывная технология, она глубоко изменит наш мир, но этого прорыва до сих пор нет.
Итак, нужна нереляционная база знаний. Я данной проблемой озаботился достаточно давно, с тех времён, когда простое накопительство с анализом у меня сменилось синтезом. Особый затык случился на вопросах организационно-штатной структуры армии. Захотел было попробовать сделать свою оргштатную структуру армии, хобби такое, да. Так вот, жопа. Беспросветная. Всё завязано на всё, прямо-таки гордиев узел. Изменяешь один элемент, и он заставляет изменять многие остальные элементы. Каждое подразделение во многом универсально, оно заточено одновременно сразу на решения множества задач. И изменение баланса мельчайшего элемента меняет баланс всего в целом. Но, конечно же, существуют некоторые рамки, в которых это изменение не несёт особого вреда. Но эти рамки совершенно непрозрачны, и более того, динамичны, что собственно и послужило первой проблемой, которую я попытался решить.
Традиционно нереляционные базы знаний строятся с оглядкой на реляционные. Если в реляционной базе каждый элемент имеет одно отношение, то в нереляционной базе отношений несколько. То есть допускается включение объекта сразу в несколько классификаций, и всё. Взять то же тегирование. Но этого мало, слишком мало. Да и само по себе тегирование глубоко ущербно, поскольку изменение сложившейся структуры является очень трудоёмкой задачей. Явно нужно что-то иное. Причём нужно не просто заложить некую структуру, а ещё и приложить к этой структуре некоторые полезные механизмы. Этой проблемой я и занялся несколько лет назад, в результате чего родился Monster Book. Звучит несколько пафосно, но мне нужно было данный проект как-то назвать, и я не нашёл ничего лучшего, как назвать его по своему нику.
Итак, Monster Book первого поколения.
В результате достаточно продолжительных размышлений я пришёл к следующему:
1. Книга состоит из разделов небольшого размера. Минимального, минимально достаточного размера. В разделе должно описываться лишь то, что относится к данному УРОВНЮ раздела, любые намёки на подструктуру должны описываться отдельной явной структурой, отдельным набором разделов, причём далеко не обязательно располагающейся в текущей классификации.
2. Разделы имеют явную иерархию, которая является уточнением ответов на корневой вопрос. Всё, что вне данного вопроса, должно описываться где-то во вне. То есть если разбираем организацию армии, то ни каких вопросов вооружения, снаряжения, тактики и прочего в данной иерархии рассматриваться не должно. И даже более того. Сам вопрос организационно-штатной структуры должен описываться несколькими отдельными иерархиями знаний. Каждый уровень армейской иерархии необходимо включать в отдельные иерархии знаний, пусть они и будут объединяться под одной крышей. Но, скажем, оргструктуры уровня роты никак нельзя описывать подразделами к какому-либо объекту уровня полка. Уровень роты, это отдельная и самостоятельная иерархия высокого уровня. Таким образом, разбиение должно быть предельно аккуратным, точным и мелким. Да, это достаточно трудоёмко сделать, но зато использовать такое будет куда как проще и понятней.
3. Каждый раздел может входить только в одну иерархию. Вас это наверное сбивает с толку, ведь мы как бы рассматриваем НЕреляционную структуру. Но всё должно быть именно так, нереляционность станет заметна чуть позже. Иерархии нужны здесь по сути дела исключительно для максимально точного разграничения рамок разделов нашей базы знаний. Кто занимался подобными вещами, наверняка помнит мучительное ощущение потребности выбора, типа а куда же это что-то там запихать. Размен шила на мыло, когда вроде бы и то надо, и это. Мучительнейшее ощущение, которое является всего лишь следствием недостаточно ясно и чётко формализованного подхода к классификации. Тут же эта проблема уничтожается на корню.
4. Разделы можно связывать горизонтальными связями, ассоциациями, причём эти связи обязаны быть двунаправленными, прямая ассоциация (используем вот его) должна порождать обратную ассоциацию (меня использует вот он). Эти горизонтальные связи принципиально неформализуемы, и именно в этом и заключается нереляционность. Горизонтальными связями должны описываться все те отношения, все те связи с разделами, которые не являются уточнением на вопрос, по которому строится текущая иерархия. Таким образом, по сути дела из привычной всем анархичной нереляционности мы выделяем скелет иерархий, который позволяет нашей куче данных не превратиться совсем уж в бесполезное дерьмо.
5. Не нужно пытаться объять необъятное, нужно активно пользоваться системным подходом, выделять в описываемом подсистемы. В идеале каждый раздел должен иметь 5-10 подразделов и 5-10 ассоциаций, причём выделяемые из массива ассоциаций подсистемы должны описываться в корректно обозначенных иерархиях.
Monster Book первого поколения. Реализация.
Итак, получилась достаточно несложная технология, которая элементарно реализуется не только на практически любом языке программирования (я использовал Lotus Notes), но даже НА БУМАГЕ. Берём тетрадь, отрезаем от неё узкую "тетрадку" шириной 3-5 см, возможно в двух экземплярах. Если тетрадь большая, то лучше сначала разрезать её напополам. И оформляем:
Широкая часть используется для описания разделов, а узкая сторона, -- ссылок. Каждую страницу нужно пронумеровать; если для ссылок используется несколько тетрадей, то их нумеровать насквозь. Поскольку таких "книг" будет наверняка несколько, то имеет смысл нумеровать и сами "книги". Таким образом, ссылки на страницы будут состоять из двух частей:
(номер страницы) - (номер "книги")
Если ссылка производится внутри "книги", то номер можно опускать.
Первая страница "книги" описывает самый верхний уровень, каталог иерархий. В принципе, для таких примитивных разделов, которые являются лишь набором ссылок, список подразделов можно давать сразу в поле текста, сопровождая их для удобства наименованием подраздела. Но вообще желательно для этого использовать тетрадь ссылок, потому что так будет удобнее пробежаться по всему списку.
При создании подраздела находим чистый лист, делаем на него ссылку в списке подразделов "родителя". Неплохой идеей является одновременное использование сразу ДВУХ тетрадей, с чередованием уровней разделов, т.е. при создании подраздела брать чистый лист не из той же тетради, а из другой тетради, после чего при дальнейшем углублении древа подразделов тетради меняются ролями. Так можно будет при работе видеть сразу и "родителя", и "потомков", что делает работу значительно более понятной. После выделения листа пишем на нём название, текст, и так далее. При потребности создаём разделы ещё более низкого уровня.
Когда нужно указать горизонтальную связь, открываем лист прямых ассоциаций (если его нет, то заводим), где прописываем ссылку на связываемый раздел, И ОДНОВРЕМЕННО для связываемого раздела указываем обратную ссылку в разделе обратных ассоциаций. Наличие списка обратных ассоциаций изрядно облегчает жизнь, потому что этот список хранит по сути дела список всех тех разделов, в которых используется данный раздел. Например, если изменяем какой-то критичный параметр раздела, то можно сразу же оценить, к каким последствиям это приведёт, пролистав оный список обратных ассоциаций.
Если страница заканчивается, то производим перенос, находя чистую страницу и указывая её в поле переноса. В принципе, было бы неплохо сохранять и обратные ссылки, но мне они пока не требовались. Точно также имеет некоторый смысл и в странице ссылок делать обратную ссылку на раздел, к которому относится ссылка; и так же и в прочих подобных местах. Но мне всё это пока не требовалось, я вообще с бумажным вариантом особо не работал, поскольку имею более удобный электронный вариант. Но бумажный вариант вполне работоспособен, и вероятно, кому-то будет полезен. Бумага проигрывает в наглядности, но есть у неё и свои сильные стороны.
У каждого наверное есть дома архив. У кого-то большой, у кого-то маленький. Кто-то собирает музыку, фильмы, и игрушки, кто-то порнуху, а я вот собираю знания.
Что такое знание, и чем оно отличается от обычной информации? Информация буквально есть то, что содержится в форме. Форма, цвет, запах... Белый шум тоже вполне себе является информацией, поскольку имеет форму. Но белый шум вряд ли кому интересен, не так ли? Человеку нужна не информация, человеку нужны именно что знания.
Грубо говоря, знания являются информацией, которую можно использовать. Это проявляется не только в особом структурировании, в классифицировании и каталогизировании информации. Это проявляется в первую очередь в заточке собираемой информации под конкретные задачи. Знания, это всегда ответы на вопросы.
Итак, знания представляют собой ответы на вопросы. Тут-то и начинаются сложности. При грамотном подходе комплекс вопросов избыточен, и предметы знаний зачастую являются ответами сразу на многие вопросы. Таким образом, ни одна простая классификация не делает из информации знаний. Нет, конечно же можно создать отдельную классификацию по каждому интересующему вопросу, продублировав элементы нужное число раз, но это несерьёзно. Знания всегда находятся в состоянии уточнения, их нужно постоянно изменять. А изменять копии этих знаний в множестве классификаций, это адский труд.
Нет, дублирования знаний быть не должно, предметы знаний должны иметь возможность сразу входить в множество классификаций. Реляционный подход отпадает, и вместе с ним отпадает и практически весь набор методов работы с данными, который наработан к нашим дням. Технологии работы с нереляционными данными можно сказать что нет. Это прорывная технология, она глубоко изменит наш мир, но этого прорыва до сих пор нет.
Итак, нужна нереляционная база знаний. Я данной проблемой озаботился достаточно давно, с тех времён, когда простое накопительство с анализом у меня сменилось синтезом. Особый затык случился на вопросах организационно-штатной структуры армии. Захотел было попробовать сделать свою оргштатную структуру армии, хобби такое, да. Так вот, жопа. Беспросветная. Всё завязано на всё, прямо-таки гордиев узел. Изменяешь один элемент, и он заставляет изменять многие остальные элементы. Каждое подразделение во многом универсально, оно заточено одновременно сразу на решения множества задач. И изменение баланса мельчайшего элемента меняет баланс всего в целом. Но, конечно же, существуют некоторые рамки, в которых это изменение не несёт особого вреда. Но эти рамки совершенно непрозрачны, и более того, динамичны, что собственно и послужило первой проблемой, которую я попытался решить.
Традиционно нереляционные базы знаний строятся с оглядкой на реляционные. Если в реляционной базе каждый элемент имеет одно отношение, то в нереляционной базе отношений несколько. То есть допускается включение объекта сразу в несколько классификаций, и всё. Взять то же тегирование. Но этого мало, слишком мало. Да и само по себе тегирование глубоко ущербно, поскольку изменение сложившейся структуры является очень трудоёмкой задачей. Явно нужно что-то иное. Причём нужно не просто заложить некую структуру, а ещё и приложить к этой структуре некоторые полезные механизмы. Этой проблемой я и занялся несколько лет назад, в результате чего родился Monster Book. Звучит несколько пафосно, но мне нужно было данный проект как-то назвать, и я не нашёл ничего лучшего, как назвать его по своему нику.
Итак, Monster Book первого поколения.
В результате достаточно продолжительных размышлений я пришёл к следующему:
1. Книга состоит из разделов небольшого размера. Минимального, минимально достаточного размера. В разделе должно описываться лишь то, что относится к данному УРОВНЮ раздела, любые намёки на подструктуру должны описываться отдельной явной структурой, отдельным набором разделов, причём далеко не обязательно располагающейся в текущей классификации.
2. Разделы имеют явную иерархию, которая является уточнением ответов на корневой вопрос. Всё, что вне данного вопроса, должно описываться где-то во вне. То есть если разбираем организацию армии, то ни каких вопросов вооружения, снаряжения, тактики и прочего в данной иерархии рассматриваться не должно. И даже более того. Сам вопрос организационно-штатной структуры должен описываться несколькими отдельными иерархиями знаний. Каждый уровень армейской иерархии необходимо включать в отдельные иерархии знаний, пусть они и будут объединяться под одной крышей. Но, скажем, оргструктуры уровня роты никак нельзя описывать подразделами к какому-либо объекту уровня полка. Уровень роты, это отдельная и самостоятельная иерархия высокого уровня. Таким образом, разбиение должно быть предельно аккуратным, точным и мелким. Да, это достаточно трудоёмко сделать, но зато использовать такое будет куда как проще и понятней.
3. Каждый раздел может входить только в одну иерархию. Вас это наверное сбивает с толку, ведь мы как бы рассматриваем НЕреляционную структуру. Но всё должно быть именно так, нереляционность станет заметна чуть позже. Иерархии нужны здесь по сути дела исключительно для максимально точного разграничения рамок разделов нашей базы знаний. Кто занимался подобными вещами, наверняка помнит мучительное ощущение потребности выбора, типа а куда же это что-то там запихать. Размен шила на мыло, когда вроде бы и то надо, и это. Мучительнейшее ощущение, которое является всего лишь следствием недостаточно ясно и чётко формализованного подхода к классификации. Тут же эта проблема уничтожается на корню.
4. Разделы можно связывать горизонтальными связями, ассоциациями, причём эти связи обязаны быть двунаправленными, прямая ассоциация (используем вот его) должна порождать обратную ассоциацию (меня использует вот он). Эти горизонтальные связи принципиально неформализуемы, и именно в этом и заключается нереляционность. Горизонтальными связями должны описываться все те отношения, все те связи с разделами, которые не являются уточнением на вопрос, по которому строится текущая иерархия. Таким образом, по сути дела из привычной всем анархичной нереляционности мы выделяем скелет иерархий, который позволяет нашей куче данных не превратиться совсем уж в бесполезное дерьмо.
5. Не нужно пытаться объять необъятное, нужно активно пользоваться системным подходом, выделять в описываемом подсистемы. В идеале каждый раздел должен иметь 5-10 подразделов и 5-10 ассоциаций, причём выделяемые из массива ассоциаций подсистемы должны описываться в корректно обозначенных иерархиях.
Monster Book первого поколения. Реализация.
Итак, получилась достаточно несложная технология, которая элементарно реализуется не только на практически любом языке программирования (я использовал Lotus Notes), но даже НА БУМАГЕ. Берём тетрадь, отрезаем от неё узкую "тетрадку" шириной 3-5 см, возможно в двух экземплярах. Если тетрадь большая, то лучше сначала разрезать её напополам. И оформляем:
Широкая часть используется для описания разделов, а узкая сторона, -- ссылок. Каждую страницу нужно пронумеровать; если для ссылок используется несколько тетрадей, то их нумеровать насквозь. Поскольку таких "книг" будет наверняка несколько, то имеет смысл нумеровать и сами "книги". Таким образом, ссылки на страницы будут состоять из двух частей:
(номер страницы) - (номер "книги")
Если ссылка производится внутри "книги", то номер можно опускать.
Первая страница "книги" описывает самый верхний уровень, каталог иерархий. В принципе, для таких примитивных разделов, которые являются лишь набором ссылок, список подразделов можно давать сразу в поле текста, сопровождая их для удобства наименованием подраздела. Но вообще желательно для этого использовать тетрадь ссылок, потому что так будет удобнее пробежаться по всему списку.
При создании подраздела находим чистый лист, делаем на него ссылку в списке подразделов "родителя". Неплохой идеей является одновременное использование сразу ДВУХ тетрадей, с чередованием уровней разделов, т.е. при создании подраздела брать чистый лист не из той же тетради, а из другой тетради, после чего при дальнейшем углублении древа подразделов тетради меняются ролями. Так можно будет при работе видеть сразу и "родителя", и "потомков", что делает работу значительно более понятной. После выделения листа пишем на нём название, текст, и так далее. При потребности создаём разделы ещё более низкого уровня.
Когда нужно указать горизонтальную связь, открываем лист прямых ассоциаций (если его нет, то заводим), где прописываем ссылку на связываемый раздел, И ОДНОВРЕМЕННО для связываемого раздела указываем обратную ссылку в разделе обратных ассоциаций. Наличие списка обратных ассоциаций изрядно облегчает жизнь, потому что этот список хранит по сути дела список всех тех разделов, в которых используется данный раздел. Например, если изменяем какой-то критичный параметр раздела, то можно сразу же оценить, к каким последствиям это приведёт, пролистав оный список обратных ассоциаций.
Если страница заканчивается, то производим перенос, находя чистую страницу и указывая её в поле переноса. В принципе, было бы неплохо сохранять и обратные ссылки, но мне они пока не требовались. Точно также имеет некоторый смысл и в странице ссылок делать обратную ссылку на раздел, к которому относится ссылка; и так же и в прочих подобных местах. Но мне всё это пока не требовалось, я вообще с бумажным вариантом особо не работал, поскольку имею более удобный электронный вариант. Но бумажный вариант вполне работоспособен, и вероятно, кому-то будет полезен. Бумага проигрывает в наглядности, но есть у неё и свои сильные стороны.