data-structures - 结构化数据 > 微数据和 Json-LD > 实体 ID > 片段标识符

Question

我想知道使用片段标识符格式引用实体是否更好/正确 - 基本上是通过在名称前插入一个哈希
[url] + # + [name] => http://example.com/page/#webPage
编辑:

遵循永远慷慨而伟大的@Unor 的友好回答，我添加了此编辑以尝试限制我的查询范围并阐明我遇到的主要问题。我还删除了大部分原始问题(大约 95%)，(事后看来)我觉得有损于:
1.我的核心问题；和
2.对 future 读者的好处。

简而言之，这是我的问题:

在微数据的 itemid 和 json-ld 的 @id 值的开头手动输入哈希的做法是否有效？

这是我更详细地表达的问题:

我可以在微数据的 itemid 值和 json-ld 的 @id 值中插入一个 HASH 符号 (#)，以创建有效的结果 URI，并正确且有效地使用片段标识符吗？

因此，如果这是在网页上:

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

或者，如果这也在网页上:

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

我知道他们将被读取以制作这样的 uri(假设消费者的相对构造就像 Google 的结构化数据测试器工具所做的那样):

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

那是uri吗:

一个有效的 uri；和

是否正确使用片段标识符(HASH)？

Answer 1

在请求 URI 时允许检索有关实体的描述是一个很好的做法(参见 Cool URIs for the Semantic Web: 1. Be on the Web.)。

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

http://example.com/flower代表关于一朵花的文档

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

→ 检索时http://example.com/flower#this , 你得到了关于它的文档

通过使用 斜线 URI ，您必须自己实现重定向( with status code 303 ):

http://example.com/flower代表关于一朵花的文档

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

→ 检索时http://example.com/flower/this ，你会得到 303 重定向到关于它的 URI ( see an example )

因此，在不了解您后端的更多信息的情况下，我建议使用 Hash URI，因为它通常更容易设置。

(我不确定您对“网页实体”的确切含义，但只是为了确保:哈希 URI 应该用于“真实世界对象”，而不是用于文档。)

编辑(针对您更新的问题):

是的，您可以在 itemid 中提供哈希 URI和 @id ( example ) 通过仅指定片段组件(以 # 开头)。

所以在一个带有 URL http://example.com/foobar 的文档上，这四个语句生成相同的哈希 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>

(是的，您的示例 URI 是有效的；这里是 which characters the fragment component may contain 。)

笔记:

该片段区分大小写，因此您的 itemid="#joe"和 "@id":"#Joe"解析为不同的 URI( j 与 J )。

当不指定绝对哈希 URI 时，您必须确保当前文档的 URL 是规范的。例如，尾部斜杠很重要( /page/#joe 与 /page#joe )；查询组件很重要(页面 /page?foo=bar 将创建哈希 URI /page?foo=bar#joe ，而不是 /page#joe )；如果主机有 www.与否无关紧要； URI 方案很重要( http 与 https )；等