Семантика наступает на WEB…  RDFa самый простой способ внедрить семантику в веб-страницы.

Перевод стандарта RDFa можно почитать здесь.

Google станет первой машиной поиска, которая начнет учитывать семантику веб-страниц.

С этим шагом, даже те, кто относился снисходительно к технологиям Semantic Web, пересмотрят свое отношение. А те кто не захотят, потеряют прибыли. Кстати говоря, несмотря на критические замечания менеджмента Google в сторону Semantic Web, поддержка семантических технологий  у  Google появилась первой.

Думаю это может говорить о положительных тенденциях… ))

Подборка ссылок по теме от Новитского Александра:

http://googleblog.blogspot.com/2009/05/more-search-options-and-other-updates.html

http://www.jenitennison.com/blog/node/104
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=146898
http://dltj.org/article/google-rdfa/

---

Как я написал в одном комментарии:

ДА СОДРОГНУТЬСЯ ВСЕ SEOШНИКИ!
Как только семантическая разметка начнет влиять на выдачу результатов google. Все продвигаемые сайты станут семантически размечены. Скорее всего «черной» семантикой, но …прийдет «злобный» Pellet, мы к нему напишем правила фильтрации, и сделаем логический вывод и все станет «белым и пушистым»
А если это будет так, то Яндекс без поддержки семантических технологий будет выглядеть бледно. А жаль, кто-кто, а они могли бы внедрить поддержку этого формата уже давно.

Наверное все, кто читает  SHCHERBAK.NET, уже раньше встречались с этой аббревиатурой, но все же позволю себе напомнить основы.

SIOC (Semantically-Interlinked Online Communities ) – связанные семантически онлайн сообщества.  Этот словарь позволяет описывать онлайн общение (блоги, форумы, комментарии, трек-, пингбеки, etc.) семантическим образом.  

Read the rest of this entry »

Сегодня читателям SHCHERBAK.NET представляется возможность посмотреть какие языки описания графов (RDF-based) можно применять при разработке прикладного программного обеспечения. А главное, в очерке вы найдете описания фреймворков для работы с графовыми разметками.

Читать

---

Александру Качуру, студенту кафедры Информационных управляющих систем, хочу выразить благодарность за предоставленные материалы.

Александр Качур

Как известно граф — это совокупность объектов со связями между ними.

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

