1. Введение

Данный документ является частью рабочей документации проекта: «Разработка веб-сервера онтологий с использованием технологий веб 2.0».

Документ находится в стадии доработки и редактирования.

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

Перечень режимов:
1. Открыть форму с онтологией в режиме редактирования (сейчас делает приложение, а должен сервер) с редактируемым полем наименования:
• новую форму (пустую) в среде ядра;
• новую форму (пустую) в среде любой выбранной онтологии;
• форму с онтологией, сохраненную в режиме редактирования (черновик);
• форму с онтологией для создания новой версии онтологии.
2. Сохранить черновик онтологии на сервере и построить внутреннее представление по тексту онтологии.
3. Построить ответ на запрос к онтологии.
4. Сохранить онтологию в режиме редактирования на сервере (черновик)
5. Окончательное сохранение редактируемой онтологии (перевод онтологии из состояния «редактирование» в состояние «только чтение») с сохранением введенных шаблонов. Действие делается, если выполнено «построить» (в форме должен быть признак этого).
6. Открыть форму с онтологией, сохраненной в состоянии «только чтение» с кнопкой или пунктом меню для вызова формы задания вопроса и получения ответа.
7. Удалить онтологию вместе с введенными в ней внешними шаблонами и со всем, что на нее ссылается (работает по-разному для удаления «черновиков» онтологий и онтологий, сохраненных окончательно).
8. Построение формы словаря внешних шаблонов, видимых из данной онтологии (сейчас это делает приложение, а должен делать сервер).
9. Построение словаря внутренних шаблонов.
10. Сервисы, делающие удобной работу с системой (например, поиск, деревья данных и т.д.).

Все действия должны сопровождаться выдачей сообщений. Управление сообщениями должно быть в форме с онтологией (индивидуально для каждого экземпляра формы, возможно с установкой в форме фильтра для сообщений).

Дополнительные функции на сервере
1. Разовая загрузка на сервер данных о шаблонах ядра системы из файла kernel.tmt.
2. Функция (на сервере) для загрузки из файла онтологии на сервер данных о внешних шаблонах, введенных в этой онтологии, и данных об использовании других онтологий в этой онтологии.
3. Функция формирования на сервере списка шаблонов, видимых из онтологии, для:
показа на сервере в форме «Словарь шаблонов»;
передачи в пролог-приложение для задач грамматического анализа (можно передавать не все, а только те шаблоны, слова которых встречаются в анализируемом тексте в той же последовательности).

2. Общее описание объектов и функций системы

2.1. Онтологии – это страницы, к которым можно обращаться с вопросами и получать ответы.

2.2. Каждая онтология на сервере должна быть сохранена либо с отметкой «только чтение», либо с отметкой «редактирование» и должна иметь автора, зарегистрированного на сервере. Онтологии разбиваются по темам. По каждой теме есть ответственный, объявивший эту тему и набирающий группу пользователей – создателей онтологий этой темы. Он ставит свою отметку о прочтении онтологий своего раздела (визирует онтологии) или доверяет эту функцию каким-либо членам своей группы.

2.3. Онтологии с отметкой «только чтение» могут быть опубликованы для разных групп пользователей, включая незарегистрированного пользователя. К ним можно ограничить доступ пользователей, их можно удалять, если они не используются в других онтологиях. Онтология «Ядро системы» не может быть удалена. Онтология может переименовываться пользователем, ответственным за раздел, в котором она создана, если она не используются в других онтологиях. Онтологии с отметкой «только чтение» не могут редактироваться, но их можно использовать при создании новых редактируемых версий.

2.4. Среди версий онтологий, всегда выделяется одна, которая показывается по умолчанию и загружается в редактируемые онтологии при использовании по имени (без указания версии). Следовательно, все версии одной онтологии имеют одинаковые имена (но могут иметь разные суффиксы версий). Редактируемая версия не может быть выделена, как главная, если есть другие версии этой онтологии. Просмотр списка версий, производится дополнительной функцией. Выделенная версия не может быть удалена, если есть другие версии этой онтологии.

