我想知道使用片段标识符格式引用实体是否更好/更合适-基本上是通过在名称之前插入一个哈希
[url] + # + [name] => http://example.com/page/#webPage
编辑：
在得到来自@Unor的慷慨回答之后，我添加了此编辑内容，以尝试限制查询范围并阐明我要解决的主要问题。我还删除了大部分原始问题（约95％）（事后看来），这有损于我：1.我的核心问题；2.对未来读者的好处。
简而言之，这是我的问题：
在微数据的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）是否正确？
允许在请求URI时检索有关实体的描述是一个好习惯（请参阅语义Web的酷URI：1.在Web上。）。
通过使用哈希URI，您可以免费获得以下功能：
http://example.com/flower 代表关于花的文件http://example.com/flower#this 代表花http://example.com/flower#this，您将获得有关它的文档通过使用Slash URI，您必须自己实现重定向（状态码为303）：
http://example.com/flower 代表关于花的文件http://example.com/flower/this 代表花http://example.com/flower/this，您将303重定向到有关它的URI （请参阅示例）因此，在不了解您的后端的更多信息的情况下，我建议您使用哈希URI，因为它通常更易于设置。
（我不确定您对“网页实体”的确切含义是什么，只是为了确保：哈希URI应该用于“实际对象”，而不用于文档。）
编辑（针对您的更新问题）：
是的，您可以通过仅指定片段组件（以开头）在itemid和@id（示例）中提供哈希URI #。
因此，在具有URL的文档上http://example.com/foobar，这四个语句生成相同的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>
（是的，您的示例URI有效；这是片段组件可能包含的字符。）
笔记：
itemid="#joe"和"@id":"#Joe"解析为不同的URI（jvs J.）。/page/#joevs. /page#joe）；查询组件很重要（该页面/page?foo=bar将创建Hash URI /page?foo=bar#joe，而不是/page#joe）；主持人是否www.重要；URI方案很重要（httpvs. https）；等等本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句