When a WebPage (or similar type) uses an ID that matches a breadcrumb ID, why does the WebPage become part of the BreadcrumbList?

Question

Is this what is supposed to happen? If so, why?

Here's an example (test code here):

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@type": "WebPage",
    "@id": "http://example.com/"
}
</script>
<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement":{
   "@type": "ListItem",
   "position": 1,
   "item":{
    "@id": "http://example.com/",
    "name": "Lecture 12: Graphs, networks, incidence matrices"
    }
  }
}
</script>

Answer 1

Yes, I think it makes sense that Google’s SDTT does this. It’s just a usability question if the WebPage item should be displayed as top-level item in addition; it doesn’t affect the semantics.

In the first script data block, you say that the WebPage has the URI http://example.com/. In the second script data block, you say that the value of the item property has the same URI, http://example.com/.
Because these two items have the same URI, they have to be the same thing.

You may want to use the breadcrumb property to make clear that the BreadcrumbList belongs to the WebPage:

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "WebPage",
 "@id": "http://example.com/",
 "breadcrumb": {
   "@type": "BreadcrumbList",
   "itemListElement":{
     "@type": "ListItem",
     "position": 1,
     "item":{
      "@id": "http://example.com/",
      "name": "Lecture 12: Graphs, networks, incidence matrices"
      }
    }
  }
}
</script>

As you can see in the SDTT, the properties you provide for the item property will be displayed under the top-level WebPage item.

(N.B.: Google’s SDTT seems to be bugged for cases where different types get provided for the same URI.)

Answer 2

Think of ID as a global variable, the first time you "declare" its value, this value is set througout the document and will "render" the given value anywhere you call the ID.

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@type": "WebPage",
    "@id": "http://example.com/" *here you give ID a value*
}
</script>
<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "BreadcrumbList",
 "itemListElement":{
   "@type": "ListItem",
   "position": 1,
   "item":{
    "@id": "http://example.com/", *here you just "paste" the given value*
    "name": "Lecture 12: Graphs, networks, incidence matrices"
    }
  }
}
</script>

That's why you literally get a full URL within a breadcrumb trail.

In fact IDs should be VERY consistent domainwise in order to disambiguate entities and actually spare the effort of having to declare one time and another the same thing, like repeating several times a homepage URL or very likely a postalAdress if you do content about LocalBusiness and other types of Organization.

A big benefit is that other authors may reference this ID from extrnal sites/domains and even then this will be an univocal relation. Think big, kinda semantic link building (out of scope, just an example of possible use).

You can find a working example in ZeClinics contact page where I am hashing the 2 premises of the company in order to set a precedent to be recalled in future RDF and onpage Schema developments.

Furthermore, if you are using CMS for website maintenance I would perhaps advise to implement Breadcrumb with RDFa (my favorite vs Microdata) and keep this trail apart from the far more flexible (and thus complex) JSON-LD scripts.

This is absolutely common in many WP themes, for example.
Have fun!