The problem is that the consumer will think that different things are being described (or more precisely: the consumer would not know if things are the same or not).
There is a way to prevent this: give each thing a URI , and in case everything is the same, the same URI.
This can be done using @id in JSON-LD and itemid in Microdata.
So a simple case could be:
<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Product", "@id": "#this", "name": "Foo" } </script> <article itemscope itemtype="http://schema.org/Product" itemid="#this"> <h1 itemprop="name">Foo</h1> </article>
In the event that a property of type name has different meanings, the obvious way a consumer could handle this is to give verbose words. For a function where the consumer requires exactly one name (for example, in a rich result), it is not determined which of the name values will be used. If the consumer is a search engine, he is likely to use existing patented algorithms to handle such cases.
¹ Of course, it is unclear how and how all the various consumers support it. But this is the right way to do it, and this is the only explicit way to do it. Implicit methods include the hope that the consumer understands that identical values for typical (but not necessary) unique properties (e.g. url , email , productID , etc.) mean that everything is the same. But such an implicit method can, of course, be used together with an explicit one.