Knowledge Graph (知識圖譜)的前世今生

講到Knowledge Graph 一詞,很多人大概會直覺地想到Google的Knowledge Graph,隨著AI再度興起,使得Knowledge Graph變得熱門,舉例而言(圖1),在Google 中查找,「歐巴馬老婆那裡畢業?」,Google能回答出,她畢業於普林斯頓大學和哈佛法學院,並且還把蜜雪兒的生平生事蹟結構化的列出來。Google能回答這些問題,Knowledge Graph扮演相當重要的角色,此外,Google對於問題中的具名實體及關係的區辨能力也是能夠準確回答的重要因素,這必須區辨出這個問題不是問歐巴馬,而是蜜雪兒,且「那裡畢業」是要問蜜雪兒在那個學校畢業。因此,Google能夠回答這個問題,不僅是Knowledge Graph內容豐富,而且要有很好的中文斷字斷詞,以及對於問題語意的解讀能力,這方面能力的提昇應該與2014年Google在KDD研討會中發表的Knowledge Vault有關。

圖1: Google 查尋的問答

Google Knowledge Graph 的應用,使得「知識」在網路世界中表達和使用達到另一個境界,但Knowledge Graph並不是偶然發生,有一部份是歸功於過去的發展,早在2000年左右建立knowledge graph的觀念就被提出來,加上Web 2.0的風潮,認為knowledge graph的建立可以透過群眾的力量共同編輯,因此在2007年Freebase由Metaweb所創立,很快的2010年就被Google買下來,到2016年整個服務停掉,Freebase也整併到Google 的Knowledge Graph,但龐大的資料並沒有消失,而是由Wikidata接續群眾共同編輯知識的工作。另一方面,在2007年,利用Wikipedia中infobox中的資料製作而成的DBpedia被發表,帶動了鏈結資料的發展,2008年YAGO 利用更強大的資訊擷取技術,把Wikipedia中非結構化資料,轉為knowledge graph。而NELL (Never-Ending Language Learning)計畫則是在2010年由CMU在AAAI上發表,是一透過網路爬蟲大量由網頁中擷取資料,並結構化且正規化資料的計畫。再者,Cyc是一個歷史悠久的人工智慧計畫,從1984年就開始進行,是一個龐大Knowledge base計畫,讓人不清楚最終是否完成? 但Cyc有一部份,開放出來為OpenCyc

事實上,在Google Knowledge Graph 尚未成熟時,2009年智慧問答系統 Wolfram Alpha 被發表出來,引起高度的重視,它能回答像,「英國女王伊莉莎白二世在1974年時是幾歲?」、「貸款利息隨時間的變化」,這種較為複雜的問題,邏輯推演能力其實很強,但侷限在於內容,Wolfram Alpha 不像 Google Knowledge Graph 具有這種龐大的內容來迎合一般民眾的問答。而另一個強大的問答系統IBM Watson,已經眾所皆知的人工智慧平台。

Semantic Network (語意網)

Semantic Network 可以說是Knowledge Graph的濫觴,早在1960年代,多數人把知識中概念概念串起來的網絡稱為semantic network,許多自然語言處理的研究致力於整理這些知識,以便促成更智慧、更精準的自然語言處理,最知名應該是普林斯頓大學的WordNet,是一個相當完整的英文為主的語料庫,後來也有其它語言加入,如中文。以WordNet為例,這個semantic network 著重的是詞彙的上下位關係和同義詞之建立,所謂上下位關係是以詞彙語意上較為抽象、描述範圍較大者為上位詞,而較明確、描述範圍較小者為下位詞。

和knowledge graph的比較,WordNet強調的是詞彙語意的正確表達,而knowledge graph是著重於真實世界實體的關係,例如,巴拉克·歐巴馬和蜜雪兒·歐巴馬的配偶關係,而不是去定義配偶為何,其上下位關係和同義詞為何。在Knowledge Graph中的配偶是一個用於「人」這個概念(concepts or classes)的關係(relations),巴拉克·歐巴馬和蜜雪兒·歐巴馬都是「人」的實例(instances),所以可以用配偶關係來表達。

圖2:WordNet

Ontologies (知識本體)