Вопрос для обсуждения: В какой мере имя онтологии должно быть уникальным? (Вместе с номером версии? В пределах видимости из текущей онтологии?) Может быть, нужно обеспечить работу с разными видами имен: краткое имя, краткое имя + номер версии, имя онтологии + имя среды, путь от «ядра системы» до нужной онтологии, имя онтологии + имя автор? (Будем делать уникальным имя онтологии+номер версии. Проверка уникальности будет проводиться на сервере. Разные версии одной онтологии должны иметь одинаковые имена.)
Если внутри некоторой онтологии используется другая онтология, для которой была изменена главная версия, то исходная онтология отмечается на сервере как «требующая построения новой версии».

2.5. К онтологии с отметкой «редактирование» ограничивается доступ. Они могут быть доступны, только автору и ответственному за раздел онтологий, который может управлять доступом к онтологии в пределах своей группы.

Каждая онтология создается в среде некоторой онтологии, находящейся с отметкой «только чтение». Изменение авторства онтологии возможно только при построении новой версии онтологии. Для редактируемой версии внешние шаблоны, создаваемые в ней, и данные об использовании в ней других шаблонов не сохраняются во внешних словарях и файлах BaseEsaples.ezp и BaseEsaples.tmt. Сохранение этих данных во внешних словарях происходит при выполнении команды сохранения редактируемой онтологии на сервере в состоянии «только чтение», после проверки уникальности имени.

Состояние онтологии с отметкой «редактирование» может сохраняться на сервере кнопкой «Сохранить черновик». При этом проверяется уникальность имени онтологии вместе с номером версии, и на сервере сохраняется идентификатор, название онтологии, название и идентификатор среды, раздел онтологии, текст, автор, версия какой онтологии, дата и время сохранения. Номер версии строится автоматически, если еще не был определен. При каждом сохранении черновика все данные прежнего черновика онтологии удаляются. На стороне Web-приложения сохранение черновика не происходит. Списки черновиков могут просматриваться на сервере. Запуск формы онтологии для редактирования с этим черновиком производится из списка черновиков (с фильтрами для пользователей и разделов).

Вопрос для обсуждения: Нужен ли id онтологии в приложении, отличающийся от id node для онтологии на сервере? (Давайте для простоты делать эти идентификаторы совпадающими.) При создании новой онтологии и запуске формы для создания новой онтологии можно не создавать и не передавать id форме. Идентификатор (id node) создается, когда впервые сохраняется черновик онтологии. Передается название текст и автор, название среды, id среды. Обратно возвращается все это и id онтологии с датой сохранения. Название для новой онтологии может измениться, если оно занято. Если онтология не имеет черновика и даты последнего сохранения (следовательно, нет id онтологии), то она не может быть построена. В этом случае, при запуске «Построить» сначала должно выполниться на сервере сохранение черновика и запуск с сервера приложения с функцией построить (то есть серверу передается команда «создать черновик и построить» с необходимыми исходными данными), а приложение выполняет построение аппроксимации и строит форму онтологии с отметкой «редактирование» в состоянии после построения.

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

Вопрос для обсуждения: Как сохранять новые состояния файлов приложения BaseExamples.ezp и BaseExamples.tmt общих для всех пользователей? (Пользователи могут одновременно писать в эти файлы из разных процессов?) Я думаю, что в условиях параллельной работы лучше ими не пользоваться (если можно), а всю информацию хранить на сервере и пользоваться стандартными средствами друпал многопользовательской параллельной работы. Для ведения онтологий без этих файлов можно обойтись. Но для алгоритма грамматического анализа пролог-приложению нужно передавать требуемые шаблоны, а для использования других онтологий в данной онтологии нужно загружать файлы главных версий онтологий по названию онтологий. При этом главные версии выделяются на сервере.
Сейчас в тексте онтологии пишется, какие онтологии в ней используются, но не указывается какие версии. Поэтому нужно изменить программу выполнения действия загрузки онтологии по имени и заставить ее выдавать в тексте онтологии сообщение о том, какая версия использована.
Если оставлять файлы BaseExamples.ezp и BaseExamples.tmt, то для обеспечения параллельной работы с ними при использовании режимов, требующих обновления этих файлов, нужно при считывании файла считать время сохранения файла (в предикате get_dic…), а при перезаписи обновленных данных в файл (в предикате save_dic) нужно сравнивать считанное время и время сохранения существующего файла. Если времена не совпадают, то откатиться и заново совершить загрузку файла, изменение данных файла, сохранение файла.
Давайте пока сохраним использование файлов BaseExamples.ezp и BaseExamples.tmt, так как мы не освоили возможности вызова запросов к базе данных mySQL из пролога. В этом случае, чтобы в прологе загружалась нужная версия, в файлах нужно дополнительно хранить номер версии и идентификатор главной версии. Текст онтологии в предикате name_file можно не хранить, так как он передается формам с сервера или из предыдущей формы.

