資料轉成RDF就是4星級資料了嗎?

因產銷履歷農產品鏈結資料之計畫所需,在data.gov.tw上尋找食品業者登錄資料集,意外的發現這筆資料居然提供RDF格式,不但如此,衛福部食藥署還有一個LOD的網頁,集合了他們製作的RDF資料集。引起了我的好奇,去看看這些RDF的資料,若他們的資料與系統完備,我們的產銷履歷農產品RDF資料即可以和衛福部食藥署的RDF資料連結,但看完資料後覺得有些建議,提出來和大家分享。

<rdf:Description rdf:about="http://data.fda.gov.tw/lod/tfda/FoodCompanyRegistration_VIEW/DATA_SN/6833319">
   <rdf:type rdf:resource="http://data.fda.gov.tw/lod/schemas/tfda/FoodCompanyRegistration_VIEW"/>
   <tfda:公司或商業登記名稱>早安!美芝城仁愛店</tfda:公司或商業登記名稱>
   <tfda:食品業者登錄字號>E-200028714-00002-7</tfda:食品業者登錄字號>
   <tfda:登錄項目>販售場所</tfda:登錄項目>
   <tfda:公司統一編號/>
   <tfda:業者地址>高雄市新興區仁愛一街177號</tfda:業者地址>
</rdf:Description>

上述是食品業者登錄資料集中的一筆資料,沒有了URL,其它的格式的資料沒有什麼不一樣。URL所指涉的是一件事物,讓別人可以去連結這份資料,而在食品業者登錄資料集中,主體是「食品公司」,所以<http://data.fda.gov.tw/lod/tfda/FoodCompanyRegistration_VIEW/DATA_SN/6833319> 指的是一個「食品公司」,即是「早安!美芝城仁愛店」,可被連結的。「早安!美芝城仁愛店」是一個實例(instance),而「食品公司」則是類別(class),因此rdf:type中應該指的是「食品公司」,就是<http://data.fda.gov.tw/lod/schemas/tfda/FoodCompanyRegistration_VIEW>。

1. URL 設計不良

邏輯上,這個RDF 的表達沒有錯,但就URL的設計而言,實在很糟禚。為什麼不簡單清楚一些? 例如,類別的名稱簡單清楚,用FoodCompany取代FoodCompanyRegistration_VIEW,因此,<http://data.fda.gov.tw/ontology/FoodCompany>來指食品公司的類別(class),而<http://data.fda.gov.tw/ontology/FoodCompany/6833319>來指「早安!美芝城仁愛店」這家店。

其實URL的設計是有一些原則,其詳情可以參考W3C的文件 Cool URIs for the Semantic Web

2. RDF與知識本體應一致

再者,這份RDF中的標籤使用中文,但知識本體的宣告卻是英文,這樣的做法機器是沒辦法知道RDF內用中文宣告的屬性,在知識本體中是對到那一個英文。或是說URL根本就不一樣,怎麼有可能對在一起!

3.提供SPARQL查詢

RDF資料通常會利用三元組儲存庫(triple stores)來管理、儲存和查詢資料,這些三元組儲存庫通常也可以透過網路提供SPARQL的查詢服務,因此常稱為SPARQL endpoints,這些工具的技術都己經成熟,而且也有自由軟體可以利用,同時因開放碼源,也可以客製化成自己需求的服務,如果使用者還是把資料下載再使用,那用URL去指稱事物的功能,在網路上就無法發揮更好的效用。

4.缺乏利用既有語彙

為了資料容易整合,在建立資料知識本體時,多考慮使用標準或既有的語彙為主,以增加資料的可再使用性。食藥署的這批RDF資料,無論在類別或屬性都有標準或既有的語彙,是可以考慮多使用這些語彙。