上述的概念、關係、和實例都是構成知識本體要素,但ontologies建立更重視正規化的知識表達,所謂的正規化就是如何以邏輯關係來定義知識、確立語意,Gruber(1995)提出用框架和第一階邏輯(First Order Logic)來建立知識本體,並定義 5 種基本要素:類別(Classes)、關係(Relations)、功能(Functions)、正規的原則(Formal axioms)和實例(Instances)。之後,Noy and McGuinness(2001)認為建立知識本體應該定義:

  1. 知識本體中的類別(Classes);
  2. 安排分類體系中的類別(Subclass–Superclass);
  3. 定義屬性(Slot)和描述這些屬性的允許值;
  4. 給實例(Instance)填入屬性的值。

隨著,語意網技術的發展,W3C已製定了知識本體的語言OWL(Web Ontology Language) ,其中使用描述性邏輯(Description Logic) 來定義語意,目前大多數知識本體的建立皆以 OWL 為主,只是在格式上採用較為簡單的Turtle或N3。而知識本體的建立工具則以Protégé 為最多人使用。

舉例來說,日本農業活動知識本體(Agricultural Activity Ontology, AAO)的建立,播種(seed propagation)是一個農業活動(Agricultural Activity),所以播種是農業活動的子類別,播種的概念比散播控制小、散播控制又比作物成長小、作物成長又比作物生產小,因此這些概念的活動即形成一個階層,且每一個概念都是由邏輯關係所定義而成。許多知識本體都像日本的農業活動知識本體之建立,強調於概念(concepts)或類別(classes)之間的邏輯關係,而較缺乏實例的部份,如DOCLE,這和Knowledge Graph有相當大不一樣的地方,Knowledge Graph的類別(classes)通常不複雜,階層較淺,但實例(Instances)的部份相當豐富。

圖3:日本農業活動知識本體(AAO)

Knowledge Base (知識庫)

Knowledge base 早在1970年代就被提出來,主要有二個特徵,一是有一個知識呈現方式來表達事實(facts),通常是知識本體,並有儲存庫(repository)來儲存這些事實,這裡的事實和資料不一樣的地方在於結構化和正規化,以知識本體的角度而言,就是一個被陳述的事實一定會有一個類別來說明並表明這個事實應有可有的關係。另一個特徵是推理機(inference engine),可以使用邏輯規則來推論以減少這些事實的不一致(inconsistence),當然早期許多以Knowledge base為基礎的專家系統會強調,推理機可以透過規則和邏輯關係的建立,回答問題,或預測更多事實。

Knowledge Base和Knowledge Graph應該是被混用最多的二個名詞,本質上,這二個東西確實是相似,有綱要(schema)部份,也就是圖4中TBox (Terminology Box),一般而言,是以OWL來實現,以及ABox (Assertion Box),就是事實(facts),一般由RDF來實現。為了進一步解釋,圖5中在雲朵中的都屬於TBox的部份,都是類別(classes),而方框中的是ABox,是根據TBox類別所定義的實例(instances),或者是事實(facts)。

圖4: Knowledge base的組成ABox 和 Tbox
圖5: ABox和TBox的實際範例

最大的差別在於Knowledge base在提出時,並沒有想到是一個網路規模(Web scale)的應用,內容(也就是事實)如此龐大,對於資料的綱要(schema)(TBox)要求較多,相對而,knowledge graph的TBox部份就比較沒這麼複雜。另一方面,knowledge base的建立常常只是單一領域,例如,Geonames 只有地名,和knowledge graph盡量收納所有知識的基調,是完全不一樣的。

 

為什麼HTML不能實現語意網?

