Предрассудки (небольшой разбор полетов)

Основа, первопричина часто скрывается от нас. Будь это в силу традиций, утверждений, по  простоте душевной принятых на веру, - причин может быть много, но все-это может в один момент подвести нас.

Вот и с тегами вышла заминка. А все из-за массовости применения тегов. Причем однотипного применения тегов. И мне в этом применении не нравились некоторые детали - иерархия тегов и составные теги.

По поводу иерархии тегов решил почитать что пишут в интернете. Поиск дал не так уж и много релевантных ответов. Наткнувшись на некоторые оговорки о тегах, понял что есть всего три принципа реализации иерархии:

1. У тегов не может быть иерархии по определению.
2. Иерархия тегов может быть:
1. Монородительская (у тега может быть только один родитель).
2. Полиродительская (у тега может быть сколько угодно родителей - встретил всего в одном блоге).

Из всех этих мне понравилась идея полиродительской реализации иерархии. Более того, я это уже пытался реализовать. Кроме того, только так можно было воплотить идею о том, что "объект - это тоже тег", т.е. у "тегов тоже могут быть теги". К тому же полиродительское построение тегов позволяло легко реализовать идею составных тегов: части составного тега - это просто его теги. Но натыкался на некоторые сложности, в частности, на то что нельзя было однозначно указать такую ситуацию:

1. Иванов работает бухгалтером в Рога и копыта.
2. Сидоров работает директором в Рога и копыта.
3. Иванов работает директором в Шарашкиной конторе.

Так как если бы захотели узнать кто работает директором в Рога и копыта, то получили бы как несложно догадаться и Иванова и Сидорова.

После чего было решено записывать связи тегов в виде дерева значений. Что-то вроде вот такого человечка:

Заполнив базу минимальным набором данных пришел к печальным выводам: все это работает очень медленно, легко зацикливается при поиске данных и все это тяжело для понимания.

Было решено отказаться от деревьев. Хотя идея мне была интересна. И опять начались поиски. Лишь теги не претерпевали никаких изменений.

Вечерними муками было решено создать систему, состоящую из трех частей:

1. Теги объектов.
2. Состав сложных тегов.
3. Значения свойств тегов.

И все это держалось на коэффициентах релевантности связей, подкрепленная простой математической моделью.

Реализовав в черновом варианте такую систему, дошел до поиска информации. И... окончательно запутался в подсчете коэффициентов сложных связей. Самые большие трудности возникали со свойствами. Было решено отказаться от них в пользу системных составных тегов.

Нарисовав карту свойств нашел некоторые парадоксы, о которых можно прочитать в предыдущем посте.

Попив чаю, попытался уснуть. Сон не шел. Все думал как решить проблему. Ведь мне хотелось создать универсальную систему, позволяющую немного-немало описать мир, и, что самое главное, легко находить информацию в этом мире. Но решение никак не приходило в голову.

Но утро вечера мудренее :) И с утра я понял, что не то я убрал. Нужно как раз все кроме свойств убрать. В том числе и теги. О Боже, система тегов без тегов! Кто бы мог подумать. А решение - на поверхности. И слышал я о нем еще в 11ом классе на уроках математики когда учитель спросил нас "Что такое четыре?" и нарисовал на доске "4". Все мы было немного озадачены и поэтому молчали. Ведь ответ был слишком очевиден. "Четыре" - это число. Однако, это не так. "Четыре" - это всего лишь обозначение числа.

А может все-таки свойства?

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

У %клиента1 свойство бухгалтер равно %Иванов. Так должен ли %Клиент1 быть в списке "%Иванов"?.

Черт ногу сломит!

Да уж. Идея с унификацией хранения всей информации имеет свои минусы. Как и что можно с этим делать?

где
#1 - Контактные данные Клиента1
#2 - Телефон из Контактных данных Клиента1
#3 - Телефонный код России
#4 - Телефонный код Чебоксар

А теперь вопрос:
Как определить телефонный код города в в теге "+7 8352 20 00 01". А еще лучше получить город из этого телефона.

После болезни приятно побриться

Начались проблемы. То, что так хорошо выглядит на бумаге совсем не хочет реализоваться в коде. Вся моя концепция тегов не то чтобы не работает, но со странным нежеланием не хочет реализовываться. Это упорство настолько велико, что ставит под сомнения основы. А что самое обидное, я не понимаю причину этих трудностей. Отчего так все тяжело реализовывается? Прямо-таки стена, которую надо преодолеть. Связано это с долгой болезнью, или с действительными проблемами в концепции тегов, мне не известно. Но код совершенно не хочет писаться. Вот и долблю головой непонятно откуда появившуюся стену. Причем получается это, мягко говоря, немного неуклюже.

