SERP : 搜尋排前對消費者的影響

不管公司的大小, 許多產品都希望能夠讓消費者於網路搜尋時可以排列在最前面, 到底搜尋排前對消費者的影響是如何呢? 3位武漢大學的學者在2007年WiCom研討會上有一篇論文: "Does It Pay to Get to the Top? Contextual Factors of Branding in Search Engine Marketing", 做了一個SERP的研究 ... 他們把使用者分成兩大類, 一部分是具備搜尋技能的人, 一部分是不具備搜尋技能的人, 進行四項實驗, 然後去評估他們對產品的認知 這個研究得到幾個結論: (1)具備搜尋技能的人較不易被SERP結果影響, 但不具備搜尋技能的人易被SERP結果影響對產品的認知 (2)當他們瞭解許多產品有進行SEO(Search Engine Optimization)來影響SERP時, 沒有顯著影響他們原有的產品認知 (3)不知名產品在搜尋排前時, 產品認知的影響比知名產品來得顯著 以上結果代表什麼意義呢? 就是沒有名氣的產品如果能夠搜尋排前是非常重要的, 可以快速建立產品的Branding, 相對的知名產品就沒必要花太大心力在SERP上, 並且對於廣大的不具備搜尋技能的人影響較大, 就算他們知道SERP可能是被操作的, 也不太會對於搜尋排前產生太大疑問 所以如果您的產品越沒有名氣, 把精力放在SEO來改善SERP, 是決對能夠逐步建立品牌的一個快速方式, 並且能夠獲得消費者對於您的產品的正面認知!

SERP : Search Engine Results Page

前幾篇文章談了一堆關於Ranking的技術, 最後也就是最重要的就是SERP (Search Engine Results Page), 不管您的PageRank, TrustRank ... 等等指標多好, 如果使用者在搜尋時無法出現在前幾頁, 也就是有較好的SERP的話, 所有的指標都只是白費功夫, 空有好的內容, 但搜尋引擎並不認識你, 可說是非常可惜的事情, 如何才能夠讓您的網頁有優秀的SERP表現呢? SERP與keyword及網頁結構關係最密切, 而高的PageRank不能保證有好的SERP, 高的流量也不能保證有好的SERP, 如果能夠有好的內容再加上優秀的SERP, 那才是網站成功的保證 當使用者下了一個keyword, 哪些重要因素影響SERP的結果呢? (1)網頁title 例如本文章的重點在談SERP, 而title就是"SERP : Search Engine Results Page" 如果您的內容無法表現在title tag上, 當然SERP就無法有好的表現, 這也就是上次談到: SEO 三大建議, 希望能夠使用blog結構的原因, 因為可以不需額外功夫就讓內容的title顯示出來 (2)網頁meta data meta data中的keyword, 與內容中的heading處理, 也可以讓search engine特別注意, 這個在上文Semantic HTML也提到過, 使用正確的tag, 可以讓search engine瞭解您的內容 (3)網址與目錄 如果您的網址或目錄中含有keyword, 如http://www.serp.com/serp-pagerank/serp.html, 如此也可以讓您針對SERP這個keyword有較好的結果, 並且就網址後綴來說, 一般org/net/com 也比ccTLD (Country Code Top Level Domain, 如org.tw/net.tw/com.tw)要好 (4)網頁內容 當然在您文章的內容一定要出現該keyword, 並且真的就是關於該keyword的文章, 否則使用者找到您的網頁也就沒啥意思了 (5)Refresh rate 什麼是Refresh rate? 就是您網站的更新頻繁度, 如果您的網站內容時常更新, 除了能夠讓search engine加快抓取頻率外, 也能夠讓SERP有更好的結果 也許有人會問:到底search engine會多久來抓我的資料? 除了使用http://www.google.com/webmasters/可以讓您上傳sitemap來告知之外, search engine也會自動根據您更新頻繁度來修正抓資料的頻率, 也就是如果每次search engine來抓資料都發現您已經更新, 他會修正縮短抓資料的區間, 如果來抓資料時發現您的網站沒有更新, 則放慢抓資料的區間 因此當您的網頁如果已經被indexing後, 並且您的網站屬於Trust那個區塊, 其實search engine抓資料的頻率有很大因素決定在您手上

TrustRank, PageRank, SERP