在網路搜尋資料時,最大的阻礙是資訊使用者與資訊提供者之間所使用的語意不同,如果使用者無法以 “正確”的語彙來搜尋,所得結果不是錯誤,就是眾多的搜尋結果中只有少量使用者想要的結果,以致於使用者無法擷取提供者的資訊,而提供者無法將資訊送達於使用者,這是因為搜尋工無法了解網頁中資訊的意義,為解決這樣子的問題 Tim Berners-Lee,全球資訊網(World Wide Web)之父,於2001年提出語意網的概念。在語意網中,在網頁中的文字與媒材會被連結到知識本體中相對應的概念或及其關係,而此知識本體中的概念是充份被定義,且概念中彼此的關係亦被清楚的說明,因此使用者在搜尋資料時,語意網的服務可以提供更為符合需求。
然而,目前網頁的技術—超文字標記語(Hypertext Markup Language, HTML)是無法達到語意網的實現,因為HTML的標記(tag)只針對網頁內容在瀏覽器中顯示的方式所設計,如台灣是說明台灣一詞在網頁中顯示為粗體,但可使用的標記限定於技術規格中所列,而另一種資料交換常使用的格式—可擴展標記語言(Extensible Markup Language, XML) ,雖然XML對於標記名稱沒有限定,著重於標記的結構,但這只使用資料具有語法上結構,而沒有達到語意層級。為實現意語網,W3C (WWW Consortium) 在XML的基礎上訂定了另一種具有語意的資料編碼方式,為資源描述架構 (Resource Description Framework, RDF),如class, subclassOf, property, subpropertyOf, domain, range, sequences, collections, 和其它一些相關語彙,資料經過RDF的編碼後,可所解析RDF的工具可了解資料的語意,如二個概念中具有一個subclassOf 的關係,可以知道這二個概念有上下從屬的關係,因此常被用來編寫簡單的知識本體,通常都是具有概念階層上語意關係。
更進一步,網路本體語言 (Web Ontology Language, OWL)則提供更多邏輯關係的定義來使資訊的語意更明白,包含函數化關係( functional properties)、反關係(inverse relations)、遞移性(transitivity)、同義字(synonyms)、基數限制(cardinality restrictions)和附加概念(additional concepts)。依照使用邏輯關係複雜程度,OWL三種版本可以使用,分別為 OWL Lite、OWL DL、和OWL Full。 OWL Lite 支持使用者定義分類層級的架構和簡單的限制; OWL DL中的DL即是描述邏輯(Description Logic),表示所使用的邏輯規則是以描述邏輯為基礎;而OWL Full 顧名意義即使用所有OWL的語彙,且有更多有彈性的定義,但目前多數工具或軟體不支援OWL Full所編碼的資料。語意網 (Semantic Web)將帶來Web 結構化有意義的內容,且開創了一個環境其中軟體代理人可以網頁到網頁間的漫遊,很容易地實現使用者所需的複雜任務(Berners-Lee et al., 2001). 語意網不是另一種Web而是現在的延伸,可使人與電腦再好的合作,在語意網的第一階段中結構化現存的Web己經在進行,未來這些發展應引導出重要新功能,而成為一種“機器”,使了解資料且更好地處理資料 (Berners-Lee et al., 2001)。

連結感測器資料(Linked Sesnor Data): 從氣象測站到連結資料

緣起

會進行這個Linked Sesnor Data的試作有一些緣由,把時間拉回2013年8月1日在環保署召集的「環境資源資料開放專家諮詢會議」,開會目的除了討論環保署資料開放平台,更是在於討論紫外線測站資料來當開放資料五顆星的範例。太酷了! 環保署願意進行開放資料5顆星的示範是一件很棒的事! 不但有助於環保署所屬開放資料品質的提昇,也可以刺激其它政府部會對於開放資料品質的關注。但會中業務單位所簡報的那個「紫外線測站的五顆星開放資料」是問題多多,對於OWL/RDF有了解的人,其實不難發現簡報中的那份RDF是有問題的,況且把資料編譯為RDF格式充其量就是4顆星等級,怎麼可以說是5顆星呢?再者,所謂的5顆星開放資料是要連結什麼呢!?

這個問題後來成為與會專家要給予的答案。資料集與資料集要連結,這之間就必需要有某一些關連,也就是所謂的context,以致於資料集中的某一個entity可以與另一個entity以某種形式相連,在普遍的做法就是用owl:sameAs來表達在不同資料集中的二個entity是一樣的,以我有限的所知,資料集之間的context可以由三個特性來思考: 地理空間(Geospatial)、時間的(Temporal)、和主題屬性的(Attributiive),以環保署開資料平台中的紫外線測站資料為例,有可能連結的部份看來只有地理空間的特性了! 就資料特性而言,若環保署要做Linked Open Data (LOD),建議應該朝向Linked Sesnor Data,就是把所有測站以OGC的Sensor Web Enablement (SWE)W3C SSN Ontology 二者來表達環保署中的測站,而測站所產生的資料則是以Linked Observation Data 來詮釋。

 

