 |
 |
 |
 |
 |
 |
||
 |
 |
 |
 |
 |
| 5 | 1/1 | 返回列表 |
| 查看: 1560 | 回復: 3 | |||
| 當前只顯示滿足指定條件的回帖，點擊這里查看本話題的所有回帖 | |||
stephenyong銅蟲 (初入文壇)
|
[交流]
關于Linked Data（轉） 已有2人參與
|
||
|
蒂姆·伯納斯-李(Tim Berners-Lee) 翻譯: 呂康豪(請參考原文 有任何翻譯上的歡迎寄信到kennyluck@csail.mit.edu) 日期: 2006-07-27, 最后修改: $Date: 2009/06/18 18:24:33 $ 翻譯日期: 2010-01-11 狀態(tài): 僅可個人閱讀 編輯裝態(tài): 不完美但是發(fā)表了 回到Design Issues 鍵連資料(Linked Data) 語意網(wǎng)不只是把資料放在Web上而已，它是一個把東西跟東西連起來的過程，為了讓一個人或是電腦可以探索這個資料的Web。當你已有一些的這種被連起來的資料，你就可以找到其他相關的資料。我們叫這種資料鍵連資料。 就像超連結的Web一樣，資料的Web也是由在Web上的文件構成的。然而，對于超連結的Web來說，這些連結是HTML文件之間的連結，以HTML描述，但是對于資料的Web來說這些連結是用RDF描述的任何東西跟任何東西的連結，以URI來代表任何的物件或是概念。不管是HTML還是RDF，以下的原則使得Web蓬勃發(fā)展： 把URI當作東西的名字使用 為了讓人們可以查找這些名字，使用HTTP URI。 當某個人查找某個URI的時候，以規(guī)范的標準(RDF, SPARQL)，提供他有用的資料。 在提供他的資料里，給他指到別的URI的連結，使他可以發(fā)現(xiàn)更多東西。 很簡單。但是事實上因為處理以上步驟產(chǎn)生的問題，使得到2006為止有很驚人數(shù)量的資料并尚未被連接起來。這篇文章討論這些問題的解決方法、實作的一些細節(jié)、跟一些決定你要怎么發(fā)布你的資料的因素 。 四個原則 上述那些步驟我把它們當作一種原則，你并不一定要照這些步驟做，不遵守這些原則也并不會發(fā)生什么可怕的事，但是卻會使得你的資料沒機會跟其他資料相互相連，這也使得這些資料被重復使用的可能性被限制住了。這些資料本來可以被使用在連你都不知道的地方，就是這種連你都不知道的可能性使得放在Web上的資料多增添了些許價值。 第一條原則 - 使用URI辨識東西 - 已被作語意網(wǎng)的人所充分了解。若不是使用URI的那些通用符號集合，我們就不稱之為語意網(wǎng)。 第二條原則 - 使用HTTP URI - 也已經(jīng)被充分了解，除了一些小狀況以外。自從Web開始發(fā)展以來，因為某些理由一直有人想要發(fā)明新的URI協(xié)議(或是urn:協(xié)議下的子協(xié)議)，像是LSID、Handle System、XRI、DOI等等。一般來說，這些代表那些人不想被已被廣泛使用網(wǎng)域名稱系統(tǒng)(DNS)所規(guī)范，而想弄出受其他規(guī)范控制的URI。這有時候也跟不了解HTTP URI是用來當名字的(而不是位置)且URI名字的查找過程是一個復雜、強大、且正在進化的標準。在別的地方有這個問題的詳細討論，暫時沒時間在這里提這個了。(@@連結TAG發(fā)現(xiàn)等等) 第三條原則 - 在一個URI上提供資訊。在2006年的這個時候，大部分的在Web上的本體(ontology)已經(jīng)遵守了這個原則，但是不知道為什么很多大的資料集卻還沒遵守這個原則。一般來說，你可以查找在資料里面用的那些屬性跟類然后從那些RDF、RDFS、OWL本體里面找到資料，這包含那些資料里的用語跟用語之間的關系。 在這幾年的很多語意網(wǎng)的研究計畫做出了很多本體跟資料庫，不過那些資料，就算是可以自由取得的，也被埋在不知道在哪的zip壓縮檔，而不是做為鍵連資料放在Web上。Biopax與蒐集電腦科學研究者跟專案的CSAktive資料庫是兩個例子。[CSAktive的資料已經(jīng)在現(xiàn)在(2007)成為鍵連資料了] 現(xiàn)在有更多更多非本體的資料的URI可以被查了。語意維基是一個例 子。"朋友的朋友"(Friend of a friend, FOAF)跟"一個專案的描述"(Description of a Project, DOAP)的兩個本體已被用來建立橫跨整個Web的社交網(wǎng)路。傳統(tǒng)的社交網(wǎng)站里不會有連到別的網(wǎng)站的連結，那些資料也不是用標準的格式寫的。 LiveJournal跟Opera Community是兩個用RDF發(fā)布資料的社交網(wǎng)站。這代表說我可以在我的FOAF檔案里面用Opera Community給Håkon Lie的URI寫上我認識他這件事，然后別人或是機器一但瀏覽的這份資料就可以借由這個連結跟這個連結里的其他連結找到他的所有朋友。嗯，是他的所有朋友嗎？并不見得：只有他在Opera Community的朋友而已。Opera的系統(tǒng)不讓他存在別的系統(tǒng)上的人們的URI。所以說，雖然Opera的設交網(wǎng)路對連進來的連結來說是開放的，而且可以瀏覽Opera里的所有人，但是Opera并沒有放連出去的連結。 第四個原則 - 放連到別的地方的連結，是將我們的資料連結成一個網(wǎng)的一個必要條件。這個網(wǎng)可以成為一個強大、無邊界，讓我們可以找到各種東西的網(wǎng)，就像我們辛辛苦苦建起來的超連結的網(wǎng)一樣。 對于超連結的網(wǎng)站來說，不連到相關的外部資料是被認為是相當不好的做法。你的網(wǎng)頁的價值，除了跟這個網(wǎng)頁內容的價值相關以外也跟連到的內容有關。這件事對語意網(wǎng)來說也是一樣的。 現(xiàn)在讓我們來看看連接資料的一些方法，從最簡單的開始。 基礎的Web查找 做鍵連資料最簡單的方式是，在一個檔案里用一個URI連到一個URI。 如果說你在寫的是一個RDF檔，比如說<http://example.org/smith>，那你就可以用在這個檔案里的局部id，比如說#albert、#brian、跟#carol。用N3你可以這樣說 <#albert> fam:child <#brian>, <#carol>. 或者用RDF/XML <rdf  escription about="#albert"<fam:child rdf:Resource="#brian"> <fam:child rdf:Resource="#carol"> </rdf escription>這時候WWW的架構就給了Albert一個廣域的id "http://example.org/smith#albert"。這是一件非常值得去做的事情，畢竟現(xiàn)在在這個星球上的任何一個人都可以用這個廣域id去表示Albert并給予更多的資訊。 比如說，在文件<http://example.org/jones>有人可能會這樣寫： <#denise> fam:child <#edwin>, <smith#carol>. 或者用RDF/XML <rdf escription about="#denise"<fam:child rdf:Resource="#edwin"> <fam:child rdf:Resource="http://example.org/smith#carol"> </rdf escription>很明顯一個遇到id "http://example.org/smith#carol"的人會去： 把#字前面的文件的URI拿出來 去讀那個文件以得到#carol的資訊 我們叫這個步驟「參照URI(dereference the URI)」。這就是基礎語意網(wǎng) 有幾個變化。 變化：沒斜線的URI跟HTTP 303 有一些情況下一個文件里面有數(shù)個id并不是那么好。一份文件里面有一個廣域id也是合理的，且有些人并不喜歡在URI里面放#，像是 http://wordnet.example.net/antidisesablishmentarianism#word 由于歷史因素，那些比較早的字匯像是Dublin Core跟FOAF的URI里面沒有#。不管怎么樣，假如說我們用沒#的HTTP URI代表抽象的概念且我們有一份文件載有這些概念的資訊，那我們應做好以下設定： 對一個概念的URI送一個HTTP GET請求的話要傳回303 See Also并給Location:接上那份文件的URI 那份文件就會被像一般情況一樣被傳回 這種方式的好處是URI可以是各種各樣的形式(有#或沒有#)。壞處是美一個概念就要有一個HTTP請求。比如說Dublin Core的情況里，dc:title跟dc:creator等等事實上是從同一個本體文件來的，不過在得到那些HTTP轉址碼之前沒人知道這種事。 變化：FOAF跟rdfs:seeAlso "朋友的朋友"的常規(guī)做法也是一種資料的連結，不過不是前面提到的那兩種。要提到別的FOAF檔里面的人，常規(guī)的做法是給兩個屬性，一個指向描述那個人的文件，另一個用來標示那個人。 <#i> foaf:knows [ foaf:mbox <mailto:joe@example.com>; rdfs:seeAlso <http://example.com/foaf/joe> ]. 讀作「我知道email有joe@example.com的那個人，且那個人的資訊在里」。 事實上，因為隱私權因素，人們不會把他們的email直接放在網(wǎng)上而放一個那個email的單向hash (SHA-1)。這個聰明的小技巧讓知道他們email的人算出那是同一個人，盡管email沒有被公開。 <#i> foaf:knows [ foaf:mbox_sha1sum "2738167846123764823647"; # @@ dummy rdfs:seeAslo <http://example.com/foaf/joe> ]. 這個連結系統(tǒng)是非常成功的，目前仍在成長中，且在2006的這個時候是鍵連資料的最主要的部份。 然而，這個系統(tǒng)的一個小缺點是它不會給人們URI，所以之前一開始提到的基礎連結的方式就不行了。 我建議(在部落格的文章語意網(wǎng)上的連結、給你自己一個URI、跟在RDF里向前向后的連結同等重要)做FOAF檔的人給自己一個URI同時使用FOAF的常規(guī)做法。同樣的，當有一個人的FOAF檔給他了一個URI而你要提到他這個人的時候，用他的URI代表他這個人，這樣只會用URI的而不知道FOAF的常規(guī)做法的那些軟體才能跟著那些連結走。 可瀏覽圖 我們已經(jīng)看到了造連結的一些方法了，讓我看看針對「什么時候要造連結」這個問題的一些想法。 一個重要的方式是你一定要讓使用者可以借由抓資料→點里面的連結→抓資料的模式探索你的資料。當一個人查找一個RDF圖里一個點的URI時，伺服器回傳從那個點向外跟向內的所有連結。也就是，它應該回傳任何主詞或是受詞是該URI的任何RDF敘述。 嚴格來說，我們叫一個圖G可連結圖若，對于G里面的任何一個URI，假如我查找那個URI我可以得到描述那個點的資訊�！该枋瞿莻�點」的意思是： 回傳以那個點為主詞或受詞的所有敘述，且 跟那個點以一個連接相鄰的所有白點。 實際上來說，這但表任何的一個描寫在兩個檔案里的兩個東西的關系RDF敘述都會有重復的一份拷貝。所以，比如說在我的FOAF頁里我提到說我是DIG組的一員，這份資料就會重復在DIG組的資料里。這樣的話一個從DIG組開始瀏覽的人會發(fā)現(xiàn)我也是一個組員。事實上，從我的URI開始走可以找到所有在同一個組的組員。 可瀏覽資料的限制 所以說描述在兩個文件里的東西之間關系的敘述必須要在兩個文件里面重復。這很明顯了違背了資料儲存的根本原則：不要在兩個不同的地方存相同的資料，確保他們同步是有困難的。這的確是可瀏覽資料的一個問題。一份完整且含有雙向連結的可瀏覽資料應該要是完全同步的，不過這需要所有的作者跟程式互相配合。 我們可以有完全可瀏覽的資料，只要我們讓資料自動產(chǎn)生。比如說，dbview伺服器可以讓任何的關連資料庫產(chǎn)生可以瀏覽的虛擬文件。 若我們有從很多個地方找來的資料，我們就有共識。這些共識是由常識與以下的問題來的， 「如果某個人得到一個東西的URI，跟這個東西相關的其他東西有哪些是值得知道的呢？」 有時候一些社交常識決定了答案。我在我的FOAF檔說我認識各個人。但是這些人一般不會在他們的FOAF檔講這件事。某個人可以講他認識我，這是他以FOAF的常規(guī)寫的東西，這是他的檔案所以是他寫的，由讀者去決定相不相信。 有時候，連結的數(shù)目使得知道所有的連結很不實際。一個GPS軌跡服務可以記錄數(shù)千萬個我所在的經(jīng)度緯度。每一個讀我的FOAF檔的人會希望知道我的名片上會有的內容，不會希望知道那些GPS記錄。從那些GPS記錄里(甚至是美一個點)有連到我的連結是合理的，但另一個方向不是。 一個解法是把某一個屬性的所有連結放到另一個文件里。一個人的首頁不會有他的所有論文，但是會有一個到放他所有論文的文件的連結。我們了解到foaf:made會連到那個人做的某件工作，而foaf:pubs會連到那個人做的工作的列表的一份文件。因此，某個在找foaf:made的連結的人可以就沿著foaf:pubs的連結查找。如果把這個 概念形式化，把以下的敘述放到其中一個本體里的話 foaf:made link:listDocumentProperty foaf:pubs. 可能會很有用。 查詢服務 有時候龐大的資料數(shù)量雖然可能可以分成很多個檔案，但是對于有效率的遠端查詢卻是不可能的。這種情形的話，提供一個SPARQL查詢服務是合理的。要讓資料更顯著的互相連結，當某個人得到一個東西的URI時他應該要能找到有該東西資料的SPARQL節(jié)點(SPARQL endpoint)。 這里又可以用HTTP 303回應了，提供到一個描述怎么樣的種類的URI可以用哪個查詢服務節(jié)點的文件的轉址就行了。 描述這種方法的字匯還尚未被標準化。 結論 鍵連資料對把語意網(wǎng)連結起來是個關鍵。只要多想一想會發(fā)現(xiàn)這蠻簡單的，也會變成一種習慣。其他的常識判斷會決定什么時候要放一個連結什么時候不要。 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，它有類似的功能。 |
回復此樓» 猜你喜歡
北科281學碩材料求調劑
已經(jīng)有13人回復
-
289求調劑
已經(jīng)有11人回復
-
網(wǎng)絡空間安全0839招調劑
已經(jīng)有5人回復
-
材料277求調劑
已經(jīng)有4人回復
-
274求調劑
已經(jīng)有7人回復
-
085600 材料與化工 329分求調劑
已經(jīng)有3人回復
-
302求調劑
已經(jīng)有3人回復
-
312求調劑
已經(jīng)有5人回復
-
329求調劑
已經(jīng)有3人回復
-
【2026考研調劑】制藥工程 284分 求相關專業(yè)調劑名額
已經(jīng)有8人回復
» 本主題相關價值貼推薦，對您同樣有幫助:
- Plos one 大修，要求補實驗……
已經(jīng)有34人回復
- 關于Scopus與EI Compendex不得不說的事
已經(jīng)有7人回復
- SCI期刊突然間沒有影響因子？
已經(jīng)有12人回復
- 有知道蛋白質數(shù)據(jù)庫的幫幫小弟
已經(jīng)有8人回復
- 【Journal Club】第3講 水稻全基因組基因網(wǎng)絡生物信息學平臺的建立
已經(jīng)有33人回復
- GAMESS最新安裝通過
已經(jīng)有6人回復
- 求外文文獻文獻
已經(jīng)有11人回復
- nonlinear dynamics怎么樣
已經(jīng)有11人回復
- APL投稿注意事項
已經(jīng)有29人回復
stephenyong
銅蟲 (初入文壇)
- 應助: 0 (幼兒園)
- 金幣: 299.5
- 帖子: 13
- 在線: 11.2小時
- 蟲號: 1841464
- 注冊: 2012-05-31
- 性別: GG
- 專業(yè): 計算機網(wǎng)絡
3樓2013-08-27 08:05:05
Aloha_2012
木蟲 (小有名氣)
- 應助: 0 (幼兒園)
- 金幣: 1733.8
- 帖子: 149
- 在線: 29.7小時
- 蟲號: 1999385
- 注冊: 2012-09-13
- 性別: GG
- 專業(yè): 計算機網(wǎng)絡
2樓2013-08-26 22:28:00
你的唯一123
金蟲 (初入文壇)
- 應助: 0 (幼兒園)
- 金幣: 1198.2
- 紅花: 1
- 帖子: 45
- 在線: 104.2小時
- 蟲號: 2544591
- 注冊: 2013-07-13
- 性別: GG
- 專業(yè): 制造系統(tǒng)與自動化
4樓2013-09-03 19:10:27
| 最具人氣熱帖推薦 [查看全部] | 作者 | 回/看 | 最后發(fā)表 | |
|---|---|---|---|---|
|
[考研] 材料學碩333求調劑 +4 | 北道巷 2026-03-24 | 4/200 |
|
|---|---|---|---|---|
|
|
[考研] 0854電子信息求調劑 +7 | α____ 2026-03-22 | 9/450 |
|
|
|
[考研] 281求調劑 +4 | Koxui 2026-03-24 | 5/250 |
|
|
|
[考研] 0854電子信息求調劑 324 +4 | Promise-jyl 2026-03-23 | 4/200 |
|
|
[考研] 材料調劑 +3 | iwinso 2026-03-23 | 3/150 |
|
|
|
[考研] 化學調劑 +6 | yzysaa 2026-03-21 | 6/300 |
|
|
|
[考研] 一志愿國科過程所081700，274求調劑 +3 | 三水研0水立方 2026-03-23 | 3/150 |
|
|
|
[考研] 一志愿陜師大生物學071000，298分，求調劑 +3 | SYA！ 2026-03-23 | 3/150 |
|
|
|
[考研] 333求調劑 +6 | 87639 2026-03-21 | 10/500 |
|
|
|
[考研] 315分，誠求調劑，材料與化工085600 +3 | 13756423260 2026-03-22 | 3/150 |
|
|
|
[考研] 324求調劑 +6 | lucky呀呀呀鴨 2026-03-20 | 6/300 |
|
|
|
[考研] 初試 317 +7 | 半拉月丙 2026-03-20 | 7/350 |
|
|
|
[考研] 求調劑 +3 | .m.. 2026-03-21 | 4/200 |
|
|
|
[考研] 一志愿南昌大學，327分，材料與化工085600 +9 | Ncdx123456 2026-03-19 | 9/450 |
|
|
|
[考研] 329求調劑 +9 | 想上學吖吖 2026-03-19 | 9/450 |
|
|
|
[考研] 中南大學化學學碩337求調劑 +3 | niko- 2026-03-19 | 6/300 |
|
|
|
[考研] 求調劑一志愿南京航空航天大學289分 +3 | @taotao 2026-03-19 | 3/150 |
|
|
|
[考研] 材料學碩297已過四六級求調劑推薦 +11 | adaie 2026-03-19 | 11/550 |
|
|
|
[考研] 一志愿西南交通 專碩 材料355 本科雙非 求調劑 +5 | 西南交通專材355 2026-03-19 | 5/250 |
|
|
|
[考研] 材料學碩318求調劑 +5 | February_Feb 2026-03-19 | 5/250 |
|