Попробую сформулировать вопросы, быть может они найдут решение во время обеда.
Если A имеет свойство B значение которого равно C, то входит ли С в A и B?
А что если отказаться от свойств и значений, а использовать составные теги? Например, заменить выражение "У %Клиента1 %Бухгалтер = %Иванов" выражением "%Бухгалтеры_клиента1 содержит %Иванов, а %Бухгалтеры_клиента1 входит в %Бухгалтеры и %Клиент1". Это сулит упрощением упрощением хранения информации. Но усложнением её ввода. Эй, где моя бритва Оккама?!

Используя свойства (было):

ЗначенияСвойствОбъектов Объект Свойство Значение Коэффициент А В С 0,75 КоэффициентыВхожденияТегов ПервыйТег ВторойТег Коэффициент А С 0,5 В С 0,5

Используя составные теги (стало):

СоставТегов ПростойТег НомерТега СложныйТег А 1 АВ В 2 АВ КоэффициентыВхожденияТегов ПервыйТег ВторойТег Коэффициент А АВ 0,5 В АВ 0,5 АВ С 0,75

Похоже, что мысль совсем неплохая. Так как составные теги я буду использовать в любом случае остановимся на этом. Вот и сломлена стена. Руки так и чешутся все переделать. В который раз...

Парад слонов

И что будем делать? Наслаждаться моментом! И я..и я не знаю!) Просто откинулся на спинку стула, руки за голову и у меня все хорошо. И все друзья мои, они улыбаются. И все хорошо. И я люблю) И она меня любит!)... И столько было в прошлом! И всему, что в прошлом я говорю "спасибо!". Но самое главное... Самое главное это то, что когда я помахал рукой, она захихикала). Это настоящий парад слонов, с морем красок, воздушных шаров, и морем улыбок.. и я ей помахал, а она захихикала))

Концепция тегов 0.1.120

Ко всему ниже перечисленному добавились составные теги. Вся фишка в прямом указании состава тега. Например тег "Главный бухгалтер" состоит из "Главный" и "Бухгалтер". Это означает, что эти переходы (как от простых к составному, так и наоборот) должны иметь коэффициент связи равный единице, т.е. происходить без потерь. Остается открытым вопрос методов поиска вхождения. Например, как организовать поиск "Клиент1(0,5), Главный Бухгалтер (0,5)", если предположить что некий объект имеет теги "Клиент1", "Гланый" и "Бухгалтер". Что меня занимает - способ модификации коэффициентов. Но на данный момент я болею, к слову, уже вторую неделю:(, и голове не хватает ясности.

Концепция тегов (вер 0.0.110) [ищу помощь]

Не придумав как обозначить коэффициентом связь родителя от подчиненного, решил разделить их. Есть только связь подчинения. Но зато при поиске можно выбирать тип поиска: в глубину или к вершине. Также не удалось придумать нормальное отделение установки подчинения от установки свойства с помощью коэффициентов. Решил разделить задание тегов (подчинения) от задания значений свойств. Теперь это два различных документа, и двигают они различные регистры. Также в динамических группах появился специализированный поиск следующих типов: 1) поиск значений по свойствам объектов (указываем объект и свойство, получаем - значение), 2) поиск свойств по их значениям у объектов (задаем значение и объект, получаем - свойство) и 3) поиск объектов по значениям их свойств (соответственно, задаем значение и свойство, получаем - объект).

Ах да, чуть не забыл. Документ установки свойств не только делает движения по соответствующему регистру, но и создает подчинения типа “объект - значение”, “свойство-значение”. Необходимость задания подчинения “объект - свойство” поставлена под сомнение :).

PS: У меня нет того, кто интересуется тегами. А я бы не отказался от дискуссии. Вплоть до того, стоит ли вообще это делать. Напомню, я пытаюсь создать органайзер с продвинутыми тегами, который будет хранить в себе всю информацию, и контактные данные, и списки рассылки, и дочерние фирмы, и список сотрудников... ровно как и двоичные данные. Основное отличие - у органайзера описание метаданных сведено к минимуму. Вся структура данных создается с помощью указания тегов. К тому же активно применяются сложные (составные) теги. Кто заинтересовался, могу подробно написать как считается релевантность результатов, и как она задается, да и вообще, отвечу на любые вопросы. Так как одному это очень долго делать :(