The problem is that a consumer would think that different things are described (or more accurately: the consumer wouldn’t know if the things are the same or not).
There is a way to prevent this¹: give each thing a URI, and in case the things are the same, the same URI.
This can be done with @id
in JSON-LD, and with itemid
in Microdata.
So a simple case could be:
<!-- markup on the product page,
so the fragment "#this" results in an absolute URI like
"http://example.com/products/foo#this" -->
<!-- JSON-LD -->
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "Product",
"@id": "#this",
"name": "Foo"
}
</script>
<!-- Microdata -->
<article itemscope itemtype="http://schema.org/Product" itemid="#this">
<h1 itemprop="name">Foo</h1>
</article>
In case a property like name
has different values, the obvious way a consumer could handle this is to give the thing multiple names. For a feature where the consumer needs exactly one name (e.g., in a rich result), it’s not defined which of the name
values will be used. If the consumer is a search engine, it will likely use its already existing proprietary algorithms to handle such cases.
¹ Of course it’s not clear if/how all the various consumers support it. But it’s the correct way to do this, and it’s the only explicit way to do this. Implicit ways include hoping that a consumer understands that identical values for typically (but not necessarily) unique properties (e.g., url
, email
, productID
, etc.) mean that the things are the same. But such an implicit way can of course be used together with the explicit one.