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