這篇”Google: You’re Really Dead, Really“說，Amy Wilentz這位美國作家，生於1954年，但是Google卻把她的生日弄成1927年，並且說她已經於1996年過世 (如下圖)。

這個已經不是第一個被Google弄錯的人，Madhav Prasad Ghimire這位尼泊爾的學者，生於1919年，也被Google弄成1909年出生，於1959年過世 (如下圖)。

為什麼會發生這種錯誤呢? 作者推論原因是，可能還有另外一位相同姓名的人，其資料被張冠李戴了，或是Google根本抓到的資料就是錯誤的，也可能從Wikipedia抓到的資料是錯誤的，但是後來Wikipedia更正後，Google並沒有跟著更新。

如下圖: Wikipedia的舊資料確實也是寫~ Madhav Prasad Ghimire生於1909年，於1959年過世。但是後來Wikipedia已經修正錯誤資料，只是Google的Knowledge Graph資料並沒有更新。

所以上述的幾種發生錯誤的原因中，也相同的會出現一般搜尋資料中，例如你要搜尋「pisa」，可能就有許多完全不同的資料都叫~pisa。例如Google也可能抓取了某些信譽良好的網站資料，但是這些網站資料也可能出錯，當然Google就跟著錯了。例如Google的回訪抓取，如果沒有抓到更新的資料，當然就無法更正了。

所以如果我們的網站資料沒能讓Google了解，當然就無法出現在使用者的搜尋中。所以我們從Google的烏龍事件應該記取什麼教訓呢?

(1) 應該使用語意標記，如microdata，讓機器可以順利解讀資料。
(2) 應該讓Google更頻繁的回訪，抓取更多更正的資料。
(3) 應該把更多相關網頁正確的串聯，讓Google知道網頁的相關性。

曾經有許多人說: 我的網頁根本不需要SEO，就可以有不錯的搜尋流量，但是卻不知道，如果能夠透過 SEO讓Google更瞭解的話，會有更驚人的搜尋流量。

Knowledge Graph也有人翻譯成~ 「知識圖譜」或是「知識圖表」。

但是還是覺得「知識結構圖」或是「知識關係圖」比較能夠表示這裡Graph的真正意含。

因為「圖譜」已經在許多領域有既定的用法，指的是有系統性分類的圖集，而「圖表」則跟graph意義差更遠。

graph的意義是指: A graph in this context is a collection of “vertices” or “nodes” and a collection of edges that connect pairs of vertices. A graph may be undirected, meaning that there is no distinction between the two vertices associated with each edge, or its edges may be directed from one vertex to another … 意思就是由「節點」與連接節點的「邊」所組成，具有方向性或是沒有方向性的結構，稱之為graph。

「節點」就是vertices或是nodes，「邊」就是edges。 例如下圖就是一個沒有方向性的graph:

下圖就是一個具有方向性的graph:

為什麼Google要把knowledge跟graph加在一起? 知識具有graph的什麼特性呢?

知識(knowledge)是由訊息(information)而來的，訊息就好像是「節點」，而訊息跟訊息之間的「邊」就是關係，這個關係可能有方向性，也可能沒有方向性。透過「邊」的連接，就讓「節點」與「節點」產生了某些關係。

例如，我們來看看下面的影片介紹

上面的說明中，提到一個例子，我們想知道諾貝爾獎有多少女性得主?

我們就可以從「諾貝爾獎」這個節點出發，找到關係為「得獎者」的節點，並且這個「得獎者」的節點必須是具有「女性」屬性。

而這些資料其實原本就在Google的資料中心，只是沒有解構出「節點」、「邊」、與「屬性」，現在Google推出knowledge graph，表示已經完成了一部分的graph關係，並且可以解析使用者的query (查詢)，瞭解使用者到底想問什麼。

例如你搜尋~ tallest building in the world (世界最高的建築)，你就可以看到如下的內容，左邊是一般的搜尋結果，右邊是特別整理出來的knowledge panel (知識面板)，這個右邊的面板並不是所有的問題查詢都會出現。

但是如果你想查詢~ greatest president in the world (世界最偉大的總統)，對不起 … Google也不知道。

其實這些東西，很早WolframAlpha就已經提供了。

如下圖，如果你一樣搜尋tallest building in the world … WolframAlpha直接給你答案。

但是如果你問wolframalpha ~ greatest president in the world (世界最偉大的總統)，他會告訴你不合邏輯，因為總統是以國家為單位，沒有一個人是世界的總統 … 哈，還蠻有道理的。

如果你問~ greatest president of United States (美國最偉大的總統)，他會避重就輕，只回答你 美國的總統，因為他不知道誰是美國最偉大的總統。

所以許多訊息談到Google knowledge graph，都把這個東西說得太出神入化了，其實Google在這個時間點推出來，有點在提醒大家不要只是一直注意Facebook IPO的味道。

