关于JSON-LD的@id引用之后的结构化数据测试工具 - 这是否按预期工作？

Question

我正在使用JSON-LD标记包含架构数据的网站。做完作业后，我了解到@id可以用来引用其他模式片段。例如编写WebPage isPartOf我的WebSite架构的Organization架构。

在此之后，我为我的网站创建了基本模式; WebSite，WebPage和WebSite其中WebPage链接到Organization和WebSite。

当我将标记插入Google的结构化数据测试工具时，所有内容都会汇总到@id架构中。但是，当我删除@id引用时，它会显示为三种不同类型的模式。

使用@id

没有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" } } }

(Get-Content c:\temp\file.json).replace('status: 1', 'status: \'Open\'') | Set-Content c:\temp\file.json

Answer 1

  

当然，我希望我的架构数据被解释为一系列关系，这就是重点。

完全。使用@id引用是实现此目的的一种方法，将完整项目嵌套是另一种方式。结果将是相同的，即它们是等价的。

  

但我也想确保解析每个单独的模式。

如果您认识的消费者只能识别顶级商品，那么您可能需要进行调整。通常可以在顶级（making use @reverse或反向属性，如果存在）中选择一个项目，但Google的SDTT等工具当然可能以不同的方式显示解析结果。

但除非你知道这样的消费者，否则我认为省略使用具有项目值的属性是不明智的。你会错过最重要的语义信号：关系。

理论上，提供mainEntity / mainEntityOfPage属性应足以让面向页面的消费者了解该页面上的主要实体是什么。实际上，消费者当然可能不会认识/支持这种财产。但我不明白消费者应该如何更容易处理几个顶级项目，因为它们不清楚彼此之间的关系（因为没有指定关系），所以消费者应该有兴趣支持如何在Web上提供Schema.org结构化数据的常用方法。