IMG_20140103_121214從Sesnor nodes組成sensor network,然後以OGC SWE來架構Sensor Web,所以容易再以W3C SSN Ontology表達

 

IMG_20140103_121156Linked Sesnor Data, Linked Observation Data, and Geonames

 
很遺憾的是,他們並沒有採納這些意見,在環保署開放資料平台上線後,12月初無意間看到,那個有問題的說明己經在環保署開放資料5顆星的頁面上,而有問題的RDF資料也提供下載。這種做法給了二個不好的示範,首先,在專家會議中,本人就不認為那是對的說明和對的RDF資料,但這些內容和資料還是上線了,好吧! 意見也給了,那專家會議的用意什麼? 另一個是比較嚴重的問題是,把錯誤的LOD說明和資料放在一個政府公署開放平台的網頁上,很容易就會誤導其它人,對於LOD的理解,開放也得開放「對」的資訊,是吧! 身為市井小民所幸可以透過平台「意見回饋」反應機制,向環保署說明,那份說明的LOD頁面和RDF資料有問題,哈! 意見回饋比專家會議有效耶! 環保署在一週後拿掉在資料開放平台上的那些LOD資料,所以大家己經看不到了,接著承辦這項業務的人員也來拜訪,並帶著修改的RDF來討論。的確,修改後的RDF,使用了標準語彙,如Dublin Core,但看起來就是一份單純由表格轉為RDF的文件,這不見得有錯,但語意的表達是相當弱的,對於紫外線測站詮釋,也就是紫外線測站所表達出的概念是什麼?並沒有辦法得知。

或許,你心中油然而生一個問題,「疑!那些LOD的資料,在網頁看起來都像是表格一樣,那資料轉成這樣有什麼問題?」嗯! 那些LOD的資料背後其實都有一個ontology來表達資料的語意,只是放上網頁為了瀏覽方便而表現成表格的形態,利用標準語彙也是在確保資料語意不被誤解,但ontology中,概念的結構和邏輯的規範可以使資料語意更為完備,並可以進一步達到邏輯推理,當然目前我們只需要達到將資料本身概念充份地表達,在這個紫外線測站的案例中,如同前面所說,還是採用W3C SSN Ontology來表達紫外線測站才是比較恰當的方式。

從建構知識本體(ontology)開始

這筆所謂的紫外線測站基本資料所記述的資料相當有限,主要項目如下:

  • 紫外線測站的中英名稱
  • 紫外線測站所在的縣市鄉鎮
  • 紫外線測站的空間座標和住址
  • 紫外線測站的發佈機關

這筆有限的資料能表達出的內涵確實不多,若只根據這些項目編出的ontology應該也很空洞,對於一個用來表達紫外線測站的ontology而言,不僅僅是要表述地理空間的描述,更重要是要表達什麼是紫外線測站和紫外線測站觀測什麼。根據W3C SSN Ontology 對於感測器(Sesnor)的描述和定義,可以重新想想,要如何重新表達這筆紫外線測站資料:

  • 紫外線感測器本身是用來測量紫外線(Ultraviolet)的
  • 紫外線觀測是以紫外線指數(UV Index)
  • 紫外線感測器是裝在中央氣象局的氣象站或環保署的空氣監測站
  • 無論是氣象站或空氣監測站都有空間座標、地址、和所在行政區域

W3C SSN Ontology 這份報告附有很多案例是可以依循的,其中對於Linked Sesnor Data 就有一個案例,對於紫外線測站資料,不就是一個很好拿來模仿的案例! 對於感測器(Sesnor)的描述和定義,這個案例中主要使用W3C SSN ontology和DUL(DOLCE Ultra Light) ontology,此外也描述感測器(Sesnor)觀測能力和裝在氣象局的事實,更重要的是這樣表達的感測器(Sesnor)是可以被連結(link)。根據這個架構,可以設計一個ontology來解釋這筆紫外線測站資料,而這個ontology 不單單只有紫外線測站的ontology,而應該是感測器知識本體(sesnor ontology),且可以應用在任何不同的感測器上,我習慣先用畫圖把需要的class和individuals先勾勒出來,以便後續ontology的編輯。

