@id и URL для связывания узлов JSON-LD

Я определил издателя Organization на WebSite узел определен на домашней странице, и теперь я хочу дать ссылку на этого издателя из статей на других страницах. Тем не менее, я также хочу ссылку на WebSite а также, и они, естественно, одни и те же @id если я последую совету использования URL в качестве @id,

{
    "@context": "http://schema.org",
    "@type": "WebSite",
    "@id": "http://www.example.com/",
    "url": "http://www.example.com/",
    ...
    "publisher": {
        "@type": "Organization",
        "@id": "http://www.example.com/",  <-- duplicated
        "url": "http://www.example.com/"
    }
}

{
    "@context": "http://schema.org",
    "@type": "WebPage",
    "@id": "http://www.example.com/news",
    "url": "http://www.example.com/news",
    "isPartOf": {
        "@id": "http://www.example.com/"  <-- site or publisher?
    }
    ...
    "publisher": {
        "@id": "http://www.example.com/"  <-- site or publisher?
    }
}

Я предполагаю, что идентификаторы должны быть уникальными для каждого узла, так что есть ли лучшая практика для уникальных идентификаторов, таких как добавление хеша?

{
    "@id": "http://www.example.com/#site",
    ...
    "publisher": {
        "@id": "http://www.example.com/#publisher",
    }
}

Если это сработает, процессоры (Google) загрузят @id найти остальные свойства узла?

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

Источник

1 ответ

Решение

@id (JSON-LD)

(и то же самое касается itemid в микроданных и resource в РДФа)

Каждая вещь должна получить свой URI, и если несколько узлов примерно одинаковы, в идеале они должны повторно использовать этот URI. Обратите внимание, что это не обязательно должны быть URL-адреса, и их часто не следует использовать в качестве значений для Schema.org. url свойство (см. раздел ниже).

Использование фрагментов URI является распространенным и наиболее простым способом достижения этого. Для примеров (и других способов), смотрите мои ответы на эти вопросы:

Для вашего примера, веб-сайт организации, корневой URL (http://www.example.com/) обычно "обозначает" три вещи:

  • домашняя страница
  • весь сайт
  • организация

Поскольку домашняя страница является ресурсом, который нужно получить, она должна получить URI http://www.example.com/, Сайт и организация должны получить свои фрагменты; Вам решать, какие из них, например: http://www.example.com/#site для сайта, и http://www.example.com/#organization для организации (FWIW, Apple, кажется, использует #organization, тоже.)

  • домашняя страница:
    http://www.example.com/

  • весь сайт:
    http://www.example.com/#site

  • организация:
    http://www.example.com/#organization

(Часто используются только две разные вещи: документ и вещь, описанная в документе. Тогда вещь часто получает фрагмент, подобный #this и в случае людей, #i, но это всего лишь соглашение.)

Если это сработает, процессоры (Google) загрузят @id найти остальные свойства узла?

Google не документирует, пытаются ли они загрузить эти URI.

Обратите внимание, что не требуется, чтобы эти URI действительно указывали на документ. Вы можете использовать HTTP URI, которые дают 404 ответа, или вы можете использовать схему URI, которая не позволяет начать поиск документов (например, urn, tag …)

url (Schema.org)

Schema.org-х url свойство должно использоваться для URL, которые ведут к страницам, которые можно посетить. Он не предназначен для предоставления идентификатора, поэтому это не обязательно тот же URI, который указан в @id,

В вашем примере, вы, вероятно, использовали бы тот же url значение для всех трех вещей:

  • домашняя страница:
    @id: http://www.example.com/
    url: http://www.example.com/

  • весь сайт:
    @id: http://www.example.com/#site
    url: http://www.example.com/

  • организация:
    @id: http://www.example.com/#organization
    url: http://www.example.com/

Источник
Другие вопросы по тегам