TGOS不進化嗎?! 從ISO 19115到GeoDCAT的鏈結資料

就目前國際潮流而言,為方便地提供開放資料,許多政府紛紛建立資料平台讓人民可以取得開放資料,基於分散式管理的概念,多數政府資料平台的架構不僅是一個資料儲存庫(Data Repository),也是一個資料目錄服務(Catalog Service),在此系統架構下,資料本身並不一定得要儲存於唯一的資料平台,而分散地儲存於各資料平台中,但資料集的銓釋資料可以彼此交換,讓使用者透過一個資料平台即可瀏覽和查詢到所有資料,因此銓釋資料能提供愈完整的資訊,則使用者能在資料平台找到所想要的資料之機會愈高。

在詮釋資料在開放資料平間交換的部份,開放資料管理平台CKAN,一套廣為被許多國家開放資料平台所使用的開源軟體,其中「資料採集(Harvest)」的模組支援了由其它平台收存銓釋資料的功能,此模組本身因整併pycsw套件,因此可處理ISO 19115標準的詮釋資料,並可將地理資訊平台發佈的標準詮釋資料,自動地搬移到CKAN的開放資料平台,而美國開放資料平台(data.gov)即是採集了過去美國聯邦政府的地理資料平台(GOS)中的目錄資料,而將地理資料目錄整併進開放資料平台,此外,CKAN也支援W3C資料目錄語彙 DCAT (Data Catalog Vocabulary) 的採集。

隨著開放資料平台的增加,因應資料目錄的交換,使用標準銓釋資料於開放資料的需求因而隨之增加,銓釋資料遇到的問題不僅在於多個平台,且是不同類型的釋銓資料之管理。基於各知識領域的使用方式,可能都存在各自的銓釋資料標準,如地理空間資料是以ISO 19115為銓釋資料標準、電子化政府資料和圖書資訊資料是以都柏林碼(Dublin Code)、而生態資料是以生態銓釋資料語言(Ecological Metadata Language)做為標準,因此英國愛爾蘭數位企業研究所(Digital Enterprise Research Institute, DERI) 在2010年左右建立了「資料目錄語彙」(Data Catalog Vocabulary, DCAT),被先W3C 電子化政府同好群(eGov Interest Group)納入討論並修改,最後被政府連結資料工作群(Government Linked Data working group) 標準化,於2013年被W3C發佈為標準。

在DCAT於開放資料平台的應用方面,相較於英美而言,歐盟的投入較為極積,這是因為歐盟的開放資料平台需要整合來自各國所提供的開放資料,為解決資料在於跨平台的互操作性問題,歐盟在2013年即發展出DCAT應用綱要(Application Profile),就而空間資料而言,歐盟空間資訊基礎設施(INSPIRE) 要考量的不只是各國地理空間資料的整合,還有地理空間資料與其他類型資料的相容性問題,他們相對積極地企圖以DCAT來整合各國資料平台之內容,並對映地理資訊銓釋資料標準(ISO19115/19119)和DCAT語彙,而發展出以地理空間資訊為主的資料目錄GeoDCAT。2015年5月 聯合國全球地理資訊管理委員會(UN-GGIM)在葡萄牙里斯本舉行的專家會議中,對於統計資料和地理資料的連結之問題中,提出以利用DCAT的解決之道,也就是將統計資訊銓釋資料標準 (SDMX) 和DACT對映,並推導出StatDACT,加上GeoDACT,讓二項釋詮資料的描敘都是以DCAT為核心,但保留對特定領域資料的描敘,使DCAT成為一個大架構來整合二種不同性質資料的想法(UNGGIM, 2015)。