uv_ontology根據W3C SSN 和 DUL設計的紫外線感測器ontology

 
與寫程式類似,ontology的編輯可以用文字編輯器,但也有一些工具輔助,一般常用的工具為Protégé,根據上面那個畫好的圖,這個UV sesnor ontology 很快就能完成。
 

Linked Data: 讓自己可以被連結,也可以連結別人

一一解釋UV Sesnor Ontology中類型(class)和個體(individual)會是冗長的說明,為了有效率的說明UV Sesnor Ontology中的知識表達,以下是擷取部份段落來做解釋:
 

Solar501A (亂瞎掰的)感測器本身是用來測量紫外線(Ultraviolet)的,安裝於台北氣象站的系統平台上,且有量測紫外線指數(UV Index)的能力,而紫外線指數有15個等級,每一個等級就是100焦身/每平方公尺,例如8就是測到紫外線800-899焦身/每平方公尺。紫外線指數又可以分級為低量級、中量級、高量級、過量級、和危險級,下面案例只顯示紫外線指數8-10是過量級。

 

###  http://lod.tw/ontologies/weather-station/uv#Sensor_Solar501A

:Sensor_Solar501A rdf:type ssn:SensingDevice ,
                           owl:NamedIndividual ;

                  ssn:onPlatform :Platform_for_Taipei_Weather_Station ;

                  ssn:hasMeasurementCapability :UV_Index_MeasurementCapability .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_MeasurementCapability

:UV_Index_MeasurementCapability rdf:type ssn:MeasurementCapability ,
                                         owl:NamedIndividual ;

                                ssn:inCondition :UV_Sacle ;

                                ssn:forProperty :Ultraviolet .

###  http://lod.tw/ontologies/weather-station/uv#Ultraviolet

:Ultraviolet rdf:type ssn:Property ,
                      owl:NamedIndividual .

###  http://lod.tw/ontologies/weather-station/uv#UV_Sacle

:UV_Sacle rdf:type ssn:MeasurementRange ,
                   owl:NamedIndividual ;

          ssn:hasValue :UV_Index_0_interval ,
                       :UV_Index_10_interval ,
                       :UV_Index_11_interval ,
                       :UV_Index_12_interval ,
                       :UV_Index_13_interval ,
                       :UV_Index_14_interval ,
                       :UV_Index_15_interval ,
                       :UV_Index_1_interval ,
                       :UV_Index_2_interval ,
                       :UV_Index_3_interval ,
                       :UV_Index_4_interval ,
                       :UV_Index_5_interval ,
                       :UV_Index_6_interval ,
                       :UV_Index_7_interval ,
                       :UV_Index_8_interval ,
                       :UV_Index_9_interval .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_interval

:UV_Index_8_interval rdf:type DUL:Region ,
                              owl:NamedIndividual ;

                     :hasMeasurementPropertyMaxValue :UV_Index_8_max_value ;

                     :hasMeasurementPropertyMinValue :UV_Index_8_min_value .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_max_value

:UV_Index_8_max_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.99"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_min_value

:UV_Index_0_min_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.0"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#Very_High_Risk

:Very_High_Risk rdf:type ssn:FeatureOfInterest ,
                         owl:NamedIndividual ;

                rdfs:label "過量級"^^xsd:string ;

                ssn:hasValue :UV_Index_10_interval ,
                             :UV_Index_9_interval ,
                             :UV_Index_8_interval .

 

台北氣象站的系統平台是台北氣象站的一部份,台北氣象站是中央氣象局的一部份,而台北氣象站和中央氣象局都是一種組織(Organization)。

 

###  http://lod.tw/ontologies/weather-station/uv#Platform_for_Taipei__Weather_Station

:Platform_for_Taipei__Weather_Station rdf:type ssn:Platform ,
                                               owl:NamedIndividual ;

                                      ssn:attachedSystem :Sensor_Solar501A ;

                                      DUL:hasLocation :Site_Taipei_Weather_Station ;

                                      DUL:isPartOf :Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_Weather_Station