Google在”Introducing the Knowledge Graph: things, not strings“說到，一個完美的搜尋引擎是要真正瞭解你要什麼，並且給你真正想要的東西。意思就是我們Google是一個完美的搜尋引擎，不要只注意Facebook。

但是Google也還算誠實，他也說到”And we can now sometimes help answer your next question before you’ve asked it, because the facts we show are informed by what other people have searched for.” 我們『有時候』能夠在你還沒有提問之前，就知道你想問什麼，因為我們呈現給你的事實是其他人已經搜尋過的。

所以，Google能提供的是已經大家經常詢問的問題，或是已經有人整理過的，Google並沒有那麼厲害自己去推理出來各物件的關係，也許以後可能，但是現在只能做到一小部分。

這篇“Google Launches Knowledge Graph To Provide Answers, Not Just Links“也說到，Google knowledge graph是一個big change (大的改變) 沒有錯，但是還不至於讓使用者有振奮的感覺。

Google目前已經對於五億個物件(object)整理出來35億個事實(fact)，並且大多屬於下列的類型: 演員、導演、電影、藝術品或是博物館、城市或是國家、島嶼、湖泊、燈塔、音樂專輯或是音樂團體、星球或是太空航空器、雲霄飛車或是摩天大樓、 運動團體 … 等等，也就是目前Google knowledge graph並不是所以問題都能夠回答。 其實Google knowledge graph的技術，我們在”搜尋引擎的語意趨勢，你準備好了嗎?“就談過了，他就是透過Semantic Web而產生的結果。

還有一個同樣的老問題，為什麼只有英文的內容才有呢? 除了因為中文的複雜度比較高之外，沒有足夠的可結構性資料來產生適當的物件(object)與事實(fact)也是一個問題，還有一個更重要的問題是~ Google是美國的公司。所以，要等到有中文內容的Google knowledge graph，大概還有得等了。

我們曾經在”搜尋引擎排名曝光度過高也不是好事?“說過，搜尋引擎會越來越知道你要的資料是什麼，並且透過統計方法，經常被需要的資料會直接出現在不需要點選的地方，因此就會造成網站的流量降低。

也就是說，Google可能把你的資料精華「浮」到上面來了，使用者不再需要點選進去你的網站去尋找，雖然讓使用者更方便了，但是卻傷害了網站的流量，就如同百貨公司一樣，Google把使用者最可能需要的東西搬到百貨公司門口，使用者只需要到門口就把東西拿走了，根本不需要再到百貨公司裡面閒逛，當然對於百貨公司來說是很大的傷害。

這篇”Will Google Hurt Your Site By Improving Itself?“就提到了這個問題，例如下圖，當你搜尋[how old is dolly parton]，問Google到底歌手桃莉芭頓幾歲了，Google就會告訴你 … 答案是66歲。你不再需要去努力的爬文，才能找到答案。

之前的文章”SEO : 什麼是 Search Engine Optimization ?“說到~SEO是將網站的資料，清楚的呈現給搜尋引擎，讓搜尋引擎能夠更順利的處理資料，SEO所得到的成果也就是搜尋引擎根據你的貢獻度來回報給你。

但是，現在是否可能SEO所得到的成果卻是無法獲得回報呢?

如同Yelp事件一樣，Google希望得到Yelp的資料，但是卻會讓Yelp流量降低，而Yelp只希望從Google獲得流量，卻不想提供資料給Google。這樣的發展，對於Google跟網站是雙輸的局面。

如下圖，Yelp提供美國各地的店家資訊，有些類似台灣的iPeen 愛評網。

Google的成功是否會是SEO的失敗? 對於某些如Yelp類型的網站而言(提供商家資訊並且獲得商家的廣告贊助)，答案是可能的。而對於不只提供資訊，還銷售商品的網站而言，就沒有太大的影響。

但是是否這些提供商家資訊的網站，就應該排斥讓Google擷取資料呢? 當然不是，「清楚的呈現給搜尋引擎，讓搜尋引擎能夠更順利的處理資料」當然還是最好的原則，但是必須除了提供商家資訊之外，要能夠有額外無法取代的「加值服務」。

如果只是商家資訊，太多競爭者也可以建立相同的網站，就算商家資訊無法從你的網站抓取，也可以透過其他管道取得，或是從頭人工輸入。單純的「商家資訊」並無法建立競爭門檻，只有無法取代的「加值服務」才能創作價值。

Google讓使用者的資料可以直接顯示在搜尋結果上，是無法避免的結果，網站不能因為如此而排斥Rich Snippets，或是語意網相關的標準。

Google的成功是否會是SEO的失敗? 如果答案是的話，那麼你的網站必須思考，為什麼這麼沒有競爭優勢? 你的網站體質必須更加強化，否則就算沒有被Google擊垮，也會被其他競爭者取代。

Semantic : 語意 ，syntax : 語法 ， pragmatics : 語用

syntax語法最容易瞭解，就是指研究文法 (grammar)，文法正確就好，不管意思如何，比如「哥哥 吃了 牆壁」，「哥哥」是主詞、「吃」是動詞、「牆壁」是受詞，而「了」可以說是指完成動詞這個動作的描述，語法上完全沒有問題，但是卻聽起來很怪。

