Связь Semantic WEB и WEB 2.0 с передачей данных о состоянии (REST)
Ключевые слова - Семантический Web, web-2.0, Representational State Transfer (Передача данных о состоянии), Веб сервисы.
Аннотация
Технологии семантических сетей должны объединится с WEB 2.0 для сочетания сильных сторон обеих концепций. Полагаем, что REST-образные методологии проектирования [2] в Интернете идеальный механизм, с помощью которого можно согласовать публикацию семантических данных с существующей архитектуры сети. Мы представляем проектирование и реализацию обеих решений, которые сочетают REST методологии и RDF [3] доступ к данным: одно решение для интеграции существующих веб-сервисов и другое, для серверной стороны RDF REST сервисов. Оба этих решения основаны на SPARQL [18], обеспечивающем унифицированный слой доступа к данным для взаимодействия семантического веба и Web 2.0.
Термины:
1. REST - архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF. В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов. Если SOAP-клиенты запрашивают выполнение действия на сервере, то REST-клиенты попросту требуют сам ресурс. Например, вместо того чтобы запрашивать удаленное исполнение функции для нахождения нужного вам формуляра заказа, вы просто запрашиваете этот формуляр, примерно так же, как статичную Web-страницу.
2. Семантический WEB - часть глобальной концепции развития сети Интернет, целью которой является реализация возможности машинной обработки информации, доступной во Всемирной паутине. Основной акцент концепции делается на работе с метаданными, однозначно характеризующими свойства и содержание ресурсов Всемирной паутины, вместо используемого в настоящее время текстового анализа документов. Термин впервые введён сэром Тимом Бернерсом-Ли в мае 2001 года в журнале «Scientific American», и называется им «следующим шагом в развитии Всемирной паутины». В семантической паутине предполагается повсеместное использование, во-первых, универсальных идентификаторов ресурсов (URI), а во-вторых — онтологий и языков описания метаданных. Эта концепция была принята и продвигается Консорциумом W3C. Для её внедрения предполагается создание сети документов, содержащих метаданные о ресурсах Всемирной паутины и существующей параллельно с ними. Тогда как сами ресурсы предназначены для восприятия человеком, метаданные используются машинами (поисковыми роботами и другими интеллектуальными агентами) для проведения однозначных логических заключений о свойствах этих ресурсов.
3. WEB 2.0 - термин, обозначающий следование интернет ресурса определенным правилам организации интерфейса взаимодействия с пользователем, требующий использования AJAX технологий. Отличается от WEB 1.0 наличием семантической и социальной составляющей.
4. RDF (Resource Description Format/Resource Description Framework) - это разработанная консорциумом W3C модель для описания ресурсов, в особенности — метаданных о ресурсах. В основе этой модели лежит идея об использовании специального вида утверждений, высказываемых о ресурсе. Каждое утверждение имеет вид «субъект — предикат — объект» и в терминологии RDF называется триплетом. Например, утверждение «Небо голубого цвета» в RDF-терминологии можно представить следующим образом: субъект — «небо», предикат — «имеет цвет», объект — «голубой». Для идентификации субъектов, предикатов и объектов в RDF используются URI (англ. Uniform Resource Identifier). Одной из главных целей RDF является предоставление утверждений одинаково в машинно- и человеко-распознаваемом виде. Существует несколько синтаксисов для представления RDF-информации, самые распространённые из которых: RDF/XML, триплеты (Нотация 3) и графовая модель. Для обработки RDF имеется несколько языков запросов: например, RQL, RDQL, SPARQL
5. SPARQL - (рекурсивный акроним, SPARQL Protocol and RDF Query Language) - разрабатывающийся стандарт семантической сети, проходящий стандартизацию RDF Data Access Working Group (DAWG) консорциума World Wide Web (W3C). Фактически, язык запросов аналогичный SQL, но для RDF.
6. URI - (англ. Uniform Resource Identifier) — единообразный идентификатор ресурса. На английский манер произносится как [ю-ар-а́й], по-русски чаще говорят [ури́]. URI — это короткая последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.
7. mash-up - концепция построения веб-приложений путем комбинирования функциональности различных программных интерфейсов и источников данных.
Введение
Веб 2.0 и сообщество семантических сетей поддерживают различные стратегии в достижении аналогичной цели - взаимосвязанные Интернет данные о том, что раскрывает информацию для легкой обработки, интеграции и повторного использования. Направленность на удобство использования, которая движет Web 2.0, привела к целой новой экономике веб-сайтов и mash-up'ов за последние несколько лет, но отсутствие семантического описания данных в Web 2.0 поставило на низкий уровень "автоматизированные" способности этих сайтов (очевидно обработки данных). Каждый новый mash требует ручной настройки каждого используемого сервиса.
В семантическом веб решены многие проблемы. Форматы такие, как OWL [16] и RDF помогают семантически описать и согласовать данных из различных источников, но отсутствие методов использования и согласования доступа к данным не позволяют широко использовать такие данные. Обе дисциплины нужны друг другу для реализации их конечных целей. Web 2.0 имеет большой объем данных, но и бедную и сложную семантику интеграции. В семантическом Web решается проблема интеграции, но это также и причина нехватки пользователей (в сравнении с WEB 2.0).
Идеальное решение объединит две дисциплины, в местах их соприкосновения. Существующие веб-сайты смогут взаимодействовать с OWL и RDF данными одновременно, а также выступать в качестве точек доступа для семантических сетей клиентам или архитектуре запросов (видимо как RDF). Этот документ показывает, что такая корректировка не только возможна, но это может быть достигнута с помощью RDF (REST) методологии разработки взаимосвязи между Web 2.0 разработчиками сегодня.
Сначала проверим REST методологию и докажем, что REST-конструкции являются основополагающими для реализации технологий Web 2,0 и естественно, пригодны для Семантических WEB-сервисов. Затем мы представим нашу разработку и реализацию двух бесплатных стратегий REST взаимодействия семантического Web и Web 2.0. Первый - семантический "мост" для веб-сервисов использует семантические теги на традиционном SOAP и конечные точки для REST позволяют их включать в семантические запросы. Второй, семантический REST, определяет стандартный путь, через который REST на базе ресурсов Web 2.0 можно формировать запросы в RDF наряду с существующей HTML, XML и JSON выдачами. Наконец, мы покажем пример интеграции этих методов при выполнении распределенных запросов к источнику данных, с использованием как семантического подхода для веб-сервисов так и семантического REST.
Разработка для WEB основанная на REST
REST - это шаблон использования ресурсов, который является стандартом де-факто для разработки в концепции Web 2.0. Если традиционный SOAP подход к Web Servic'ам использует полномасштабные удаленные вызовы удаленных объектов, методов и ориентирован на функциональность, сосредотачиваясь только на структуре данных и передачи состояния данных. REST благодаря своей простоте более подходит HTTP. Это способствовало приобретению его статуса - главного метода выбора данных в Web 2.0.
Ресурсы в REST- службах доступны или размещается по URL-адресу, который обычно принимает форму:
ResourceURL ::= Protocol://Host/ApplicationPath/ResourceType/ResourceID
Комбинация протокола, хоста и пути приложения служит в качестве пространства имен для всех ресурсов, содержащихся на сайте. Тип ресурса и ресурс-ID однозначно идентифицируют принадлежность конкретного ресурса в пространстве имен. Операций над метаописанием ресурса, то есть «тип ресурса» доступны на URL выше без ResourceID на конце. Таким образом, новый пользователь на сайте semwebcentral.org будет создан с использованием URI http://www.semwebcentral.org/user и конкретного пользователя можно будет получить через http://www.semwebcentral.org/user/ogrouch, где "ogrouch 'это пользовательский ID.
В основе REST конструкции - набор операций по передаче данных о состоянии универсальный для любых данных и любых способов хранения и поиска этих данных. Эти операции, как обычно определены в Интернете, как говорится в акрониме CRUD [11] - "Создать, Прочитать, Изменить, Удалить". Web-2.0 сообщество приняло неофициальный вариант CRUD операций основанный на командах, HTTP протокола: POST, GET, PUT и DELETE соответственно. Эти команды идентификации конкретной операции CRUD прописаны в заголовке запроса ресурса по URL.
В таблице 1 представлена проекция CRUD операций на HTTP запросы. Важно отметить, что REST не является стандартом W3C, в привычном смысле этого слова, но метод активно используется по всей сети.
Хотя в таблице ниже представлено наиболее широко используемое применение REST в Интернете, это не единственное толкование.
CRUD Operation HTTP Command Input Format Output Format
Create POST HTTP Form Encoded Status 201 CREATED
Read GET None Determined by request headers
Update PUT HTTP Form Encoded Status 200 OK
Delete DELETE None Status 200 OK
Минус в данном подходе отказ некоторых общественных маршрутизаторов направлять HTTP DELETE запросы. Решить проблему можно с помощью пересылки этой конкретной команды как URLencoded-запроса с аргументом или суффиксом. Следующий пример [11]:
GET http://www.semwebcentral.org/user/ogrouch; delete
Основное преимущество REST ориентированных web-приложений является возможность использования HTTP заголовка для обеспечения связи в запросе каждой из CRUD операций. Запрос к конкретному ресурсу может возвращать HTML, XML или JSON зависимости от типа носителя и передается в заголовке HTTP. Это дает разработчикам возможность наложения на программы API для web-сайта непосредственно в верхней части сайта. Эта API удобна для web-пользователей и снижает стоимость и сложность предоставления различных форматов доступа к сайту для получения исходных данных. Основываясь на контексте представленной HTTP проекции, web-сайт действующий в рамках REST принципов может рассматриваться в качестве web-access API. Вызов в этом API описывается в кортеже: (URL ресурса, HTTP директива, Заголовок запроса).
Использование REST- ориентированного подхода
REST ориентированное проектирование имеет решающее значение для web-2.0, поскольку она представляет собой единый способ организации доступа к данным и более независимо от среды, благодаря чему мы имеем большое количество mesh’up’ов и Ajax-приложений. С дизайн точки зрения, этот подход состоит из двух основных принципов:
• Каждый user-facing (человеко-понятный) компонент приложения моделируется как ресурс
• Каждый ресурс в web-приложении определен и доступен через URL
Эти два принципа имеют тонкие, но далеко идущие последствия, которые весьма обнадеживают и позволяют совместить 2.0 Web-сайты. В приложении обмена фотографиями, например, фотография, не помечена (глагол), но имеющая, тег «новая» (существительное) создает ресурс. Поскольку тег моделируется как ресурс, а в действии, она может быть описана в число декларативный форматов и использоваться на других сайтах. Ресурсы на основе выше оговоренных принципов, являются наложением на верхнюю часть URL структуры – это делается для удобства чтения пользователями Интернета, создания предсказуемой и определенной структуры. Так называемый, само документируемый API.
В REST методологию разработки также хорошо интегрируется ресурсная парадигма Semantic Web. Семантические унифицированные идентификаторы используют в качестве идентификаторов ресурсов, так что URL на основе идентификаторов REST соответствуют, естественной схеме. И Semantic Web, как REST, также рассматривается исключительно с декларативной стороны, описывающей объекты, и их состояние; нет параллельно существующей SOAP-как и удаленного вызова методов. Наконец, все общие операции по семантическому Web, за исключением запросов - это извлечение данных, включение и исключение - вот основные операции в REST системах. Из этого следует, что REST-на основе web-сайтов являются идеальным носителем семантических данных, и даже предоставляют дополнительную пользу – «resolvability» ресурсов в построении удобного HTML. Остальная часть этого документа посвящена стратегий реального использования данной теории.
Семантический мост для Web служб
Немало данных в Интернете уже могут быть получены через REST и SOAP на основе точек доступа, но эти данные не несут никакой разметки/увязки с семантическим значением данных. Предоставление такой разметки упрощает интеграцию этих web - служб с Семантическим web. Семантически правильное изъятия этих данных, однако, не подразумевает, что данные средства знают, что вы можете осуществлять поиск книг через Amazon.com Е-commerce Web-службы, если запрос потребляющий эти данные не знает, что служба возвращает книгу, и даже о том, как книги определяены.
Семантическая мост для Web Services (SBWS) [21] является инструментом Java (часть BBN asio [22] suite) мы разработали его для интеграции существующих web-служб с Semantic Web. Он выступает оберткой набора web-сервисных операций, описываемых с помощью WSDL [6] или WADL [10] документа по созданию SPARQL [18] - конечной точки для этих служб. С SBWS затем можно проанализировать SPARQL SELECT или CONSTRUCT запросы и определить, какое сочетание web-сервис операций даст на него ответ.
Семантические описания web-служб
Есть несколько механизмов добавить семантическую информацию для web-сервисов, таких как OWL-S[15] и SAWSDL [8]. Они предоставляют подробную информацию по каждому web-сервис-параметру, который описывается, как значения взятые из некоторых онтологий. При этом сочетание web-служб и семантическая разметка, SBWS может стать стандартным способом общения через web-2.0 запросы независимо от того, как эти запросы определены.
SOAP и WSDL
SBWS может быть сконфигурирован для запроса SOAP Web сервиса [4] с комбинацией в WSDL документ, описывающий работу службы и OWL-S документ, описывающий службу семантики из компонентов WSDL. И OWL-S документ разметки каждой операции и сообщений, определенных в WSDL по отношению к онтологии. Поскольку большинство web - сервисов возвращают простой старый XML, необходим переход от этого XML к RDF данным. В OWL-S документ содержит либо встроенный XSLT документа или URI документа. Это важно, поскольку семантический мост для Web сервисов может использовать только RDF данных. А точкой для дальнейшей работы SBWS может быть интеграция WSDL 2.0 [5] и SAWSDL, что обеспечит большую гибкость для SBWS и WSDL на основе web-сервисов.
Использование OWL-S с SOAP на основе web-сервисов предоставляет доступ к традиционным web-сервисам. SOAP, тем не менее, не вполне согласуется с REST принципами web-2.0; он имеет один пункт назначения, и множество действий на конечной точке, в то время как REST предоставляет пункт назначения для каждого ресурса, который совершает действия. Для более тесного согласования с Семантическим Web Web-2.0, SBWS необходимо работать с REST сервисами.
REST и WADL
Хотя SOAP на основе web-сервисов есть WSDL документ, который определяет их деятельность, не существует стандартных эквивалентов REST сервисам. В качестве реализации такого описании языка SBWS функций, мы выбрали Язык Описания Приложений (WADL) от Sun Microsystems, в качестве спецификации для описания REST сервиса. WADL документ предназначен для простой альтернативы WSDL для использования в XML / HTTP Web приложениях. В нем содержится описание web-приложений в более простой форме, чем WSDL, а также определено, как генерировать URI для каждой операции, а также определен формат входных и выходных параметров. WADL не предназначен для организации семантических web взаимосвязей, в нем не содержится семантических определений операций, параметров и результатов, описанных в документе WADL. SBWS предоставляет пользовательские пояснения к WADL документу [27], так же, как и SAWSDL, который описывает семантику из REST службы. Есть три аннотации к WADL документам, которые использует SBWS для добавления семантики к вводу и выводу в REST методах: modelReference, valueProperty и schemaMapping.
"modelReference" дает аннотацию SBWS в OWL класс параметра.
"valueProperty" сообщает SBWS какие данные собственности в модели использованы в качестве значения для данного параметра.
"schemaMapping" дает аннотацию SBWS по преобразованию XSL применимому к "modelReference", до установки его в качестве значения параметра, который может быть использован вместо "valueProperty".
За один выходной параметр, "schemaMapping" аннотация SBWS рассказывает о том, как преобразовать XML результат в RDF. В конце концов, это должно быть заменено на набор стандартных аннотации, возможно в SAWADL. SBWS в состоянии разложить SPARQL запросы в серию HTTP GET запросов, которые отвечают конкретным SELECT или CONSTRUCT запросам. WADL и SBWS аннотации обеспечивают интеграцию, что позволяет в качестве Семантических описаний web-использовать существующие REST сервисы.
Пример с Amazon.com
После SBWS была настроена для конкретного web-сервиса, что позволило службам, которые будут использоваться в сервисе, работать, как если бы у них был SPARQL в качестве конечной точки. В качестве примера рассмотрим Amazon.com - REST на базе электронного торгового сервиса [19], который позволяет разработчику осуществлять поиск в каталоге информации о продукции. Эта служба принимает пункт запроса адреса, как часть поиска URL и возвращает XML ответ с описанием продукта. Мы хотели бы запросить эту информацию семантически и вернуть в RDF формате.
На первом этапе необходимо определить онтологии, на которой строится разметка данных, представленных на web-службе. Пример Amazon.com онтологии используемой в этом документе имеется в [29]. Далее, аннотированный WADL документ, доступен по адресу [26] Должны быть созданы для приведения каждого элемента онтологии с запросом параметров и ответ Web-службы. С помощью этих элементов в месте, SBWS может быть использован как прокси-сервер для SPARQL Amazon.com ECommerce платформы.
Этот конкретный пример SBWS был настроен на использование Amazon.com " REST службы с определениями на Amazon.com ItemLookup и ItemSearch операций. В ItemLookup службе определен Amazon-стандарт Идентификационный номер (номера книги), в обмен на информацию, и ItemSearch служба принимает Автор и цену в качестве запроса. Использование описанной конфигурации, мы можем представить следующий запрос к SBWS искать название, цена, и автора книги с ISBN "0470082801":
PREFIX rdf:
PREFIX xsd:
PREFIX :
SELECT ?title ?price ?author
WHERE {
?item a :Item;
:asin "0470082801"^^xsd:integer;
:hasItemAttributes ?attributes.
?attributes a :ItemAttributes;
:price ?price;
:author ?author;
:title ?title.
}
Листинг 1 - Пример SBWS-образного SPARQL запроса
Преимущества семантически ориентированных Web сервисов
Существует огромная польза в том, что может быть достигнуто путем интеграции существующих веб-сервисов с Semantic Web. Добавив семантику к существующим веб-сервисам, многие различные наборы данных на веб-сайте могут быть интегрированы с меньшими трудозатратами. Позже в этом документе, мы представляем пример, использования нашей распределенной архитектуры запросов называемой Semantic Query Decomposer (SQD) [14] [20]. SQD обеспечивает единую SPARQL конечную точку для нескольких отдельных источников данных и автоматических запросов между ними. Компоненты такие, как SQD, могут быть настроены на несколько разных SBWS и совместно работать. Так, например, один экземпляр SBWS может быть настроен на использование Amazon.com ECommerce службы, а другой на использование Facebook Web-службы API. С помощью этой системы и SPARQL SELECT или CONSTRUCT запросов пользователи могут узнать цену и оценку для каждой книги в профилях своих друзей (Facebook). Это позволяет SBWS ответить на запросы веб-слубж, которые не могут быть получены от индивидуального веб-сервиса. А популярные темы в веб-2.0 объединяют различные веб-сервисы вместе, чтобы сформировать "mashup."
Даже в рамках одной web-службы и ее деятельности, SBWS обеспечивает выгоды для потребителей web - службы. Его умение анализировать запрос и цепь вместе вывода из одной web-службы в ссылку на ввод другой web-службы. Запрос дает ему возможность рассмотреть весь комплекс web-сервисных операций отвечать на вопросы, которые не ограничиваются API, представленным разработчикам web-службы. Данные, которые представлены в обычных REST и SOAP web-сервисах является более доступными, когда они семантически обоснованы и интегрированы в SBWS. Используя SBWS с семантическим описанием web-службы позволяет SPARQL стать стандартом языка запросов web-служб и позволяет легко объединить несколько семантических web-служб и запросить их, как если бы они были единым семантическим mashup'ом. Более традиционные web 2.0 mashup в значительной степени зависит от программ непосредственно на web-сервисе API. SBWS (с SQD) запросы вдали от этой проблемы, благодаря единому интерфейсу SPARQL.
Семантический REST
Семантический REST является различным подходом к web-2.0 и семантический web-интеграции, который объединяет существующие RDF операции с REST точками доступа. Хотя SBWS дает возможность адаптировать существующие REST и SOAP на базе web - сервиса для семантического запроса, Semantic REST предоставляет новую возможность - осуществление REST на базе web-сайтов интегрированных в полной мере в Semantic Web. Семантический REST принимает существующий набор стандартных REST операций и определяет сдерживающие факторы и моделей для использования с SPARQL и RDF. Результатом этого является возможность запроса, извлечь, изменить, удалить, RDF и добавить данные непосредственно из конечных уже используемых в REST на базе web-приложений. Используя эту модель, существующие Семантический web-приложения, которые работают через SPARQL конечные точки могут наращивать функционал через расширение набора операций REST.
Сначала мы рассмотрим особенности семантических REST запросов, в том числе данных препятствующих соответствию REST мышлению и расширенный SPARQL синтаксис, предложенный Hewlett-Packard группы Йена [25]. Далее мы дадим разметку HTTP REST операций для семантического веб с описанием того, что каждая комбинация из конечной точки и HTTP запроса разметки означает, в плане SPARQL и RDF.
Запрос Характеристики
Граф условий переходов
Одним из основополагающих принципов REST, использованных в web-2.0, является идея использования в качестве URL разрешимых идентификатора ресурсов. Все операции по поводу какого-либо конкретного ресурса могут обрабатываться с помощью запросов к ее идентификатору. Это также означает, что все операции на ресурс, URL-адрес должны производится только над этим ресурсом. Поскольку RDF обеспечивает гибкость в плане описания - HTML Form Encoded запрос данных не используется (эти ограничения косаются данных направленных в Semantic REST для предотвращения произвольных запросов). Это гарантирует, что все RDF отправленных данных в рамках запрос имеют отношение к ресурсу что достигается запросом к конечной точке. Чтобы решить эту проблему, Semantic REST требует, чтобы все запросы, содержащиеся в RDF графе ссылок на конечные точки URI в каждом, отключены югу графа, включенного в запрос. Если запрос содержит граф не включающий конечной точки в качестве RDF узла, то запрос отклоняется сервером, и ответ HTTP 406 .
Кроме того, Semantic REST операций, которых нет в графе на сервере должны быть созданы, если оно подходят под описание REST. Именно серверу хранит разрешения на каждого человека в ресурсах в рамках своих разрешимых имен ссылок на INSERT или UPDATE запрос к уже существующим ресурсам, в своем локальном графе. Заметим, что это правило означает, что в открытом мире гипотеза не применяться к ресурсам, в местном пространстве имен, что Semantic REST сервер-контролер; сервер должен иметь возможность сообщить, существуют такие ресурсы или нет. И наконец, обеспечить, чтобы все операции, связанны с графом, и, таким образом, могут быть подвергнуты этим ограничениям, Semantic REST поддерживает только SELECT, CONSTRUCT, UPDATE, INSERT, и DELETE операторы SPARQL и SPARQL / Update (см. ниже).
Расширенная SPARQL синтаксис
Семантический REST использует расширение SPARQL называемые SPARQL / Update, чтобы получить весь спектр возможностей REST. Стандарт для вставки, обновления и удаления, необходимый для любой системы данных пока еще не появился на RDF, но есть основания ожидать, что SPARQL, как предложил RDF языка запросов, будет прослойкой для этих операций, когда они станут стандартными. Таким образом, семантический REST использует расширение SPARQL называемое SPARQL / Update, придуманное в команде Йена на Hewlett-Packard. Это расширение к SPARQL добавляет еще две команды, INSERT и DELETE, а также CONSTRUCT, MODIFY оператора, что позволяет исключить и включить запрос в другой запрос, чтобы создать эквивалентную SQL запись. SPARQL / Update основан на гибком синтаксисе SPARQL чтобы переменные данных для INSERT и DELETE команд могли выдавать для многих ресурсов, в базе знаний множество ответов (как и в SQL). Это влечет использование INSERT и DELETE запросов непосредственно которые знакомы любому, кто использовал SPARQL, таких, как, например в распечатке 2, которая удаляет все заявления о пользователях, чьи подписки истекают до 1 января 2007 года. На конечной точки этого примера запрос класса-на уровне конечного пользователя, http://example.org/somewebsite/User.
PREFIX rdf:
PREFIX xsd:
PREFIX subscription:
PREFIX somewebsite:
DELETE {
?user ?p ?v
}
WHERE {
?user a somewebsite:User .
?user subscriptions:subscriptionStops ?finalDate .
FILTER ( ?finalDate < "2007-01-01T00:00:00"^^xsd:dateTime )
}
Листинг 2 - Пример SPARQL / Update запроса
Определение семантического REST
Как Semantic REST операции направлены на то, чтобы быть выполнены над существующими REST конечными точкам на web-сайте, так и HTTP заголовки должны использоваться, чтобы определить, что данный запрос является Semantic REST запросом. Во всех из операции подробно описанных ниже, ответ типа будут либо применение / rdf + xml или применение / sparql-результата + xml. Клиенты должны знать, на характер просьбы, какой тип ожидать, в ответ на запрос, но, возможно, просто включают в себя как согласование типов, если они хотят избежать необходимости поочередно разбирать два заголовка по шаблону на основе этих знаний. Каждая из этих двух типов принят в распечатке 3 Semantic REST операции.
Accept: application/rdf+xml
Accept: application/sparql-results+xml
Листинг 3 - HTTP согласиться заголовки семантические остальной операции
Синтаксис REST
Центральная идея Semantic REST - учет отличий общепринятого HTTP REST запроса и соответствующего действия для Semantic Web. Мы сосредоточимся на этой разметке в первую очередь на SPARQL, так как она представляет собой существующий стандарт, на котором многие Семантические web-приложения уже основаны.
Семантический REST операций могут происходить на двух типах конечные результатов: на уровне класса, и на уровне ресурсов. Уровень класса представляет собой целый класс ресурсов на удаленном сервере, например, всех пользователей. Позволяет создать запрос к большому количеству данных, которые затрагивают или возвращают ряд ресурсов этого типа, а также позволяет создать ресурс. В каждой URI ресурса в Semantic REST также является конечной точкой. Эти ресурсы на уровне конечных предоставлений информаций о
ресурсе в RDF, а также дают возможность добавлять, удалять или изменять информацию о ресурсе.
Операции в таблице 2 - описания уровня класса конечной функциональности, которая может быть использована для операций, касающихся какого-либо конкретного типа ресурса.
Operation
HTTP
Command
Request Data
Format
SPARQL
Command Response
List
GET None n/a SPARQL Select result of all resources
of the type specified by the URL
Query GET SPARQL SELECT or
CONSTRUCT Query Results
Create POST None n/a Status 201 CREATED
Insert PUT SPARQL/Update INSERT Status 200 OK
Remove DELETE SPARQL/Update DELETE or
MODIFY Status 200 OK
Таблица 2 - Class Class-level Endpoints of Semantic REST
Создание ресурсов и запрос вставки полностью отделены от удалиния. HTTP-запрос отправки, создает новый ресурс, при этом не несет никакой полезной нагрузки - это просто сообщает серверу, что нужно создать новый идентификатор ресурса и вернуть его клиенту. Ресурс обработки использует уровень класса конечной точки, как ее имя, поэтому POST к / пользователю повлечет за собой новый ресурс с URI в виде / пользователи / resource_id время создания. На стороне сервера, ресурс описан созданным единым триплетом который должен быть включен в граф ссылок, так что новый ресурс имеет класс типа определенный в пункте назначения, используемого для создания этого ресурса.
В этой ранней версии семантического REST, идентификаторы созданные на сервере создаются автоматически, как авто-увеличивающиеся целое домене данных строки идентификатора. Разработан метод определения пользовательской обработки (например, "ebenson"), кроме того, в будущих версий Semantic REST он также будет учтен. Требование на сервере для генерации этой обработки также свидетельствует о том, что некоторые механизмы индексации должны использоваться вместе с триплетами и отслеживать существующие идентификаторы и создавать новые, уникальные из них.
Так, например, одни HTTP POST запросы могут быть отправлены в пункт назначения на http://www.semwebcentral.org/user для создания новых пользовательский ресурсов о SemWebCentral. На сервере будет создан уникальный идентификатор ресурса (1234), включающий запрос, объявляющий его тип (1234), и, наконец, ответ с URI, что создан новый ресурс, http://www.semwebcentral.org/user/1234. Клиент может взаимодействовать с этой новой единицей ресурса на уровне конечной точки с использованием следующих ресурсов на уровне семантических REST преобразований:
Operation HTTP Command Request Data Format SPARQL Command Response
Read GET Empty n/a RDF/XML
Insert PUT SPARQL/Update INSERT Status 200 OK
Remove DELETE SPARQL/Update DELETE or MODIFY Status 200 OK
Таблица 3 - Resource-level Endpoints of Semantic REST
Вставка и удаление конечных точек влечет изменения в объекте
Пример. Текущий 1234, пользователь может используя ресурс на уровне семантических REST преобразований добавит информацию с HTTP Insert операции в Листинг 4. На конечной точке для этого запроса будет URI из нового ресурса, только что созданного http://www.semwebcentral.org/user/1234:
PUT
xmlns:swc="http://semwebcentral.org/example/semwebcentral-ontology#"
xmlns:user="http://semwebcentral.org/user/"
xml:base=" http://semwebcentral.org/user/">
Листинг 4 - Создание ресурса с Semantic REST
Сервер проверяет граф, содержится ли в запросе ссылки на ресурс определенные на конечной точке указанной в запросе, а затем добавляет новый триплет коллекцию триплетов. Именно ответы на этот запрос, Status 200 OK означает, что граф содержит ресурс http://www.semwebcentral.org/user/1234 и был успешно обновлен.
В данной работе не достаточно внимания уделяется безопасности сервисов.
Пример: Использование семантических запросов в Web 2.0
Чтобы проверить идеи, представленные в настоящем документе, создадим распределенный семантический запрос через три отдельных источника данных, в каждом используя разные методы воздействия на данные:
1. А DAML DB основан на [24] RDF триплетах, содержащий макет данных «работника» из системы начисления заработной платы через SPARQL конечные точки
2. А Semantic REST репликация SemWebCentral.org
3. Amazon.com REST служба, позволяющая пользователям найти свою базу данных, но не в формате RDF
Мы создали SBWS обертка для Amazon.com REST службы на основе того, что она может рассматриваться в качестве семантической RDF источника данных. Эта обертка содержит необходимые пояснения к разметке данных книги и автора в онтологии элементов публикации от Amazon в REST службе [25].
Выполнение распределенных семантических запросов не является тривиальной задачей, даже когда они действуют строго в рамках Семантический веб-среды. Мы использовали Semantic Query Decomposer (SQD), чтобы помочь нам в этой операции. SQD оберткой обернуты данные из нескольких семантических источников с их собственными источникоми онтологии данных, что обеспечивает единую точку доступа SPARQL для запросов с предусмотренного домена ontologythat. Он определяет чего касается запрос. SQD разлагает эти запросы в документообороте к югу от конкретных запросов для каждого источника данных и их онтологии. Разложение решения основываются на SWRL [12] правилах о разметке источников данных в онтологии или в мастер-домен онтологии. Наконец, SQD сливается его к югу от запроса результаты и обеспечивает единый запрос ответ на языке домена онтологии. Рисунок 2 изображает общей архитектуры системы, которую мы использовали для нашего теста. Эта архитектура позволяет нам направить SPARQL запросов к SQD помощью единой онтологии предметной области (имеется в [28]), и те вопросы, автоматически распространяются на все три источника данных, описаные в части 2.
SQD сконфигурирован для наших трех испытуемых источников данных. Мы, запрашиваем нашим SPARQL запросом: данные о работниках BBN, которые также разработчики Семантического Веб, и какие книги они написали? Этот запрос основывается на нашей макете размещении информации от SPARQL конечной точки, до SemWebCentral, и информации из Amazon.com REST службы.
Связные работы
The Semantic Bridge for Web Services functions somewhat like a semantic web service matchmaker. There have been several service matchmakers that have been developed such as OWLS-MX [13] and the OWL-S IDE [17]. These, however, focus on more generic service matchmaking than SBWS. SBWS is more of a query engine using a Web service as a knowledge base than a discovery tool. SBWS uses signature matching as it extracts concepts and data from the query to match and ultimately invoke a set of Web service operations to provide an answer, while the more conventional service matchmakers take a request of desired inputs and outputs and provide a corresponding service using signature matching, reasoning, or some other hybrid mechanism to match the service.
Past approaches to the topic of merging the semantic web with the existing world-wide web have often focused on the extraction of semantic content from HTML-based pages rather than the coexistence of HTML and RDF services as two different access mediums for the same data. MIT’s Piggy Bank plugin for Firefox uses pre-defined “scrapers” to extract semantic information out of the DOM structures of popular web sites such as Flickr and Amazon.com, for example [7]. Other examples use a combination of user-guided training and tree-based algorithms to learn how to
scrape data from a site that presents multiple data objects of the same type with the same basic DOM layout [9][solvent].
Microformats [1] are a way for web scrapers and HTML developers to meet in the middle. Developers embed lightweight semantic markup into the class attribute of HTML elements (generally used for CSS styling). These markers provide a standard context through which to interpret the contents of the HTML tag. Semantic REST offers a different approach than the above tools because it focuses on the co-existence of HTML and RDF rather than a method for extracting RDF from HTML content. This different approach attempts to retain the capabilities and flexibility that make RDF and HTML attractive data formats in the first place.
Выводы и будущая работа
Ответы, которые будут поступать от интегрированных данных, моделирования из Семантического веба с пользователем участия Веб 2,0 будет намного больше, чем любая из двух составных частей. Семантические веб-пользователи смогут выполнять запросы и анализ всей палитры данных из различных веб-сайтов, которые они могут использовать каждый день. Web запросы будут также в выигрыше от способности использовать семантические разметки для включения внешних данных в своих собственных сервисы.
Этот документ, показывает способы интеграции между этими двумя мирами, и причины, почему REST передача является идеальной общей почвой, на которой будет выполнятся интеграция. Мы предлагаем две альтернативных и бесплатных стратегии для выполнения этой REST ориентированной интеграции. Вместе с этими двумя методами предусмотрен способ обновить существующие веб-сайты и способ строительства новых гибридных конечных точек, как показано в наших опытах с выборкой запроса.
В реальном использовании возникнет несколько вопросов не рассматриваемых в этой работе. Эти вопросы неизбежно должны быть решены до того, как эти технологии получат широкое применение. Аутентификации и авторизации отсутствует с обеих семантических REST и SBWS концепциях. А веб-сайт или хранилище данных должны контролировать кто и как может получить доступ к информации и то, какого рода информация о том, что пользователь может получить доступ. Решение этих вопросов является важной задачей, и должно быть в центре внимания будущей работы, с тем, что SemWebCentral пользователь не может сделать утверждение о том, что, например, они были rdf: тип
semwebcentral: Админ. Семантические REST модели, приведенные здесь также используют дополнения к SPARQL, которые еще не добавлены к предлагаемому SPARQL стандарту.
