Structured Data Testing Tools following @id references for JSON-LD – Will this work as expected?

Question

I'm working on marking up a site with schema data using JSON-LD. After doing my homework, I learned that @id could be used to reference other snippets of schema. Such as writing WebPage schema that isPartOf my WebSite schema.

Following this, I created the basic schemas for my website; Organization, WebSite, and WebPage where WebSite links to WebPage and Organization.

When I plug my markup into Google's Structured Data Testing tool, it all gets rolled up into the WebSite schema. However, when I remove the @id references, then it is shown as three different types of schema.

With @id

Without @id

Of course, I want my schema data to be interpreted as a series of relationships, that's the whole point. But I also want to make sure each individual schema is being parsed.

So what do you think, will this be okay?

---

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

Of course, I want my schema data to be interpreted as a series of relationships, that's the whole point.

Exactly. Making use of @id references is one way to achieve this, nesting the full items is the other way. The result will be the same, i.e., they are equivalent.

But I also want to make sure each individual schema is being parsed.

If you know a consumer that only recognizes top-level items, you might want to adapt. It’s often possible to have one item of your choice on the top-level (by making use @reverse or inverse properties, if existing), but tools like Google’s SDTT might of course display the parsed result in a different way.

But unless you know such a consumer, I don’t think it would be advisable to omit using properties with item values. You would miss out on the most important semantic signal: relations.

In theory, providing the mainEntity/mainEntityOfPage property should be sufficient for page-oriented consumers to learn what the primary entity on that page is. In practice, consumers might not recognize/support this property, of course. But I don’t see how it should be easier for consumers to handle several top-level items, where it’s unclear in which relation they stand to each other (because the relations aren’t specified), so consumers should have an interest to support the common way how Schema.org structured data is provided on the Web.