而semantics跟pragmatics兩者意思很近似，這篇文章”Syntax, Semantics, and Pragmatics“將他們的差異解釋得很好:

Semantics is the study of the meanings of linguistic expressions.

Pragmatics has to do with context-dependent features of language. 

pragmatics(語用學)比semantics(語意學)複雜，因為會因為上下文的差異而不同，也可能會因為說話的音調而有不一樣的意義 … 所以semantics只要知道其意義，而pragmatics還要知道在什麼狀況下使用，才能瞭解真正的意義。

以上可能還不容易清楚知道，因此用例子來說明他們的差異 …

如果有人說「不理你了」，就semantics來說，就是「我+不想+理會+你+了」，「理會」的意思可以是「說話」、「在意」、「關心」…. 等等，也就是我要切斷存在跟你中間的「連接線」，semantics是純粹研究這句話的意思。

但是如果談到pragmatics，就必須知道這句話的上下文、語氣 … ，這句話如果是男女朋友間很俏皮的笑說: 「不理你了」，還可能是撒嬌的意思。而除了上下文跟語氣之外，還有整個環境都可能影響同樣一句話的pragmatics上的意義，如女生說: 「我的肚子好像在叫」，她並不是要陳述「肚子在叫」這件事，而是希望男生帶她去「吃飯」，同樣的有人說: 「好像蠻熱的」，也不是要告訴你「熱」這件事，而是暗示你「開冷氣」。

因此，如果真的要知道一句話的真正意義，不能只是semantics，而必須pragmatics，但是就網頁上的內容來說，淬取semantic應該已經足夠。

而semantic web則是為了達成semantic search所做的準備，也就是說semantic web跟semantic search不是相同的意思。

簡單來說semantic web是跟tag (標記) 有關，semantic search 就必須要知道使用者下某個關鍵字所指的真正意義，然後從浩瀚的資料中抓出使用者想要的資料。

就Wikipedia的解釋 … 語意網(Semantic Web) 是在全球資訊網上的文檔(如:HTML)上添加能夠被電腦所理解的語意(Meta data)，從而使整個網際網路成為一個通用的資訊交換媒介。

如果能夠精準的在文檔上加上適當的meta data，則可以將沒有結構化的文檔資料，變化成具有結構化關係的資料，那麼電腦就能夠妥善的處理這些資料來讓我們搜尋。

semantic search (語意搜尋) 則是要瞭解使用者到底想要什麼，利用各種方式來提高搜尋的準確性。當然semantic web只是達成semantic search的其中一個方式，因為不可能先把所有文檔都加上meta data，還是會有許多資料是非結構化而且非常凌亂的。只是建構semantic web可能是達成semantic search比較省力的方式，並且semantic web除了達成semantic search外，還有其他目的，就是讓電腦跟人腦一樣能夠瞭解資料，讓電腦自動去完全一些事情。

所以企業網站就是要盡量做到semantic web (語意網)的要求，讓搜尋引擎比較容易進行Semantic Search (語意搜尋)。

所以搜尋引擎不僅要Give me what I said，而更要Give me what I want! 但是要做到這樣，你就必須協助搜尋引擎，給他semantic web (語意網)就是最基本的工作。

因為亞馬遜書店的PageRank值高, 因為亞馬遜書店的流量大, 所以搜尋引擎就以最可能你需要的出現在最前面, 但是偶爾(或是常常?)你要的資料並非最熱門的, 你就得耐心的多翻幾頁, 或者多使用不同的搜尋引擎來找尋 …

但是, 這種現象已經慢慢在改觀中, 因為許多語意相關的技術已經逐漸純熟 …

如上面畫面的izito, 當你輸入關鍵字以後, 右邊會出現Topic與domain選項, 當你輸入amazon後, 就可以選擇river或books等選項來確認你所謂的amazon是啥意思, 但是不幸的是…雖然izito可以搜尋中文, 但是對於資料的分類(也就是ontology的建立), 尚無法精確的處理中文網頁, 你如果輸入”五佰”, izito自做聰明的分類還是會讓你滿臉豆花 …

而如下圖顯示的ujiko雖然不允許處理中文資料, 但是允許使用者對搜尋結果做客製化(如搜尋到的結果給他一顆心, 或丟到垃圾桶), 下次搜尋就會以你客製的結果出現, 並且ujiko也提供跟izito類似的topic分類, 並且可以往下再分子類別, 雖然介面稍微複雜些, 但搜尋結果還算不錯

而如下所顯示的kartoo就更厲害啦, 當滑鼠移動到某個link時, 便會顯示這個link在ontology中的關係, 同樣的他的左邊選單也提供topic的選項, 不過kartoo也不支援中文搜尋

當然Semantic Search Engine還不只這些, 下次再來談多些相關網站及這些語意搜尋的技術層面內容 …