Задача возникла в контексте проблемы визуального представления сети. От формата ожидалась возможность описания помимо топологии сети, еще и некоторых составных элементов рабочих станций. Идеальным для этой цели стал RDF-based формат NDL (http://www.science.uva.nl/research/sne/ndl).

NDL — Network Description Language, по сути является онтологией для описания компьютерных сетей.

NDL представляет собой совокупность пяти ключевых структур.

Topology schema — структура для описания устройств (рабочих станций), сетевых интерфейсов и соединений между ними. Также в этой структуре определен класс Location, определяющий месторасположение устройства.

Layer schema — абстрактная структура для описания специфических сетевых технологий и взаимосвязью между сетевыми уровнями.

Сapability schema —  структура служащая для описания совместимости устройств.

Domain schema  – описывает область администрирования(домен), сервисы в этой области, а также логическое представление данного сегмента сети, входящего в домен.

Physical schema — описание физических аспектов сетевых элементов, а также составных частей этих элементов.

Ниже представлена UML диаграмма классов данных структур.



Но в связи со сложностью работы с сетями, описанными с помощью NDL, пришлось продолжить поиск, и  следующим рассмотренным форматом стал DOT.

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

Неориентированный граф

graph graphname { a — b — c; b — d; }

Ориентированный граф

digraph graphname { a -> b -> c; b -> d; }

Конечно, данные примеры являются по сути «Hello world»-графами, но принцип описания узлов и связей между ними они отображают в полной мере. Для описания топологии данный формат подходит отлично, являясь простым и «обезжиренным». Набор атрибутов, применимых к объектам графа, предельно лаконичен ну и реализация API для работы с ним не представляет особого труда, в отличие от громоздкого NDL. Однако DOT не предоставляет возможности пользователю описывать и добавлять собственные параметры к ребрам и вершинам, что является серьезным минусом в контексте рассматриваемой проблемы.

Этого недостатка лишен формат GraphML, идущий следующим в данном обзоре, который сочетая простоту описания графа предоставляет удобный механизм расширения собственными свойствами.

GraphML — это формат описания графов основанный на XML. GraphML – полнофункциональный и удобный в работе файловый формат для описания графов. Он включает базовый язык предназначенный для описания структурных свойств графа и гибкий механизм расширения его расширения, что позволяет включать в описание графа данные специфичные для приложений.

GraphML включает поддержку направленных, ненаправленных, и смешанных графов, гиперграфов, иерархических графов, описание графического представления, ссылок к внешним данным, специфических для приложения атрибутов, и облегченного синтаксического анализатора.

В отличие от многих других форматов описания графов, GraphML не использует специфический синтаксис. Вместо этого он использует синтаксис основанный на языке XML, и следовательно идеально подходит в качестве универсального средства для формирования, архивирования, или обработки графов.

Примитивный граф с двумя вершинами и ребром между ними выглядит так:

<?xml version="1.0" encoding="UTF-8"?>

<graphml xmlns="http://graphml.graphdrawing.org/xmlns"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns

     http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd">

 <graph id="G" edgedefault="undirected">

    <node id="n0"/>

    <node id="n1"/>

    <edge id="e1" source="n0" target="n1"/>

  </graph>

</graphml>

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

Java Graph Editing Framework (GEF)

Цель проекта GEF заключается в том, чтобы создать библиотеку для редактирования графов, которая может быть использована для построения  высококачественных пользовательских приложений работы с графами. Возможности GEF:

• Простой и понятный  дизайн, который дает возможность разработчику расширять функциональность библиотеки.
• Node-Port-Edge модель представления графа, которая позволяет выполнять подавляющее большинство задач встречающихся в приложениях для работы с графами.
• XML-based формат файлов, основанный на стандарте PGML (в скором времени обещают поддержку SVG).

ILOG JViews

ILOG JViews предоставляет компоненты, предназначенные для использования в пользовательских приложениях, а также на совместно с Ajax и платформой Eclipse.

Java Universal Network / График Framework (JUNG)

JUNG  - это программная библиотека, которая предоставляет удобный и расширяемый интерфейс для моделирования, анализа и визуализации данных, которые могут быть представлены в виде графа или сети. Он написан на Java, что позволяет JUNG-приложению использовать в полной мере Java API, а также сторонние библиотеки. Являясь open-source библиотекой, JUNG представляет собой фреймворк для анализа и визуализации, как графов так и  сетей.

JGraphT является свободно распространяемой библиотекой, которая обеспечивает математический аппарат теории графов. JGraphT поддерживает различные виды графов, включая: ориентированные и неориентированные графы; графы со взвешенными / невзвешенный / именованными или любым другим форматом ребер определенным пользователем; не модифицируемые графы – обеспечивается доступ в режиме «только чтение» к внутренним графам; listenable графы – разрешает внешним слушателям отслеживать возникновение событий; подграфы – графы, которые являются представлением других графах.

JGraphT являясь мощным средством, разрабатывался как простое и type-safe (с использованием Java кодогенераторов) средство для работы с графами. Например, вершиной графа может быть любой объект. Вы можете создавать графики на основе: строки, URL, XML документов и т.п., вы можете даже создавать графы графов.

Вот еще некоторые из визуализационных фреймворкков для Java – Piccolo, Processing, The Visualization Toolkit (VTK), JUNG, The InfoVis Toolkit, Improvise.

Наиболее интересным на мой взгляд средством визуализации графов является проект под названием prefuse, разработанный в Berkeley.

Prefuse изначально разрабатывался как фреймворк  для создания интерактивных приложений визуализации информации с использованием языка программирования Java. Prefuse flare предоставляет собой средство для анимации с помощью ActionScript Adobe Flash Player.

Prefuse поддерживает богатый набор функций для передачи данных моделирования, визуализации и взаимодействия. Она предоставляет оптимизированные структуры данных для представления таблиц, графиков, а также деревьев, поддержку анимации, динамические запросы, комплексный поиск и подключение базы данных. Prefuse написан на Java, с использованием Java 2D графической библиотеки, и легко интегрировать в Java Swing приложений или веб-апплеты. Prefuse лицензируется по условиям лицензии BSD, и могут свободно использоваться как для коммерческих и некоммерческих целях. Он может быть использована для создания обычных приложений, визуальных компонентов, встроенных в более крупных приложений и веб-апплеты. Prefuse является гибким средством визуализции данных, существенно упрощающий процесс отображения данных на их визуальное представление, а также взаимодействия с данными.

API Рrefuse’a работает с такими форматами данных как GraphML, TreeML. Существует также поддержка простых типов представления данных таких как CSV и возможность получения данных напрямую из таблиц баз данных.

Таким образом можно сделать заключение о преимуществах и недостатках каждого варианта представления графа.

NDL — мощнейшее узкоспециализированное средство для представления сетей. Является RDF онтологией и позволяет детальнейшим образом описать компьютерную сеть.

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

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

Ув.  читатели  сайта SHCHERBAK.NET, в переводе стандарта языка SPARQL исправден ряд ошибок как синтаксических, так и смысловых.

Обязательное обновление!

Кроме того, в переводе по рекомендации Павла Клинова заменен термин «пустая вершина» на «безымянную вершину».

PS. Это не последняя версия перевода, это скорее предпоследний релиз-кандидат перевода. Кроме того, ожидается в ближайшем будущем исправление ошибок и в других моих переводах. Следите за обновлениями!

На странице переводов стал доступен перевод рекомендации W3C «Язык запросов SPARQL для RDF».

Таким образом, читатели SHCHERBAK.NET, могут получить доступ к важной подборке переводов нормативных документов W3C, а именно к рекомендациями RDFa, SPARQL, SPARQL PROTOCOL и черновику рекомендации OWL 2.
Read the rest of this entry »

Рабчевский Евгений

Пермский Государственный Университет

Введение

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

Однако задачи пользователей требуют более систематизированного и настраиваемого механизма интеграции распределенных и разнородных знаний в целостную картину предметной области.

Необходимо заметить, что оригинальная спецификация WWW [1] разрабатывалась именно для решения задачи интеграции научных материалов.

Очевидно, что для эффективной интеграции данных некой предметной области из различных Интернет источников, соответствующее приложение должно работать с семантикой веб ресурсов. В этой связи, в таких приложениях актуально использование различных технологий Semantic Web [2].

Стандарты Semantic Web

В Интернет используется множество языков представления данных, основанных на XML. В рамках проекта Semantic Web, для представления данных, имеющих графовую структуру, консорциум W3 разработал язык RDF (Resource Definition Framework – Среда Описания Ресурса). RDF предоставляет средства для записи триплетов, троек данных – субъект – предикат – объект. Объект и субъект соответствуют узлам графа, а предикат или свойство – направленной дуге графа. Дуга направлена от субъекта к объекту. Каждый из элементов триплета называют RDF ресурсом и идентифицируют с помощью URI идентификаторов.

Платформа RDF активно используется для представления различных данных, в частности RSS 3.0 агрегаторы новостей собирают информацию в формате RDF.

Для машинного представления различных предметных областей в Интернет, используются онтологии и словари. Онтология – спецификация концептуализации [3], или явное, формальное описание предметной области. Как и в объектно-ориентированном описании, онтология состоит из классов и их экземпляров. У классов и экземпляров выделяются свойства, на свойства могут накладываться логические ограничения.

Поисковой системой SWOOGLE [4] на сегодня проиндексировано свыше 10 тысяч онтологий и словарей, доступных в Веб. Онтологии используются научными сообществами – для описания терминологии [5], в электронной коммерции – для описания товаров и услуг [6], и в других приложениях Интернет. Из-за своей популярности онтологии стали использоваться и в качестве баз знаний локальных интеллектуальных систем.

Для описания онтологий, доступных через Веб, созданы языки RDFS [7] (RDF Schema – RDF Схема) и OWL [8] (Ontology Web Language – Язык Сетевых Онтологий). В качестве своих базовых элементов данные языки используют RDF ресурсы. RDFS используется для записи словарей, а OWL – онтологий. Сетевые онтологии предоставляют более выразительные возможности по сравнению с RDF словарями, например логические операции над классами и логические ограничения свойств.

Постановка задачи

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

Базовой является задача разработки алгоритма автоматического построения семантической карты веб ресурса с помощью анализа его текста. Семантической картой ресурса назовем отображение контента Веб ресурса в концептуализацию его содержания, представленную в виде OWL онтологии.

Для решения данной задачи был сформирован корпус англоязычных текстов, относящихся к теме Semantic Web.
Ресурсы корпуса представляют собой спецификации технологий Semantic Web с сайта
W3 консорциума.

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

Построение семантической карты ресурса

Семантическая карта ресурса строится на основе особенностей языка, которые позволяют вытягивать семантические конструкции из текста. Исследования проводились следующим образом:

1. формировался набор пар «текст – конструкция языка OWL»;

2. по набору выявленных пар «текст – OWL конструкция» выявлялись правила, позволяющие автоматизировать процесс отображения текста в соответствующую OWL конструкцию;

Семантическая карта строится в два этапа, на первом строится формальная семантическая OWL конструкция, на втором происходит привязка полученной конструкции к конкретной предметной области.

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

Рассмотрим несколько правил:

1. «Сложный предмет» или «noun1 + noun2» (два подряд идущих существительных),
например словосочетание «ontology editor».

Проанализируем данный пример. Можно предположить существует целый класс абстрактных редакторов – Editor. Этот класс характеризуется тем, что все его экземпляры обладают неким характерным для этого класса свойством. В данном случае, это то, что они все что-либо редактируют. Назовем это характерное свойство mainPropertyOfEditor. Доменом этого свойства является класс Editor. Определим диапазон этого свойства, как класс RangeOfMainPropertyOfEditor. Выделим класс OntologyEditor, который будет подклассом класса Editor. При этом значение свойства mainPropertyOfEditor для подкласса OntologyEditor имеет строго определенное значение – экземпляр класса RangeOfMainPropertyOfEditor, индивид Ontology. Данные утверждения можно представить следующим OWL кодом:

<owl:Class rdf:ID=»Editor»> <rdfs:comment rdf:datatype=»http://www.w3.org/2001/XMLSchema#string»>класс абстрактных редакторов</rdfs:comment>

</owl:Class>

<owl:Class rdf:ID=»RangeOfMainPropertyOfEditor»><rdfs:comment rdf:datatype=»http://www.w3.org/2001/XMLSchema#string»>диапазон характерного свойства реадактора (редактируемый объект)</rdfs:comment>

</owl:Class>

<owl:Class rdf:ID=»OntologyEditor»>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty>

<owl:ObjectProperty rdf:ID=»MainPropertyOfEditor»/>

</owl:onProperty>

<owl:hasValue>

<RangeOfMainPropertyOfEditor rdf:ID=»Ontology»/>

</owl:hasValue>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:comment rdf:datatype=»http://www.w3.org/2001/XMLSchema#string»

>класс редакторов онтологий</rdfs:comment>

<rdfs:subClassOf rdf:resource=»#Editor»/>

</owl:Class>

<owl:ObjectProperty rdf:about=»#MainPropertyOfEditor»>

<rdfs:domain rdf:resource=»#Editor»/>

<rdfs:range rdf:resource=»#RangeOfMainPropertyOfEditor»/>

<rdfs:comment rdf:datatype=»http://www.w3.org/2001/XMLSchema#string»

>характерное свойство редактора (редактирует)</rdfs:comment>

</owl:ObjectProperty>

2. «Предмет с определением» или «adjective + subject», например словосочетание «abstract syntax». Для записи соответствующего OWL кода необходимо провести рассуждения, аналогичные приведенным в предыдущем примере.

3. Простое предложение, subject1 + verb + preposition + subject2 (подлежащее, сказуемое, предлог, дополнение), например «Ontology’s incorporate information about

4. subject1 + are + subject2 + that + verb + preposition + subject3 (подлежащее, are/is, дополнение, that, сказуемое, предлог, дополнение), например предложение «Decision Engineering is an emerging discipline that focuses on developing tools».

Отдельно выделяются правила, которые сами не строят семантическую конструкцию, но определяют, каким образом (к каким словам) применять правила, непосредственно выявляющие семантические конструкции. Например, правило «Если сложный предмет состоит из трех и более простых, то нужно применять правило «noun1 + noun2» начиная с конца».

Рассмотрим правило из примера 2, в котором по аналогии с примером 1 были бы введены свойство mainPropertyOfAbstract и класс RangeOfMainPropertyOfAbstract. Данные конструкции введены чисто формально, используя некие законы языка, однако данное свойство и класс имеют определенную семантику. Так определение Abstract характеризует некую особенность предмета Syntax. В данном случае эту особенность можно назвать, например как «степень детализации».

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

Задача преобразования формальных семантических конструкций в конструкции, привязанные к семантике конкретной предметной области, на данный момент автором не решена. Автор считает, что для решения данной задачи требуется источник знаний со структурой подобной таблице, приведенной ниже:

Слово	Характерное свойство
Abstract	Степень детализации
Editor	Редактирует

Предполагается представить данный источник знаний в виде RDF представления WordNet подобного ресурса [9] компьютерной лингвистики.

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

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

Онтология «Semantic Web»

Для оценки метода автоматического построения онтологии авторы создают онтологию предметной области «Semantic Web» без средств автоматизации. Онтология создается на основе того же корпуса англоязычных  тестов, из которого выявляются правила построения семантической карты ресурса. Тексты корпуса исследовались следующим образом:

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

- каждое понятие дополнялось экспертным определением;

- выявлялись триплеты, содержащие найденные понятия;

- для каждого понятия и триплета фиксировался ресурс-источник.

Для оценки программной реализации метода автоматического построения онтологии предполагается обработать исследуемый корпус полученным программным средством и сравнить результаты с онтологией, полученной ручным способом. Создан RDF словарь для хранения результатов ручной разработки онтологии. Словарь представляет собой модель для хранения понятий с их определениями, триплетов и оригинальных источников понятий и триплетов.

Семантическая разметка,  RDF/A, GRDDL

RDF графы и онтологии на их основе могут размещаться в отдельных Веб ресурсах, например файлах или RDF хранилищах, доступ к которым осуществляется через RDF сервера. Также  RDF графы могут встраиваться в другие XML документы, например в XHTML. Встраивание RDF данных в XHTML используется для спецификации семантики (семантической разметки) контента.

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

Рабочая группа развертывания Семантического Веба W3 консорциума разработала технологию RDF/A [10], которая позволяет встраивать RDF данные в XHTML. RDF/A является одним из множества микроформатов [11] или диалектов языков, расширений языка HTML, в котором определяется, каким образом использовать конструкции языка HTML, чтобы интерпретировать записанный таким образом HTML код, как RDF данные.

Существуют микроформаты для записи таких словарей, как vCard, DC, RDF Calendar, RSS, GeoInfo. Все указанные словари записываются в виде RDF графов, RDF/A является микроформатом для записи непосредственно RDF синтаксиса, и может быть использован для записи терминов любых RDF словарей, например тех же vCard, DC, RDF Calendar, RSS, GeoInfo.

Ниже следует пример использования терминов словаря набора данных DC (словарь DC описывает мета свойства электронных документов) в XHTML.

<head profile=»http://www.w3.org/2003/g/data-view»>

<link rel=»schema.DC» href=»http://purl.org/dc»/>

<meta name=»DC.Title» xml:lang=»en» lang=»en» content=»Использование терминов словаря DC в XHTML коде» />

</head>

Данный XHTML соответствует триплету субъектом которого является URI самого ресурса, предикатом – свойство Title, описанное в словаре DC по адресу http://purl.org/dc, объектом – строка «Использование терминов словаря DC в XHTML коде». Вставка такого RDF триплета в заголовок HTML страницы позволит соответствующим приложениям понять, что название документа – «Использование терминов словаря DC в XHTML коде». При этом это название может отличаться от того, которое представлено пользователю с помощью тега <title>. Таким образом, в XHTML можно вставлять любые RDF графы. Использование профиля profile= необходимо для возможности указания значения «transformation» у тега rel, что необходимо для указания ссылки на механизм GRDDL извлечения (см. следующий абзац).

Для извлечения RDF данных из различных микроформатов W3 консорциум разработал технологию GRDDL [12] (Gleaning Resource Descriptions from Dialects of Languages – Извлечение Описания Ресурса из Диалектов Языков). Для работы GRDDL-скреперов (программ, извлекающих RDF данные из XHTML) в XHTML коде необходимо указать ссылку на механизм извлечения:

<link rel=»transformation» href=/>

Механизм извлечения основан на технологии преобразования XML документов XSLT[18], в данном случае XHTML преобразуется в RDF.

Литература

1. Tim Berners-Lee, World Wide Web: Proposal for HyperText Project. 1990. //http://www.w3.org/Proposal.html

2. Сообщество Semantic Web // http://www.w3.org/2001/sw

3.Gruber, T.R. (1993) A translation approach to portable ontology specifications. Knowledge Acquisition. Vol. 5.

4. Swoogle – Semantic Web Search Engine. // http://swoogle.umbc.edu/

5.Е.М. Бениаминов  «Алгебраические методы в теории баз данных и представлении знаний». М.: Научный мир, 2003.

6.Реестр товаров и услуг ООН. // http://www.unspsc.org/.

7.RDF Schema 1.0, Язык описания RDF словарей. Рекомендация W3C 10 Февраля 2004. // http://www.w3.org/TR/rdf-schema/

8. Язык OWL. // http://www.w3.org/2004/OWL/

9. RDF/OWL представление WordNet, Рабочий документ W3C 19 Июня 2006 http://www.w3.org/TR/wordnet-rdf/

10. Встраивание RDF в XHTML RDFa. Рабочий документ W3C 12 марта 2007. //http://www.w3.org/TR/xhtml-rdfa-primer

11. Сообщество пользователей микроформатов. http://microformats.org/

12. Рабочая группа GRDDL http://www.w3.org/2001/sw/grddl-wg/

Ув. читатели SHCHERBAK.NET, вашему вниманию предлагаются материалы статьи «Semantic Web как новая модель информационного пространства Интернет» авторов  Ф.И. Андон, И.Ю. Гришановой и В.А. Резниченко.

В этой статье описаны базовые концепции и архитектура Semantic Web, а также положение дел по разработке данного проекта по состоянию на конец 2007 года. Выделены проблемы, которые стоят перед мировым сообществом для дальнейшего развития Semantic Web.

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

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

От имени читателей SHCHERBAK.NET хочу выразить благодарность  Ирине Гришановой за предоставление материалов интересной статьи!

В продолжение заметки о семантических плагинах FireFox…

Итак, чем радует нас Mozilla Foundation в семантической сфере:

FOAFox 0.2.1 – плагин для обнаружения профилей FOAF на веб-страницах. Напомню, FOAF – акроним понятия Friend-of-a-Friend – RDF/XML формат для описания людей и их взаимоотношений в Semantic Web.

Внедренный в веб-страницу профиль FOAF можно с помощью этого плагина просмотреть через HTML-интерфейс.

Semantic Turkey 0.6.5 – семантический «закладочник»(Semantic Bookmarking tool) и средство разработки онтологий. С одной стороны, это исследовательский проект  ART Research Group, позволяющий создавать онтологии на языках RDF/RDFS и OWL. С другой стороны, с помощью этого плагина можно сформировать онтологию на основе информации о посещенных веб-страницах. Кроме того, есть средства для экспорта полученных онтологий. Среди недостатков, отмечу следующее – несмотря на то, что плагин, ориентирован на использование в  Firefox, домашняя страница этого плагина в  FF нормально не отображается – пришлось заходить на сайт через Safari. Далее, плагин очень интересный, но текущая функциональность скромна ( даже до возможностей редактора онтологий Protege бежать еще и бежать)  и чувство недоделанности проекта не покидало меня на протяжении всего знакомства с плагином. Обратить внимание на этот плагин стоит обязательно, но мой вывод – надо подождать релиза! А так, конечно, must have!

Headr surf tool 0.0.1.21 – инструмент для семантического серфинга – дополнительная панель инструментов для Firefox (сходу минус проекту – ну нельзя иметь в одном маленьком файрфоксе десяток панелей инструментов). Тем более задача плагина анализировать просматриваемые веб-страницы с целью рекомендации для прочтения связанных по смыслу веб-страниц и сайтов.  Я считал и считаю, что такие инструменты должны вызываться по нажатию кнопки на стандартной панели инструментов( или в статус баре), как, например, Zotero – почему-то о потенциальных пользователях разрабытываемых средств никто не хочет думать – а ведь для них все делается! Как результат – эта панель инструментов надоела мне через пять минут и была отключена. Но в идее этот семантический проект интересен.

Google Semantics 2.2.  – легкий способ получить синоним для ключевых слов через Google – этот плагин позиционируется как средство для поисковой оптимизации – общем для улучшения SEO необходим.

The Data Browser Extension 0.8.7 -  средство для табличного отображения RDF-данных (визуализация RDF в виде таблиц). Одно из лучших средств для представления «машино-понимаемых» форматов в человеко-читаемом виде.

Ontos Semantic Web Navigation Plug-in 1.0 – плагин,  делающий FireFox совместимым с Семантическим вебом. Как бы странно, это не звучало, смысл в этих словах есть – семантическая аннотация ресурсов на серверах проекта Ontos позволяет находить новую информацию об просматриваемых страницах, есть фукнция автоматической генерации семантических отчетов о ресурсах. Интересный плагин, но из серии надоедающих, при обращении к любом сайту идет запрос на сервера Ontos, что есть не очень хорошо (тотальный контроль об ваших перемещениях по Веб – оно вам нужно?). Я не хочу сказать, что проект плох. Я хочу сказать, что Семантический Веб не предназначен для увеличения контроля за его пользователями, уровень этого контроля как  раз должен уменьшиться. Я конечно, понимаю, что   тотальная слежка за пользователями есть и никуда не девается – ведь надо же адаптировать (улучшить) результаты поиска под наши потребности? – конечно надо. Кроме того, мы же повышаем уровень своей социальности. Правда этот уровень «держит за руку» мир программ, который о нас иногда знает больше чем собственно мы сами. Вот это проблема, при чем проблема, о которой буквально через 3-4 года будут все говорить, говорить, а может будут еще и кричать, только сделать уже ничего нельзя будет. Правда и сейчас нельзя ничего сделать, так как Семантический Веб стал инструментом для заработка денег, очень больших денег…

Fuzzbot 0.8.3  – еще один из плагинов для идентификации внедренной семантической информации в веб-страницы. Fuzzbot использует парсер ibrdfa для извлечения триплетов  RDF из веб-страниц. Этот плагин можно рассматривать как альтернативу SemanticRadar. Мое мнение – SemanticRadar более зрелый плагин, пока он лучший.

MozCC 2.4.3 – средство для просмотра метаданных о веб-страницах, включая информацию о лицензии Creative Commons. Метаданные, должны быть представлены на языке RDFa. Все стандартно, кроме информации о лицензии. Плюс плагина в том, что если информация о лицензии  на странице есть, то об этом отдельно будет пользователю сообщено!

И, напоследок, скажу – Файрфокс, как был самым семантическим браузером, так и остался!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом разделе я планирую выставлять мои переводы на русский язык различных стандартов и черновиков W3C.

Для начала Вашему вниманию предлагается перевод чернового варианта стандарта W3C «Язык Web-онтологий OWL 2: начальное руководство».

Перевод доступен здесь!

---

Перевод Заметки рабочей группы W3C от 14 октября 2008 «Начальное руководство по RDFa».

Перевод доступен здесь!

---

Рекомендация W3C «Протокол SPARQL для RDF» от 15 января 2008. «Оригинальная версия».

Перевод доступен здесь!

---

Рекомендация W3C «Язык запросов SPARQL для RDF» от 15 января 2008. «Оригинальная версия».

Перевод доступен здесь!

---

Не забывайте о правилах использования материалов сайта SHCHERBAK.NET!

Буду очень благодарен, если ВЫ в комментариях напишите свое мнение по поводу перевода (качественный перевод получился или нет, есть ли ошибки, если есть, то какие?).

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

Заранее спасибо

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

Cначала давайте определимся, что будем понимать под приложением Semantic Web.

Итак, если приложение построено с использованием таких средств Semantic Web, как XML,  RDF, OWL, SPARQL, то такое приложение будем называть приложением Semantic Web первого типа.

В случае, если приложение реализует идеи Semantic Web, как концепции,  тогда такое приложение назовем приложением Semantic Web второго типа.
Read the rest of this entry »

== Семантическая Паутина. Часть 1 ==

Жишкевич Николай

Прогресс в IT похож на морские приливы: сначала волна энтузиазма штурмует берег обыденности и коммерческой целесообразности. Затем, будучи не в силах удержаться, волна отходит назад, с тем, чтобы набраться сил и спустя некоторое время попробовать еще раз захватить плацдарм. Сегодня я хочу поговорить о Семантической Паутине и микроформатах.

В начале 2000-ых годов я впервые услышал о идее которую пропагандировал Тим Бернерс-Ли. Это была идея Семантической Паутины (Semantic Web) и о том как она изменит привычный нам internet. Не секрет, что с самых первых дней развития internet предпринимались попытки создать такой способ представления информации в ней, чтобы указывать на ее логическое значение. Указать, что же хранится в том или ином абзаце или таблице. Придумали теги, такие как STRONG, EM – они должны были играть роль указателей на то, что какие-то части веб-страницы имеют более важное значение, дать акцент на них. Или, например, тег CITE, который должен был служить для хранения цитат или сносок на другую информацию. Тег ACRONYM мог бы указать на … акронимы. Или тег ADDRESS, который должен был бы хранить информацию об авторе документа. Все эти теги не только имели особые шрифты или отступы, но, прежде всего, должны были дать больше “информации об информации” поисковым машинам и браузерам. А теперь, положа руку на сердце, признайтесь, кто из вас слышал и тем более использовал эти возможности? Во всевозможных книжках про веб-программирование и верстку говорят, прежде всего, о том, как создать какой-то красивый эффект, о том, как сделать, чтобы что-то мигало, вертелось и двигалось. Все теги, о которых я упомянул выше (EM, CITE, ACRONYM), пали жертвой ряда обстоятельств: отшумевшая война браузеров, слабые визуальные возможности html заставляли использовать эти теги, прежде всего, для визуального оформления, не обращая внимания на их логический смысл. Эти теги были первой робкой попыткой сделать internet более целостным, что же … покойтесь с миром. Первоначальный этап, когда при разработке сайтов говорили только о его визуальном наполнении, картинках, flash-роликах прошел. Конечно, и сейчас визуальное оформление является важнейшим фактором, но по мере увеличения количества людей постоянно пользующихся internet-ом, ростом широкополосных сетей, бумом социальных сетей, с тем как internet становится все более близким для “домохозяек” и появлением новых моделей коммерции в internet, произошел возврат к старым идеям и попытка их реализовать на новой технологической базе.

Read the rest of this entry »

Браузер Firefox имеет ряд плагинов для идентификации и просмотра семантической разметки на web-страницах.
Наиболее полезными, на мой взгляд, являются плагины:

SemanticRadar -  плагин, предназначенный для автоматической идентификации внедренного RDF в страницу HTML. В случае, обнаружения FOAF (Friend-Of-A-Friend),  SIOC (Semantically-Interlinked Online Communities),  DOAP (Description Of A Project),  RDFa (RDF embedded in XHTML) плагин выведет соответсвующую иконку в статус-баре браузера…

Operator - плагин для определения и обнаружения микроформатов.

Tabulator -  плагин для просмотра и анализа связанных с web страницей семантических данных.

RDFa – плагин для автоматической идентификации RDFa на web-страницах с возможностью извлечения через PyRDFa.

RDF Viewer – навигатор по структуре RDF.

Semantic Radar, Operator и Tabulator работают с Firefox 3.  Остальные можно пытаться запустить с помощью MR Tech Toolkit.

Отдельно, нужно сказать о плагине Blue Organizer (smart browsing) . Однако, на момент написания заметки страница плагина не была доступна. Так что об этом позже!