Какая польза от @id в синтаксисе json-ld?


16

Я действительно запутался в том, что @idиспользуется в синтаксисе json-ld. Образец с apple.com. Что на @idсамом деле представляет. Любая помощь будет отличной?

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@id": "http://www.apple.com/#organization",
    "@type": "Organization",
    "url": "http://www.apple.com/",
    "logo": "https://www.apple.com/ac/structured-data/images/knowledge_graph_logo.png?201608191052",
    "contactPoint": [
        {
            "@type": "ContactPoint",
            "telephone": "+1-800-692-7753",
            "contactType": "sales",
            "areaServed": [ "US" ]
        }
    ],
    "sameAs": [
        "http://www.wikidata.org/entity/Q312",
        "https://www.youtube.com/user/Apple",
        "https://www.linkedin.com/company/apple"
    ]
}

Ответы:


26

@idКлючевое слово позволяет дать Узел URI. Этот URI идентифицирует узел.

См. Идентификаторы узла в спецификации JSON-LD.

(Эквивалентом в микроданных является itemidатрибут, а эквивалентом в RDFa Lite является resourceатрибут.)

Почему идентификаторы полезны?

  • Вы можете ссылаться на узел, а не повторять его ( см. Мой пример ).
  • Другие авторы могут сделать то же самое (на внешних сайтах): когда они используют указанный вами URI, становится ясно, что они говорят об одном и том же.
  • Потребители могут узнать, что разные узлы - это одно и то же.

Это также одна из основных концепций связанных данных и семантической сети. Если вы заботитесь об этом, вы можете использовать URI, которые различают реальную вещь и страницу об этой вещи ( см. Мое объяснение ).

Это то, что Apple делает в примере. URI http://www.apple.com/#organizationпредставляет реальную организацию, а не страницу (и не часть на этой странице) об организации. Это хэш-URL-адрес , и это популярный способ различать вещь и страницу о ней. Если вы хотите сказать в своем JSON-LD, что вам нравится Apple, вы можете использовать http://www.apple.com/#organizationдля идентификации Apple. Если вы используете http://www.apple.com/вместо этого, это будет домашняя страница Apple, вам нравится.


Пытаетесь понять ваш последний абзац, поэтому страница должна иметь одинаковые значения как @id, так и url? Я думал, что если мы предоставим 'url', то у нас может быть идентификатор на основе хеша. Это помогает держать вещи единообразно.
Итан Коллинз

1
@EthanCollins: Это хорошая практика, чтобы предоставить и ( @idи url), да. В случае страниц они обычно имеют тот же URI, что и значение; в случае других элементов они, как правило, будут иметь разные URI в качестве значения ( @idдля вещи, urlдля страницы об этой вещи). - Чтобы быть уверенным, что мы находимся на одной странице: под идентификатором на основе хеша вы подразумеваете URL-адреса хеширования в контексте связанных данных, а не в контексте одностраничных приложений / сайтов на основе JavaScript, верно?
ОООНР

Спасибо за разъяснение. Я также взглянул на другие полезные ссылки, которыми вы поделились в своих ответах, теперь это стало намного понятнее. (чтобы ответить на ваш последний запрос, да, я хотел иметь в виду хэш-URI).
Итан Коллинз

7

Читая следующую ссылку от разработчиков Google - Типы данных - Local Business в разделе свойств Local business:

[...] ID должен быть стабильным и неизменным с течением времени. Поиск Google обрабатывает URL как непрозрачную строку, и она не обязательно должна быть рабочей ссылкой. Если у компании несколько местоположений, убедитесь, что @id уникален для каждого местоположения.

@Id почти для всего объекта

Я надеюсь, что мой ответ поможет вам :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.