Практический пример

Так чем же полезен RDF? Тем, что это самая подходящая технология, когда нужно свести распределённую информацию в общую систему.

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

RDF бы подошёл в этом проекте особенно хорошо. Каждый поставщик и каждый эксперт бы размещали на собственном веб-сервере RDF-файл. Поставщики выбирают для своих продуктов URI, и эксперты используют эти URI, когда публикуют свои оценки. Тогда поставщики не вынуждены выбирать общую схему наименования для своих продуктов, и эксперты не привязаны к форматам данных, выбранным поставщиками. RDF позволяет и поставщикам, и экспертам использовать те инструменты, которые им удобнее, и никто не заставляет никого пользоваться каким-то определённым языком.

Такой вид имели бы RDF-файлы, которыми они обмениваются:

Поставщик 1:

vendor1:productX dc:title "Cool-O-Matic".

vendor1:productX retail:price "$50.75".

vendor1:productX vendor1:partno "TTK583".

vendor1:productY dc:title "Fluffertron".

vendor1:productY retail:price "$26.50".

vendor1:productY vendor1:partno "AAL132".

Поставщик 2:

vendor2:product1 dc:title "Can Closer".

vendor2:product2 dc:title "Dust Unbuster".

Эксперт 1:

vendor1:productX dc:description "This product is good buy!"

Эксперт 2:

vendor2:product2 dc:description "Who needs something to unbust dust?

A dust buster would be a better idea,

and I wish they posted the price.".

vendor2:product2 review:rating review:Excellent.

Отдельный вопрос – как именно они обменивались бы этими файлами; его пока оставим в стороне. Как только приложение получает эти файлы, у него появляется достаточно информации, чтобы соотнести продукты, цены, оценки, и даже такую специфическую информацию, как vendor1:partno (шифр изделия). То, что вы должны понять из этого примера, – это насколько гибок RDF: он не накладывает практически никаких ограничений и всё же позволяет приложениям моментально соотносить распределённую информацию.

Поставщикам и экспертам не приходилось идти на компромиссы: они договорились использовать RDF, и всё. Им не приходилось договариваться о конкретном формате данных, или даже о конкретных URI. Что важнее всего, им не пришлось перечислять заранее все пункты, которые поставщик может включить в информацию о своём продукте, и в этой системе ни одного из экспертов невозможно лишить возможности публиковать свои оценки.

Кроме того, можно рассмотреть эту систему с точки зрения взаимной совместимости. Формат, используемый Поставщиком 1, полностью совместим с форматом, используемым всеми остальными, хотя они не вырабатывали общий формат целенаправленно. Когда в системе появится новое действующее лицо, которое захочет работать с информацией Поставщика 1, ему не потребуется реализовывать новый формат: всё что ему будет нужно – это выбрать те же подлежащие, сказуемые и дополнения, которые выбрал Поставщик 1.

Выводы

Если вы думали, что RDF – это сложно, то надеюсь, теперь вы поняли, что это совсем не обязательно. RDF – это лёгкая, гибкая и необременительная технология. С ней становится лёгким моделирование знаний и объединение распределённых источников данных.

Черепаха документ позволяет записав граф RDF в компактном текстовом виде. Он состоит из последовательности директив, тройной генерирующих заявлений или пустых строк. Комментарии могут быть предоставлены после # и продолжаются до конца строки.

Простые тройки последовательность (подлежащее, сказуемое, объект) терминов, разделенных пробелами и заканчиваются '. после каждой тройки.Это соответствует N-троек ([N-тройки]).

Есть три типа RDF Срок: RDF URI Ссылки URI (для краткости), литералы и пустые узлы.