上一篇：《Using OpenRefine》翻譯~14
•點3-增加解析服務
本小點中，你應該已經安裝好了RDF擴展包。如果沒有請參考上一點。如果已經裝好了，那麼你可能會對RDF 和SPARQL代表什麼意思感到疑惑，因爲這兩個詞彙一隻出現，現在讓我們解釋一下：
Resource Description Framework (RDF) 是一種可以被機器讀取的數據模型。因爲人類能讀懂互聯網上的HTML格式，而機器卻不能，所以需要爲機器準備其能夠讀懂的格式。不會引起歧義是很重要的一方面；比如Washington是個城市還是人名，或者究竟是哪個人？爲了解決這個問題，RDF使用URL或者URI來唯一確定。就如我們在OpenRefine進行解析一樣。這就是爲什麼用RDF進行解析比較有用的原因。
SPARQL Protocol and RDF Query Language (簡稱SPARQL)，是一種查詢RDF數據源的語言。傳統的關係型數據庫試用SQL爲查詢語言；RDF數據庫解析通訊就使用SPARQL語言。
如果你想將你的數據與一個RDF數據源進行解析，那麼你就必須告訴OpenRefine與這個數據源的通訊方式。當你安裝好RDF擴展包後，你就已經給OpenRefine添加了SPARQL語言支持。但是，在我們可以將單元格值解析成URL前，我們必須配置好數據源。單擊右側頂部的RDF按鈕，選擇Add reconciliation service| Based on SPARQL endpoint…. ，你也可以使用本地RDF文件進行解析，這樣當然更加便捷。OpenRefine 會顯示Add SPARQL-based reconciliation service對話框：
這個對話框首先讓你選擇SPARQL服務端點的名稱，服務端點的細節（位置及工作模式），以及什麼樣的信息用來匹配單元格值與URL。你可以使用自己的SPARQL服務端點或者http://www.w3.org/wiki/SparqlEndpoints.中列出的公開服務端點。
在本例中，我們將使用我們已經建立的服務端點。這包含了Library of Congress SubjectHeadings(LCSH) 數據集的最新公開版本。爲了使用這個服務端點，我們按如下參數設置：
• Name: LCSH
• Endpoint URL: http://sparql.freeyourmetadata.org/
• Graph URI: http://sparql.freeyourmetadata.org/authoritiesprocessed/
• Type: Virtuoso
• Label properties:只勾選 skos:prefLabel
Endpoint URL 是服務端點具體的位置， Graph URI指明瞭究竟是用該服務端點中哪個數據集。Type 指明服務端點所使用的軟件。這並不需要一定指明，但是知道這些細節能夠極大提升底層解析速度。最後， Label properties指明瞭用那些字段來解析單元格值。在RDF中，這些屬性一般有一個通用的名稱（事實上一般就是URL地址），一旦設置完畢，點擊OK確定。
現在並沒有發生什麼變化，你可能會疑惑我們該如何知道這個新的解析是否正確添加好了。你可以通過在Categories 列下拉菜單中選擇Reconcile | Start reconciling…. 來驗證。在彈出對話框左側應該將看到新的服務名稱。現在讓我們進入下一點學習，你一定迫不及待了。
•點4-與關聯數據進行解析
在上一小點 中 ，我們簡單介紹了RDF 和 SPARQL，但是並沒有深入。所以本小點我們將深入介紹。大概2000年左右，互聯網研究者和工程師發現人類並不是互聯網唯一的使用者；越來越多的機器客戶端以及軟件基於不同目的開始使用互聯網。但是，每個軟件必須爲了某個特定的任務進行編碼，軟件也無法理解互聯網中用自然語言寫成的文檔。因此，一種Semantic Web（語義網）的概念形成了，這是一種可以被機器解析的網絡。這就是RDF 和 SPARQL的開端。
但是，這個概念實在對於大多數人太過抽象。很多概念是基於本體論和推理學的。互聯網發明者以及Semantic Web概念提出者之一的Tim Berners-Lee發現了這個問題，所以發起了數據鏈接準則（http://www.w3.org/DesignIssues/LinkedData.html），這些準則關注於基於語義網絡的數據集互聯。其主要的準則如下：
1、 使用URI作爲名稱
2、 使用HTTP URI，使得用戶能夠查詢這些名稱
3、 當某人查詢一個URI時，使用標準化的方式(RDF, SPARQL)提供有用信息。
4、 包含鏈接到其他URI，這樣我們可以發現更多的東西。
第一條準則要求使用無歧義的標識符來表示內容，第二條準則明確了URL來對應HTTP URI。我們對數據集進行解析都將用到這些準則。第三條準則明確了數據集發佈的準則。事實上，RDF擴展包能夠讓我們導出數據集爲RDF格式。第四條準則是關於數據集互聯的，這也是數據解析所要做到的東西。
閒話少說，讓我們開始解析。就像點1-使用FREEBASE解析值一樣，選擇Categories列下拉菜單：Reconcile | Start reconciling…, 這將打開解析對話框，這次我們選擇左側LCSH reconciliation service，上一小點中我們已經安裝完畢了。OpenRefine 會猜測單元格值類型。幾秒以後，其會提示建議值爲skos:Concept.這是正確的，因爲Category列確實是一些事實內容。你可以讓其他的設置保持默認然後點擊Start Reconciling.
|
就像前面所介紹的，你可以使用數據子集才嘗試上述步驟以節省時間。或者，你可以在其處理時休息一下。 |
當解析結束後，你會發現三處情況。首先，OpenRefine創建了透視圖包含兩項透視項，一項是匹配到的行，另一項是未匹配到的行。第二，你可以在Category列頂部看到一個綠色指示條，這指示了有多少數據被成功解析。第三，單元格值內容會顯示不同；某些是藍色，另一些有新的選項。
讓我們首先關注顯示爲藍色的已解析項。這些項越多表示解析的越成功（頂部綠色條越長）。顯示爲藍色是因爲它們是鏈接項；如果你點擊這些鏈接，你會打開該URL對應的頁面。比如，你點擊鏈接Specimens，我們就會打開http://id.loc.gov/authorities/subjects/sh87006764.html此鏈接，所以這就是我們創建的鏈接數據。對於電腦來說，現在不再是面對一個單獨的字符串Specimens，而是被OpenRefine解析好的一個URL地址。這個地址能夠被機器所解析，因爲這個URL地址鏈接到了其他地址，所以機器能夠很好的理解其意義。
你看見的黑色的值表示未被解析項，表示這些項目未被找到。這些值不是鏈接，所以OpenRefine並未自動找到一個URL匹配項。未解析有兩個方面問題；首先，找到了多個建議項，但是OpenRefine無法確定究竟是哪個，這時其會列出一些可選項給你，如果某一項是正確的，那麼你就可以單擊該項，這樣該項內容就會替換當前值，也可以雙擊該項，那麼所有具有相同內容的項都會被替換成該項內容。這需要很仔細，因爲很有可能某些項其實是指向其他鏈接條目的。記得可以點擊這個建議項的鏈接，這樣會打開相應頁面以方便確認信息。
未解析項的產生還有一個原因，那就是OpenRefine沒有找到匹配項。這種情況，我們只能說是運氣不好。可能是你的數據中的條目並沒有在解析數據庫中，或者是名字上有區別導致匹配不到。這種情況下，你只能手工給其指定一個URL。可以點擊search for match鏈接，打開的對話框可以幫助你找到正確的匹配。
最後一個可選動作是點擊Create new topic 鏈接（或者在Search for Match對話框中選擇New Topic）爲單元格值創建一個新的主題，這並不是在LCSH 數據庫中創建一個新的URL（本身你也沒有權限這麼做），其只不過將這些單元格值標成new.這樣你就可以在judgement透視界面進行其他操作，比如，你可以使用其他的數據集對這些值重新解析，以看看是否能夠找打匹配。
我們如何才能獲取解析結果中的URL地址？同時，如何保留原始category列內容。正確的做法是基於Categories列創建一個新列，就像我們以前曾經做過的一樣，點擊Categories列下拉菜單： Edit Column | Add column based on this column…. 我們將這一列命名爲Category URLs. 輸入URL轉換表達式cell.recon.match.id.這段GREL代碼將單元格解析後的信息中的ID（這裏就是URL）抽取出來。那些沒有匹配到的項會出現錯誤提示，所以請確保勾選set to blank（對於錯誤項），點擊OK後，你將看到包含對應URL地址的新列。
當你做完解析過程及抽取到需要的URL後，你可能想將Categories列恢復原貌。畢竟，解析數據還在那裏，可能對我們產生干擾。爲了清除它們，再次點擊Categories 列下拉菜單： Reconcile| Actions| Clear reconciliation data. 這樣categories 列就會恢復原貌。當然，你還可以通過點擊左側透視窗口頂部的Remove All按鈕恢復原貌。