Short link service (деревья из коротких гиперссылок)

---
Short link service (деревья из коротких гиперссылок)
Существует немало сервисов, генерирующих короткие
гиперссылки. Но это – вчерашний день. Сегодня востребован
сервис построения из таких ссылок иерархического или
сетевого дерева, охватывающего определённую сферу
деятельности в Интернете (для соответствующего пользователя
или организации). При таком подходе важна не краткость
ссылки, а её человеческий смысл, представленный именем этой
ссылки и её связью с другими узлами сетевой структуры.
Предоставляя короткую гиперссылку на определённый узел
дерева, этот сервис тем самым даёт возможность не только
перехода от этого узла на соответствующий Интернет-ресурс,
но и возможность отследить по этому дереву все другие
ресурсы, увязанные в сетевую иерархию (представленную
деревом).
Ссылка через дерево называется множественной.
Взаимосвязь ресурсов, представленная деревом гиперссылок,
определяется составителем этого дерева, но она может быть
включена в совершенно другие деревья, составленные другими
пользователями. То есть, гиперссылку можно давать не только
на обычный Интернет-ресурс, но и на уже существующие
деревья (которые со временем могут изменяться без Вашего
участия). Это – перспективный способ командной работы.
Суть идеи «глобального форума» заключается в следующем:
1.
Система оценок, которая снижает информационный шум на несколько порядков (
~ в десятки тысяч раз). Новая система будет работать по принципу приоритетной
(рейтинговой) сортировки: малополезные сообщения «теряются в
бесконечности», то есть, просто не доходят до потенциального потребителя (если
для него есть более востребованная, свежая и желанная информация).
По этой технологии даже огромный и старый форум, обросший сообщениями как
корабль ракушками, вдруг предстанет маленьким и по-детски прозрачным,
причём, молодеющим день ото дня (так как отношения приоритета переносят
центр общения с производства информации на постепенное повышение её
качества).
Одновременно решатся и спорные вопросы, в том смысле, что спорить придётся
по справедливым и эффективным Правилам... Сюда же можно отнести
всевозможные опросы, голосования.
Модель идеального форума. Общие правила оценки.
Модель форума с сортировкой сообщений по приоритету очередного ответа вносит
определённые коррективы в само понимание интернет-форума. Вот они:
1. Сообщения разных форумов можно группировать, создавая или изменяя
уровни обсуждений. Любую сколь угодно сложную систему взаимосвязей
между файлами или постами всегда можно наглядно представить в виде
сетевого дерева. На основе введённых взаимосвязей между гиперссылками
рисовать (автоматически создавать) такие «деревья» будут специальные
серверы, обеспечивая навигацию в море информационных связей, показывая в
первую очередь самые важные уровни и лучших специалистов. Появятся
глобальные системы структурирования и оценки знаний. Последствия
предвидеть сложно. Но осторожно попробовать стоит.
2. По этой модели вместо понятия «тема» в форуме будут использоваться
«уровни обсуждений». Уровень обсждений образуют только те сообщения
глобального форума, которые являются ответом на одно определённое
сообщение.
3. Для каждого сообщения может быть несколько уровней обсуждения: группы
ответов на определённый пост – это и есть разные уровни. Это могут быть
несколько различных тем, ничего общего между собой не имеющих (кроме
единого родительского объекта-сообщения).
4. Участники обсуждения могут перечислять приоритет только на данном уровне
обсуждения. На этом уровне всегда есть ключевое сообщение – которое имеет
самый большой приоритет и, обычно, собирает в себя всё ценное, что
появилось на данном уровне.
5. Основной вид сортировки сообщений – по приоритету (отдельно для каждого
уровня).
6. Первоначально КС формируется при создании уровня обсуждений: автор
первого и пока единственного сообщения на этом уровне получает права
члена Координационного Совета с нулевым приоритетом. В дальнейшем он
может начислить приоритет кому либо из участников данного уровня (хоть
самому себе), либо разрешить такое начисление со стороны других
участников.
7. КС, как и любой пользователь или коллективный профиль, может создавать на
своём уровне любое количество сообщений. Но приоритет каждого из них
будет нулевым, если именно на это сообщение не было ни одного
перечисления.
8. Приоритет каждого сообщения – это «след» от приоритета, перечисленного его
автору. Приоритет сообщения не уменьшается со временем, но может
увеличиваться (при каждом новом перечислении на это сообщение); если
перечисление отрицательное, то приоритет сообщения при этом уменьшится.
Приоритет каждого пользователя в теме всегда меньше либо равен приоритету,
когда-либо начисленному на все его сообщения в этой теме.
9. Форум с приоритетом создаёт условия для коллективного творчества. Ведь на
каждом уровне в создании ключевого сообщения фактически участвуют все
пользователи данной темы (даже если у этого сообщения только один автор):
лучшая информация собирается воедино. Возможно и коллективное авторство,
когда автор – это не отдельный человек, а зарегистрированное сообщество
пользователей. Членство в сообществе может динамически изменяться, но к
авторству постов от него это не имеет отношения.
10. Одним из участников в любой теме является КС. КС имеет право перечислять
приоритет на один уровень выше или ниже ключевого сообщения.
Получателем может быть только КС соответствующего уровня. Образно
можно сказать, что пользователи имеют право перечислять приоритет по
горизонтали, а КС – по горизонтали и по вертикали.
11. Приоритет Координационного Совета складывается из приоритета всех
фондов соответствующего уровня. Эти фонды, как и денежные, могут быть
трёх типов:
* персональный
* общий
* совместный
Приоритет как и деньги можно начислять авансом, за будущую, ещё не
созданную информацию. Но есть несколько потенциальных ограничений для
таких транзакций .
 Нужно разрешение КС
 Не погашенная транзакция считается не завершённой, и её можно отменить
