Проблема в том, что потребитель будет думать, что описаны разные вещи (или, точнее, потребитель не будет знать, одинаковые вещи или нет).
Есть способ предотвратить это¹: назначьте каждой вещи свой URI, и, если вещи одинаковые, тот же URI.
Это можно сделать с помощью @id
в JSON-LD и с помощью itemid
в микроданных.
Итак, простой случай может быть:
<!-- 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>
В случае, если такое свойство, как name
, имеет разные значения, очевидный способ, с помощью которого потребитель мог бы справиться с этим, — дать объекту несколько имен. Для функции, где потребителю требуется ровно одно имя (например, в расширенном результате), не определено, какое из name
значений будет использоваться. Если потребителем является поисковая система, она, скорее всего, будет использовать свои уже существующие проприетарные алгоритмы для обработки таких случаев.
¹ Конечно, неясно, поддерживают ли его различные потребители и каким образом. Но это правильный способ сделать это, и это единственный явный способ сделать это. Неявные способы включают надежду на то, что потребитель понимает, что одинаковые значения типично (но не обязательно) уникальных свойств (например, url
, email
, productID
и т. д.) означают, что вещи одинаковы. Но такой неявный способ, конечно, можно использовать вместе с явным.
person
unor
schedule
08.12.2016