:Taipei_Weather_Station rdf:type :Weather_Station ,
                                 owl:NamedIndividual ;

                        rdfs:label "Taipei"^^xsd:string ,
                                   "台北"^^xsd:string ;

                        DUL:isPartOf :Central_Weather_Bureau_Taiwan ;

                        DUL:hasLocation :Site_Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Weather_Station

:Weather_Station rdf:type owl:Class ;

                 rdfs:subClassOf DUL:Organization .

###  http://lod.tw/ontologies/weather-station/uv#Central_Weather_Bureau_Taiwan

:Central_Weather_Bureau_Taiwan rdf:type :Government_Organization ,
                                        owl:NamedIndividual ;

                               rdfs:label "中央氣象局"^^xsd:string .

 

台北氣象站是在台北氣象站場址(site),這個場址是一個地方(Place),有一個WGS 84 XY座標的參考點(reference point),且這個場址有一個地址(Address),這場址也在一級行級行級區的台北市之中和二級行政區的大安區之中,且大安區也在台北市之中,而台北市在台灣之中。

 

###  http://lod.tw/ontologies/weather-station/uv#Site_Taipei_Weather_Station

:Site_Taipei_Weather_Station rdf:type DUL:Place ,
                                      owl:NamedIndividual ;

                             geo:hasGeometry :Reference_Point_Taiepi_Weather_Station ;

                             vcard:hasAddress :Address_Taipei_Weather_Station ;

                             :is_in :Daan_District ;

                             :is_in :Taipei_City .

###  http://lod.tw/ontologies/weather-station/uv#Reference_Point_Taiepi_Weather_Station

:Reference_Point_Taiepi_Weather_Station rdf:type geo:Point ,
                                                 owl:NamedIndividual ;

                                        wgs84_pos:long "121.55834"^^xsd:float ;

                                        wgs84_pos:lat "22.036934"^^xsd:float ;

                                        geo:asWKT "Point(121.5583420000, 22.0369330000)"^^sf:wktLiteral .

###  http://lod.tw/ontologies/weather-station/uv#Address_Taipei_Weather_Station

:Address_Taipei_Weather_Station rdf:type owl:NamedIndividual ,
                                         vcard:Address ;

                                vcard:street-address "公園路64號"^^xsd:string ;

                                vcard:locality "台北市"^^xsd:string ;

                                vcard:country-name "台灣"^^xsd:string ;

                                vcard:region "大安區"^^xsd:string .

###  http://lod.tw/ontologies/weather-station/uv#Daan_District

:Daan_District rdf:type lodtw:2nd_Administration ,
                        owl:NamedIndividual ;

               :is_in :Taipei_City ;

               owl:sameAs freebase:Daan District ,
                          geonames:Daan District .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_City

:Taipei_City rdf:type lodtw:1st_Administration ,
                      owl:NamedIndividual ;

             :is_in :Taiwan ;

             owl:sameAs freebase:Taipei ,
                        geonames:Taipei ,
                        wikidata:Taipei ,
                        depedia:Taipei.

 
眼尖的你不難的不發現,上述的每一個「類型(Class)」和「個體(individuals)」都是以URL方式呈現,如http://lod.tw/ontologies/weather-station/uv#Taipei_City; 且上一段中的台北市和大安區都己經以owl:sameAs分別連結到DBPediaGeonamesWikidata、或Freebase,如UV sesnor ontology中的Taipei_City是以owl:sameAs連結http://rdf.freebase.com/ns/m.0ftkx, http://sws.geonames.org/7280290/, http://www.wikidata.org/entity/Q1867, 和http://dbpedia.org/resource/Taipei。與一開始所做的分析一樣,在這筆資料中地名是最有可能拿來連結其它資料的實體(entities)。

最後,想強調的是,編寫這個UV Sesnor ontology用意在於讓更多人了解什麼是LOD,並期待能引發更多LOD的討論,而能有更多更正確的LOD資料。

語意技術聯合國際研討會 (Joint International Semantic Technology Conference, JIST 2012)

JIST2012是第二屆,上一屆在中國杭州,如果沒有搞錯這個研討會的前身應該是ASWC (Asian Semantic Web Conference)。

JIST2012