2.6. Удалять онтологии может ответственный за тему онтологий, а онтологии, находящиеся в режиме редактирования, и автор онтологии. Удалять онтологии можно только удовлетворяющие условию удаления (условие: не используются в других онтологиях, не выделены в качестве главных версий среди нескольких версий).

При удалении онтологии, должны быть удалены все данные, которые связаны с этой онтологией. То есть внешние шаблоны, введенные в этой онтологии, сведения о том, какие онтологии эта онтология использовала, данные в таблицах версий и id онтологий и т.д., а также все данные в приложении, связанные с этой онтологией (файл аппроксимации и данные в файлах шаблонов и каталога, если они будут использоваться).

При удалении онтологии, находящейся в «режиме редактирования» (черновика), онтология удаляется с сервера вместе с файлом внутреннего представления и данными, находящимися в файле каталога онтологий в пролог-приложении (в файле шаблонов шаблоны такой онтологии не сохраняются).
Вопрос для обсуждения: Возможна технология, при которой удаляемые онтологии реально в первый момент не удаляются, а отмечаются к удалению и становятся невидимыми (это можно осуществить средствами таксономии в друпал). Реальное удаление происходит через некоторое время. До этого времени «удаленные» онтологии можно посмотреть в разделе «удаленные» и восстановить. При использовании этой технологии либо информация об «удалении» должна передаваться в приложение и использоваться там в предикате видимости, либо требуемые данные о шаблонах и онтологиях будут передаваться приложению с сервера с учетом видимости.

При реальном удалении, с сервера запускается удаление в приложении, а после сообщения об успешном выполнении запускается удаление данных на сервере (без открытия промежуточных форм).
Вопрос для обсуждения: Возможен другой вариант: файлы пролог-приложения удаляются и редактируются средствами PHP при удалении онтологий с данными идентификаторами.

3. Формы интерфейса пользователя и режимы работы системы

3.1. Перечень форм приложения

В соответствии с перечнем режимов работы приложения и общим описанием работы в различны режимах, среди форм интерфейса пользователя можно выделить следующие формы:
1. Форма 1 нужна для построения новой онтологии или новой версии онтологии с отметкой «редактирование». Она может быть похожей на существующую форму, выдаваемую приложением, но с другим меню и дополнительными полями: ник автора, номер версии, дата и время последнего сохранения, отметка «построена полностью».
2. Форма 2 нужна для просмотра онтологии с отметкой «только чтение». В ней нет редактируемых полей. Ее поля - это часть полей Формы 1. Отсутствуют поля: «Необработанная часть текста», «Команда», «Сообщения». То есть она похожа на ту, которая открывается при показе онтологии на сервере, но вместо кнопки «Сделать текущей» будет кнопка (или пункт меню?) «Запрос к онтологии». При выборе этой кнопки в отдельном окне открывается Форма 3.
3. Форма 3 нужна для формулировки запроса к онтологии и представления ответа на запрос с выдачей сообщений о результатах анализа запроса (Форму 3 лучше сделать отдельной, не частью Формы 2?).
4. Форма 4 нужна для просмотра словаря шаблонов, видимых из текущей онтологии. Выдача словаря может быть ограничена различными фильтрами.

3.2. Режим «Создать новую онтологию»

3.2.1. Это режим нужно будет отладить в первую очередь вместе с другими режимами, запускающими или запускаемыми из Формы 1.