許多站長常常問一個問題 : 為何我的網頁已經建置很久了, 但一直沒被Google index? 另外一個問題也常常被問到 : 為何許多PageRank值比我低的網頁, 搜尋時出現在我的網頁前面? 第一個問題的答案是 : TrustRank, 而第二個問題的答案是 : SERP (Search Engine Result Page)與PageRank不一定成正比 本部落格的網頁最快約10~30分鐘就會被Google抓走, 最慢也在一天內就被Google抓走, 原因是TrustRank 什麼是TrustRank? 詳細資料請看 : Combating Web Spam with TrustRank 由於全球的網頁數目太龐大, 因此Google的Sandbox, TrustBox技術會將網頁區分為兩大區塊-被排除的區塊(Sandbox)與信任的區塊(TrustBox) 哪些網站會被信任? 被Dmoz list的網站, 被Social bookmark熱門推薦的網站, 被TrustRank/PageRank高的網站所連結的網站 ... 這篇文章也提到一些成為TrustBox區塊的方式 另兩篇文章 : What is Google TrustRank (TR)?, The Social Side Of Trustrank 也提出許多提高TrustRank的方式, 本站之前的文章也都提到過 當TrustRank較好時才會快速被抓取, 被抓取後才可能有好的SERP, SERP就與網頁結構有很大的關係, 但是真正決定SERP的因素, 現在還是只能由結果來猜測, 尚無真正能夠證明哪些因素來決定SERP (SERP的研究倒是不錯的研究題目) 不過不管如何, 研究了一堆PageRank, TrustRank, SERP ... 之後, 其實最重要的還是老話一句 - 內容與結構! 就把一些指標暫時放一邊, 好好研究如何產生好的內容與正確使用Semantic HTML比較實在吧!

PageRank, BrowseRank, AlexaRank

在八月初的SIGIR (Special Interest Group on Information Retrieval)研討會上, 出現了BrowseRank: Letting Web Users Vote for Page Importance 這個微軟研究中心的BrowseRank演算法, 大抵是想跟Google的PageRank一別苗頭, 到底這個BrowseRank是否能夠比PageRank來得好呢? 我們來研究一下 大略瀏覽了上述的論文, 發現BrowseRank只是Page-level的AlexaRank, 他的data set來自於瀏覽軟體的使用者資料, AlexaRank由Alexa toolbar所得到的資料來分析, 而BrowseRank由微軟的IE所得到的資料來分析 AlexaRank只是Domain-level ranking, BrowseRank比較仔細一些, 進到Page-level Ranking, Website-level Ranking, 而PageRank是透過link-analysis來取得頁面的重要度 論文題目說: Letting Web Users Vote for Page Importance, 其實是值得商確的, 網友到訪了一個網頁, 未必就認為該頁是重要的, 可能看完後幹聲連連 ... 因此我們可以粗略的說AlexaRank標示了網域的熱門度, BrowseRank標示了網頁/網站的熱門度, PageRank標示了網頁的重要度 到底哪個比較精準, 就牽涉到幾個問題: (1)比較熱門的網站是否就比較重要? (2)link數目多就代表比較重要? (3)不同階層的使用者, 熱門度如何參考? (4)廣度網站與深度網站, 熱門度如何參考? 當然上面問題沒有正確答案, 學術研究的網站一般不能跟入口網站比熱門度(AlexaRank與BrowseRank), 而新興網站一般不能與歷史悠久的網站比重要度(PageRank), 但是也可能會有例外 (而且例外還不少) 所以也很難去比較AlexaRank,PageRank,BrowseRank到底哪個好, 後續有更多資料再來分享啦...

Pagerank 演算法研究

