語意網不只是把資料放在Web上而已，它是一個把東西跟東西連起來的過程，為了讓一個人或是電腦可以探索這個資料的Web。當你已有一些的這種被連起來的資料，你就可以找到其他相關的資料。我們叫這種資料鍵連資料。
就像超連結的Web一樣，資料的Web也是由在Web上的文件構成的。然而，對於超連結的Web來說，這些連結是HTML文件之間的連結，以HTML描述，但是對於資料的Web來說這些連結是用RDF描述的任何東西跟任何東西的連結，以URI來代表任何的物件或是概念。不管是HTML還是RDF，以下的原則使得Web蓬勃發展：
把URI當作東西的名字使用
為了讓人們可以查找這些名字，使用HTTP URI。
當某個人查找某個URI的時候，以規範的標準(RDF, SPARQL)，提供他有用的資料。
在提供他的資料裡，給他指到別的URI的連結，使他可以發現更多東西。
很簡單。但是事實上因為處理以上步驟產生的問題，使得到2006為止有很驚人數量的資料並尚未被連接起來。這篇文章討論這些問題的解決方法、實作的一些細節、跟一些決定你要怎麼發佈你的資料的因素 。
上述那些步驟我把它們當作一種原則，你並不一定要照這些步驟做，不遵守這些原則也並不會發生什麼可怕的事，但是卻會使得你的資料沒機會跟其他資料相互相連，這也使得這些資料被重複使用的可能性被限制住了。這些資料本來可以被使用在連你都不知道的地方，就是這種連你都不知道的可能性使得放在Web上的資料多增添了些許價值。
第一條原則 - 使用URI辨識東西 - 已被作語意網的人所充分了解。若不是使用URI的那些通用符號集合，我們就不稱之為語意網。
第二條原則 - 使用HTTP URI - 也已經被充分了解，除了一些小狀況以外。自從Web開始發展以來，因為某些理由一直有人想要發明新的URI協議(或是urn:協議下的子協議)，像是LSID、Handle System、XRI、DOI等等。一般來說，這些代表那些人不想被已被廣泛使用網域名稱系統(DNS)所規範，而想弄出受其他規範控制的URI。這有時候也跟不了解HTTP URI是用來當名字的(而不是位置)且URI名字的查找過程是一個複雜、強大、且正在進化的標準。在別的地方有這個問題的詳細討論，暫時沒時間在這裡提這個了。(@@連結TAG發現等等)
第三條原則 - 在一個URI上提供資訊。在2006年的這個時候，大部分的在Web上的本體(ontology)已經遵守了這個原則，但是不知道為什麼很多大的資料集卻還沒遵守這個原則。一般來說，你可以查找在資料裡面用的那些屬性跟類然後從那些RDF、RDFS、OWL本體裡面找到資料，這包含那些資料裡的用語跟用語之間的關係。
在這幾年的很多語意網的研究計畫做出了很多本體跟資料庫，不過那些資料，就算是可以自由取得的，也被埋在不知道在哪的zip壓縮檔，而不是做為鍵連資料放在Web上。Biopax與蒐集電腦科學研究者跟專案的CSAktive資料庫是兩個例子。[CSAktive的資料已經在現在(2007)成為鍵連資料了]
現在有更多更多非本體的資料的URI可以被查了。語意維基是一個例 子。"朋友的朋友"(Friend of a friend, FOAF)跟"一個專案的描述"(Description of a Project, DOAP)的兩個本體已被用來建立橫跨整個Web的社交網路。傳統的社交網站裡不會有連到別的網站的連結，那些資料也不是用標準的格式寫的。
LiveJournal跟Opera Community是兩個用RDF發佈資料的社交網站。這代表說我可以在我的FOAF檔案裡面用Opera Community給Håkon Lie的URI寫上我認識他這件事，然後別人或是機器一但瀏覽的這份資料就可以藉由這個連結跟這個連結裡的其他連結找到他的所有朋友。嗯，是他的所有朋友嗎？並不見得：只有他在Opera Community的朋友而已。Opera的系統不讓他存在別的系統上的人們的URI。所以說，雖然Opera的設交網路對連進來的連結來說是開放的，而且可以瀏覽Opera裡的所有人，但是Opera並沒有放連出去的連結。
第四個原則 - 放連到別的地方的連結，是將我們的資料連結成一個網的一個必要條件。這個網可以成為一個強大、無邊界，讓我們可以找到各種東西的網，就像我們辛辛苦苦建起來的超連結的網一樣。
對於超連結的網站來說，不連到相關的外部資料是被認為是相當不好的做法。你的網頁的價值，除了跟這個網頁內容的價值相關以外也跟連到的內容有關。這件事對語意網來說也是一樣的。
現在讓我們來看看連接資料的一些方法，從最簡單的開始。
做鍵連資料最簡單的方式是，在一個檔案裡用一個URI連到一個URI。
如果說你在寫的是一個RDF檔，比如說<http://example.org/smith>，那你就可以用在這個檔案裡的局部id，比如說#albert、#brian、跟#carol。用N3你可以這樣說
<#albert> fam:child <#brian>, <#carol>.
或者用RDF/XML
<rdf:Description about="#albert"
<fam:child rdf:Resource="#brian">
<fam:child rdf:Resource="#carol">
</rdf:Description>
這時候WWW的架構就給了Albert一個廣域的id "http://example.org/smith#albert"。這是一件非常值得去做的事情，畢竟現在在這個星球上的任何一個人都可以用這個廣域id去表示Albert並給予更多的資訊。
比如說，在文件<http://example.org/jones>有人可能會這樣寫：
<#denise> fam:child <#edwin>, <smith#carol>.
或者用RDF/XML
<rdf:Description about="#denise"
<fam:child rdf:Resource="#edwin">
<fam:child rdf:Resource="http://example.org/smith#carol">
</rdf:Description>
很明顯一個遇到id "http://example.org/smith#carol"的人會去：
我們叫這個步驟「參照URI(dereference the URI)」。這就是基礎語意網
有幾個變化。
有一些情況下一個文件裡面有數個id並不是那麼好。一份文件裡面有一個廣域id也是合理的，且有些人並不喜歡在URI裡面放#，像是
http://wordnet.example.net/antidisesablishmentarianism#word
由於歷史因素，那些比較早的字彙像是Dublin Core跟FOAF的URI裡面沒有#。不管怎麼樣，假如說我們用沒#的HTTP URI代表抽象的概念且我們有一份文件載有這些概念的資訊，那我們應做好以下設定：
這種方式的好處是URI可以是各種各樣的形式(有#或沒有#)。壞處是美一個概念就要有一個HTTP請求。比如說Dublin Core的情況裡，dc:title跟dc:creator等等事實上是從同一個本體文件來的，不過在得到那些HTTP轉址碼之前沒人知道這種事。
"朋友的朋友"的常規做法也是一種資料的連結，不過不是前面提到的那兩種。要提到別的FOAF檔裡面的人，常規的做法是給兩個屬性，一個指向描述那個人的文件，另一個用來標示那個人。
<#i> foaf:knows [
foaf:mbox <mailto:joe@example.com>;
rdfs:seeAlso <http://example.com/foaf/joe> ].
讀作「我知道email有joe@example.com的那個人，且那個人的資訊在
事實上，因為隱私權因素，人們不會把他們的email直接放在網上而放一個那個email的單向hash (SHA-1)。這個聰明的小技巧讓知道他們email的人算出那是同一個人，儘管email沒有被公開。
<#i> foaf:knows [
foaf:mbox_sha1sum "2738167846123764823647"; # @@ dummy
rdfs:seeAslo <http://example.com/foaf/joe> ].
這個連結系統是非常成功的，目前仍在成長中，且在2006的這個時候是鍵連資料的最主要的部份。
然而，這個系統的一個小缺點是它不會給人們URI，所以之前一開始提到的基礎連結的方式就不行了。
我建議(在部落格的文章語意網上的連結、給你自己一個URI、跟在RDF裡向前向後的連結同等重要)做FOAF檔的人給自己一個URI同時使用FOAF的常規做法。同樣的，當有一個人的FOAF檔給他了一個URI而你要提到他這個人的時候，用他的URI代表他這個人，這樣只會用URI的而不知道FOAF的常規做法的那些軟體才能跟著那些連結走。
一個重要的方式是你一定要讓使用者可以藉由抓資料→點裡面的連結→抓資料的模式探索你的資料。當一個人查找一個RDF圖裡一個點的URI時，伺服器回傳從那個點向外跟向內的所有連結。也就是，它應該回傳任何主詞或是受詞是該URI的任何RDF敘述。
嚴格來說，我們叫一個圖G可連結圖若，對於G裡面的任何一個URI，假如我查找那個URI我可以得到描述那個點的資訊。「描述那個點」的意思是：
實際上來說，這但表任何的一個描寫在兩個檔案裡的兩個東西的關係RDF敘述都會有重複的一份拷貝。所以，比如說在我的FOAF頁裡我提到說我是DIG組的一員，這份資料就會重複在DIG組的資料裡。這樣的話一個從DIG組開始瀏覽的人會發現我也是一個組員。事實上，從我的URI開始走可以找到所有在同一個組的組員。
所以說描述在兩個文件裡的東西之間關係的敘述必須要在兩個文件裡面重複。這很明顯了違背了資料儲存的根本原則：不要在兩個不同的地方存相同的資料，確保他們同步是有困難的。這的確是可瀏覽資料的一個問題。一份完整且含有雙向連結的可瀏覽資料應該要是完全同步的，不過這需要所有的作者跟程式互相配合。
我們可以有完全可瀏覽的資料，只要我們讓資料自動產生。比如說，dbview伺服器可以讓任何的關連資料庫產生可以瀏覽的虛擬文件。
若我們有從很多個地方找來的資料，我們就有共識。這些共識是由常識與以下的問題來的，
「如果某個人得到一個東西的URI，跟這個東西相關的其他東西有哪些是值得知道的呢？」
有時候一些社交常識決定了答案。我在我的FOAF檔說我認識各個人。但是這些人一般不會在他們的FOAF檔講這件事。某個人可以講他認識我，這是他以FOAF的常規寫的東西，這是他的檔案所以是他寫的，由讀者去決定相不相信。
有時候，連結的數目使得知道所有的連結很不實際。一個GPS軌跡服務可以記錄數千萬個我所在的經度緯度。每一個讀我的FOAF檔的人會希望知道我的名片上會有的內容，不會希望知道那些GPS記錄。從那些GPS記錄裡(甚至是美一個點)有連到我的連結是合理的，但另一個方向不是。
一個解法是把某一個屬性的所有連結放到另一個文件裡。一個人的首頁不會有他的所有論文，但是會有一個到放他所有論文的文件的連結。我們了解到foaf:made會連到那個人做的某件工作，而foaf:pubs會連到那個人做的工作的列表的一份文件。因此，某個在找foaf:made的連結的人可以就沿著foaf:pubs的連結查找。如果把這個 概念形式化，把以下的敘述放到其中一個本體裡的話
foaf:made link:listDocumentProperty foaf:pubs.
可能會很有用。
有時候龐大的資料數量雖然可能可以分成很多個檔案，但是對於有效率的遠端查詢卻是不可能的。這種情形的話，提供一個SPARQL查詢服務是合理的。要讓資料更顯著的互相連結，當某個人得到一個東西的URI時他應該要能找到有該東西資料的SPARQL節點(SPARQL endpoint)。
這裡又可以用HTTP 303回應了，提供到一個描述怎麼樣的種類的URI可以用哪個查詢服務節點的文件的轉址就行了。
描述這種方法的字彙還尚未被標準化。鍵連資料對把語意網連結起來是個關鍵。只要多想一想會發現這蠻簡單的，也會變成一種習慣。其他的常識判斷會決定什麼時候要放一個連結什麼時候不要。
Tabulator(在一個合適的瀏覽器上跑)讓你瀏覽用上述方法建構起來的鍵連資料，也可以讓你確認你的鍵連資料是不是正確的。
參考資料
[Ding2005] Li Ding, et. al., Tracking RDF Graph Provenance using RDF Molecules, UMBC Tech Report TR-CS-05-06
2006-02 Rob Crowell改進了Dan Connolly的把SQL資料轉成鍵連RDF的DBView(2004)，他加入了雙向連結。
2006-09-05 Chris Bizer跟其他人改進了D2R Server，讓他可以以鍵連資料的模式看一個資料庫。
2006-10-10 Chris Bizer跟其他人寫了一個Semantic Web Client Library，「技術上來說，這個libray讓你可以把整個Semantic Web當作是一單個Jean的RDF圖或是Jena Model」程式碼會為了回答某些問題去抓Web上的文件。
2007-01-15 Yves Raimond寫了Semantic Web client for SWI prolog，它有類似的功能。