Структура данных не нарушается.

Меняются связи между объектами, не затрагивая свойств объекта. 

Может быть я чего-то не знаю, что знаешь ты, но исходя из того что я знаю следует что у объекта могут быть свойства, наследованные от цепочки родителей, что происходит если изменить цепочку родителей (да и собственно любого из родителей)? - изменение свойств объекта. Собственные свойства не изменяются, конечно.

CandleMan, я наверное не врубаюсь в твою идею, может ты поподробнее расскажешь? 

Если создавать объекты знания такие же, как объекты программирования, то Ваша точка зрения была бы верна, но абсолютно не приемлема в динамических системах. 

В моем случае, объект знания – это запись в таблице. А свойство данного объекта – это тоже записи. Между ними организуется связи и таким образом осуществляется формирование субъекта знания. В этом случае всегда одну связь между двумя записями можно поменять на другую связь. Поэтому система получается очень гибкой.

А тэги, о которых велась речь выше, это некие объекты-ссылки, с помощью которых расставляются эти связи.

Обратите внимание: Такая база существует реально. Она достаточно легко управляется и данными в ней очень легко манипулировать. 

Я предлагаю создать интерфейс к ней. Поскольку считаю, что самая большая проблема и задача – это организовать легкий, понятный, удобный способ формирования этой базы.

Что должно входить в понятие легкий и удобный способ формирования:
Например:
Мы находимся в IE. Нас заинтересовала статья или новость. Нажатие правой клавиши мыши вызывает контекстное меню, в котором первым шагом размещаем заинтересовавшую нас статью в нашей базе, а вторым привязываем интересующий нас объект-статью к какому-то другому объекту-знанию.
Это первое приближение. Второе:
Нам не нужна полная статья – просто факт. Но факт – это слова. Процедура примерно такая же, только мы работаем с набором слов.
 
 

Здравствуйте!
жаль позно нашел эту тему - ЖИЗНЕННО мне Интересную!
Потребность похожая.. чем-то..

попробую рассказать - и  Извините за сбивчивость и сумятицу в мЫшлях!!   

