Также, есть множество мелких свойств, которые требуется как-то передавать, но сложно (да и не нужно) ограничивать одной предметной областью. Адрес фирмы, вес модели ноутбука, год издания книги, etc. А если взять и всё что можно запихнуть в один формат? Это удобно. Один и тот же код на чтение, запись, показ, надо только договориться о словарях, чтобы не путаться у кого для ноутбуков "weight", а у кого "product_weight". В идеале должно получиться как с моделью данных на атрибутах.
Однако, в реальности всё чудесатее. Начнём с самого проблемного пациента, набора технологий под общей маркой Semantic Web.
Идейно данная тема идёт от Тима Бернерса-Ли (родоначальника HTML и обычного веба), так что античеловечность и техническая безграмотность подразумевались сразу. Однако реализационная база семантиквеба началась с человека по имени Раманатан Гуха, который несколько лет проработал у Лената над Cyc, но затем посчитал Cyc слишком сложным решением и решил написать формат интеграции данных
RDF базируется на тройках (subject, predicate, object), где subject и predicate являются URI, а object - URI или литералом (текстовой строкой, либо парой строка+language, либо парой строка+datatype). Выглядит это так:
box123 ns1:hasName "Коробочка"@ru .
box123 ns1:hasWidth "15"^^xsd:integer .
box123 ns1:contains box577 .
box123 ns1:contains box578 .
box123 ns1:contains box1045 .
...
Единственная общая с атрибутами идея в этой истории - глобальность predicate. Дальше начинаются сон разума. Основа графовая. Т.е. запрашивая ns1:hasName для какой-то сущности мы получаем множество чего попало. Но мы можем приписать к ns1:hasName соответствующий rdfs:range и тогда... Получим утверждение, что предикаты ns1:hasName ведут только к строкам, а значит это уже множество строк, а точнее строк или пар (как демонстрировалось выше). Также (залезая уже в OWL) можно зафиксировать максимальную мощность этого множества. Тогда при рассмотрении ns1:hasName в качестве атрибута у него будет тип "множество из одной строки или пары". Назначить типом просто строку нельзя.
Более того, независимо от таких определений, при добавлении в базу данных нового факта
box123 ns1:hasName "Коробочка123" .
или ошибочного
box123 ns1:hasName ns2:sometrash .
они просто допишутся к существующим данным. Достаточно распространённая проблема, год назад я сам натыкался на подобное в файлах одного проекта, по которому мы консультировали.
Особо запоминающимся элементом дизайна является представление списков, когда на каждый элемент тратится по три факта (с rdf:type и предикатами rdf:first для головы и rdf:rest для хвоста). Нет, это не структура с двумя полями и лисповыми CAR/CDR, а три записи в базе данных для указания наличия элемента в списке.
Основные текстовые представления для RDF - Turtle (примеры показаны на нём) и формат RDF XML. Последний настолько дебильно и противоречиво описан, что этой осенью у меня была переписка с авторами одного довольно mature продукта, где нашлись проблемы в парсинге, пришедшие напрямую из фрагмента W3C спецификации. К счастью, с цитатами в почте из других фрагментов спецификации, данную проблему разрулили.
Но RDF это лишь начальный кирпичик семантиквеба. Web Ontology Language (OWL) позволяет более детально описывать схему данных (ограничения на мощность множества, ...) и делать синтетические выводы о самонепротиворечивости на базе description logic. Такая академическая игрушка. Элементарное "папа папы это дедушка", как в примерах на Prolog, оно уже не умеет. SPARQL - язык запросов для RDF-фактов, извращённое переосмысление SQL. Представьте себе сборку проекта, вот берутся у вас исходники из системы контроля версий, сразу нужная ветка... А если по одному файлу? А если по одной строке? Последний вариант - это как в SPARQL.
Ругаться про эти технологии можно много, а цензурных слов у меня мало, так что далее переходим к ситуации на сегодняшний день.
RDF (скорее даже RDF-мини) используется для метаданных (автор, лицензия, вебсайт, ...), которые можно положить внутрь некоторых видов XML файлов. Например, SVG. В аддонах Firefox такие метаданные выделены в отдельный install.rdf.
RDF с кусочками OWL (в основном owl:sameAs) применяют для публикации открытых данных в тех случаях, когда структура данных слишком разнообразна и плохо помещается в CSV или JSON. Обычно это тройки "сущность-свойство-значение" и "сущность-связь-сущность", без использования какого-либо синтетического вывода, которые пользовальский код может прочитать и привести к удобной внутренней модели данных. Иногда большие датасеты публикуют и на SPARQL-серверах, но скачать такие объёмы SPARQL-запросами технически невозможно. Так, балуются.
OWL, OWL 2, соответствующие ризонеры и специальные инструменты вроде Protégé используют только онтологи. В этом направлении пилят гранты и дают студентам темы дипломных вида "Семантическ(ий|ая|ое) [подставьте сюда любое сочетание слов]". Хотя есть и приличные люди. Сам видел.
В общем и целом хайп Semantic Web не прекращается, но концепция себя дискредитировала. Чтобы какие-то данные хорошо совмещались недостаточно их сливания в одну помойку.
Гуха теперь работает в Google, признал некоторые ошибки в дизайне RDF (а именно, RDF XML), но стабильно наступает на остальные грабли, сначала в виде микроформатов, а затем в виде их ребрэндинга schema.org
К сожалению, хайп затронул авторов частей 8 и 9 ISO 15926. Мы в .15926 Editor с этим справляемся, пропаганду игнорируем, умеем гонять RDF туда-сюда, настраивать триплстор и запрашивать SPARQL без попадания на грабли. Как поддержка форматов, в которых встречаются реальные данные, это имеет смысл. А остальное семантиквебовское - палочкой потыкать можно, но главное не вляпаться, считайте советом.
Продолжение следует.