Larry Page在1996年間發明了Pagerank的演算法, 爾後又與Sergey Brin在Stanford發表了"The Anatomy of a Large-Scale Hypertextual Web Search Engine", 這個Web Search Engine就是現在使用的Google, Pagerank詳細內容到1998年才發表, 並且直到2001年才取得專利 Page Rank公式如下 (以上公式圖形由http://www.sitmo.com/latex/產生) 以上d指damping factor, 其值在0~1, 一般設為0.85 PR(Vi)為Vi這個頁面的PR值 In(Vi)為連進Vi這個頁面的link數目 Out(Vj)為Vj這個頁面連出去的link數目 也就是說如果有3個頁面A,B,C A如果連到B,C B如果連到C 如果A的PR=4 則PR(B)=(1-0.85) + 0.85 * 4/2 = 1.85 而PR(C)=(1-0.85) + 0.85 * (4/2 + 1.85) = 3.4225 B,C會平均繼承A的PR值, 但C會單獨繼承B的PR值 Pagerank是一種link-analysis algorithm, 是根據citation analysis而來, 原本使用在學術期刊論文被引用次數的技術 在Pagerank之後, 1999年Kleinberg發表了HITS algorithm(Hyperlink-Induced Topic Search), HITS決定兩個值: authority value & hub value, 並且是在query time計算, 而不是像Pagerank是在indexing time計算, Teoma就是使用HITS (目前被Ask.com收購) 相對於link-analysis algorithm的content-analysis algorithm, 於另外文章再討論 不管是Pagerank或是HITS, 都是iterative ranking algorithm, 非常耗費演算時間及資源, 因此許多研究者提出了不同的方式來加速計算時間: 1999年 Efficient Computation of PageRank(Haveliwala and et al.) 2002年 Pagerank Computation and the Structure of the Web:Experiments and Algorithms(Arasu and et al.) 2002年 I/O Efficient Techniques for Computing PageRank(Chen and et al.) 2003年 Scaling Personalized Web Search(Jeh and et al.) 2003年 Exploiting the Block Structure of the Web for Computing PageRank (Kamvar and et al.) 2003年 Extrapolation Methods for Accelerating PageRank Computations (Kamvar and et al.) 2004年 Parallel PageRank computation on a gigabit PC cluster (Manaskasemsak and et al.) 2006年 Parallel adaptive technique for computing PageRank (Rungsawang and et al.) 2007年 Improvement of Pagerank for Focused Crawler (Yuan and et al.) 但是不管怎麼加速演算法, 其iterative ranking algorithm的特性不會改變, 但可能會加入content-analysis algorithm的一些特性來走向semantic web 而Pagerank公式內的Out(Vj), 使得一些做SEO的人注意到HTML中的nofollow特性, 來進行一些link quality的改善

Google資料中心的秘密

Google提供全球大量的服務，幾乎已經快橫跨整個資訊科技的服務，但是Google資料中心的內部運作一直都是秘而不宣，許多人可能都碰過Google的服務出狀況，但是這些狀況總能在可容忍的範圍內解決，你可能發現你的Gmail的容量一直在改變，是什麼架構讓空間像捏橡皮糖一樣越捏越大?前陣子Google伙伴Jeff Dean在Google I/O會議中稍微揭開了公司基礎設施的神秘面紗。 Google的神秘面紗包括了: (1)軟體 (2)硬體 (3)叢集平行處理機置 Google軟體的三個核心要素：GFS（Google檔案系統）、BigTable和MapReduce演算法。而硬體卻是一般的伺服器、處理器、硬碟、記憶體等等。另一方面伺服器的叢集能在半秒之內回應700至1,000台伺服器的搜尋請求。 根據Google的說法，GFS是"a scalable distributed file system for large distributed data-intensive applications. It provides fault tolerance while running on inexpensive commodity hardware, and it delivers high aggregate performance to a large number of clients". 就是這個GFS的分散式檔案系統，讓Google服務可以隨時長出空間或是切去毀損的部分，而管理這個GFS的機置就是BigTable。目前有超過200個叢集在執行GFS，其中許多都包含數千台主機。 GFS把一塊儲存的資料(通常是64MB)，至少放在三台稱為chunkserver的主機內。 如果chunkserver發生故障，Master Server(主伺服器)便負責把資料備份到一個新的地方。至少在儲存層級，主機故障完全由GFS系統處理。 Google到底擁有多少台伺服器?據Dean表示，每個機櫃存放40台伺服器。而根據某項估計，Google目前在全球有36個資料中心，以每個中心有150個機櫃計算，Google的伺服器至少超過20萬台，並且每天都在增加中...下圖就是Google最早期的server rack，當然目前的硬體比這個肯定更驚人了。 Google之所以成為Google，部分原因是他們推翻了電腦界的傳統作法。當所有的超大型資料中心都使用主流伺服器和軟體，Google的資料中心絕大部分是靠本身的技術構建而成。Google把命運操縱在自己手中，共同創辦人Larry Page鼓勵員工"別太相信有什麼不可能的事情"。 要維持如此大規模的運作，也許可以說全世界是卯起來操Google的架構，Google必須對每一台機器抱有一種隨時可犧牲的態度。伺服器製造商喜歡主打他們的高階主機承受故障或當機的能力，但Google寧願把錢投資在容錯軟體上。他們認為擁有兩倍數量但較不可靠的硬體，勝過一半數量但較可靠的硬體。你必須在軟體的層級提供可靠度，如果你有1萬台主機在運作，每天一定會有一些東西掛掉。這個跟我們一般的認知確實有蠻大的差異，我們通常都希望有數量雖少，但功能穩定的機器，而不願意有一大籮筐兩光的機器。 每個新叢集上線的第一年，通常會發生1,000次個別主機的故障，數千次硬碟故障... 一次電力輸送問題，導致500至1,000台主機失效約6小時... 20次機櫃損壞，每次造成40至80台主機下線... 5次機櫃搖晃，導致半數的網路封包在傳送過程中遺失... 整個叢集至少一次重新上線，在兩天之內的任何時間，影響5%的主機... 整個叢集還有一半的機率會過熱，在5分鐘之內讓幾乎所有伺服器當機，並且花上1到2天的時間恢復... 雖然Google用一般硬體組件來組裝其伺服器，但卻不用傳統的封裝，他們要求Intel提供特製的主機板。Google目前在每40台伺服器的機櫃外，包覆一層外殼，而不是每台伺服器有個別的外殼。 Google在2004年開始設計的BigTable，用BigTable為所有資料提供若干結構，目前用在超過70個Google計畫，包括Google Maps、Google Earth、Blogger、Google Print、Orkut和核心搜尋索引。最大的BigTable實用範例管理橫跨數千台主機、約6 PT(petabytes)的資料。 Google在2003寫出第一版的MapReduce，讓該公司有辦法實際發揮那些資料的用處。舉例來說，MapReduce能找出某個特定字彙在Google的搜尋索引中出現的次數、列出所有特定字彙出現的網頁，和連結到某個特定網站的所有網站。 利用MapReduce，Google能用相對迅速的時間，建立一個包含"digital"、"network"和"society"三個字的所有網頁索引。"Dean說：「你必須能夠依序地橫跨數千台主機作業，才能在一個合理的時間內完成這項工作。」 MapReduce軟體在Google內部的應用日漸增加，2004年8月，該軟體執行2.9萬項工作，到2007年9月，已經暴增到220萬項。在這段期間，完成一項工作的平均時間也從634秒降至395秒，而MapReduce的工作產出則從193 terabytes上升到約1.4萬terabytes。Dean說，Google在任何一天都要執行約10萬項MapReduce工作，每一項工作佔用400台伺服器，且需要5到10分鐘完成。 MapReduce就像GFS，是特別設計用來迴避伺服器問題的。Dean表示：「當某台主機故障，主伺服器知道那台機器正在執行什麼工作，將命令其他主機接手那項map工作。你可能影響到100個map工作，但會有100台主機接手那些工作。」 MapReduce的可靠度一度遭到嚴厲的試煉，當時一個1,800台伺服器的叢集正進行維護作業，工作人員一次拔下80台主機的插頭，同時另外1,720台主機必須接下停頓的工作。Dean說：「速度變得有點慢，但工作全部完成。」而在一次2004年的簡報中，一個1,800台叢集的系統，承受了1,600台伺服器同時故障。 所以，Google資料中心的運作似乎如魚得水，一切順利。但該公司還不滿足，列出了一長串待改進的事項。大多數公司都試圖找出如何平順地將工作在伺服器之間轉移，但Google已經超越了那項挑戰，他們要能夠自由、平順，且自動地，將工作在各個資料中心間轉移。 Dean說：「我們下一代的基礎設施要是一個能夠橫跨大區塊主機轉移，而非單一機器的系統。」目前，某些大型的檔案系統具有不同的名稱，如GFS/Oregon和GFS/Atlanta，但他們都是彼此的拷貝。他表示：「我們要一個單一的名稱集。」 Google種種獨創的系統替他們開創了天下，也建立了其他競爭者很難跨過的門檻，但是隨著越來越複雜的環境，Google自己需要解決的問題，肯定挑戰會越來越大。

近期語意技術探討(一)

(圖片來源:http://gridinoc.name) 2008年可以說是語意技術發燒的一年, 並且近年來不管是研究單位或是新創公司, 對於語意相關技術的重視與投資可謂不遺餘力, IEEE Intelligent Systems也在今年初刊登了不少關於語意技術的文章, 我們來看看到底語意已經發展到什麼程度 ... 語意技術對於一般使用者是感覺不到的, 您並不知道到底哪個東西應用了語意技術, 頂多您會覺得電腦好像變聰明了, 但是如果運用得不好, 您可能會覺得怎麼電腦這麼笨, 電腦的聰明與愚蠢就完全取決於到底是否正確的運用Semantic Technology(語意技術)、Artifical Intelligence(人工智慧)、Nature Language Processing(自然語言處理)、Ontology(本體論)...等等 在W3C的網站就舉了幾個語意技術的使用案例 例如其中BT(英國電訊)的案例, 根據Forrester研究顯示排名前3500的大公司, 花費在整合的費用是$6.3 million並且其中的31%花在整合外部公司, 而電信類的公司花在整合外部公司的比例高達70% BT就將Semantic運用在SOA(Service-Oriented-Architecture)上, 讓他們的外部夥伴使用Internet與BT的B2B Gateway聯接, 輕易的自行處理作業支援相關運作, 如此一來減輕了支援成本, 也加速了作業效率 這個技術使用SOA來將整個系統分成Presentation Tier、Service Tier、Data Tier, 透過Service Tier的Semantic Broker去抓取異質系統的資料, 然後呈現在外部公司的系統上或是瀏覽軟體上, 如此一來BT本身的不同系統整合起來了, 外部公司使用各種不同系統也都可以順利的透過這個B2B Gateway來整合 在目前語意技術的運用上, 幾乎離不開Web2.0與SOA, 就其中Markup與Mashup的特性來發揮, Markup讓資料可以分析、交換(如XML、RDF、RuleML), 而Mashup可以讓服務混搭, 因此幾乎所有的技術都繞著Markup與Mashup走, Semantic/Web2.0/SOA幾乎就是Internet三位一體的趨勢 目前在歐洲的語意研究上, 以Neon-Project、SEKT、DIP為主, 各自都發展許多不同的語意技術與工具, 下次再仔細說明囉 ...

語意搜尋的前哨站 : 垂直搜尋

在Google的一般搜尋後又推出各類搜尋之際(圖書搜尋, 地圖搜尋, 學術搜尋, 網誌搜尋, 產品搜尋, 新聞搜尋...等), 各家一堆特定目的垂直搜尋也紛紛想要搶下一片江山, 這些搜尋引擎到底存活的機率有多少? 功能如何? 目前廣泛性的搜尋除了Google外, 大抵普遍被使用的就是Yahoo/Microsoft/A9/AltaVista/AllTheWeb/Lycos/Ask.com/Baidu...等等, 在這些廣泛性搜尋引擎與語意搜尋引擎(如Kartoo/izito/ujiko/hakia...等)之間, 垂直搜尋引擎的出現也彌補了目前搜尋不精準的缺點。 以下就來介紹一些功能不差的垂直搜尋及特殊查詢網站... (1)(垂直搜尋)Kooxoo酷訊網 : 提供中國大陸的工作、房屋、票務、酒店、旅遊、購物等生活內容的搜索服務。這個酷訊網由北京大學計算機工程背景的陳華所創辦, 可以搜尋到的訊息可以說幾乎涵蓋了中國大陸的食衣住行娛樂, 由於表現不凡, 也獲得了Qihoo不少資金的投資。 (2)(垂直搜尋)Jobui/Jobmet : 為求職者提供大量的工作訊息，及中高端人才獵頭服務。這類服務與台灣的104人力銀行不同, 他們沒有自己的資料, 只是提供界面去各人力資源網站抓取資料加以整合。 (3)(垂直搜尋)Krillion產品搜尋 : 這個查詢與Froogle類似, 但資料量不夠多, 面對Google大概存活率不高, 除非資料能夠往精緻化發展。 (4)(垂直搜尋)Spock找人服務 : 這個找人服務與USA People Search類似。 (5)(垂直搜尋)Yoinkd音樂搜尋 : 與百度的MP3搜尋類似, 精準度不錯, 而且資料量也不差。 (6)(特殊查詢)Openrice餐廳搜尋 : 可以搜尋香港各類餐廳, 但不算是垂直搜尋, 因為資料蠻齊全的, 因此也把他列進來。 (7)(整合界面搜尋)oskope視覺搜尋 : 提供搜尋eBay/Amazon/flickr/Fotolia/Yahoo/YouTube等內容的視覺化搜尋, 其功能與Spacetime類似, oskope需要安裝額外的plug-in, 而Spacetime需要安裝額外的軟體, 並且硬體需求也較高。 (8)(垂直搜尋)FindBook翻書客 : 提供各網路書店的書籍比價搜尋, 類似的服務有isoshu, 但是isoshu找的不是書籍的價格, 竟然找的是書的內文, 不知他是如何處理版權問題。 (9)(垂直搜尋)Yousee BBS搜尋 : 提供BBS站內的文章搜尋, 是政治大學資科系團隊製作出來的。 在網路上資料日增的情況下, 各種需求已經無法以單一普遍性搜尋引擎來滿足, 因此專門領域搜尋、垂直搜尋、語意搜尋等需求會越來越高, 並且更符合人性化的界面也是大家所期盼的, 以上這麼多的搜尋網站到底誰能勝出? 還是只是曇花一現? 就看使用者賞不賞臉了!

搜尋引擎的下一步:語意搜尋

現在的搜尋引擎雖然精準度已經比以往提高不少, 但是還是常常搜非所尋, 想要找亞馬遜叢林的資料, 輸入Amazon卻都是亞馬遜書店相關訊息, 必須翻到好幾頁以後才陸續出現亞馬遜叢林的資料 因為亞馬遜書店的PageRank值高, 因為亞馬遜書店的流量大, 所以搜尋引擎就以最可能你需要的出現在最前面, 但是偶爾(或是常常?)你要的資料並非最熱門的, 你就得耐心的多翻幾頁, 或者多使用不同的搜尋引擎來找尋 ... 但是, 這種現象已經慢慢在改觀中, 因為許多語意相關的技術已經逐漸純熟 ... 如上面畫面的izito, 當你輸入關鍵字以後, 右邊會出現Topic與domain選項, 當你輸入amazon後, 就可以選擇river或books等選項來確認你所謂的amazon是啥意思, 但是不幸的是...雖然izito可以搜尋中文, 但是對於資料的分類(也就是ontology的建立), 尚無法精確的處理中文網頁, 你如果輸入"五佰", izito自做聰明的分類還是會讓你滿臉豆花 ... 而如下圖顯示的ujiko雖然不允許處理中文資料, 但是允許使用者對搜尋結果做客製化(如搜尋到的結果給他一顆心, 或丟到垃圾桶), 下次搜尋就會以你客製的結果出現, 並且ujiko也提供跟izito類似的topic分類, 並且可以往下再分子類別, 雖然介面稍微複雜些, 但搜尋結果還算不錯 而如下所顯示的kartoo就更厲害啦, 當滑鼠移動到某個link時, 便會顯示這個link在ontology中的關係, 同樣的他的左邊選單也提供topic的選項, 不過kartoo也不支援中文搜尋 當然Semantic Search Engine還不只這些, 下次再來談多些相關網站及這些語意搜尋的技術層面內容 ...

易經、系統理論與ITIL

ITIL (Information Technology Infrastructure Library)起源於1980年代的英國電腦通訊局(Central Computer and Telecommunications Agency, CCTA), 也就是現在的Office of Government Commerce (OGC), 其目的是要讓IT資源能夠發揮應有的效率及投資上的回報, 也就是讓花在IT上的每一塊錢都能花在刀口上。 最早的ITIL原本叫做GITIM(Government Information Technology Infrastructure Management, 政府資訊科技架構管理), 它跟現在的ITIL當然已經不太相同, 但是精神是一致的, 這套方式在1990年代早期在歐洲開始廣泛的被應用, 並且在2000年被Microsoft採用為MOF(Microsoft Operations Framework)的基本架構。 ITIL V2在2001年出現, 把架構分為兩大塊: Service Support與Service Delivery, 每塊有五個部分, 加上Service Desk與Security Management共有十二個部分。 2007年改版為ITIL V3, 強調生命週期的概念 ITIL V2各模組彼此之間相對孤立、沒有太多聯繫, V3已經開始有了類似系統理論的整體概念(System of Systems), 也許你會說V2怎麼會是相對孤立? CMDB不是在Service Support中扮演一些聯繫的角色嗎?我們看看ITIL V3的架構說明圖如下 整個架構以Service Strategies串聯 (也就是V2的Financial Management)但是V2的Process與Process之間並無整體串聯的管理。仔細研究ITIL V3的本質, 其實跟系統理論是相同的, 甚至包含System of Systems (SOS), 再究其因, 根本中國的易經都已經提出相同的看法。 一般系統論的基本原理是美籍奧地利生物學家貝塔郎菲(Ludwig von Bertranffy)在1925年提出的, 他認為系統的主要特點在於它的整體性、結構性、有序性、目的性及系統與環境的適應性。 從整體與局部、局部與局部、整體與外部環境的相互聯繫中考察對象，以獲得正確的認識及處理問題的最佳方案。Peter M. Senge的第五項修鍊(The Fifth Discipline)提到的啤酒遊戲(The Beer Game), 也是缺乏System Thinking而導致。 系統理論主要有五大部分: 系統, 要素, 聯繫, 功能, 結構, 環境。其實包括的概念可以用『大小宇宙』與『三理四相』來說明。啥叫『大小宇宙』? 就是系統中有系統 (System of Systems), 每個系統間都必須不斷的聯繫, 才能運作正常, 就如同人體一樣, 每個系統都需考慮到物、地、時, 在每個系統中的物件(物)於不同的時間(時)與環境(地), 都會有不同的功能(functions)與任務(tasks), 其子任務就是在不同的物件間聯繫, 這些子任務集合起來就讓這個系統運作起來。 啥叫『三理四相』? 就是物理中的成、住、壞、空, 心理的成、住、異、滅, 身理的生、老、病、死。而每個『相』中又都會有下階層的四相, 也就是又有System of Systems的關係。講到最後 ... ITIL竟然與易經是相通的, 而我們身體中的物理、心理、身理其實都依循ITIL在運作。

物件導向關聯式資料庫

關聯式資料庫管理系統( RDBMS, Relational Database Management System, 如mySQL, MSSQL等)是大家比較熟悉的資料庫系統，以database-table-field-record等概念來集合成資料，以field間的relation來建立table互相的關聯。但是這樣的形態有一個與實際世界的gap，也就是物件的class特性，因此而出現了物件導向的資料庫系統(OODBMS, Object-Oriented Database System, 如Caché)。 RDBMS與OODBMS的拉鋸戰，總是RDBMS勝出，最主要是因為有ER-Model及易懂的SQL等完整而簡易的工具來操作，因此雖然與實際世界有gap，但比較容易學習。 OODBMS是啥?看看以下的展示: http://www.maddash.net/videos/intersystems/cache_demo/ 也可以由這裡去找OODB的資源: http://odbms.org/ 另外的一個理論就是Object-Relational Database，使用RDBMS來建立OO的概念，這種作法就牽涉到Object-Relational Mapping，將物件與關聯式資料庫間做對映。 以上RDBMS、OODBMS、ORDBMS三種技術，到底有哪些優缺點呢？下次再談 ...

什麼叫Ontology?

根據wikipedia的解釋: In philosophy, ontology is the study of being or existence. It seeks to describe or posit the basic categories and relationships of being or existence to define entities and types of entities within its framework. Ontology can be said to study conceptions of reality. In computer or information sciences, ontology is a data model that represents a set of concepts within a domain and the relationships between those concepts. It is used to reason about the objects within that domain. 在哲學術語上，Ontology指的是一種探討"存在"的一門學問，也就是萬物存在這個宇宙，到底是安命在何處，以及萬物之間的關係為何。所以Ontology又稱之為"存在學"或"本體論"。 用白話來說，就是各種活的、死的東西，到底他是屬於哪個類別，可以歸類在何處，並且這些活的、死的東西之間到底有什麼關係。 電腦與資訊科學上，Ontology指的是資料模型，在各種不同的領域(domain)上，建立individuals (instances), classes (concepts), attributes, 及relations，來描述這個領域上各實體的特性。 如以下例子: Vehical(車輛)可分成Car與Truck，而Car又可分成兩輪車與四輪車。 當然，您可能對以上分類可能有不同意見，您也可以建立自己的Ontology。 因此Ontology建立是否完善與客觀就關係著實體描述關係的正確性。 建立這些Ontology目的在哪裡？用什麼來建？自動還是人工？由誰來建？與Ontology相關有哪些需要瞭解的？ 後續再來探討。