Концепция тегов (вер 0.0.105)

Есть теги, есть группы, есть динамические списки. Теги – это просто теги. Сложнее с группами. Если между тегами есть связь, то они объединяются в группы. Например, “А” имеет свойство “Б”, значение которого равно “С”. Как таковой группы нам мало. Нам нужно знать еще и отношения между элементами. Ведь одно дело группа “Иванов - Бухгалтер”, другое – “Старший бухгалтер - Бухгалтер”. В первом случае, тег “Бухгалтер” содержит “Иванова”. Во втором же, мало того, что “Бухгалтер” содержит “Старшего бухгалтера”, так еще это практически одно и то же. Вот так возникла идея коэффициентов связи. И понятие релевантности.
Понятие релевантности очень помогло при создании динамических списков. Например, у нас есть связи "А-(0,5)-Б", "Б-(0,5)-В", "В-(0,5)-Д". И мы делаем запрос А(0.2), что значит "найти". Он будет содержать сам тег А, тег Б (релевантность = 0,5) и В (релевантность = 0,5*0,5 = 0,25), а вот Д - уже в наш список не входит. Пока все легко.
Открытыми остаются следующие вопросы:

1. Как записывать коэффициенты в группах типа "Объект - Свойство - Значение"?
   На данный момент это реализовано попарным указанием коэффициентов. Что-то вроде этого (коэффициенты расставлены условно):
   Объект (0,5) Свойство
   Объект (0,5) Значение
   Свойство (0,2) Объект
   Свойство (0,5) Значение
   Значение (0,3) Свойство
   Значение (0,2) Объект
2. Ну и как же считать эти коэффициенты?
   

Концепция тегов (вер 0.0.100)

Вчера перед сном в голову пришла на удивление неплохая мысль (обычно, чем ближе к ночи, тем глупее и сложнее мысли): отказаться от деревьев в пользу указания в ручном порядке связей тегов, ровно как и типов этих связей. Например:
“Бухгалтер Клиента1” входит в “Клиент1” и в “Бухгалтеры” и содержит “Иванов А.А.”. Очень просто!

Но это мне бы не позволило столь сильно поднять номер версии. У меня появились динамические теги! Динамические теги содержат строки вида “Что искать, где искать”. Например:
Что искать = “Физические лица”, Где искать = “Бухгалтер”. Это даст всех людей (физических лиц), которые работают бухгалтерами. А
Что искать = “Физические лица”, Где искать = “Клиенты” выдаст нам список всех сотрудников у всех клиентов!

Это позволит создавать задачи с тегами вида “Все директора”. И при выводе списка задач для директора N-ной конторы в списке будет сиять наша задача с динамическим тегом! Фиуви!

Концепция тегов (вер 0.0.014)

Начну с рассмотрения развития идеи. Начиная свой “проект” я был просто-таки уверен, что это движок займет у меня месяц-два. А как бы не так! Просто все начиналось довольно банально – нужна была иерархия тегов. Но “реализовав” ее (до конечной реализации дело не дошло: создал обработку, которая могла выводить это самое дерево), мне она показалась недостаточной. Так как я решил что у меня будет “полноценный” органайзер. Под полноценным я понимаю, что тегом может являться все что угодно – любой объект базы, причем объект в расширенном смысле.

Вскоре стало ясно, что нужны свойства объектов. Точнее, свойства тегов. Около месяца ушло на осознание этих свойств. После чего пришлось нехотя признать что нужны деревья значений. Около двух недель ушло на написание основных процедур и функций по работе с деревьями. Как-то само собой стало понятно что свойства могут быть сложные. И что свойства так же связаны между собой. Например, “Главный бухгалтер” входит в более общую группу “Бухгалтер”. Проблемы возникли с определение работы и хранением свойств типа “Контактные данные – Физический адрес”. Но эти вопросы остались чисто теоретическими, хотя были более-менее реализованы.

Через несколько месяцев у меня было нечто близкое, как мне казалось, к финальной версии. У меня были за плечами процедуры перестановок элементов дерева не теряя родителей, процедуры нахождения объектов, процедуры нахождения вхождения одних подстрок в другие. Были и отвлекающие факторы: BattleField2, COD4 и NFSU2 по интернету. Но в итоге у меня по запросу “Клиенты:Должности” выводились сотрудники клиентов с занимаемыми ими должностями. Но при наличии небольшого числа связей все это работало ужасно долго и требовало ручного управления поиском данных. Иначе оно могло уйти в дебри и искать очень, очень сложные структуры.

Не давеча как три дня назад меня в очередной раз осенило “объектами”. Под рукой не было компьютера и все это варилось до вчерашнего дня только в голове. А сегодня начало приобретать четкие границы. Допустим все слова – теги. Создаем связь “Клиент – (Контактные данные) (Адрес физический) – %Адрес%”. Здесь %Адрес% – это нечто что имеет собственные свойства, такие как: город, улица, номер дома и проч. При записи такой связи происходит поиск объектов: “Клиент”, “(Контактные данные) (Адрес физический)” и “%Адрес%”. Если таких объектов еще нет, то они создаются. Отдельный разговор про сложный объект “(Контактные данные) (Адрес физический)”. В связи можно указать, что он аналогичен, например, “(Данные контактные) (Адрес физический)”. При создании этого объекта ищутся объекты в него входящие: “Данные контактные” и “Адрес физический”. Если нашли – то представляем наш сложный объект как совокупность двух. Одновременно записывается, сложный объект входит в состав двух более простых (как уточнение). Таким образом при запросе “Клиент” – “Адрес” алгоритм поиска такой:

Клиент - Адрес	пусто (нет таких данных)
Клиент – Адрес Физический	пусто (так как “Адрес физический” входит в “Адрес”)
Клиент – (Контактные данные)(Адрес физический)	%Адрес% (Ага! так как есть такой объект)
%Адрес% (заменяем найденное свойство объект значением)	Поиск дальше не идет. Так как это и есть объект.

На данный момент проблема в том, что у меня поиск идет дальше и создает строки:
Клиент – (Клиент – (Контактные данные)(Адрес физический)),
Клиент – ((Контактные данные)(Адрес физический))(Адрес физический),
А из первой строки он может создать строку
(Клиент – (Контактные данные)(Адрес физический)) – Адрес.
А является ли это бредом еще стоит обдумать.