Агенты, Взаимодействия, SPARQL, Производительность!

, , , , , , , | Shcherbak Sergey | 23.01.2009 | 6 комментариев


В продолжение тем, поднятых в комментариях предыдущих постов!

Уважаемые читатели SHCHERBAK.NET, cкажу Вам чесно — меня вообще угнетают все эти языки запросов (SPARQL, SPARUL и другие) — я и взялся работать с ними только для того, что хочу повысить уровень совместимости моего текущего проекта с другими семантик веб приложениями, а для этого мне нужна sparql-точка доступа.

Кроме того, я добился почти линейного роста сложности для алгоритма анализа онтологии, это при том, что я контролирую этот процесс — а что такое sparql и тому подобное — это логические вычисления (сложность которых может возрастать експоненциально) — которые очень ресурсоемкие — и в большинстве задач вообще не нужные — например, зачем статистку работы пользователей с сайтом бросать в triple store (пусть даже через маппинг)? если реляционная база данных справиться с этим лучше. А, умный запрос построить сможете по этому! ну и что. Есть специальные аналитические средства, которые это все равно сделают лучше.
Semantic Web он потому и хорош, что поддерживает распределенность и разнородность источников информации. И опять же не обязательно через тотальный переход на RDF или OWL.
А через динамическую составляющую Семантического Веба — семантические веб-сервисы. Вот в их задачу входит поддежка доступа через SPARQL. Но это минимум, который надо поддерживать. И абсолютно не обязательно, чтобы источник (хранилище) информации был на RDF и OWL.
То что надо уметь делать маппинг в OWL — это конечно да, но маппинг нужно поддерживать для каких задач?
Для возможности адекватно реагировать на внешние воздействия в условиях неизвестности содержания входящих запросов и не более того!
Зачем городить рекурсивный запрос, например, через Jena, для выборки экземпляров какого-то класса,
если вы как разработчик системы можете написать запрос на классическом SQL, который в несколько (а может и несколько десятков) раз выполниться быстрее. Вы же знаете схему данных! Пусть внешний пользователь или агент не знает схемы (потому мы ему и точку доступа предоставляем). Повторюсь, вы же знаете схему. Зачем делать логический вывод? Это же не эффективно. Или выборку вы не сможете сделать? Логический вывод надо делать там, где это действительно надо.

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

Я просто смеялся, когда мне говорят, о построении «руками» запросов к онтологии, у которых число связей более тысячи. Это же какой у вас должен быть ум, чтобы построить вывод, учитывающий смысл, хотя бы половины связей.
Конечно, Вы скажете, не все используют онтологии с тысячей связей. Хорошо, думаете, на сотне связей Вам будет намного легче. Если да, то вы гросмейстер по анализу ситуаций (шахматисты отдыхают и нервно курят в сторонке)
А когда мы говорим о агентах — он же должен уметь обследовать окружение с целью «понять» — а где же я нахожусь. А зачем это? чтобы понять как реализовать какое то действие на обследуемом источнике. Вот тут Вам и начинает помогать SPARQL. Только вот проблема — логику действия вы ему (агенту) должны объяснить, при чем так, чтобы он это понял и внял. А это уже чистой воды программирование — причем программирование действий. А это уже не просто описание фактов и объектов, это уже нечто посложнее… И поверьте, не такое уже это и простое дело, как многим может показаться! Вот здесь то и начинается, страшное слово Искусственный Интелект.
PS Я конечно понимаю, сейчас каждый кому не лень начинает писать SW приложения, типа бум, и все такое. Только думать все таки надо, где технологии SW надо применять, а где нет.


Понравилась статья? Поделитесь с друзьями!


6 Responses to Агенты, Взаимодействия, SPARQL, Производительность!

  1. Аргументом к необезательному переходом на RDF хранилище, является также то, что определенная организация уже может иметь огромный багаж определенной информации и ПО для его обработки, поэтому его перевод в RDF может потребовать больших ресурсов.
    Но при помощи онтологии можно добиться соблюдения семантической непротиворечивости данных — к примеру: оператор заносит в БД данные о семье в БД и случайно указывает родителем — человека 3-х лет (предтавленного кортежем в другой таблице), соответвенно «увидеть» ошибку может ПО (если учтено) или ошибка может быть учтена в структуре для хранения данных — онтлогия, в этом случае, обладает большей гибкостью чем схема БД. Т.е. в онтологии можно задать что родитель есть человек <10 лет. И если ввод данных осуществлять «через» онтологию, то программному обеспечению надо проверять целостность онтологии. Помимо семантической непротиворечивости здесь также плюс — можно ПО по обработке менять, а функционан будет оставаться.

  2. Насчет, рекурсивного запроса через Jena. Я когда экспериментировал с Jena — пробовал получить свойства определенного класса, функция мне и возв-ла свойства только этого класса, не обращая внимание но то что есть надклассы со свойствами. Потом я еще долго читал док-ю, понял — нужно машину вывода подключить. Подгрузил онтологию через одну из таких машин — Pellet, jena начала выдавать как надо т.е. и наследуемые свойства. И вот что интересно, без машины мне надо было несколько раз вызывать метод полученя свойств над всей ветвью классов, а с машиной — толко один, но машина то, никак концептуально по иному-то запрос не обрабатывает -т .е. есть ли какой-то весомый выйгрыш производительности от использования машины вывода?

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

    по второму комментарию не все так однозначно!

    Кстати, вы смотрели последие тесты скоростей работы различных triple store?
    Там можно увидеть зависимости эффективности работы машины вывода от сложности запроса

    А если в общем, то —

    любое действие, которое совершает программа ресурсоемко, но вот насколько будет ресурсоемкое ваше решение, без машины вывода? . Это еще тот вопрос! Ведь что делает машина вывода — она реализует некоторое унифицированное действие, активацию которого вы осуществляете — по сути это кусок алгоритма по обработке онтологии (который вы не создаете)
    . Ту же функциональность вы можете получить написав некоторый (ес-но, многобольший) кусок кода. Насколько он быстрее будет, чем тот же Pellet не известно

    Кстати обращаю ваше внимание на слово унифицированное (действие), те действие, реализация которого строго определена как по сути так и по API ))

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

  5. me.yahoo.com/a/2pDbV7k3x…:

    «например, зачем статистку работы пользователей с сайтом бросать в triple store (пусть даже через маппинг)?»

    А зачем её туда «бросать»? Почему не использовать RDF View? Если есть подходящие общеупотребительные классы и предикаты, почему бы не сделать экспорт данных в этом стандартном виде?
    Тем более что написать SPARQL-запрос не дороже, чем на SQL.

  6. Написать Sparql запрос конечно не дороже SQL, вот только вероятность того, что он выполнится быстрее не велика.

    Экспорт сделать можно для внешнего использования, но зачем создавать систему, в которой внутренние связи будут неоптимизированы?

    В этом плане, почему мне нравилcя spatial в oracle —
    надо мне было делать вывод через sparql точку доступа используем sparql, надо напрямую с какими то вещами поработать, пожалуйста, PL/SQL.

    Хотя я сторонник «чистых» систем на основе онтологий (RDF,OWL и тп), где основа RDF или OWL и ничего более… но вопросы оптимизации таких систем на практике особо не решены,

    а онтологические решения на основе реляционных БД еще и дешевле получаются

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


Ответить с помощью ВКонтакте: