Инструменты тестирования структурированных данных по ссылкам @id для JSON-LD - Будет ли это работать так, как ожидалось?

Question

Я работаю над разметкой сайта данными схемы с использованием JSON-LD. Сделав домашнее задание, я узнал, что @id можно использовать для ссылки на другие фрагменты схемы. Например, написание WebPage схемы, isPartOf моей WebSite схемы.

После этого я создал базовые схемы для своего сайта; Organization, WebSite и WebPage, где WebSite указывает на WebPage и Organization.

Когда я подключаю свою разметку к инструменту тестирования структурированных данных Google, все это сворачивается в схему WebSite. Однако, когда я удаляю ссылки @id, это отображается как схема трех разных типов.

С @id

Без @id

Конечно, я хочу, чтобы данные моей схемы интерпретировались как последовательность отношений, вот и весь смысл. Но я также хочу убедиться, что каждая отдельная схема анализируется.

Так что вы думаете, это будет хорошо?

---

Organization

{
    "@context": "http://schema.org",
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Organization",
    "legalName": "Organization, Inc",
    "description": "We rock",
    "logo": "https://www.example.com/images/logo.jpg",
    "url": "https://www.example.com",
    "telephone": "+1-111-111-1111",
    "sameAs": ["https://twitter.com/example", "https://www.linkedin.com/company/example/", "https://plus.google.com/u/0/+example", "https://www.facebook.com/example", "https://www.youtube.com/user/example", "https://www.instagram.com/example/", "https://en.wikipedia.org/wiki/example", "https://www.wikidata.org/wiki/Q1", "https://www.crunchbase.com/organization/example"],
    "address":
    {
        "@type": "PostalAddress",
        "streetAddress": "111 Street",
        "addressLocality": "Nowhere",
        "postalCode": "11111",
        "addressCountry": "United States"
    }
}

WebSite

{
    "@context": "http://schema.org",
    "@type": "WebSite",
    "@id": "https://example.com/#website",
    "name": "Website",
    "alternateName": "Web",
    "url": "https://www.example.com",
    "hasPart":
    {
        "@type": "WebPage",
        "@id": "https://www.example.com/#webpage"
    }
}

WebPage

{
    "@context": "http://schema.org",
    "@type": "WebPage",
    "@id": "https://www.example.com/#webpage",
    "name": "Webpage",
    "description": "Told you, we rock",
    "url": "https://www.example.com/",
    "isPartOf":
    {
        "@id": "https://www.example.com/#website"
    },
    "potentialAction":
    {
        "@type": "SubscribeAction",
        "agent":
        {
            "@type": "Organization",
            "@id": "https://example.com/#organization"
        },
        "object":
        {
            "@type": "Product",
            "name": "Mailing List"
        }
    }
}

Answer 1

Конечно, я хочу, чтобы данные моей схемы интерпретировались как последовательность отношений, вот и весь смысл.

Точно.Использование ссылок @id - это один из способов достижения этого, а вложенные элементы - другим способом.Результат будет одинаковым, т. Е. Они эквивалентны.

Но я также хочу убедиться, что каждая отдельная схема анализируется.

Если вы знаете потребителякоторый распознает только элементы верхнего уровня, вы можете адаптировать.Часто можно иметь один элемент по вашему выбору на верхнем уровне (, использующий @reverse или обратные свойства, если таковые имеются), но такие инструменты, как SDTT от Google, могут, конечно, отображать проанализированный результат в видепо-другому.

Но если вы не знаете такого потребителя, я не думаю, что было бы целесообразно не использовать свойства со значениями элементов.Вы упустите самый важный семантический сигнал: отношения.

Теоретически, для свойства page- должно быть достаточно mainEntity / mainEntityOfPage.ориентированные потребители, чтобы узнать, что является основным объектом на этой странице.На практике потребители могут не признавать / поддерживать это свойство, конечно.Но я не понимаю, как для потребителей должно быть проще обрабатывать несколько предметов верхнего уровня, когда неясно, в каком отношении они стоят друг к другу (потому что отношения не указаны), поэтому потребители должны быть заинтересованы в поддержкераспространенный способ предоставления структурированных данных Schema.org в Интернете.