12. Устанавливать связи между любыми двумя сообщениями может любой
пользователь, у которого есть соответствующие права. Информационная связь
возможна, если есть разрешение с обоих её концов.
Чтобы программным способом рисовать иерархические и
сетевые структуры, достаточно задать отношение между двумя
множествами объектов.
Эту взаимосвязь можно представить как таблицу, связывающую
идентификаторы объектов отношением многие-ко-многим
yEd-диаграмма
Одна и та же таблица «Объект» служит источником для полей
родительского и подчинённого информационных объектов, а
также, может указывать причину каждой взаимосвязи (то есть,
она сможет, как информационный объект, представлять связь
между двумя другими объектами, любой из которых в этой
связке не обязательно должен быть задан в явном виде, то есть,
допустимы значения Null).
Преимущества таких деревьев по сравнению с yEd-диаграммами следующие:
 Возможность частично разворачивать только нужные ветки (при программном доступе к
определённому узлу),


Удобство работы с длинными именами объектов, и с безразмерными комментариями (это
не одно и то же). В комментарий можно записать несколько файловых ссылок (вместе с
комментарием для каждой из них), и все указанные файлы сразу или последовательно
будут открыты одним нажатием кнопки.
Непосредственная завязка на СУРБД. Это позволяет гибко работать с данными
стандартными средствами СУРБД (которые роскошны!), и, при необходимости, добавлять
собственные программные обработчики.
Так почему же «сетевые деревья» до сих пор не получили широкого распространения? Потому что
даже умения их строить ещё недостаточно для нормальной работы с ними! Именно завязка на
СУРБД плюс специальный интерфейс (о котором речь впереди) делает работу с запутанными
данными лёгкой и комфортной.
Александр Ильин
http://forum.oberoncore.ru/viewtopic.php?p=79861#p79861
Что за цифры, что за значки? Что означают галочки в дереве?
Что значит "| не полные" и чем отличается от просто "|" и от "не
полные"? Что такое "&" и "о"? Что значит "[Объект2] не
задан"? Есть ли какой-то внятный пример организации
реальных данных - например, списка литературы?
-Что за цифры?
Цифры – это имена информационных объектов. Имена можно задавать буквами. Цифрами
задал для простоты, и чтобы, для понятности, было однозначное соответствие между
двумя атрибутами каждого объекта:

