roboforum.ru

Итак, пока в соседнем топике народ во главе с DeaD борется с аудиовизуальными признаками и образами, продолжу, а кое-что и повторю. FIPA может являться основой для объединения различных субагентов одного робота, кот. могут общаться через различные протоколы нижнего уровня включая интернет. Основное требование, чтобы ожидание не превышало утановленные в сообщениях лимиты.
Далее, содержание сообщения должны основываться на OWL. Нужно только выбрать одну из удобных нотаций. Над этим языком делаем надстройку в виде семантической сети SUMO, где определены важнейшие понятия, такие, как процесс, сущность, время, пространство и т.д.
После этого можно определять параметры отдельных субагентов. Таких, как зрительный, слуховой, речесинтезаторный и т.д. Т.к. все субагенты должны понимать SUMO, то в каждом субагенте должно присутствовать его подмножество, необходимое для работы субагента. Кроме этого, в большинстве субагентов, для работы с онтологией необходима машина логического вывода. Как я раньше писал, можно использовать FACT++.

С помощью онтологии можно описать не только какое-то состояние или процесс мира, собственных мыслей, но и программировать поведение субагента. Если посмотреть на SUMO http://www.site.uottawa.ca:4321/sumo/in ... RealNumber и выбрать в левой колонке по алфавиту Procedure , то в правом окне станет видно, что из себя представляет она из себя. ComputerProgram - субкласс Procedure.
Но особо интересно, если вверху левого окна выбрать закладку Graph. Тогда станет видна вся онтология. Слева - корневой класс Entity. Все сущее в этой онтологии разбивается на абстрактное и физическое. Физическое - на процессы и объекты.

Для знакомства с OWL можно взглянуть на переводы двух документов консорциума w3c:
http://sherdim.rsu.ru/pts/semantic_web/ ... 10_ru.html
В http://sherdim.rsu.ru/pts/semantic_web/ ... 10_ru.html написано:
"3.1.3. Дизайн для использования
Существуют большие проблемы относительно различия между классом и индивидом в OWL. Класс - это просто название и совокупность свойств, которые описывают набор индивидов. Индивиды - это члены этих наборов. Таким образом, классы должны соответствовать естественно образованным наборам вещей в рассматриваемой области, а индивиды должны соответствовать реальным объектам, которые могут быть сгруппированы в эти классы."

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

Товарищ, таких схем у каждого программиста и не только у него будет несколько.
Для них, все предельно и кристально ясно, типа "реализовывайте давайте, я вам все нарисовал.."
Вот тут то и проблема, что реализовывать то некому.
У реализаторов:
a) свои схемы в голове и нет времени заниматься чужими
б) схемы на бумаге просты, в реализации невозможны... "кроме реализации конкретных технических решений"

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

Ок. Молчу.
Дело не в схеме. А в том что игрушка SIMS содержит в себе отличную модель для реализации взаимодействия робота с окружающей обстановкой и людьми, которая уже десятки лет совершенствуется. Просто хочу обратить внимание, вдруг что-нть полезное будет.

После длительных раздумий я понял, что кое-что реализовывал неверно. Точнее, не совсем так. В первоначальной версии моей ИИ системы, которую я написал на ассемблере, была одна общая онтология, хранимая на жестком диске. Множество демонов могли взаимодействовать между собой и с этой онтологией. Затем я сделал систему, основанную на Rules Engine. Но когда поверх нее начал создавать онтологию, то понял, что это неправильно. Теперь же я начинаю делать новый движок OntoEngine, который должен сочетать лучшие свойства двух предыдущих.
Одна общая онтология, которая частично расположена в RAM и частично на HDD - кешируемая специальным образом. В RAM не демоны, а факты, которые привязаны к листьям этой онтологии. А где же тут может располагаться сама программа? В самой этой же онтологии. Т.о. вновь приобретенные знания могут изменять поведение системы самым простым способом. Правила также являются частью онтологии, как и другие вычислительные операторы. Интерпретируя эту онтологию, аналогично Rules Engine получим вычислительный процесс, который длится до тех пор, пока есть хоть одно нереализованное правило.
Вот такие мысли. Теперь бы дойти до каких-то результатов. Они могут быть и отрицательными. Пока не знаю, буду кодить.

А может всё-таки начать с Use Case'ов?

Поясните, что именно в данном случае вы подразумевали?

Добавлено спустя 40 минут 26 секунд:
Такая пока вырисовывается структура. Тут возникает ряд проблем. Если каждая Rules Engine будет работать независимо от другой, то любые изменения общей онтологии со стороны одной Rules Engine могут затронуть работу других. Кроме того, возможно, они будут работать в разных тредах.

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

В том то и дело, что в нескольких конкретных применениях предыдущие решения оказались не очень хорошими. Одно из них - это База Знаний (БЗ) на основе SUMO и WordNet. Когла я ее наполнил и попытался пользоваться, натолкнулся на низкую производительность, огромную затрату RAM и HDD. На основе этой онтологии я хотел двигаться от довольно абстрактных запросов к БЗ к распознаванию окружающей робота или программного агента обстановке. Но напоролся на такие грабли.

База знаний - это тоже инструмент, какие практические задачи то вы в качестве примера выбрали?

Хотел бы начать с энциклопедических способностей. Это далеко не то же самое, что гугли. Скорее похоже на клуб "Что-где-когда?" Выявление скрытых знаний в имеющихся знаниях, вывод новых знаний на основе имеющихся. На первом этапе все будет довольно примитивно, затем планирую усложнение. Кстати, с помощью действующего варианта моей программы AIAssistant это уже реализовано - простые поиски в онтологии. Например, что такое аэропорт, какая валюта действует в России и т.д. при некоторых из этих ответов система показывает требуемое кол. суперклассов и их свойства для данного понятия.

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

А можно именно use cas'ы указать? Типа - что система планируется должна ответить на открытый вопрос типа "что такое аэропорт?". С вопросом "какая валюта в россии" - тут более менее ясно

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

Ну википедия тоже справочник, в чем отличие будет? Где отличительный от простого справочника use case, т.е. в чем эта особая интеллектуальность будет проявляться?