本文描述的是推薦系統使用Linked Data做爲主要數據源的情況。
注：文中的SparQL語句可以在這裏查詢
首先介紹一點背景信息。Dr. Gautam Shroff在《Web Intelligence and Big Data》裏提到語義網（semantic web）大致的vision是：將facts和rules從現有的web裏面提取出來。老的facts又和rules產生新的facts，於是semantic web不斷壯大。他指出這樣的semantic web雖然沒有被實現，但能跨領域地表示knowledge（facts和rules）的技術已經出現了：RDF（Resource Description Framework）RDFS（RDF Vocabulary Definition Language），OWL（Web Ontology Language）等。
<----------------------------------------
小知識：RDF使用3元組的形式組織數據：subject(主語)，predicate(謂語)，object(賓語)。其中，subject和object可以均是由URI標識的resource，也可以分別是resource和字符串。RDFS和OWL能用於創建描述entity和entity之間聯繫的vocabularies。Vocabularies是classes和 properties 的集合，他們被表示成RDF格式，使用的是RDFS和OWL中的術語。（摘譯自[29]）
----------------------------------------->
Linked Data可以看成一種協議，它用於描述如何將有關聯的data連接起來，以形成一個knowledge base（可以簡單地當做存儲knowledge的datasets）。不同的knowledge base又可以相互連接，最終形成LOD（Linked Open Data） cloud，部分截圖如下（來自這裏）：
圖中每個圈表示一個knowledge base，圈內部又是很多相互連接的data。來看張內部放大圖，大致是這樣子的：
從圖中，我們可以獲取挺多信息。比如，《洛奇II》的導演是史泰龍，他同時也是裏面的主角。
回到圖1。其中，DBpedia是從Wikipedia中抽取knowledge而建立起來的。Wikipedia中的每一篇文章在DBpedia裏都有對應的URI。因此，DBpedia也被稱爲Linked Data version of Wikipedia。由於Wikipeida內容本身涉及不同領域，DBpedia便成爲了LOD cloud 的一個core，或者說是hub —— 連接了來自不同領域的knowledge bases。其他的knowledge bases有LinkedMDB（RDF version of IMDB）,Freebase等。
首先，Wikipedia裏有個叫infobox的模板，通常位於文章的最右上角，用來概括每篇文章的重要內容。比如，英文維基百科中，關於Leonardo DiCaprio的infobox如下：
----------------------------------------->
可以看到，整個LOD cloud跟傳統的互聯網很相似。搜索引擎可以順着data間的鏈接將數據爬下來，以提供類似傳統搜索引擎的搜索功能。查詢使用的語言是SPARQL，有點類似SQL語句。很多knowledge base都提供了SPARQL endpoint，方便用戶查詢。當然，相互連接起來的data作用不止供用戶查詢、瀏覽這麼簡單。更重要的，在linked data 格式下，data以及data之間的關係能夠被計算機理解、處理。其實，linked data主要是給機器看的！
機器能理解數據後，會有什麼好處？舉個簡單的例子。回想最簡單的搜索方法：關鍵字匹配。它的問題在於一個詞在不同的語境下有不同的含義，而且還會存在近義詞。因此，基於關鍵詞匹配的上下文廣告推薦效果不好。但若將關鍵詞對應的概念（concept）映射到knowledge base中，就能大大消除概念之間的歧義和模糊性。因爲與其相連的resource能夠確定該concept的上下文環境。
接下來纔是文章的重點，我們如何把knowledge base運用到推薦系統中？首先，要利用knowledge base中的關係網絡，就要把現實裏的item映射到裏面去。由於[22]使用Movielens數據集，因此它首先通過SPARQL查詢語句將MovieLens裏的電影映射到DBpedia（即movie id -> URI in DBpedia）。使用如下SparQL查詢語句：（注：其實用id映射感覺更好，因爲DBpedia Ontology中有個property就是imdbId ）
SELECT DISTINCT ?movie ?label ?year WHERE {
?movie rdf:type dbpedia-owl:Film.?movie rdfs:label ?label.
?movie dcterms:subject ?cat .
?cat rdfs:label ?year .
FILTER langMatches(lang(?label), "EN") .
FILTER regex(?year, "^[0-9]{4} film", "i")
}
ORDER BY ?label
然後借鑑文本處理中詞袋（bag-of-word）模型的思想，將一個item用tf-idf向量表示。然後使用SVM來對item分類：（大於3分的）喜歡和（否則）不喜歡（就像將郵件分類爲spam和not spam一樣）。[23]整體上採用相同的方法，不過它另外使用了 Freebase 和 LinkedMDB 。作者沒有重新將MovieLens中的電影重新映射到這兩個knowledge base上，而是使用property owl: sameAs 直接將DBpedia裏的resource 與 Freebase 和 LinkedMDB 的resource聯繫起來。
回到item的表示上來。具體如何計算每個物品對應的tf-idf向量，可以參見[23]。大致是將movie看成document，與movie通過某一property相連的resource看成keyword。可見作者是將不同property分別考慮的。由於與電影相關的property不只一個，如starring，director等等。因此，一部movie相當於是按property分段表示的。有了向量表示（也被稱爲Vector Space Model），作者使用cosine計算兩個向量的相似度。這裏又涉及如何結合不同屬性對應的similarity，以得到最終similarity的問題。基本思想是爲不同property賦予不同的權值。[23]提供了兩種方案：（1）採用遺傳算法。（2）使用Amazon給用戶的推薦。具體地，如果Amazon推薦電影b給看過電影a的用戶，那麼連接a和b的屬性p對應的權值加1，最後進行歸一化。這兩個方法求得的property權值向量都是全局的。
然而如何選擇property？話句話說，哪些property能體現兩部電影的客觀相似性，或者（從用戶角度來說）主觀相似性。 [23]指出三種情況：(1) 兩部電影直接相關，如同屬一個系列的，如The Ring I，The Ring II。可以使用dbpedia-owl:previousWork和subsequentWork表示。(2) 對同一個property來說，兩部電影共享一個object。(3) 對同一個property來說，兩部電影共享一個subject。最終，作者使用瞭如下propery：(1) dcterms:subject計算電影所屬類別，並使用skos:broader獲得更高層類別（可以看到適當的類別expansion是有益的）；(2) dbpedia-owl:wikiPageWikiLink：用以指示Wikipedia中兩個page間的鏈接；(3) dbpedia-owl中的property，如dbpedia-owl:starring, dbpedia-owl:director。更多使用如下SparQL查詢語句查看：
SELECT ?p, COUNT(?p) AS ?n WHERE {
?s a dbpedia-owl:Film .
?s ?p ?o .
FILTER(regex(?p, "^http://dbpedia.org/ontology/"))
}
GROUP BY ?p
ORDER BY DESC(?n)
最後梳理一下：
I 準確度不高。雖然[23]沒有將純基於knowledge base的推薦系統與傳統的基於CF的推薦系統對比，但[22]的結果顯示，它跟CF-based之間的準確度是有差別的。
II 只適用於隱式評分。基於knowledge base的推薦系統只適用於隱式評分問題。因爲，語義不能捕捉一部電影的好壞，同樣題材的片子：有的好，有的就爛。因此只能反過來推：從用戶喜歡的物品裏推出knowledge base裏他喜歡的東西。
III 個性化推薦是個問題。[23]訓練出來的是一個全局property權值向量。這個不符合common sense：不同用戶的側重點不同，有人偏愛演員，有人篇導演。而[22]的方法，如果我沒有理解錯的話，是行不通的。而且使用某一用戶的數據單獨訓練，就無法捕捉用戶之間行爲的聯繫。CF證明這種關係是vital的。因此，如何更好地實現個性化推薦是個問題。
IV property選擇是個問題。在多級評分(如1-5)可用的情況下，將其轉化爲binary評分這一過程本身就損失了很多信息。所映射到的knowledge base的質量又是另一個更大的問題：比如ontology裏面的屬性亂不亂，即具有推薦參考價值的屬性佔多少。因爲，我們自己去看DBpedia film ontology裏的屬性的話，會看到很多相當生僻的屬性。無關的屬性會引入噪聲，SVM雖然在最大margin的限制下VC維度有上限，但也不能把所有屬性一股腦考慮進去。feature數比樣本數大很多時，SVM的效果不好。
IV 信息的缺失。將物品的映射到人工構造的knowledge base會帶來或多或少的信息缺失。理想地，應該從包含更多信息的源數據直接做推薦。何況而且已有的FM被證明是十分有效的。
V 所以，個人覺得用knowledge base作爲唯一數據源來做推薦的效果不會超過傳統的CF。但是可以把它集成進現有的CF算法中去。而且它還有很多其他的用途：用來做推薦的解釋，在跨領域推薦問題中發揮作用以及有助於解決推薦系統冷啓動問題。
update：
————————————————————————————————————————
針對上面總結的I、IV兩點，這篇補充介紹一個使用knowledge的CF混合模型。之前就有文章提出使用ontologies來緩解推薦系統的冷啓動問題，但是它們大多針對評分預測問題。而且這個模型使用近來越來越熱的learning to rank方法進行訓練。
回想以往利用ontology作爲輔助的推薦系統。它們要麼使用用戶的demographic信息來輔助計算用戶的相似度，要麼使用物品的類別信息來輔助計算物品間的相似度。因此，容易想到的是使用knowledge base輔助計算物品間的相似度，然後使用協同過濾算法。這是個方法，不過這裏我們要使用Learning to rank。作者使用圖模型結合評分記錄和knowledge：knowledge base本身是一張圖，而用戶和物品也可以看成一張二分圖。因此，這兩張圖可以無縫地拼接起來。如下圖：
其中，藍色代表用戶，紅色代表物品。綠色代表knowledge中的點。
作者的做法是從這張圖中抽取基於路徑的特徵向量。具體的，向量中的一個item對應一種類型的路徑的數量。由於路徑類型數幾乎是指數級別的，無法考慮所有路徑。而且，不同的路徑應該有不同的權重。因此，作者考慮長度不大於L的路徑。至於權值問題，可以交給機器學習算法自己解決。
文中的機器學習算法採用RF和GBRT的結合體——Bagboo。具體地，它將RF中的每棵樹都替換成了gradient boosted tree。因此，Bagboo即具有RF不會over-fitting的健壯性，又有GBRT高accuracy的特性。
<----------------------
小知識：
Random Forest和Gradient Boosted Regression Tree是兩個強大的機器學習算法。其中，Random Forest的主要思想是使用booststrap sampling訓練多個decision tree（high variance），然後將所有樹的結果平均起來，以減少variance。與RF訓練一個森林不同，GBRT訓練一棵樹。從一棵小樹開始，每次迭代都加入一個high bias的樹（weak learner），以針對當前的訓練error。
------------------------->
數據處理方面，作者將MovieLens和LastFM中少於20個評分項的用戶刪掉。將剩下的物品使用類似的方法映射到DBpeida，再去掉沒有映射的物品。然後迭代式地查詢與物品直接相關、間接相關的entity。如查詢Adele寫的歌：SELECT ?s WHERE{ ?s dbpedia-owl:writer dbpedia:Adele. }
參考文獻：
[23] Linked Open Data to support Content-based Recommender Systems
[27] Top-N Recommendations from Implicit Feedback leveraging Linked Open Data