3.2.2. Запускается этот режим либо из меню сервера пунктом «Создать новую онтологию в среде Ядра», либо из перечня онтологий (с показом начала текста), либо из Формы 2 из пункта меню «Создать новую онтологию в среде этой».

3.2.3. Результатом этого режима является открытие Формы 1, в которой указываются поля:
• идентификатор онтологии – (скрытое поле) с пустым значением;
• имя онтологии – пустое редактируемое;
• номер версии – пустое не редактируемое;
• имя среды (имеется ссылка на страницу с онтологией среды);
• идентификатор среды – (скрытое поле);
• название раздела – группа, в которой на момент вызова определен автор;
• имя автора;
• построена – пустое не редактируемое;
• дата и время последнего сохранения - пустое не редактируемое;
• текст онтологии – пустое редактируемое;
• необработанная часть текста – пустое редактируемое;
• сообщения - пустое не редактируемое.
Вопрос для обсуждения: последние два поля старой формы
• вопрос (команда) – пустое редактируемое;
• ответ - пустое не редактируемое;
предлагаю вынести в отдельную Форму 3, в которой указывать имя онтологии, версию, среду, текст запроса, ответ и сообщения об ошибках.

Все параметры для Формы 1 передаются из форм, вызывающих Форму 1 (при первом запуске новой онтологии идентификатор онтологии не существует, и он создается только при первом сохранении онтологии в виде черновика).
Данные из файлов пролога не используются.
Онтология не создается ни на сервере, ни в прологе. (Это делается для того, чтобы уменьшить объем мусора в системе).

Форма 1 должна строиться в друпал средствами PHP и пролог-приложении средствами пролога. Созданные в разных местах Фомы 1 должны выглядеть одинаково и работать одинаково!!!

3.2.4. Меню Формы 1 содержит следующие пункты:
• Сохранить черновик;
• Проверить текст (Построить);
• Вопрос к построенной части онтологии (Команда);
• Сохранить в библиотеке;
• Удалить;
• Словарь шаблонов;
• Управление сообщениями;
• Помощь.

3.3. Режим «Сохранить на сервере онтологию с отметкой «редактирование» (черновик)

3.3.1. Этот режим выполняется по-разному в зависимости от значения переменной «Идентификатор онтологии». Дальше предполагается, что идентификаторы онтологий на сервере и в пролог-приложении совпадают.

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

Если значение переменной «Идентификатор онтологии» пусто, то на сервере создается страница онтологии типа «черновик» с датой сохранения и с текстом, который является соединением значений полей «Текст онтологии» и «Необработанная часть текста» Формы 1. Эта онтология делается доступной только автору и руководителю группы. (Онтология может быть открыта для изменений другому пользователю руководителем группы). Далее у клиента воспроизводится прежняя Форма 1, но с заполненным полем «Дата и время последнего сохранения» и с построенным значением переменной «Идентификатор онтологии», равным id node на сервере.

Если значение переменной «Идентификатор онтологии» не пусто, то на сервере вызывается обновление (сохранение в БД) параметров страницы типа «черновик» в полях текст, автор, дата. Далее у клиента воспроизводится прежняя Форма 1, но с новым значением поля «Дата и время последнего сохранения».

3.3.3. Сохраненный на сервере «черновик» онтологии может быть открыт в Форме 1 автором онтологии со страницы «Онтологии пользователя», на которой указывается перечень всех онтологий пользователя по разделам, или со страницы «Онтологии раздела» руководителем раздела и автором.

3.3.4. Открытие Формы 1 с сервера происходит средствами друпал без использования пролог-приложения.

3.4. Режим «Сохранить черновик на сервере и построить внутреннее представление по тексту»

3.4.1. Этот режим вызывает работу системы, как на сервере, так и в пролог-приложении.

3.4.2. Режим вызывается из Формы 1 пунктом меню «Проверить текст (Построить)»

3.4.3. На первом этапе выполнения режима происходит сохранение состояния Формы 1 на сервере в виде «черновика» (см. пункт 3.2) без обновления Формы 1.

3.4.4. На втором этапе происходит вызов с сервера пролог-приложения с функцией «построить все» и передачей ему всех новых значений полей и переменных Формы 1, кроме поля «Сообщения».

