Я бы хотел подробнее остановиться на ответе Билла Карвина о семантической паутине и триплетах, так как это то, над чем я сейчас работаю, и мне есть что сказать по этому поводу.
Идея триплет-хранилища заключается в том, чтобы хранить базу данных на основе графов, корни данных моделей которой лежат в RDF. С помощью RDF вы описываете узлы и ассоциации между узлами (другими словами, ребрами). Данные организованы в три раза:
start node ----relation----> end node
(в речи RDF: субъект --предикат -> объект). С помощью этой очень простой модели данных любая сеть данных может быть представлена путем добавления все большего и большего числа триплетов, если вы придаете смысл узлам и отношениям.
RDF носит очень общий характер и представляет собой модель данных на основе графиков, которая хорошо подходит для критериев поиска для поиска всех троек с определенной комбинацией субъекта, предиката или объекта в любой комбинации. В конце концов, с помощью языка запросов SPARQL вы также можете выполнять более сложные запросы, операцию, которая сводится к поиску изоморфизма графа на графе, как с точки зрения топологии, так и с точки зрения значения края узла (мы увидим это в настоящее время). SPARQL позволяет вам только ВЫБРАТЬ (и аналогичные) запросы. Нет УДАЛИТЬ, без вставки, без обновления. Информация, которую вы запрашиваете (например, конкретные интересующие вас узлы), отображается в таблицу, которую вы получаете в результате запроса.
Теперь топология сама по себе ничего не значит. Для этого был изобретен язык Schema. На самом деле их больше одного, и называть их языками схемы в некоторых случаях очень ограниченно. Самыми известными и используемыми сегодня являются RDF-схема, OWL (Lite и Full), и они предшествуют устаревшим DAML + OIL. Смысл этих языков в том, чтобы свести вещи к минимуму, чтобы придать смысл узлам (предоставив им тип, также называемый тройным) и отношениям (ребрам). Кроме того, вы можете определить «диапазон» и «домен» этих отношений или иначе сказать, какой тип является начальным узлом, а какой тип является конечным узлом: например, вы можете сказать, что свойство «numberOfWheels» может применяться только соединить узел типа Vehicle с ненулевым целочисленным значением.
ns:MyFiat --rdf:type--> ns:Vehicle
ns:MyFiat --ns:numberOfWheels-> 4
Теперь вы можете использовать эти онтологии в двух направлениях: проверка и вывод. Валидация сегодня не так уж и хороша, но я видел примеры ее использования. Вывод - это то, что круто сегодня, потому что оно позволяет рассуждать. Вывод в основном берет RDF-граф, содержащий набор троек, берет онтологию, смешивает их в базу данных троекратного хранилища, которая содержит «механизм логического вывода» и, как по волшебству, механизм логического вывода изобретает тройки в соответствии с вашим онтологическим описанием. Пример: предположим, что вы просто храните эту информацию в базе данных
ns:MyFiat --ns:numberOfWheels--> 4
и ничего больше. Тип этого узла не указан, но механизм вывода автоматически добавит тройку, говоря, что
ns:MyFiat --rdf:type--> ns:Vehicle
потому что вы сказали в своей онтологии, что только объекты типа Vehicle могут быть описаны свойством numberOfWheels.
И наоборот, вы можете использовать механизм логического вывода для проверки ваших данных по онтологии, чтобы отказаться от несоответствующих данных (вроде XML-схемы для XML). В этом случае вам понадобятся обе тройки, чтобы ваши данные были успешно приняты в хранилище триплетов.
Дополнительными характеристиками триплетов являются формулы и контекстно-зависимое хранилище. Формулы - это утверждения (как обычно, объект-предикат в три раза), которые описывают нечто гипотетическое. Я никогда не использовал формулы, поэтому я не буду вдаваться в подробности того, чего не знаю. Контекстная осведомленность - это, в основном, подграфы: проблема с хранением троек заключается в том, что тебе нечего сказать, откуда эти тройки. Предположим, у вас есть два дилера, которые описывают одну и ту же цену компонента. Один говорит, что цена 5,99, а другой 4,99. Если вы просто сохраняете обе тройки в базе данных, теперь вы ничего не знаете о том, кто указывал каждую информацию. Есть два способа решения этой проблемы.
Одним из них является овеществление. Реификация означает, что вы храните дополнительные тройки, чтобы описать другую тройку. Это расточительно и превращает жизнь в ад, потому что вы должны заново определять каждую тройку, которую вы храните. Альтернатива - понимание контекста. Наличие контекстно-зависимого хранилища Это все равно, что иметь возможность упаковывать кучу троек в контейнер с меткой (идентификатор контекста). Теперь вы можете использовать этот идентификатор в качестве субъекта для дополнительных утверждений, следовательно, описывая набор троек в одном действии.