結構化數據>微數據＆JSON-LD>實體ID>片段標識符

Question

我想知道如果它是更好/正確引用使用片段標識符格式的實體 - 基本上由名稱之前插入散列

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

編輯：

在從不斷的慷慨和巨大@Unor一種答案，我已經加入此編輯試圖限制我的查詢的範圍和澄清，我在獲得的主要問題。我也刪除了大部分原來的問題（大約95％），我認爲這有損於我的觀點： 1.我的核心問題;和 2.對未來讀者的好處。

這是我的問題，簡而言之就是：

是在微觀的開始在哈希手動鍵入實踐爲itemid和JSON-LD的@id值是否有效？

這裏更詳細表達了我的問題：

我可以插入一個HASH符號（＃）到微觀的爲itemid值和JSON-LD的@id值，來創建一個適當和有效的有效產生的URI使用片段標識符？

因此，如果這是在網頁上：

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

或者，如果這也是網頁：

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

我知道他們將被讀作這樣的URI （假設消費者像谷歌的結構化數據測試工具那樣進行相對構建）：

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

是那個uri：

1. 一個有效的uri;和

2. 它是否正確使用片段標識符（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 （see an example）

因此，如果不瞭解有關後端的更多信息，我會建議使用Hash URI，因爲它通常更易於設置。

（我不知道究竟你的意思「網頁實體」，而只是爲了確保：哈希URI應該是「現實世界對象」，而不是文件）

---

Edit（對於您的問題更新）：

是的，你可以通過指定唯一的片段組成部分（從一#）提供的哈希URI在itemid和@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"解析爲不同的UR是（j與J）。
• 未指定絕對哈希URI時，必須確保當前文檔的URL是規範的。例如，尾部斜槓很重要（/page/#joe與/page#joe）;查詢組件很重要（頁面/page?foo=bar將創建哈希URI /page?foo=bar#joe，而不是/page#joe）;如果主機有www.或不重要; URI方案很重要（http與https）;等等