3.4.5. Пролог-приложение загружает из файла среду онтологии (по идентификатору) вместе с видимыми шаблонами (из файла шаблонов или с сервера?) и строит по «тексту»+«необработанная часть текста» предикатом execute внутреннее представление текста до ошибки в тексте.

Результатом работы приложения является построение новых значений полей «Текст», «Необработанная часть текста», «Сообщения», «Построена».

Сообщения строятся приложением в соответствии со значениями параметров управления сообщениями, переданными из Формы 1.

Если значение поля «Необработанная часть текста» становится пустой, то значением поля «Построена» Формы 1 становится слово «Построена».
Кроме того, приложение сохраняет построенную онтологию в файле с именем, совпадающим с идентификатором онтологии. (Файл шаблонов не обновляется и не сохраняются данные редактируемой онтологии в файле BaseExamples.ezp.)
Далее приложение строит Форму 1 с обновленными значениями полей и переменных (скрытых полей).

3.4.6. При изменениях пользователем значений в редактируемых текстовых полях Формы 1 значение поля «Построена» становится пустым.
Вывод: Форма 1 строится и в друпал и в приложении.

3.5. Режим «Окончательное сохранение редактируемой онтологии»

3.5.1. В этом режиме онтология переходит из состояния редактирования в состояние «только чтение» и открывается в Форме 2.

3.5.2. Режим вызывается из Формы 1 пунктом меню «Сохранить в библиотеке», только если есть в форме значение поля «Построена» заполнено. Иначе выдается сообщение о необходимости проверки текста онтологии (Построить).

3.5.3. При выполнении режима вызывается пролог-приложение (или сервер, который будет работать с файлами онтологии?) с функцией «сохранить» и идентификатором онтологии в качестве параметра. Приложение формирует список внешних шаблонов, введенных в этой онтологии (удаляя их из файла онтологии), для ввода в файл шаблонов для передачи серверу в базу шаблонов сервера. Кроме того, приложение формирует список идентификаторов онтологий, используемых в данной онтологии, сохраняет новый файл онтологии, вводит данные об онтологии в файл BaseExamples.ezp и запускает функцию сервера с построенным списком параметров и идентификатором онтологии для обновления базы данных.

Вопрос для обсуждения: Действия, описанные в пунктах 3.5.3. и 3.5.4., могут быть выполнены программой на PHP путем обработки файлов онтологии, BaseExamples.ezp и BaseExamples.tmt и без вызова пролог-приложения.

3.5.4. На сервере «черновик онтологии» переводится в состояние «только чтение», и в базу данных вводятся данные о шаблонах и об использовании онтологий в данной онтологии. Далее на стороне клиента открывается Форма 2, которой передаются все нужные параметры для отображения этой формы.

3.5.5. Результатом этого режима является создание онтологии с отметками «только чтение» и «не утверждена», а также открытие ее в Форме 2, в которой указываются поля:
• идентификатор онтологии (скрытое поле);
• имя онтологии (имеется ссылка на страницу с онтологией);
• номер версии;
• имя среды (имеется ссылка на страницу с онтологией среды);
• идентификатор среды (скрытое поле);
• название раздела;
• имя автора;
• дата и время создания;
• текст онтологии.

Меню Формы 2 содержит следующие пункты:
• Запрос к онтологии;
• Словарь шаблонов онтологии;
• Показать список версий;
• Создать новую онтологию в среде этой онтологии;
• Создать новую версию этой онтологии.
Кроме того, в форме должны быть видны стандартные меню сервера.

3.5.6. Форма 2 открывается сервером.

3.6. Режим «Запрос к онтологии»

3.6.1. Режим запускается из пунктов меню Формы 1 и Формы 2 и в обоих случаях выполняется одинаково: открытием формы запроса и ответа, то есть Формы 3.

