Если вас терзает ночами вопрос «В чем разница между JSON-LD и схемой JSON» или «Могу ли я использовать схему JSON и Schema.org одновременно», то эта статья точно для вас.
В наших проектах мы используем и JSON-LD и Schema.org и однозначно ясно только то, что ответить что лучше — невозможно.
Есть очевидное сходство в стандартных именах, таких как «Схема» и «JSON». Синтаксис обеих систем очень похож. Для примера сравните страницу «person» в Schema.org — Person вот с этим примером на странице схемы JSON. Ну, скажете они не похожи?).
Добавим сюда тот факт, что Schema.org рекламирует JSON-LD, который — по замыслу — очень похож на обычный JSON, и все становится на свои мета.
Схема JSON
Схема JSON для JSON — это то же самое, что схема XML для XML. Она позволяет вам указать структуру документа JSON.
К примеру, вы можете указать, что поле «электронная почта» должно следовать за определенным регулярным выражением или что адрес имеет поля «street_name», «number» и «street_type».
Рекомендуем статью для программистов и сеошников Понимание JSON Schema — в ней объясняется синтаксис. Единственное, что она на английском.
Основной вариант использования схемы JSON, по-видимому, заключается в API-интерфейсах JSON, где она играет две основные роли:
- Клиенты и серверы могут проверять объекты запросов и ответов обычным способом. Это значительно упрощает разработку, поскольку реализация может «передать» эти проверки стандартному компоненту. После того, как сообщение прошло проверку, вы можете уже быть уверенным, что документ соответствует правилам.
- Как и в случае с любым API, документация является ключевым моментом, когда разработчики пишут код, который ее использует. Схема JSON все чаще используется для описания структуры запросов и ответов путем встраивания ее в общее описание API.
Рассмотрим пример зоомагазина . Прокрутите страницу до конца, и вы увидите определение схемы JSON для «Pet», которое является основным элементом в запросах и ответах этого API (вы можете найти фактическую схему JSON, встроенную в необработанный файл Swagger — обратите внимание, что в настоящее время все еще есть некоторые различия между спецификацией OpenAPI и схемой JSON, которые будут устранены с помощью OpenAPI 3.1).
Схема JSON имеет возможность импортировать схемы с помощью ключевого слова $ ref . Также предпринимаются попытки поделиться схемами. Хранилище схем JSON — один из примеров. Его основной вариант использования — поддержка подсветки синтаксиса для редакторов, например, при редактировании файла в swagger. На момент написания он содержит более 250 схем, включая… барабанная дробь…… вы наверняка догадались — Schema.org. Они описывают такие вещи, как » Действие» и » Место».
Таким образом, идея могла бы заключаться в централизованном определении строительных блоков схемы JSON, которые можно было бы повторно использовать в различных API, чтобы упростить их использование, возможно, даже до такой степени, что интеллектуальное программное обеспечение может автоматически взаимодействовать с API. Но прежде чем мы увлечемся, давайте взглянем на Schema.org.
Schema.org
Schema.org предоставляет «схемы для структурированных данных в Интернете». Предположим, вы бронируете отель и получаете электронное письмо с подтверждением. Электронное письмо содержит разметку schema.org, предоставляющую содержание электронного письма в машиночитаемой форме. Это позволяет, к примеру, вашему гугл-календарю «понимать» электронную почту и автоматически добавлять записи . Мы заключили слово «понять» в кавычки, потому что здесь действительно нет никакого волшебства. Эта очень полезная функция стала возможной благодаря тому факту, что ИТ-система отеля и календарь согласовывают, что такое отель , а также соглашаются представить эту концепцию с помощью такой разметки:
{
"@context": "http://schema.org",
"@type": "Hotel",
"name": "ACME Hotel Innsbruck",
" checkinTime ": "13: 00: 00-05: 00"
…
}
Фактически, это похоже на то, как если бы они договорились об API, который использует электронную почту в качестве транспортного механизма (обратите внимание, что schema.org не ограничивается электронной почтой и ее используют множество сервисов).
Важно отметить, что Schema.org не только определяет концепции или классы. Поля или свойства также стандартизированы. Возьмем, к примеру, схему checkinTime , которая представляет собой строку схемы XML (время и часовой пояс), определяющую «самое раннее, когда можно заселиться в гостиницу».
Schema.org не только определяет согласованные определения классов и свойств, но также определяет иерархию классов и свойств (отель — это LodgingBusiness), какие свойства разрешены для какого класса (checkinTime можно использовать для LodgingBusiness и LodgingReservation) и тип свойств (checkinTime — это DateTime или Time, а starRating — это рейтинг).
И схемы Schema.org, и схемы JSON описывают структуры документа с помощью классов и свойств / типов и полей. Разница в том, что Schema.org основан на онтологии, которая публикуется в разных форматах на GitHub . Онтология:
- определяет классы и свойства с согласованными IRI, например: https://schema.org/Hotel
- описывает данные, в которых узлы (являющиеся экземпляром класса) связаны с другими узлами (через свойства), образуя связанный граф данных
- устанавливает классификацию
- рассматривает свойства и типы (диапозоны)
Теперь давайте немного конкретизируем и рассмотрим JSON-LD как одно из возможных представлений данных Schema.org.
JSON-LD
Девиз JSON-LD: «Данные беспорядочные и разрозненные. JSON-LD упорядочивает и связывает их, создавая лучшую сеть ».
В качестве примера возьмем описание отеля. Начнем с «обычного» представления JSON:
{
"name": "ACME Hotel Innsbruck",
" checkinTime ": "13: 00: 00-05: 00",
"starRating": {
"bestRating": 10,
...
}
...
}
Этот документ JSON имеет следующую древовидную структуру:
Мы уже используем словарь Schema.org, однако может быть и другой словарь, и особенно такое поле, как «name», скорее всего, будет неоднозначным. Поэтому мы уточняем наш словарный запас следующим образом:
"@context": "http://schema.org/"
Это приводит к тому, что «name» становится http://schema.org/name . Фактический URL-адрес контекста представляет собой простой список, который определяет сопоставление простых имен с URL-адресами Schema.org. В других примерах определяются такие типы данных, как строка, дата или ссылка (@id).
Наше дерево уже представляет собой график, однако нам не хватает информации о том, какой отель мы имеем в виду. Другими словами, мы не знаем ID верхнего узла графа. Мы можем указать это, используя:
"@id": "urn: acme-hotel"
Мы выбрали URN, обратите внимание, что возможен любой IRI. Вы также можете использовать URL-адрес отеля. Единственным условием является то, чтобы другие участники понимали и интерпретировали идентификатор.
Наконец, мы можем добавить информацию о том, что этот документ описывает отель:
"@type": "Отель"
Итоговый документ JSON-LD:
{
"@context": "http://schema.org/",
"@type": "Hotel",
"@id": "urn: acme-hotel",
"name": "ACME Hotel Innsbruck",
" checkinTime ":" 13: 00: 00-05: 00 ",
" starRating ": {
" bestRating ": 10,
...
}
...
}
который представляет вот такую структуру:
Если вы вставите пример в проверочный сервис, такой как JSON-LD PlAYGROUND: вы получите этот точный график (мы выбираем представление таблицы, где каждая ссылка выше становится одной строкой таблицы, в которой указан объект предиката субъекта).
Обратите внимание, что рейтинг узла имеет идентификатор _: b0, который является анонимным идентификатором. Это означает, что на рейтинг нельзя ссылаться в другом документе, и он существует только как дочерний или родительский объект. Однако на отель можно ссылаться и в других документах. Например, человек (http://example.ru/ivan) может быть связан с отелем:
{
"@context": "http://schema.org/",
"@id": "http://example.ru/ivan",
"affiliation": {
"@id": "urn: acme-hotel "
}
}
Оба документа можно объединить, в результате чего получится диаграмма с одной дополнительной ссылкой Ивана на отель. Добавление дополнительных свойств под идентификатором добавит еще одно свойство отеля.
Так-с, что дальше?
Мы рассмотрели JSON Schema, Schema.org и JSON-LD, и теперь вопрос в том, можем ли мы комбинировать подходы? Давайте рассмотрим три возможности:
Проверка JSON-LD с использованием схемы JSON
Первая идея, которая приходит в голову, — использовать схему JSON для проверки JSON-LD. Фактически, JSON-LD публикует схему JSON . Однако схема рассматривает только ключевые слова JSON-LD и общую структуру документа и не проверяет фактическую онтологию. Имеет смысл проверить JSON-LD, преобразовав его в граф RDF и проверив его с помощью базовой онтологии с помощью инструментов RDF / OWL.
Создание схемы JSON из Schema.org
Следующим подходом может быть создание схем JSON из Schema.org. Помните, что Schema.org присутствует на веб-сайте каталога схем? Оказывается, одна из основных проблем — это обработка массивов. В «обычной» схеме JSON вы указываете, является ли свойство массивом или имеет одно значение. В мире связанных данных любое свойство может повторяться. Таким образом, совершенно законно и реально, чтобы два источника указали время прибытия в отель. Следовательно, модель данных графа всегда будет возвращать список значений, когда вы запрашиваете свойство данного узла графа.
Это конечно можно попробовать обойти, определив все свойства как одно значение «oneOf» или массив значений, но это приводит к сложным и запутанным схемам — лучше так не делать.
Построение схемы JSON с использованием Schema.org
На веб-сайте схемы JSON представлен ряд инструментов линтера, которые проверяют саму схему. Один из подходов может заключаться в поощрении использования словаря Schema.org, поэтому в качестве предложения линтинга можно было бы изменить amenity_feature на amenityFeature. Преимущество для разработчиков состоит в том, что они могут повторно использовать документацию Schema.org. Кроме того, возможно, однажды их сервисы REST будут поняты и использованы умными клиентами.
Для кого нужен JSON-LD?
Рис. Микроразметка в поисковой выдаче
JSON-LD (javascript object notation for linked data) — это формат данных, который используется для описания структурированных данных в сети и не требует изменения содержимого страницы. Этот инструмент подойдет владельцам сайтов, желающим быстро внедрить микроразметку. В настоящее время поисковые системы отображают на странице небольшое количество маркеров JSON-LD, включая информацию об авторе и организации в графе знаний, а также информацию о форме поиска и событиях в сниппете. Поэтому его практическое применение на данный момент ограничено.
Реализация JSON-LD становится все более распространенной благодаря простому применению. Вполне вероятно, что поисковые системы распознают этот формат и в будущем будут отображать в результатах поиска больше типов разметки. Сейчас самое время воспользоваться преимуществами JSON-LD. Кстати, если ваш сайт работает на WordPress или Drupal, вы можете легко внедрить разметку данных с помощью плагинов.
Резюме
Понятно, что Schema.org и JSON-LD, с одной стороны, и JSON Schema, с другой — не подходят друг другу. Тем не менее, они могут друг другу помогать. Схема JSON может узнать об онтологиях, повторном использовании и семантике. Сообщество связанных данных может извлечь уроки из прагматизма схемы JSON. Фактически, JSON-LD уже усвоил этот урок и является большим улучшением по сравнению с NTriples или RDF / XML. Аналогичным образом, такие подходы, как JSON API, вводят принципы связанных данных в мир REST API.