連結感測器資料(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資料。

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,與這些詞相關的也會被找出來,換句話說,和這句話意思接近的網頁都會被找出來。

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

地理資訊在環保公民運動中的問題與重要性

將近80%的數位資訊中含有地理資訊,這句常被提起,雖然難以考究何人提出,但從許多文獻樂於引用它來看,地理資訊的確在現代資訊社會中,佔有重要的地位。然而,地理資料多樣、複雜且多層級的特性,使地理資訊的處理需要更有效、更專門的方法來處理。地理本體學(Geospatial ontology)的研究是用來釐清和分享地理資訊的語意(semantics),以便於整合異質的地理資料,但過去10餘年的研究中,多著重於國家等級的空間資料基礎設施(National Spatial Data Infrastructure, NSDI)整合,例如環境保護署各類環境資料、地政民政機關的地藉資料和水資源局的水文水利資料。無論是局處內或局處間的資料整合(integration),地理本體學在環境資料的整合已經扮演重要角色。然而,這些地理資料僅侷限於政府部門和專家學者使用,整合後的網路服務也不近民情,並無法將地理資訊的使用推向更高效率的使用情境。
隨著資訊社會的演進,走向Web2.0的世代,社群合作(community-based collaboration)成為主流趨勢,網路的互動不再是一個單一方向資料傳遞,使用者不僅只是接收資料,本身所生產的資料透過合作協同,亦可回饋至網頁上。然而,地理資訊在各國政府都視為重要的基礎之下,皆投注大量資源建立資料庫,而資料不斷累積的結果,是將地理資料堆積成一個龐大的巨怪,面對靈敏的網路世代,顯得緩慢且不知所措,若使用者對於資料不認識或不具有資料本身的知識,是無法運用資料,此外,如此大量的寶貴資料在沒有適當整合(integration),一般人無法輕易地的找到所要資料,即找到資料,這些地理資料通常需要專門的地理資訊系統軟體才可以使用,更是限制了這些資料的使用。
開放地理空間協會(Open Geospatial Consortium, OGC)針對地理資料格式和網路發佈制定了規範,解決地理資料格式整合和網路分享,但地理資料語意(semantic)的整合仍然是一個棘手的問題,這個問題包含由上從下(top-down)和由下而上(bottom-up)的整合。地理資料語意從上而下的整合,是著重在於降低地理資訊專業知識隔核,使一般使用者能輕易使用由專家所建立的地理資料,例如,吾人規劃一條路徑想從烏來到福山、從雙連埤出宜蘭,想知道這一路可以會遇到什麼動植物,此時他只要將路徑上傳到動植物查詢網頁中,此時系統會根據他的路徑、路徑所經之高度、植被狀況和人一般眼力可視範圍,產生一塊區域,再將此區域和動植物調查所記錄的位置逐一比對,即可顯示可能出現在的動植物。一般人不需要了解什麼是視域範圍、環域(buffer)、空間運算,也不需要XY空間坐標,只要告訴電腦經過的地名,可能出現的動植物即可顯示。而由下而上的整合著於現今網路的合作協同,透過Web2.0的技術,使用者可生產資料,而將這些再利用,整合到資料庫中,成為另一項資源,又以前者為例,使用者去走了這一條路徑後,發現系統所顯示的動植物分佈點並無出現,他可以在註記這些分佈點並無系統顯示的動植物出現,當然也可以報導系統所顯示的動植物分佈確實出現,以便提高系統預測動植物出現精準度,另一方面,他可以記錄那些系統所沒有提供動植物分佈至系統,增加資料庫的豐富度,如此這樣的系統不但增進資料庫的使用,另一方面,也降低了資料庫的更新的成本。然而,一般人並未受過動植物調查的訓練,這樣的資料如何能整合一個由專家所建立的資料庫之中,因此需要解決專業上動植物出現認定和一般人所認為的植物出現的語意(semantic)問題,這也是一個地理空間上的語意(semantic)問題,例如,使用者加註一筆資料為,「台灣藍鵲在哈盆附近」,何謂「附近」? 50公尺、100公尺或150公尺呢? 又如「紅嘴黑鵯在南勢溪上游」,「南勢溪上游」是指那一個地方? 界線為何? 使用者的所貢獻的動植物資料在空間上是否能正確無誤呢? 如何設計一個讓使用者容易報告位置的介面呢? 而空間資料能夠整合至動植物資料庫呢? 這樣的發想產生一連串的問題,而這些問題是來自於上下位之間語意的不一致,使目前Web 2.0世代中,使用者資料大量生產,但無法再加以利用,本研究在於解決這樣的問題,企圖以地理空間的角度出發,研究如何整合上下位語意差異,進而使得政府或專家所建立之資料庫可以被一般使用者用,而使用者可進而成為專業或政府資料庫的提供者。
而這樣的研究將可以在環境保護上創造什麼利益呢? 地理資訊系統逐漸成為公民運動的一項工具,如美濃水庫事件,公民運動中常透過地理資訊系統使在地居民隨時空推演來建立並累積地方知識,進而使在地居民理解在地環境的脈絡,強化在地居民對地方的關心和發展,進而成為解析公共議題、解決公共問題的基礎,但以國內(社區大學促進會)為例,所面臨問題即是再於政府資料的取得,再者,即是如何提供親近人群的介面使在地居民輕易地提供資料,而在地居民所記錄的資料又如何整併到(專業的)政府的資料,而成為有利於說服政府,提起輿論的工具。因此上下位資料整合成為重要的一環,使一般人所生產的資料產生更大利用價值和可信度,使公民運動得以依賴地理資訊系統而解決更多的公共議題。
最後,我相信Green Map是一項成功的公民運動,參與者透過參與、收集和分享綠色商店、生態產品和回收點,進而了解綠色商品和回收在環境保護上的重要性,但在我研究的架構下,我不僅要問,那下一步呢?這些資料是否能產生更重要的價值、激發更多回饋和輿論、解決更多環保的公共議題呢?