圖1: DCAT語彙之UML關係圖 (Source: https://www.w3.org/TR/vocab-dcat/)

DCAT是一個RDF語彙,用來使發佈於網路上資料目錄能夠達到資料的互操作性,DCAT為W3C的銓釋資料標準,利用DCAT 在語彙描述資料集,可以使應用程式能容易地消化不同知識領域的銓釋資料,並使資料發佈者增加所發佈資料集在網路中被尋找可能性,再進一步地,DCAT可使資料目錄的發佈更為去中心化,促進跨平台的聯合式(federated)資料集搜尋的可能。DCAT語彙 包含三個主要類別(classes),如圖1,分別為dcat:Catalog, 用來表達一整個資料目錄; dcat:Dataset, 用來表達一目錄中的資料集; 以及,dact:Distribution 用來表達資料集的可及性方式,例如以下載、RSS或網路服務的方式來提供資料集。另一個重要的類別是選填的,dcat:CatalogRecord 是用來描述一資料集在資料目錄中。DCAT、GeoDCAT和ISO 19115的對映與討論,可透過歐盟網站上文件來了解,並可設計一套轉換的程式,自動將本來為以XML編輯的ISO 19115語彙轉成RDF編輯的GeoDCAT,也就是將銓釋資料轉為四星級資料。

圖2‭: ‬TGOS資料「座標對位影像五萬分之一分幅地質圖‭ ‬‭(‬頭城‭)‬」之銓釋資料

圖3‭: ‬以平溪「火燒寮」在TGOS上無法查詢到相關圖資在這個ISO 19115語彙可轉換成GeoDCAT的語彙的條件成立下,接下來可以討論以ISO 19115為銓釋資料標準的TGOS,如何在四級星的開放資料下擴展為五星級的可能。以TGOS中「座標對位影像五萬分之一分幅地質圖 (頭城)」為例,其銓釋資料如圖2所示,這個案例著重於在這銓釋資料中二個的項目,分別是關鍵詞和圖資的空間範圍,如圖2所示,其空間範圍為:

最西經度值 gmd:westBoundLongitude:121.748481 ;
最東經度值 gmd:eastBoundLongitude:122.002055 ;
最南緯度值 gmd:southBoundLatitude:24.748512 ; 和
最北緯度值 gmd:northBoundLatitude:25.001564。

利用此一圖資的四極座標範圍,查詢地名資料庫,可得到177筆地名,涵蓋新北市的坪林區、平溪區、貢寮區、雙溪區、和宜蘭縣壯圍鄉、宜蘭市、礁溪鄉、頭城鎮,若這171筆地名皆成為該筆資料的關鍵詞,那TGOS在查詢資料時,則可以查詢到該筆資料,反之,則無法讓使用者利用地名,這種便於人們查詢地理資料的語彙,在TGOS中來查詢圖資料,如圖3所示,若以上述圖資四極座標範圍中的地名之一 「火燒寮」來查詢TGOS,其實無法找到相關圖資,但若是先前將圖資四極座標範圍和地名,或相關資訊做一關連後,再補充該筆資料的銓釋資料,則可增加資料被查詢到的可能性與向度。 此外,可以接續地名連結資料的處理,以達成TGOS資料的五星級。

為什麼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資料。

鏈結資料 (Linked data)、開放資料(Open Data)和鍵結開放資料(Linked Open Data): 從學術到產業行與不行?

昨天應「高人」之邀,參與了台北市電腦公會舉辦的第三場 Open Data產業新契機系列論壇,會中的提問,好像講了太多我們過去的做LOD的經驗,但我提出問題的可能不是很精確,所以台上沒有任何回應,會後也沒有進一步的討論,只有台北市議會的人,是周柏雅議員的助理嗎? 說如果台北市的資料有這樣的問題我們可以幫你,感恩啦! 因為說的不好,所以在自己的部落格上解釋一下。我的發言應該是這樣的

本人在LOD上有實作,有一些經驗可以分享。研考會陳怡君科長說得好,政府資料中有74%是與地理資料有關,地理資料的開放與LOD的發展有很大的關係,今天就以地名而言,是一個很好的鍵結資料,如大家知道「野柳」過去被西班牙人稱為Diablo,這就是同一地點在不同時間上的對於地方稱呼的鍵結,也是台灣與西班牙的鍵結,地名資料目前是沒有公開授權的資料庫,中研院生物多樣性中心和農委會林試所,已經就利用他們所建立的4 5個資料庫中的資料透過開放授權,將資料釋出後,再以LOD技術與全球資料庫GBIF鍵結,並上傳到datahub.io被審核後成為LOD cloud的一雲,而我以內政部地名資料為主,做了另一個LOD的資料集已經與全球最大的地名資料庫Geonames.org 連結,並沒辦法完全上傳至datahub.io,原因是台灣地名資料庫沒有公開授權,若我上傳即有法律上責任,目前只能以學術研究方式提供參考。

(發言的內容有做過一些修飾,但大意沒變。哈哈哈,當天下午已經是疲憊不堪,在沒有充足的提精飲料下,實在無法完整的想起來我說了什麼。TCA的人在我發言完後,拿了一張紙來叫我把我的發言寫下來,幹嘛!這是小學生考試嗎?TCA的大哥大姊別欺負我,請看上面不精確的回憶)

我的問題要表達一件重要的事情,資料沒有公開授權怎麼有辦法做LOD,若要說也只是Linked Data不是Linked Open Data,我長年關心的是地理資料開放授權議題,都到現在這個節骨眼上了,總不能還叫廠商花錢買? 但在場的人似乎不是很在乎這件事。

接下來,對於LOD在產業上的發展,有些觀察,因個人研究興趣,對於語意網和鍵結資料有一些經驗,但三年多來對於鍵結資料的研究,多是都在學習歐美國家發展的狀態,本身並沒有研發出了不起的理論或軟體,相信一定有人比我還專業,能夠說得上的,獻醜了,就是去年在一個日本舉辦的國際會議上,就如何利用LOD資源來做強化非結構性資料,讓使用者在Facebook上貢獻資料中的能夠與現存的LOD資料相連,發表了一篇文章,論文集會由LNCS出版,有興趣可以看看投影片內容

然而這一趟去了日本,學習不少,讓我驚豔的地方是日本對於Open Data的推動方式。學術團體、地方政府和民間業者共同推動Linked Open Data (LOD) Challenge,使得產官學能夠以Open Data的需求與供應面上,就資料集(Data set)、想法(idea)、應用程式(Application)、視覺化(Visualization) 等四個面向來做競賽,個人對於這個活動做了一個簡單的介紹,而觀察了幾個月下來發現,這樣子的競賽活動快速帶動政府、產業和學術的相互交流,強調的是Open Data資料真正落實資料應用的發展、從個人收集女性流行服飾資料並做成APP,到利用政府公開資料來發展生態或深度旅遊應用程式,對於Open Data的應用上,就廣度和深度都有一定的水準。

學術上的研究本來就應該落實到產業,但學術研究的人並不一定能夠了解產業的需求,藉由一次次名為“Challenge”活動,實際上是一種「溝通與對話」,可以逐步地媒合資料供給、技術研發和產業發展,TCA舉辦一系列論壇的目的和日本LOD Challenge相同嗎?老實說,在昨天的論壇中,我沒有看到LOD真正能夠落實到產業是什麼?先不論技術層面的問題,資料連不連的起來的問題,就「原住民族文化觀光資料開放」中的幾個Use cases,看起來就只是在消費原住民的文化,是以治理(或統治)者的角色在思考產業,但這或許是原罪,現存資料庫中的資料本來就是以治理者角度在建立資料,而不是保存文化的角度,舉一個簡單的例子,傳統領域可能與觀光不是那麼密切,但傳統原住民的地名,用他們自己語言來謂呼的地方的名字,是一個重要的文化資產,各位到蘭嶼,下飛機後,看到的地圖是漢語不是達悟族語,那他們為什麼不能用達悟族語來表達他們的地名?同樣的,玉山、雪山和許多高山可能都有布農族或泰雅族地名,為什麼沒有一個漢語和原住民語,雙語併行的地圖? 若原民會手上有原住民傳統地名,拿來和內政部地名Link一下,往後觀光業者就這個資料開發,就可以有雙語,可以行銷在地,又可以教育民眾在地知識,保存原民文化,(長官~,我希望看到的這樣的案例)。廣告一下,事實上,有一群長期關心原民文化的朋友(而且還有外國人參與,汗顏!外國人比我們還關心原住民),長期在花東一帶做原住民語輸入法,也逐步地將原住民語地名建入OpenStreetMap。

LOD的發展是技術面很吃重的工作,若要以推廣LOD進入產業,工具的研發或在化地是很重要的一環。目前在歐洲多是以歐盟層級的大型計畫,如FP7中的LOD2來做研發,並釋放許多的Open Source工具,使後續可以就他們的經驗和基礎再研發。但有許多工具,不一定適合於台灣的資料,最簡單,我們使用的是中文,和別人語系不同,在處理語意,和資料鏈結也會不同,(腦海中竟然出現肝藥廣告詞:成份不同、效果也不同),工研院扮演的角色是針對原民會的這個計畫研發工具,並釋放給業界使用? 昨天的簡報和問答,實在沒有辦法了解到這點。

LOD是達到開放資料五顆星等級的方法,是世界潮流與趨勢,很高興,政府單位開始想做著手做這部份,舉雙手贊同。但昨天聽起來,心中疑惑更多,這樣的討論充其量的只是一個Linked Data的論壇,而不是Linked Open Data的論壇,這麼多被提到資料,有多少是開放授權呢? 再者,談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,與這些詞相關的也會被找出來,換句話說,和這句話意思接近的網頁都會被找出來。

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