с 97 года делаю проект  Прогулки по России
это тысячи фотографий собранные в "прогулки" - т.е. имеет значение порядок их следования.
к снимку приписываются дополнительные виды и переход на другую "прогулку" на их пересечении (на пересадочных станциях метро это видно(  станция Таганская
в работаюшая версия построенна на списках в текстовых файлах

в 2002 году написал новый "движок"  проекта.  ( на его основе делался и этот проект барк "Летучий" )

в новом "движке" сделано такое разделени:
 - программы, 
 - оформление разбитое на отельные блоки из которых собирается (по указанным в запросе и "вычисленым" данным) показываемая страница белая  синяя ehglish, 
 - правила выборки данных из базы (MySQL) с возможностью вложенных запросов.

НО! - разрабатывая новую структуру проекта для увеличения  возможностей "Прогулок" понял, что для управления им нужна "клиентская" часть с удобным, комфортным интерфейсом и следующими возможностями
 - создание и ведение локальной базы данных (бд) 
 - внесение в бд новых информационных материалов (изображения, тексты, файлы мультимедиа)
 - ведение каталога информационных материалов
 - создание и изменение шаблонов оформления
 - перенос созданной структуры и новых изображений на web-сервер

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

Пользователь может создавать на базе идущих в комплекте с программой вариантах  оформлений свои варианты для представления своих коллекций материалов на интернет сервере, в виде CD-презентаций или для распечатки.


вот.. вкратце..

почему я решил здесь написать - показалось, что в наших потремностях есть нечто общее - а именно требуемая 
и Вам и мне система Администрирования со схожими вожможностями!

Моих знаний хватает только для понимания того, что создать подобный продукт я сам не смогу! 
заказать его изготовления я не могу по денежной причине (их может хватить только на небольшие поощерения)


 

Leshak:

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

Спасибо Вам. Вы продемонстрировали конкретный пример, где можно было бы ее использовать.

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

 

Или найти средства для оплаты его труда!
постепенно могу набрать около 1000уе...
 
может пора обудить тех.задание на систему управления? 

Это сообщение отредактировал(а) Leshak - 21.6.2006, 16:40

Честно говоря, я затрудняюсь написать грамотное тех.задание.

Могу предложить пока только описание проекта (смотрите прикрепленный файл):

Кстати, работа уже началась. 
Пока сейчас  на первом пункте - разработка дизайна страницы.

 

Присоединённый файл ( Кол-во скачиваний: 22 )
 Description_DBMS_Logos.doc 37,00 Kb

ммммм... мне видится все несколько иначе...
предлагаю следующий порядок работы:
0 - выбор языка для создания клиента
1 - разработка клиента изначально нацеленного на дальнейшее развитие
2 - функциональная отработка клиента начинается с менеджера баз данных (в качестве некоторого праобраза предлагаю MySQL-Front Manager )
2.1 -  отдельный список (лист) базовах запросов по созданию, администрированию, управлению БД с тем, чтобы его можно было легко редактировать, пополнять или подключать другие списки с запросами для других БД  SQL, mSQL, MySQL и т.п.
2.2 - отдельный список (лист) прикладных запросов для работы с конкретной БД или для решения текущих задач
2.3 - список основных функций - определяет структуру меню клиента и функциональное наполнение каждого пункта меню /плохо представляю как это может быть реализованно под Windows, средствами perl, php - это решаемо/
2.4 - библиотека средств визуализации извлекаемой из БД информации

вот так как-то.. 

предлагаю Visual C++


Зачем? На сервере уже существует менеджер базы данных. Другой не нужен.

В клиенте, Главное - интерфейс для пользователя.

Его функциональность - прочитать данные с сервера, отобразить в понятном для пользователя виде, сохранить сделанные изменения
и передать изменения обратно на сервер.


Поясните, пожалуйста.


Библиотеку средств также не надо разрабатывать, она содержится в библиотеке языка создания клиента 

смотря в каком виде и для чего он не нужен? 
по моим предположениям он является ОСНОВОЙ  Клиента..
к тому - на моем сервере может и стоит - но мне удобнее MySQL-Front.. - но не у всех же MySQL - соответственно нужны возможности работать с разными версиями SQL.
опять-же свою работу Клиент-Сервер лучше организовывать через собственные средства 
(или мы путаемся в названиях?)



попробую присоединить архив со своими наработками (bark - клуб, magic - основа и тур.магазин) - там есть многое из перечисленного Вами здесь и в  Description_DBMS_Logos.doc в серверной части - вот только с описаниями там совсем плохо


посмотрите в присоединенном архиве inquire.txt..
или коротко тут:


если запросы (да и оформления лежат подобным образом - легко менять набор запросов в зависимости от используемой БД и решаемой задачи 

аналогично решается вопрос с оформлением - но об этом потом 



я говорю о другой библиотеке - более прикладной и нацеленную на решение конкретных задач - визуализаця объектов базы, их связей и взаимоотношений

вот. 

Присоединённый файл ( Кол-во скачиваний: 6 )
 magic.zip 106,48 Kb

Ваша логика понятна.

Но, к сожалению, подходы к решению проблемы у нас с Вами совершенно разные.

Вы строите свою систему (или хотите построить) на основе какой-то структуры,
Поэтому готовите списки запросов по этой структуре.
Т.е. опять заданность структуры и манипуляции внутри этой заданности.

Это стандартное решение, понятное и, к сожалению, идет вразрез с моим представлением.

Мое решение:

Объект-А (картинка, все-что-угодно) имеет свои параметры.
Ее месторасположение - На вашем компьютере.

Объект-Б (все-что-угодно) имеет свои параметры.
Ее месторасположение - На другом компьютере.

Мы устанавливаем связь между объектам-А и объектом-Б

И это мы делаем в клиенте. 

Суть понятна, нужна универсальность. А общая идея я так понял в том, чтобы всё связывалась со всем, и могло быть получено всеми известными человеку способами. Я об этом тоже думал. Думаю, многие об этом думали. Ведь как хорошо было бы иметь универсальный инструмент позволяющий взаимодействовать с любой инфой и именно нужным способом. Но всё не так просто. Существует такое понятие как формат данных. Формат данных это то, каким способом эти данные будут извлекаться, обрабатываться и храниться. В компьютерах универсальны только двоичные строчки и чтобы это преодолеть, придётся или использовать псевдотипы, то есть собирать формат из типов и заранее обговорённых действий, или научиться работать с изначальной логикой, но на высшем уровне. В этом вопросе нужно, прежде всего, понять, что хочешь получить, а потом экспериментировать, экспериментировать и ещё раз экспериментировать.

Что нам это даст?

1.    Абсолютный контроль над информацией.
2.    Абсолютное понимание происхождения и способов обработки данных.
3.    Сверхбыструю обучаемость.
4.    Да мало ли что ещё…

Но всегда есть но. Реализовать подобную систему будет крайне сложно, а почему? Да потому что придётся пользоваться той самой структурой, которая имеет основу. То есть программа сможет рассматривать универсальные данные, но сама она должна иметь структуру, и реализована на конкретных языках и платформах. Очевидно, речь идёт о теории «Мегаграфов», хотя в данном случае я бы употреблял более высшие приставки (гига, …).
 

Что имеется ввиду под "Мегаграфами"? 

Теория сложных связей 

Система, которую  я предлагаю создать, уже существует в прототипе.

Конечно, она не закончена. Есть еще много вопросов, 
Нет, пока, решения приемлемой визуализации данных.
Отсутствует механизм использования данных различного типа, поскольку я отрабатывал только взаимодействие между объектами.

Но разработан основной алгоритм связывания данных, логика его работы.

Действительно, это система графов, теория которых, в настоящее время, усиленно разрабатывается некоторыми
теоретиками. В теории я не силен. Я не смогу здесь с полными теоретическими выкладками обосновать право на существование такой базы данных. Но то, что такую систему можно построить, не сомневаюсь.

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