Alexsalog Воть

Особенно по теме:
про пользовательский интерфейс
Да как-то тут ранее поднималась как раз эта проблема, про пользовательский интерфйес на оснвое онтологий и про эту работу я упоминала. Сегодня в МИЭТ (Зеленоград) защита кандидадтской по схожей тематике. Я посчита работу сильной (отзыв писала).

AlexsalogИ опять же - если кто понимает о чем речь, то главнейшей проблемой в системах онтологии является не описание онтологий (это все банально и тривиально), а их маппирование друг на друга. По моему это уже на уровне подступов к ИИ.

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

Alexsalog - НЕТ, не одно и тоже. Источник один, но от него берут начало другие онтологии с дополнительным (и дополняемым) собственным контекстом, но тем не менее жестко связанные с центральным описанием.


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

AlexsalogПри этом работа может быть двух типов

1) Конечные действия (выполенние запросов, формирование интрефейса, расчет, сохранение и исзвлечение данных)

2) Трансферт - внесение изменений в активное состояние других онтологий с использованием структуры взаимосвязи.

Если нравится, то можно классифицировать как угодно, главное, чтобы из классификации что-то следовало.
Простое изменение экземпляров понятий на основании описания онтологий и отношений между ними- это обычная вещь. Она давно есть. Я не об этом. Хотя и это полезно, но все же не это самое интересное.

Mainframe_старый Alexsalog - НЕТ, не одно и тоже. Источник один, но от него берут начало другие онтологии с дополнительным (и дополняемым) собственным контекстом, но тем не менее жестко связанные с центральным описанием.


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

Кстати да. чтоб понятно одно описание - это не одна онтология. Просто, описав что-то один раз, можно это потоv использовать в разных местах. Например, описали что есть понятие с какими-то атрибутами. Потом определили, что это понятие имеет отношения проекции с источником данных 1 и 2, но с 1 отношения на чтение/запись, а с 2 только на чтение. ЧТо из этого следует ?
1. Что должна быть автоматически выполнена репликация из источника 1 на источник 2 и вся репликация уже определена потому что все описано в описания понятия и отношений проекции дополнительно не нужн описывать.
2. Что при выборки понятия можно обратиться к истчонику 1, но лучше при прочих арвных начать с 2, но если связи нет, то можно и один
3. Что если нужно создать экземпляр, то только к 1
ну и так далее там еще много чего.

guest_20040621>
Онтология в чистом виде здесь бесполезна. Уже потому, что Вы определяете понятия источников не семантически, а идентифицируете их. Т. е. в данном случае онтологию есть смысл использовать как дополнительную парадигму.

Итосник данных ведь тоже понятие, имеющее атрибуты - сервер, база, таблица (представление) и атрибуты таблицы (поля). Т.е. отношения проекции устанавливаются между понятиями, а не между понятием и источником данных.

guest_20040621> отношения проекции устанавливаются между понятиями, а не между понятием и источником данных

Пожалуйста, продемонстрируйте это примером.

Вводим понятие - сервер (с атрибутами - имя сервера, при необходимости свойства ОС, назначение и т.п.) , понятие - база данных с атрибутами название, отношением "размещается на" с понятием сервер. Понятие - источник данных с атрибутами название и свойством - база данных, т.е. отношением "является объектом", а так же множеством свойств - поля. Поле тоже понятие имеет тип, назание (понятное человеку, можно русское и англ. , которое будет принмать значение имени атрибута таблицы, ну и идентификаторы поля в системных таблицах СУБД).

Далее описываем, например, понятие студент (ФИО, паспорт, отношение с образовательной программой и т.п.). Но студент вводится в основном вузе - в базу основного вуза и в филиалах - в базу филиала. При этом студенты филиала должны быть в базе головного вуза, но там не могут редактироваться. Определяем понятие студент головного вуза, как производное от студента. Условие наследования, что некая характеристика образовательной программы с которой студент связан однозанчно идентифицирует основной вуз. Опреедляем понятие студент филиала как производный от понятия студента, но характеристика образовательной программы определяет только программы филиала.
Определяем отношения проекции между понятием студент и источником данных, т.е. определяем какой атрибут понятия студент какому атрибуту экземпляра понятия источник данных соответствует. При этом отношения проекции тоже могут иметь производные - проекция на чтения -запись и на запись. Далее определяем, что между источником соотвествующим головному вузу определены отношения проекции на чтение с понятием студент и отношения на чтение/запись с понятием студент головного вуза. Между понятием студент филиала определены отношения проекции на чтение/запись с источником филиала.
Далее вводим правило : если есть отношения проекции ан чтение запись в производном понятии и отношения проекции на чтение в базовом с арзными источниками данных, то должна быть организована репликация из первого источника во второй.

Как я понимаю, вопрос Ваш касался того, что отношения проекции определяются с произвольным понятием и экземпляром понятия источник данных?
Вы думаете это не вписывается в онтологическую парадигму?

guest_20040621
Да. И Ваш пример это иллюстрирует. ;)


Согласна.

guest_20040621
> Вы думаете это не вписывается в онтологическую парадигму?

И идентификатор экземпляра сущности - суррогатный. Имя поля, которое Вы назвали понятным человеку, таковым быть вовсе не обязано. Штатных средств преобразования метаданных СУБД в онтомодель - нет.

Тоже согласна. Но кто мешает самим сделать? (только время и деньги). Собственно мы сделали для одной СУБД для некоторого ограниченного подмножества объектов.

Есть два способа хранить экземпляры. Можно преобразовав метаданные СУБД - и потом корректировать в ручном режиме - вводя понятность пользователям - русские слова, прописывая врунчую отношения, которые не построены, потому что они были "логическими", а ен физическими в СУБД.
Есть второй способ - в начале описать на уровне понятным предметникам и это описание транслируется - Не в таблицы - в одной таблице хранится и метаописания и собственно экземпляры (по горизонтали).
Мы пока делаем и так и так (ну если честно, пока нет ни в чем твердной уверенности). При необходимости репликации делаются в обе стороны.

guest_20040621> Но кто мешает самим сделать?

Как Вы правильно заметили, никто не мешает. Но я бы все-таки использовал онтологию как дополнительную парадигму, а не основную.
А какую бы Вы использовали как основную ?