结构化数据>微数据Json-LD>实体ID>片段标识符 [英] Structured Data > Microdata & Json-LD > Entity IDs > Fragment Identifier

问题描述

我想知道使用片段标识符格式引用实体是否更好/适当 - 基本上是通过在名称之前插入一个哈希

[url] +＃+ [name] => http://example.com/page/#webPage

编辑：

从慷慨和伟大的@Unor中回答一个善意的答案，我已经添加这个编辑尝试限制我的查询的范围，并澄清我正在得到的主要问题。我也删除了大部分原始问题（约95％）（事后看来）我感到有些损失：
1.我的核心问题;和
2.对未来读者的好处。

以下是我的问题：

这是我的问题，这是在microdata的itemid和json-ld的@id值开始时手动输入哈希的做法吗？更详细地表达：

我可以在微数据的itemid值和json-ld的@id值中插入一个HASH符号（＃），以创建有效的结果URI适当有效地使用片段标识符？

所以如果这是在网页上：

 < div itemscope itemtype =http://www.schema.org/Personitemid =＃joe>< / div> 
  

或者如果这也在网页上：

  {@context：http://schema.org，
@type：Person，
@id ：＃Joe} 
  

我明白他们会读取这样一个uri（假设相对消费者由Google的结构化数据测试工具进行构建）：

  http://www.example.com/page#joe 
  

是那个uri：

1. 有效的uri;和




2. 是否正确使用片段标识符（HASH）？

解决方案

允许检索关于实体的描述是一个很好的做法当请求URI时（请参阅语义网的酷URI： 1.在网上。 ）。

通过使用哈希URI ，您可以免费获得此功能：

• http://example.com/flower 表示有关花的文件


• http://example.com/flower#this 代表花


• →检索 http://example.com/时花＃这个，你得到关于的文件

通过使用 Slash URI ，您必须自行实施重定向（，状态码为303 ）：

• http://example.com/flower 表示有关花的文档


• http://example.com/flower/this 代表花


• →检索 http://example.com/flower/this ，您可以将303重定向到关于的URI （查看示例）

所以，不用多了解你的后端，我建议使用哈希URI，因为它更容易设置。

（我不知道你的意思是网页实体，但只是为了确保：哈希URI应该是真实世界的对象，而不是文档。）

---

编辑（对于您的更新问题）：

是的，您可以提供哈希 itemid 和 @id （＃开头）来指定json-ld /＃reverse-propertiesrel =nofollow>示例）。

所以在URL http://example.com/foobar 的文档中，这四个语句生成相同的哈希URI （ http://example.com/foobar#this ）：

 < article itemscope itemtype =http://voc.example.net/Exampleitemid =＃this> 
< / article> 
 
< article itemscope itemtype =http://voc.example.net/Exampleitemid =http://example.com/foobar#this> 
< / article> 
 
< script type =application / ld + json> 
 {
@context：http://voc.example.net/，
@type：示例，
@id： #this
} 
< / script> 
 
< script type =application / ld + json> 
 {
@context：http://voc.example.net/，
@type：示例，
@id： http://example.com/foobar#this
} 
< / script> 
  

（是的，你的示例URI是有效的;这里是片段组件可能包含哪些角色。）

注意：

• 片段是区分大小写的，所以你的 itemid =＃joe和@ id ：＃Joe解析为不同的URI（ j 对 J ）。


• 不指定绝对哈希URI时，必须确保当前文档的URL是规范的。例如，尾部斜杠重要（ / page /＃joe vs. / page＃joe ）;查询组件重要（页面 / page？foo = bar 将创建哈希URI /页？foo = bar＃joe ，而不是 / page＃joe ）;如果主机有 www。或不重要; URI方案很重要（ http vs. https ）;等等。

I was wondering if it is better/proper to reference the entities using a fragment identifier format - basically by inserting a hash before the name

[url] + # + [name] => http://example.com/page/#webPage

EDIT:

Following a kind answer from the ever-generous and great @Unor, I have added this edit to try confine the scope of my query and clarify the main issue I am getting at. I have also deleted most of the original question (about 95%) which (in hindsight) I feel detracts from: 1. my core question; and 2. the benefit to future readers.

Here is my issue in short:

Is the practice of manually typing in a hash at the start of microdata's itemid and json-ld's @id values valid?

Here is my issue expressed in more detail:

Can I insert a HASH symbol (#) into microdata's itemid values and json-ld's @id values, to create valid resulting URIs with a proper and valid use of a fragment identifier?

So if this is on a web page:

<div itemscope itemtype="http://www.schema.org/Person" itemid="#joe"></div>

Or if this is also on the web page:

{"@context":"http://schema.org",
"@type":"Person",
"@id":"#Joe"}

I understand they will be read to make a uri like this (assuming relative construction by the consumer as Google's structured data tester tool does):

http://www.example.com/page#joe

Is that uri:

1. a valid uri; and

2. is it properly using a fragment identifier (HASH)?

解决方案

It’s a good practice to allow to retrieve a description about the entity when requesting the URI (see Cool URIs for the Semantic Web: 1. Be on the Web.).

By using Hash URIs, you get this functionality for free:

• http://example.com/flower represents the document about a flower
• http://example.com/flower#this represents the flower
• → When retrieving http://example.com/flower#this, you get the document about it

By using Slash URIs, you have to implement a redirect (with status code 303) yourself:

• http://example.com/flower represents the document about a flower
• http://example.com/flower/this represents the flower
• → When retrieving http://example.com/flower/this, you get 303-redirected to the URI about it (see an example)

So without knowing more about your backend, I’d suggest to go with Hash URIs, because it is typically easier to set up.

(I’m not sure what exactly you mean with "webpage entity", but just to make sure: the Hash URI should be for the "real-world object", not for the document.)

---

Edit (for your updated question):

Yes, you can provide the Hash URI in itemid and @id (example) by specifying only the fragment component (starting with a #).

So on a document with the URL http://example.com/foobar, these four statements generate the same Hash URI (http://example.com/foobar#this):

<article itemscope itemtype="http://voc.example.net/Example" itemid="#this">
</article>

<article itemscope itemtype="http://voc.example.net/Example" itemid="http://example.com/foobar#this">
</article>

<script type="application/ld+json">
{
  "@context": "http://voc.example.net/",
  "@type": "Example",
  "@id": "#this" 
}
</script>

<script type="application/ld+json">
{
  "@context": "http://voc.example.net/",
  "@type": "Example",
  "@id": "http://example.com/foobar#this" 
}
</script>

(And yes, your example URI is valid; here’s which characters the fragment component may contain.)

Notes:

• The fragment is case-sensitive, so your itemid="#joe" and "@id":"#Joe" resolve to different URIs (j vs. J).
• When not specifying an absolute Hash URI, you have to make sure that the URL of the current document is canonical. For example, the trailing slash matters (/page/#joe vs. /page#joe); the query component matters (the page /page?foo=bar would create the Hash URI /page?foo=bar#joe, not /page#joe); if the host has www. or not matters; the URI scheme matters (http vs. https); etc.

这篇关于结构化数据>微数据Json-LD>实体ID>片段标识符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！