Имя

ID (идентификатор)
Проще говоря, на рисунке вместо текстовых имён присутствуют цифры, потому что
[ID] = [Имя]
(в реальных базах это равенство вовсе не обязательно, смотрите
следующий рисунок или по ссылке: принцип заполнения TreeView)
Именно по идентификаторам устанавливается связь, как показано в
табличке “_t_TreeView”.
Вот, древний скриншот моего органайзера
По этому рисунку уже почти невозможно установить соответствие между
идентификатором и именем узлов TreeView. Эта связь задана в таблице Объект, которая
здесь не изображена, а показаны только два из трёх столбцов таблицы Протокол.
-что за значки? Что такое "&" и "о"?
Я не уверен, что знакомство с сетевой структурой нужно начитать со сложнейшего
алгоритма построения «сетевых деревьев». Но раз поступил вопрос по этой теме, отвечу
на него, предупреждая, что таких вопросов здесь должно быть десятка два (они появятся
позже).
"|", "| не полные", "не полные", "&" и "о" – это псевдоузлы. К ним прикрепляются
начальные узлы цепочек. А также, к псевдоузлу может быть прикреплён другой
псевдоузел. Я ввёл стандарт «скелета» сетевого дерева – единообразную структуру его
псевдоузлов. Как два года назад сделал, так и пользую.
В таком скелете главные псевдоузлы растут из корня дерева, и возможно прикрепление
любого числа дополнительных корневых узлов, к каждому из которых в свою очередь
прикрепляются такие же псевдоузлы. Из дополнительных корневых узлов на рисунке
развёрнут узел "html.mdb"
Связи можно задавать даже между отсутствующими объектами (которые будут внесены
позже, и это не является ошибкой оператора базы данных). Наличие пустых объектов и
длина цепочки определяют принадлежность этой цепочки к определённой группе. То есть,
всевозможные цепочки, делятся на группы. Каждая из этих групп растёт из своего
"значка".
"&" - цепочки из нескольких объектов
"о" - циклические (замкнутые)
"|" - одиночные звенья (почти)). Алгоритм построения рекурсивный, поэтому, в процессе
построения, может оказаться, что одиночные звенья срослись с длинными цепочками.
Алгоритм сначала ищет все одиночные цепочки, и приклеивает их к псевдоузлу "|". А если
потом оказывается, что из начала какой-то из этих цепочек растёт ещё и длинная цепочка,
то и она, фактически, начинается от "|".
Эти группы (кроме циклических) могут начинаться неполными звеньями (у которых не
задан Объект1).
Для лучшего понимания принципа группировки, мысленно попробуйте по
табличке “_t_TreeView” построить несколько цепочек. Должно получиться примерно так:
Чем отличается "| не полные" и от "не полные"?
«Не полными» могут быть как одиночные, так и множественные цепочки.
Что означают галочки в дереве?
Ничего не означают. Отмечая узлы галочками можно акцентировать на них внимание.
Отмеченные узлы можно скопом как-нибудь обработать программно. Например,
распечатать список имён соответствующих объектов. Или просто выделить отмеченные
узлы «маркером» (то есть, раскрасить).
Есть ли какой-то внятный пример организации реальных данных - например, списка
литературы?
Есть. Я ж говорю, что пользуюсь.
Александр Ильин
http://forum.oberoncore.ru/viewtopic.php?p=79861#p79861
Ну, а теперь, немного разобравшись, вопросы к автору.
1. Что означает суффикс "-" в именах элементов - например,
"16-"? Чем "16-" отличается от "+16"?
2. Что означает "(-)", см. элемент "20"?
3. Что означает "(=)"? Если это петля связи элемента с самим
собой, то почему пустой элемент в двух случаях имеет такое
обозначение, а в ещё двух - не имеет?
4. Играет ли особую роль пустой элемент, и если да, то какую?
Чем связь с пустым элементом отличается от отсутствия связи?
Если пустой элемент имеет особую роль, зачем выводятся
сообщения "[Объект2] не задан"?
5. Элементы "22" и "20" у вас находятся в ветке "& - |". Почему
элемент "13" находится уровнем выше, в ветке "&"? Ведь
структурно элемент "13" идентичен элементу "22".
1. Что означает суффикс "-" в именах элементов - например, "16-"?
Означает, что листья этого объекта сростаются, но не имеют исходящих связей.
По смыслу описания входящих связей, символ "-" имеет смысл приставки, хоть и
расположен после имени узла. Такое расположение выбрано для наглядности.
2. Что означает "(-)", см. элемент "20"?
3. Что означает "(=)"? Если это петля связи элемента с самим собой, то почему пустой
элемент в двух случаях имеет такое обозначение, а в ещё двух - не имеет?
Создавая построитель TreeView, я для эксперимента оставил в одном флаконе сразу три
варианта обозначений пустых (не заданных) объектов, да так и не определился
окончательно. Все лишние пояснения для пустых узлов можно легко удалить.
(-) означает, что соответствующий объект имеет связь по крайней мере с одним пустым.
Назначение длинного пояснения «(=) . . . [Объект2] не задан» – очевидно.
4. Играет ли особую роль пустой элемент, и если да, то какую? Чем связь с пустым
элементом отличается от отсутствия связи? Если пустой элемент имеет особую роль,
зачем выводятся сообщения "[Объект2] не задан"?
Да, играет. Я создал возможность использования пустых объектов, которые оператор или
разработчик могут применить по своему усмотрению. Например, таким
способом явно указывая, что такой объект существует, но в настоящий
момент не известен.
Следующий фрагмент Вашей схемки
(http://forum.oberoncore.ru/download/file.php?id=4076&mode=view ) – ерунда и
дилетантство в вопросах строительства баз данных.
Чтобы красиво ответить на Ваш вопрос о пустых элементах, попробую рассказать о
принципах записи информации в универсальной структуре таблиц. В каждой связующей
записи таблицы Протокол присутствуют три поля: [родитель], [подчинённый], [причина
их связи]. Пустое значение любого из этих полей говорит о многом… Во многих
конкретных случаях при помощи всего трёх этих полей приходится записывать весь
спектр информации, и применение пустых полей оказывается незаменимым
Вот, наглядный но мрачноватый пример использования пустого значения в
дополнительлном атрибуте [D/t-]: если объект – человек, то этот атрибут означает дату
смерти. Если атрибут пустой, значит, человек пока жив.
Аналогично, если атрибут [D/t+] пустой, то человек ещё даже не родился.
Сейчас в своей практике пустыми объектами пользуюсь только для обозначения важных
или приватных веток в органайзере: начинаю эти ветки с пустых элементов.
Но уже вижу, что именно применение пустых элементов позволит создавать
компьютерные системы искусственного интеллекта, и, в частности, систему унификации
программного кода:
Поговорим о фантастике
Программирование станет похожим на работу HiAsm-конструктора: мне кажется, что
элементы можно создавать и классифицировать по уровням вложенности. Знать сотни
элементов в современном редакторе – это неправильно. Со временем появится
возможность, создавая схему, видеть в ней уже существующие, но не применённые
стандартные элементы (которыми, после их настройки, можно будет заменить части уже
созданной программы).
Общеизвестно, что одну и ту же программу можно написать бесчисленным множеством
способов. Стандартизация программного кода подразумевает замену всего этого
множества одним-единственным, стандартным, вариантом.
Прикинь, творчески создаёшь свой велосипед, и тут же видишь, как его части
превращаются, превращаются … в уже готовые серийные блоки! Не программирование, а
песня!
Это похоже на процесс взвешивания: любой вес можно набрать, используя набор больших
и маленьких стандартных гирек.
Уникальное программирование «с нуля» будет восприниматься с отвращением, потому
что трудно специфицировать и понимать такой «эксклюзивный» код (что сегодня
наблюдаем повсеместно)).
Главная сложность будет не в написании программы, а в понимании, что же тебе
действительно нужно?? И появится возможность даже эту малоинтересную работу
доверить компьютеру… Компьютер будет «думать», помогая выявить информационные
связи в уже имеющихся массивах...
Закончив работу, отправляешь в Интернет запрос, и тут же видишь похожие программы,
идентифицированные по применению тех же стандартных мультиэлементов. Таким
способом можно искать программы-аналоги! Хоть, внешне эта программа может быть
предназначена для решения совсем другого класса задач.
Такие междисциплинарные, неожиданные связи, как правило, являются источником
новых открытий.
чтобы не было путаницы, недостающие узлы перед каждым парным соединением
(согласно таблице) перетаскивал из исходной матрицы в результирующую (, и тут же
соединял).
Аналог построенного TreeView.graphml
5. Элементы "22" и "20" у вас находятся в ветке "& - |". Почему элемент "13" находится
уровнем выше, в ветке "&"? Ведь структурно элемент "13" идентичен элементу "22"?
Потому что цепочки (20) и (22) короткие
(см. выше)
Необходимость такого разделения на группы поймёте, если сможете реализовать свой
алгоритм построения таких деревьев… После завершения сетевой сортировки можно
объединить группы. Но зачем??
--
2.
Сетевой принцип сортировки сообщений.
Не только сообщения, а вообще, любые объекты можно связывать при помощи такого
интерфейса.
Илья Ермаков
http://forum.oberoncore.ru/viewtopic.php?p=79870&sid=d08a0537a1b78692d250f5f8c4
1e27ca#p79870
Правильно ли я понимаю, "сетевые деревья" - это когда:
- в обычной файловой системе я имею, допустим,
/математическое моделирование - /статьи, /книги (и постоянно
мучаюсь между дилеммой - то ли так, то ли делать наоборот
статьи/темы, книги/темы)
- а Вы докопались до идеи, чтобы можно было пойти через
"статьи" к "математическому моделированию", а можно через "математическое моделирование" к "статьи" - и
получить одно и то же множество искомых объектов,
удовлетворяющих обоим элементам пути?
По просьбе Ильи Евгеньевича я проиллюстрировал эту технологию на следующем
рисунке. Люди, имеющие отношение к работе с внутренностями баз данных (и не только
…), увидят в нём великое будущее.
Из рисунка видно, что, если вместе с понятными названиями сетевых узлов использовать
гиперссылки, то таким способом каждый пользователь сможет формировать своё дерево
обсуждений, группируя информацию из Интернета, и дополняя её локальными ссылками
(например, ссылками на фрагменты того же локального документа, в котором находится
это дерево).
Простой пример: пошив «виртуальных тем» из готовых сообщений форума. Можно не
только перегруппировывать сообщения относительно времени их появления (а
некоторые вообще не включать), но и вставлять посты из других веток.
Хороший пример, как это будет работать:
(там дерево одно, достраивается по запросу браузера, и оно пока не «сетевое»)
Web-каталог
http://www.hiasm.com/wiki.html
(ветки подгружаются по мере необходимости)
Иметь такую возможность не значит обязательно пользоваться ей буквально, то есть, не
требуется рулить деревом самолично. Вместо этого можно выбрать подходящее чужое
дерево, и пользоваться только им, или включить его части в своё.
Сеть она и есть сеть – невообразимо сложное переплетение связей (если она большая). Каждую
связь можно установить между парой объектов.
Оказалось, что любую сеть можно представить в виде дерева (точнее, в виде «леса»))
В таком дереве даже теоретически не может быть ни одного пересечения связующих линий.
В «сетевом» TreeView используются два типа соединителей:
 линии,
 префиксы-суффиксы (соединительные значки, в комбинации с ID объекта).
