Архив января, 2009

OpenID на SHCHERBAK.NET! (Развитие ресурса)

SHCHERBAK.NET развивается, может быть не так быстро, как хотелось бы, но появляются новые идеи, люди, которые готовы внести свой вклад в развитие технологий Semantic Web.

Мне жаль, что некоторые авторы отказали мне в помощи по развитию этого ресурса

Я, конечно, все понимаю, но хочу им сказать - зря вы так - мне лично ваша информация не нужна - я и сам знаю весьма не мало по тематике Semantic Web - а русскоязычным читателям это было бы полезно!

Сайт как развивался, так и будет продолжать.

А поделиться информацией это иногда и не так уже плохо.

Кроме того, выражаю благодарность от себя тем людям, которые мои инициативы решили поддержать!

Сегодня добавил поддержку OpenID на сайт SHCHERBAK.NET.

Надеюсь теперь авторизироваться на сайте станет проще для комментирования
(особенно пользователям Живого Журнала) !

Кроме того, арендовал новый сервер для сайта SHCHERBAK.NET. Готовлюсь к переезду на новые "мощностя"!

Заметил, что по какой то причине произошел кросспостинг в ЖЖ - это недоразумение будет исправлено.

Кросспостингу я говорил и говорю нет!

Оставайтесь с нами, руководитель проекта SHCHERBAK.NET.

Служебная информация в RDF

Блуждая по Хабрахабру, наткнулся на пост, в котором авторы рассуждали на тему, как добавить информацию об авторе триплета в RDF. Идея проста - RDF представляет собой совокупность триплетов, но эти триплеты могут быть добавлены различными авторами. Вопрос: Как добавить информацию об авторе триплета. Как авторы правильно заметили, если информацию об авторе вынести в отдельное хранилище или таблицу, то проблем нет. Но что, делать, если не хочется привлекать сторонние средства? Одним из вариантов было предложено ввести свойство «hasAuthor» в корень объектной иерархии.

Но этот подход имеет свои недостатки. Представьте себе, некоторый объект, например, ягода вишня. Что у нас получается -«вишня» как экземляр класса Ягода, у которой автор Вася Пупкин - как то глупо звучит. И вообщем-то и не в Васе дело, а в том, что автор ягоды вишни Вася. Если мое рассуждение верно, тогда вынос hasAuthor в корень объектной иерархии ничего не дает, так как всегда будут существовать объекты для которых отношение hasAuthor не будет иметь смысла.

Хотя, например, в редакторе онтологий Protege есть наборы служебных классов, выполняющие подобные функции, которые не отображаются в основном дереве представления RDF

А решение задачи, как оказалось в результате моих рассуждений на Хабрахабре, очень простое.

В RDF нет языковых конструкций для установления авторства триплетов, но такие средства есть в Dublin Core.

Таким образом, рассматривая Dublin Core, как расширение RDF, мы можем легко ввести понятие авторства информации (триплета).

Вы можете сказать, а чем же отличается введение понятия авторства через Dublin Core от введения нового отношения hasAuthor?

А все просто - когда мы вводим новое отношение hasAuthor мы имеем ягоду вишню автора Васи, а при использовании дублинского ядра мы такого не имеем, как минимум потому, что у описания Dublin Core другое пространство имен и как результат описание некоторого объекта через Dublin core идет как описание объекта в некоторой другой семантической плоскости. А самое интересное - при проведении логического вывода мы не нарушим ни одного канона онтологий - ягоды будут успешно собраны и проданы потенциальному клиенту, а агенты будут также иметь возможность взглянуть на автора информации.

А может я не прав?

Комментарии в wordpress 2.7

В wordpress 2.7 появилась замечательная вещь под названием древовидные комментарии.
Это хорошо, конечно, только темы, которые у меня были на сайте, вдруг перестали работать.
Теперь необходимо потратить время на адаптацию тем под использование нового механизма комментариев.
Вроде и ничего сложного там нет, но повозиться прийдется. (

ТЕПЕРЬ СТАЛИ ДОСТУПНЫ КОММЕНТАРИИ НА СТРАНИЦАХ СО СТАТЬЯМИ!!!

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

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

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

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

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

Противоречивость и многоосновные миры

Интересный вопрос задали мне. Мои рассуждения на тему вопроса можно почитать здесь в комментариях

Пошли завершающие работы над переводом стандарта SPARQL PROTOCOL.

Следите за обновлениями на сайте