3.6.2. Результатом этого режима является открытие у клиента «пустой» Формы 3, в которой данные для заполненных полей передаются из форм, вызывающих «пустую» Форму 3. В Форме 3 представлены следующие поля:
• идентификатор онтологии (скрытое поле);
• имя онтологии (имеется ссылка на страницу с онтологией);
• номер версии;
• имя среды (имеется ссылка на страницу с онтологией среды);
• идентификатор среды (скрытое поле);
• название раздела;
• текст запроса ( пустое редактируемое поле);
• текст ответа на запрос (пустое не редактируемое поле);
• сообщения (пустое не редактируемое поле).
Меню Формы 2 содержит следующие пункты:
• Выполнить запрос к онтологии;
• Словарь шаблонов онтологии;
• Дерево понятий онтологии;
• Дерево использованных онтологий;
• Управление сообщениями;
• Онтологии раздела;
• Помощь.

3.6.3. Форма 3 в этом режиме строится на программными средствами PHP.

3.7. Режим «Построение ответа на запрос к онтологии»

3.7.1. Этот режим запускается из пункта меню Формы 3. Текст запроса обрабатывается пролог-приложением. В результате обработки строится ответ и выдаются сообщения об обработке запроса, выполненных действиях и ошибках в тексте запроса.

3.7.2. При выполнении этого режима запускается функция пролог-приложения «построения ответа на запрос» с парамерами: идентификатор онтологии, идентификатор среды и текст запроса.

3.7.3. Пролог приложение по идентификатору среды устанавливает среду вместе с видимыми из онтологии шаблонами (удовлетворяющими условию, что слова шаблона входят в текст шаблона в той же последовательности?), загружает по идентификатору онтологии файл онтологии, и выполняет предикат execute, на вход которого передается текст запроса. На выходе предиката строятся ответ на запрос и текст сообщений об ошибках. Далее в пролог-приложении строится Форма 3 с обновленными значениями полей «ответ» и «сообщения».
Вывод: Форма 3 строится и в друпал и в приложении.

3.8. Режим «Построение новой версии онтологии»

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

3.9. Режим «Выбор среди версий онтологии главной версии»

3.10. Режим «Удалить онтологию»

Процессы удаления онтологий c отметкой «редактирование» (черновиков) и онтологий c отметкой «только чтение» (окончательно сохраненных) отличаются.
Онтологии с отметкой «только для чтения можно удалять, только если они не используются в других онтологиях.
Онтология «Ядро системы» (идентификатор онтологии равен 1) не может быть удалена.
Выделенная версия не может быть удалена, если есть другие версии этой онтологии.
Удалять онтологии может ответственный за тему онтологий, а онтологии, находящиеся в режиме редактирования, и автор онтологии. Удалять онтологии можно только удовлетворяющие условию удаления (условие: не используются в других онтологиях, не выделены в качестве главных версий среди нескольких версий).

При удалении онтологии, должны быть удалены все данные, которые связаны с этой онтологией. То есть внешние шаблоны, введенные в этой онтологии, сведения о том, какие онтологии эта онтология использовала, данные в таблицах версий и id онтологий и т.д., а также все данные в приложении, связанные с этой онтологией (файл аппроксимации и данные в файлах шаблонов и каталога, если они будут использоваться).

При удалении онтологии, находящейся в «режиме редактирования» (черновика), онтология удаляется с сервера вместе с файлом внутреннего представления и данными, находящимися в файле каталога онтологий в пролог-приложении (в файле шаблонов шаблоны такой онтологии не сохраняются).
Вопрос для обсуждения: Возможна технология, при которой удаляемые онтологии реально в первый момент не удаляются, а отмечаются к удалению и становятся невидимыми (это можно осуществить средствами таксономии в друпал). Реальное удаление происходит через некоторое время. До этого времени «удаленные» онтологии можно посмотреть в разделе «удаленные» и восстановить. При использовании этой технологии либо информация об «удалении» должна передаваться в приложение и использоваться там в предикате видимости, либо требуемые данные о шаблонах и онтологиях будут передаваться приложению с сервера с учетом видимости.

При реальном удалении, с сервера запускается удаление в приложении, а после сообщения об успешном выполнении запускается удаление данных на сервере (без открытия промежуточных форм).
Вопрос для обсуждения: Возможен другой вариант: файлы пролог-приложения удаляются и редактируются средствами PHP при удалении онтологий с данными идентификаторами.

3.11. Режим «Словарь шаблонов онтологии»