语意网不只是把资料放在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，它有类似的功能。