雖然這是亞洲區語意網會議,但參加的人不僅來自於亞洲國家,除了日本、韓國、中國、泰國、越南、印度、伊朗、台灣,許多人是來自於歐洲,如德國、英國、愛爾蘭、瑞典、芬蘭、義大利、盧森堡,少數來自於美洲,如美國和加拿大,來參與的人不乏是語意網領域有名的單位組織,如愛爾蘭的DERI (Digital Enterprise Research Institute)、美國的Kno.e.sis Center in Wright State University、德國的 University of Leipzig、日本的NII (National Institute of Informatics)、韓國的KISTI、中國上海交通大學、清華大學,參加人數約100人左右。

會議內容雖有少數偏於理論, 但多數論文偏於語義網和資料連結的實務性研究,4個邀請演講也偏向於應用面,以業界的實務應用,詳細內容可參考議程 。與會的人多為語意網或連結資料方面專家,尤其能在亞洲地區的會議遇到這麼多來自歐美地區且是語意網的專家,三天的會議下來,彼此互動切蹉,獲益良多,有些沒想過研究主題,衝擊腦袋,產生不一樣且具體的想法 。

我們的論文有幸被接受並口頭發表。此行 另一個收獲是能夠了解日本在Open Data和LOD的推動和做法,在JIST 2012 大會的前一天LOD Challenge社群舉辦的International Asian LOD Challenge Day,雖然來不及參與這一天的活動,但後來有機會與LOD Challenge社群接觸,並了解一些日本在推動Open Data和Linked Open Data 的做法和推動方式,這一些觀察整理成 LOD Challenges

相較而言,JIST的等級當然比不上ISWC和ESWC,但被接受的文章仍然有一定的水準,但接受率略高,約在36-37%左右。詳細的接受率為:

  • Regular papers 22/58
  • In-Use track papers 7/17
  • Special track papers 6/15
  • Linked Data in Pratice 4/11
  • Database Integration 2/4

如何安裝4store

所謂的「triplestore」也就是用來儲存的RDF的資料庫,並可以應用類似SQL的語言來查詢。現在已經有許多發展不錯的triplestore。這裡介紹一個輕簡的triplestore—4store的安裝。

1.安裝相關套件

sudo apt-get install build-essential libpcre3-dev libglib2.0-dev ncurses-dev libreadline-dev libtool libxml2-dev libxslt-dev automake git-core

2.安裝raptor

wget http://download.librdf.org/source/raptor2-2.0.0.tar.gz
tar -xvzf raptor2-2.0.0.tar.gz
cd raptor2-2.0.0

3.安裝rasqal

wget http://download.librdf.org/source/rasqal-0.9.22.tar.gz
tar -xvzf rasqal-0.9.22.tar.gz
cd rasqal-0.9.22
./configure –enable-query-languages=”sparql laqrs” && make && sudo make install

4.安裝4store

git clone git://github.com/garlik/4store.git
cd 4store
git checkout a907f3e0a3717c16dabe383d1834df6f8090b97a
./autogen.sh
./configure –enable-no-prefixes
make && sudo make install

5. 測試4store

make test

 

 

hakia,語意搜尋引擎

日前讀了一篇on-line magazine文章,介紹Semantic Search,文章內容一般,但文中介紹了一個新玩意,hakia,是一個語意搜尋引擎,予許使用者以一句語、一個片語或關鍵字來搜尋網頁。當然或你也和我一樣,也用習慣了google search,對於它強大的search,感到讚嘆不已,然而googele search充只量的是以關鍵字的方式來找網頁,hakia 則是一個 semantic web engine。hakia 之中一定包含有一個斷詞系統,來判斷句子結構,並以fuzzy來分析句子中字的重要性,之後再根據己建立的ontology來判斷字和字的關係,以便於找到更符合問題的答案。例如,我問了 where is the popular place to visit?

hakia 的回答不僅找到是網頁中符合這句話中的文字而已,而是判斷出visit最重要,然後popular、place次之。

除了符合這幾個字的網頁會被找到,根據語義的ontology,與這些詞相關的也會被找出來,換句話說,和這句話意思接近的網頁都會被找出來。

哇,最近一直在想如何將地名的語意建立起來,以供查詢查時,能更加準確地或更直覺地提供查詢結果。看來我的想法是沒有錯的。