Рассматривать текстовые соединители можно непосредственно (если дерево простое) или при
помощи современных технологий баз данных (этими методами даже в огромных деревьях
несложно выделить и подробно рассмотреть любую группу комплиментарных текстовых
соединителей).
Назначение преффиксов и суффиксов в именах узлов можно уяснить из рисунка:
суффикс ("-","+") вместе с именем узла идентифицирует лист-соединитель. См.
рисунок:
"+" - соединение внутрь единственной ветки, имеющей продолжение
"-" - срастание веток в соответствующем листе
На этом рисунке сетевые деревья используются для отображения одного и того же
алгоритма (представленного в виде примитива и силуэта).
А ещё сетевые деревья можно использовать как органайзер задач и файлов.
--
Алгоритм представления Универсальной структуры (базы)
данных в виде сетевого дерева
Владислав Жаринов
http://forum.oberoncore.ru/viewtopic.php?p=79861#p79861
Судя по сказанному, Вы предлагаете, в частности, реализовать
что-то вроде "редактор контента", допускающий "повторное
использование" единиц содержания, формируемых или
выделяемых пользователями (например, аналитиком в роли
админа БД)?.. Ну и ещё с возможностью автоматизированной
(автоматической?) оценки качества единиц (и, если выделять их
строго по пользователям - то через это и их вклада)?.. И,
возможно, расширить его затем функциями "редактирования
технологий работы с контентом"?..
Насчёт того, что любой многосвязный граф можно
представить "лесом" - при прорисовке схем вроде этих
возникала мысль, а не возможно ли это?.. оно бы весьма
упростило и анализ, и синтез структур... Но это дело
математиков... Вы сами доказали это или знакомы с чьими-то
результатами?.. если можно, укажите источники какие-то?..
Если б это было возможно, оно бы давно было доказано.
К сожалению, чудеса – только в сказке (или, может быть, где-то в других измерениях).
Первый раз об этом же спросил Илья Ермаков. Соединители объектов делю на две
группы: основная группа – это соединители, которые не мешают изображению связей в
виде дерева. Остальные – вторую группу – "изображаю" ссылками.
Мой алгоритм действует топорно:
1) Оптимизированным перебором ищет начала цепочек.
2) Рекурсивно ищет последующие звенья. Если какой-либо объект-звено уже
встречался в другой цепочке (на предыдущих уровнях рекурсии), то эта, и все
последующие цепочки оборвутся на этом объекте, а в той единственной цепочке,
где присутствует его продолжение – на нём ставится "крестик" (если аналогичный
крестик-префикс не был поставлен раньше).
По этому алгоритму получается, что каждый объект присутствует в таком дереве не
более одного раза (листья+суффиксы – не в счёт – они есть ссылки-указатели).
3) Когда найдены концы всех этих цепочек (то есть, найдены все цепочки, имеющие
начало), остаётся проверить, остались ли ещё в исходном массиве не найденные
объекты? Такое возможно, если в исходной структуре взаимосвязей присутствуют
цепочки, начала не имеющие (конец у них может при этом быть):
Это единственная часть алгоритма, где присутствует приличная логика.
Вспоминать тонкости сейчас лень. Но строго доказал, что к уже построенному
"лесу" будут добавлены все эти замкнутые и частично замкнутые цепочки.
Вот и всё доказательство.
-Сетевая сортировка действительно помогает думать. Анализ и синтез от неё явно
выигрывают:
1. Ненужные ветки частично сворачиваются (хоть до корня), и не мозолят глаза.
Обычно, если человек находит какую-то взаимосвязь, то он на этом успокаивается.
В другой раз для этого же объекта он находит другую взаимосвязь (уже напрочь забыв о
прежних результатах), и, ничего не подозревая, опять фиксирует в базе свою находку.
Алгоритм построителя однозначно объединит оба этих "открытия", причём он умничает
даже когда не следует…
Обратите внимание, повторы узлов всегда исключаются самим алгоритмом построения TreeView
(повторы в «листьях» не в счёт, ведь совместно с суффиксом каждый такой лист является не
объектом, а указателем). [Если лист дерева_дополнен значком]+, то он подобен «→»,
указывающей, где в действительности расположен этот узел.
Каждый узел-объект в любом сетевом дереве всегда присутствует в единственном экземпляре. Но
можно встретить одноимённые узлы, у которых различны ID.