鏈結農產品產銷履歷資料(Linked Traceability Agricultural Product Data)

食品安全是現今社會的課題,歐美日等先進國家為確保食品安全,已先後實施食品「可追蹤系統」(Traceability System),而食品可追蹤系統應有二個方向,一為向上溯源(從下游往上由追查),二為向下追蹤(從上游往下游追查),二個方向的追蹤應都可追查食品在生產、處理、加工、流通、販賣等各階段的資訊。也就是說, 在食品生產、加工處理、流通販賣等各階段中,關於食品的進貨對象和銷售通路等記錄都予以妥善保管,並透過識別號碼的使用,使食品在各階段之產銷資訊能相互連結,進而建構出可以追溯或追蹤產銷資訊的體系,以在農產品而言,生產階段記錄農藥及化學肥料等栽培管理資訊,在加工階段,將原材料資訊等生產者或加工製造者所要傳達的資訊、將消費者需了解的資訊詳加記錄保管並發佈,以建立可供追溯或追蹤產銷相關訊息的體制 (胡忠一,2006)。台灣自2007年開始推動的農產品產銷履歷驗證制度,結合食品可追溯性(Traceability)和良好農業規範 (GAP)驗證制度,除了可追溯或追蹤產銷資訊,且具有採取嚴密驗證體系,以此建立飲食安全的基礎,並提升國產農產品的國際競爭力,創造農產品的附加價值(周念陵,2012),而可追溯性的建立,在食品安全事件發生時,可以讓主管機關、認驗證機構及相關業者,精確釐清危害來源, 並且快速回收問題食品,有效降低傷害(胡忠一,2006)。

農產品產銷履歷是一個關於農產品從這是一個從田間到零售、從生產者到消費者的記錄,包含產地、產品(作物)、生產者、通路商、栽種流程、加工流程、驗證等資訊,資料若能透過語意網技術加以精煉整理,資料本身可以展現許多知識,例如,作物之物候特性和栽種知識,據此知識,可以了解當令農產品,幫助消費者選擇,若農產品產銷履歷能與農情統計資料連結,一方面,生產者可以了解農產品的生產趨勢,商品流動狀態,因此可以訂定栽種策略,另一方面,政府則可進行作物宏觀的管理、制定作物栽種的調控策略,以免作物大量栽種,在市場崩盤,再進一步,若作物資料可與既有的生態資料庫連結,如植物資料庫,以建立長期生態農業的基礎環境。

然而,資料集與資料集之間的最基本的連結是透過主鍵(Primary Key),一般而言,就是一組不重複的唯一識別碼(ID),但以鏈結資料(Linked Data)而言,只要是資料集與資料集中有相同的實體(entity),就應該相互連結起來。相同實體在不同資料集間的連結是智慧化的開始,透過不斷地連結使得描述實體的內容愈來愈多,以作物名稱為例,作物名稱會被使用在產銷履歷中,但沒被區分出來,一旦區別出來,可與農產品批發市場交易行情中的作物名連結,而了解市場價格,這樣的過程就像是用同一作物名稱同時查詢二個資料庫再把資料整合,但同一作物有可能有不同名稱,同一名稱有可能不同作物,舉例而言,我們常吃的高麗菜,在農產品批發市場交易行情中是使用甘藍菜,鏈結資料即是把這二個作物名稱對映,機器處理資料時能透過這樣的連結而處理更多的資料,而這種連結若不斷持續的擴展,即可建立出知識圖(Knowledge graph)。

除了相同實體連結外,對於機器而言,實體的內涵,及其所代表的一種概念,都應該被清晰的解釋,在人的閱讀過程,可以將知識組合,但對於機器而言,這些實體若沒有清晰的定義,機器是沒辦法區辨出實體所代表的含意及其關係,以致於機器沒有提供進一步的有「智慧」的服務,因此,農業資料的鏈結建立,需要從實體的語意層級的定義開始,也就是建立與定義農業資料語彙,進一步地,建立農業知識本體(ontologies),並調查國際上已發展的農業詞彙,研究如何和這些詞彙映對,以擴展在地農業知識與全球的整合。

建立鏈結資料的目的在於提供一個更完善的資料基礎設施(data infrastructure),以便讓資料在不同知識領域的服務系統或資料庫中的流動,減少人為處理,並且疏理出更多知識脈絡,進而找出資料治理(data governance)的策略,因此農業鏈結資料的發展在資料基礎 設施的脈絡下,是可以增加不同知識領域或不同利益關係者的互操作性(Interoperability)和協同合作(collaboration),因而提昇公私部門協同合作的效率和生產力。

本研究利用農委會產銷履歷之開放資料,建立產銷履歷知識本體,及其三元組儲存庫,並利用該成果建立應用示範,本案朝向於如何利用語意化的產銷履歷資料提供智慧化的服務,讓使用者在瀏覽食譜過程中,有一智慧化元件利用語意化的產銷履歷資料自動地推薦產銷履歷農產品要去那裡買,或者可以去那家餐廳吃到使用產銷履歷農產品的料理。

資料與方法

為了說明如何建立利用語意化的產銷履歷資料的智慧化元件,以可以自動化推薦使用者產銷履歷農產品的服務,本節利用情境案例的方式說明該元件可以達成的服務,及建立該智慧化元件所面臨的問題和解決方法。

情境案例(use case)

小娟是一個家庭主婦,當她開始準備晚餐時,來到了iCook瀏覽蕃茄炒蛋的食譜,如圖1所示。在瀏覽食譜時,小娟可以透過一個瀏覽器上「外掛元件」的服務,找到該食譜網頁中食材所相對應的產銷履歷農產品,以及販賣產銷履歷農產品之賣場和餐廳,並利用簡單的邏輯和空間運算,可以找到在離小娟住家最近的商店,以便購買。在前往購買之前,小娟透過該元件的服務,了解該農產品的價格,估算做這道菜的成本。對於同一種農產品可能有很多的選擇,該元件後端系統整併了產銷履歷達人的資料,因此可以推薦小娟產銷履歷達人的農產品。因為食安問題,販賣產銷履歷農產品之賣場和餐廳是否為合格廠商亦是被關心的問題,衛福部食藥署之登錄的食品業者,該外掛元件後端系統將販賣產銷履歷農產品之賣場和餐廳與衛福部食藥署之登錄的食品業者先進行比對且連結,因此可以提供小華欲前往之賣場是否為衛福部食藥署已登錄的食品業者。

圖1: 在iCook中的蕃茄炒蛋食譜

問題與分析

情境案例中的「外掛元件」,可以利用JavaScript去建立Chrome瀏覽器擴增模組(extension),讓使用者在瀏覽食譜網站時,不需要跳出本來瀏覽的食譜網頁,而這個外掛元件基本上應該進行二件工作,一是讀取iCook食譜網頁中食材,二是以食材送出查詢以取得產銷履歷農產品,以及販賣該產銷履歷農產品之賣場與餐廳,並提供條件設定,可過濾不符合條件之結果。由這二件工作中,我們列出問題,並藉由分析問題中提出解決的方式。

(1) iCook食譜網頁中的食材如何清晰地被取得?

iCook網頁中使用schema.org的語彙,如圖2所示,蕃茄炒蛋中的食材,如牛蕃茄、蛋、青蔥、鹽、…等,都以schema:ingredients 這個語彙所釋詮,因此Chrome的外掛在設計上可以利用Schema.org的語彙,以避免在語意的模糊,而可以清晰地的取得食材。

圖2: iCook網頁中使用schema.org的語彙

(2) 產銷履歷農產品資料雖然已使用結構化的資料儲存方式(JSON),但資料中的實體,如作物名稱、銷售通路商、混雜在文字之中,如何被區分出來?

產品名稱中通常會夾雜作物名稱,如圖3中的產品名稱「檸檬-產銷履歷檸檬(產銷履歷檸檬)」夾雜著「檸檬」,再者,銷售通路中,也夾雜著商店名,如「惠康Wellcome超市(全台各分店), …」這一項中提到,頂好、愛買、家樂福、全聯、好市多等商店,但全在一個欄位,進一步地,「全台各分店」是指這商品在該商店的全台每一家分店都有買,就資料的語意而言,應該區分至每一家分店。

圖3: 產銷履歷農產品開放資料的JSON格式

(3) 產銷履歷農產品、產銷履歷農產品之賣場與餐廳、產銷履歷農產品達人、衛福部食藥署之食品業者登錄分屬不同資料集,資料結構亦不同,如何透過語意技術達到跨資料集的查詢?

產銷履歷農產品、產銷履歷農產品之賣場與餐廳、產銷履歷農產品達人、和衛福部食藥署之食品業者登錄之建立並不是同一個資料集,以關連式資料庫的基礎的傳統做法,是將所有資料透過主鍵的方式將資料串連,而語意網的做法,則朝向於聯合式SPARQL查詢,此查詢得以進行,是因為RDF資料集中,已經先將語意相同的事實相互連結,或以owl:sameAs語彙對映,因此SPARQL查詢過程中,以圖形(graph)為主的三元組資料(RDF),可以整合在一起,以提供完整的結果。

當然,產銷履歷農產品、產銷履歷農產品之賣場與餐廳、產銷履歷農產品達人、和衛福部食藥署之食品業者登錄等資料需要以三元組資料(RDF)方式編碼,且以知識本體為基礎,並分別建立SPARQL查詢端點(endpoint)。

(4) 產銷履歷農產品和產銷履歷農產品之賣場與餐廳中只有地號地址沒有XY座標,如何過濾結果?

產銷履歷農產品和產銷履歷農產品之賣場與餐廳之資料中只有地號或地址,為了進行空間查詢與運算,必需把地號和地址轉化為經緯度坐標。所幸內政部TGOS中有提供地址轉經緯度坐標的服務,且Google Maps亦提供地址轉經緯度坐標之服務。地籍地號方面,地政司也有地籍查詢便民系統,可查詢地籍之經緯度坐標,但無提供API查詢,本研究則是使用社群所建立的地籍地號轉座標的API 達成轉換,可透過這二個系統來取得空間座標。

技術與方法

農產品產銷履歷資料是開放資料,但產銷履歷農產品之賣場與餐廳、和產銷履歷農產品達人只公開在網頁上,但尚未以開放資料釋出,本示範案會設計網頁爬蟲,以自動化抓取這三個網頁中的內容。

取得資料後,需要清理資料,並利用自然語言處理,例如具名實體辦認(Name Entity Recognition),來區分出實體。藉由實體所表達概念與關係,建立知識本體,並利用W3C在語意網的規範,例如,OWL和RDF來編碼三元組資料,且儲存三元組於三元組資料庫(triple store),以及三元組資料服務端點(SPARQL endpoint) 。

而衛福部食藥署食品業者登錄已是開放資料,農產品產銷履歷之銷售通路商和餐廳有許多應是已登錄的食品業者,再者,這些銷售通路商也應該可以在經濟部商業司的公司登記資料中查詢的到,然而,這三者的商店或公司名稱常所指的是同一家公司,但名稱卻不一致,需要自然語言處理,找出相同的銷售商名稱和餐廳,待找出相同的實體後,利用owl:sameAs對映。

圖4: 具名實體辨識處理的示意圖

自然語言處理

具名實體辨識(Named Entity Recognition)是一種從一組文字中區分出具有意義之人事時地物名稱的自然語言處理方法,此方法將文字斷字的處理後,判斷單字會在句子之中出現的特定位置,根據文法結構,單字被分類至所屬的預設的分類,如人名、組織名、地方名、時間、數量、百分比、貨幣…等,圖3所示 。再者,為了對映二資料中相同的實體,如作物名稱,也需要字串相似度的比較 方法。

知識本體

本體論(Ontology)一詞是由亞里斯多德(Aristotle)在 Metaphysics IV, 1 中所提 出,為哲學之一個分支,是研究「 在」本身的問題,即一切現象事物的基本特質。哲 學家所探討的問題著重在於「 在是什麼?」、「 在的特徵是什麼?」和「 在所歸類 的共同特徵是什麼?」等一系列形而上學的問題。然而,本研究中的「知識本體」 (Ontologies)一詞,並非在哲學領域的討論,而是資訊工程中用來定義資料本身語意 (Semantics)的方法,Guarino(1998)為了區分哲學和資訊科學中的知識本體不同, 建議哲學領域所使用的知識本體為英文大寫單數的專有名詞 Ontology,而資訊科學所使 用的知識本體為英文小寫複數一般名詞 ontologies,也就是說,將知識本體(Ontologies) 視為資訊的一種。
而知識本體的的建立即是知識工程,是知識呈現的技術與方法,Noy and McGuinness(2001)認為建立知識本體應該定義

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

就知識工程的方法,他們認為知識本體的建立應包含三個步驟:

  1. 定義領域和範圍;
  2. 考慮重覆利用性;
  3. 列舉本體中的詞;
  4. 定義類別和層級;
  5. 定義屬性;
  6. 重新定義屬性;
  7. 建立實例。

Gruber(1995)提出用框架和第一階邏輯(First Order Logic)來建立知識本體,並定義 5 種基本要素:類別(Classes)、關係(Relations)、功能(Functions)、正規的原則(Formal axioms)和實例(Instances)。而知識本體(Ontologies)根據表達方式有不同的正規化 (Formal)程度,如果表達成自然語言,知識本體可以是高度非正規的;如果表達在一個限制和結構的自然語言形態中,則是一個半非正式的; 如果表達在人工和正規定義的 語言,如 RDF 和 UML,是一個半正規知識本體,而如果一絲不苟地以正規的屬性的語意(Semantics)、定理(Theorems)和證據(Proofs)來定義知識本體中的詞,則是 一個完全正規的知識本體,如第一階邏輯(Uschold and Gruninger,1996; Gómez-Pérez et al.,2004)。隨著,語意網技術的發展,W3C已製定了知識本體的語言OWL(Web Ontology Language) ,其中使用描述性邏輯(Description Logic) 來定義語意,目前大多數知識本體的建立皆以 OWL 為主,只是在格式上採用較為簡單的Turtle或N3。而知識本體的建立工具則以Protégé 為最多人使用。

三元組儲存庫

原始資料透過知識本體,將資料轉化為RDF格式,若是原始資料為表格型態(spreadsheets)可以用Google Refine的 RDF擴充模組、XLWrap、RDF123、或NOR2O等工具,若資料是關連式資料庫,則可以D2RQ、 ODEMapster、或W3C RDB2RDF WG 所發展的R2RML等工具。而若是 XML格式,則可以使用GRDDL或ReDeFer。
資料轉為RDF後,必需由三位組資料庫(triple stores)來儲存, 將RDF資料處理後, 以便提供查詢與管理,因為RDF的查詢語言為SPARQL,因此提供於網路上提供 SPARQL來查詢和管理RDF的接口,又稱為SPARQL端點(endpoints),目前已經有許多開源的工具可以使用,如Jena、Virtuoso、Sesame、4Store、OWLIM、和BBN Parliament等,而為方便RDF資料在網頁上瀏覽,且可以直接透過網頁展示連結資料,目前也有數套前端連結資料服務的工具可以使用,如Pubby, TalisPlatform、Fuseki、和D2RQ等,值得注意的是Pubby和D2RQ是二個受歡迎的前端連結資料服務,但其資料處理與提供方式並不相同,D2RQ強調資料儲存於關連式資料庫中,透過turtle格式映對(mapping)編輯,D2RQ可以直接將關連式資料庫中之資料轉為RDF,並直接顯示於網頁上,而Pubby的後端則必需接上一個三位組資料庫來提供資料。

SPARQL查詢

SPARQL為RDF的查詢語言,其設計的概念很像關連式資料的查詢語言SQL。為展現圖型式資料集和鏈結資料的好處,本案使用聯合式(federated) SPARQL查詢來建立前端的示範平台,為說明聯合式SPARQL查詢,本案利用Andreas Schwarte (2011) 的投影片來解釋,如圖5所示。

圖5: Federated SPARQL Query示意圖

 

RDF是一個方向性的、標籤的圖型(graph)資料,向來表達在網路中的資訊,SPARQL可以用來表達跨不同資料來源的查詢,其中資料需要是RDF或以RDF做為中繼的媒介,聯合式的(Federated) SAPRQL Query 也是一個W3C所 倡議的標準 之一。圖6為聯合式的SPARQL查詢之範例,其查詢跨過二個資料集,或者說二個SPARQL Endpoints,欲查詢紐約時報報導美國總統的頭版文章,透過DBpedia,可以找到美國總統,如圖6 所示,這些被找到的美國總統,則可以對映到紐約時報中總統,紐約時報所用的語彙只是總統,並沒有說明是那一個總統,但因為利用sameAs指向了DBpedia,因此,機器知道在紐約時報找到的這個Barack Obama總統,是美國總統,如圖8所示,聯合式的(Federated) SAPRQL可以一直利用這種方式查找下去,並找到更多的總統,及其報導文章,如圖9所示。

圖6: 聯合式的SPARQL查詢的範例

 

圖7:先找出DBpedia中的美國總統

 

圖8:利用owl:sameAs對映所找的美國總統

 

圖9:對映出更多的美國總統

系統架構

根據問題分析和技術方法的討論,本案預計以聯合式SPARQL查詢方式建立Chrome擴增模組,以提供產銷履歷農產品的應用示範,其系統架構如圖10所示,除了第一期所建立之產銷履歷農產品之三元組資料及SPARQL查詢系統(endpoint),本案會另建立產銷履歷農產品之賣場與餐廳、產銷履歷農產品價格、衛福部食藥署之食品業者登錄、和經濟部商業司工商資料庫等五個資料集之三元組資料及及查詢系統(endpoint),其所有空間參照也都將利用內政部的服務系統轉化成經緯度座標,以便空間條件的查詢過濾。整體而言,系統的運作方式,如圖11所示。

圖10: 系統架構圖
圖11: 系統運作

資料擷取與清理

產銷履歷農產品賣場資料的處理

於農產品產銷履歷網頁上,可查尋到賣場的資料,如圖12所示,且開放資料平台亦釋出「產銷履歷供需資訊-找通路」,這資料集只有8筆資料。根據農產品產銷履歷網頁上的賣場資料,大約可以得到300多筆賣場資料,但這些資料並不完整,因此,本案是以農產品產銷履歷JSON資料中,在「StoreInfo」所提到的商店名稱,該欄資料中包含了大量連鎖商店,如圖3中,惠康Wellcome超市(全台分店),因此先透過網路爬蟲將所有連鎖商店之分店資料擷取,如名稱、地址,若一農產品產銷履歷產品是記載供貨到「惠康Wellcome超市」,則該農產品產銷履歷產品是對映到頂好的全台所有分店,而不是只是記載惠康Wellcome超市。而該欄中常只有農民名稱和連絡方式之銷售通路,這部份不納入整理,主要原因沒有住址無法定位,而在本案平台中展示。最後,將所有資料一一清理並整理成銷售通路資料庫,圖13所示。

圖12: 產銷履歷銷售通路
圖13: 產銷履歷銷售通路資料庫

產銷履歷農產品餐廳資料的處理

由產銷履歷農產品供貨資訊網站中,「那裡吃」可以取得使用產銷履歷農產品的餐廳的資料,餐廳的食材溯源又分為台灣農業跨領域發展協會和有心肉舖子所建之平台,如圖14和圖15所示,二者要呈現的資料都是餐廳有那些餐點使用了產銷履歷農產品,但網頁結構不同,因此需要設計二個爬蟲程式去捉取資料。最後,整理成使用產銷履歷農產品餐廳資料庫,如圖16所示。

圖14: 有心肉舖子所建立的有心溯源餐廳平台

 

圖15: 台灣農業跨領域發展協會所建立的溯源餐廳系統

 

圖16: 使用產銷履歷農產品餐廳資料庫

產銷履歷達人資料的處理

每年的產銷履歷手冊都會把獲獎的產銷履歷達人的採訪和資料整理刊出,如圖17,而這些再被產銷履歷農產品資訊網中一則一則分出來,提出PDF檔,如圖18所示。因產銷履歷達人筆數目前不多,本案是以人工方式逐一整理,成為資料庫,如圖19所示。

圖17: 獲獎的產銷履歷達人

圖18:產銷履歷農產品資訊網中的產銷履歷達人連結
圖19:產銷履歷達人資料庫

衛福部食藥署食品業者登錄之處理

通路商和餐廳整理好之後,利用自然語言處理,自動地去比對產銷履歷中的通路商名稱和衛福部食藥署食品業者登錄中公司的名稱,計算其字串的相似度,因名稱常有重複,再者再以地址輔助來判斷是否為同一商家。在地去比對產銷履歷中的通路商名稱對應到衛福部食藥署食品業者登錄的公司後,可取得統一編號,利用統 一編號可串連經濟部商業司公司登記。

三元組資料與應用系統

知識本體的建立

為清楚解釋農產品產銷履歷資料,知識本體的設計分為三個部份,產地之地理空間、農業概念、和產銷關係,如圖20所示。在產地之地理空間方面,是以「產地 (Place of Origin)」為基礎,每一個「農產品產銷履歷 (Traceable Agricultural Product)」都透過「產於(isProducedAt)」指涉一個「產地 (Place of Origin)」,其產地則是由一個「地址(vCard:Address)」或一塊「農地(Parcel)」來表示,地址表達是再利用vCard的語彙,則可以轉換成「點(geo:Point)」,重複利用OGC GeoSPARQL語彙來表達,農地是一個圖徵概念(geo:Feature),實際上是指涉到一個地號,而地號可以轉換成「點(geo:Point)」或「多邊形(geo:Polygon)」,同樣是使用OGC GeoSPARQL語彙來表達。無論是「點(geo:Point)」或「多邊形(geo:Polygon)」都是幾何的概念(geo:Geometry),也都有geo:WKTLiteral來記錄經緯度資料。

就農業概念而言,「農產品產銷履歷 (Traceable Agricultural Product)」是一個相等於AGROVOC語彙中的農產品(agrovoc:Agricultural Product),該農產品是產品的子類別,而每一個「農產品產銷履歷 (Traceable Agricultural Product)」中都可以區別出一種「作物(Crop)」,該作物概念也同等於AGROVOC語彙中的「作物(agrovoc:Crop)」,該作物是植物的子類別,也就是植物的一種,雖然農產品和作物都是簡單的概念,若沒有充份、有邏輯的解釋,機器是沒有解讀其語彙的語意,本研究所設的知識本體並不需要「重覆製造輪子」,利用農業專業領域中所製定的國際標準語彙,即可將概念充份解釋,讓機器解讀。

同樣的,在產銷關係方面,本研究所設計的知識本體則是利用Friend-Of-A-Friend語彙(簡稱foaf),每一個「農產品產銷履歷 (Traceable Agricultural Product)」都會有一個「驗證單位(Certification Agency)」、「通路商(Store)」、和「農產品經營業者(Producer)」,這三個概念都可歸納成foaf中的「組織(foaf:Organization)」,而每一個「農產品產銷履歷 (Traceable Agricultural Product)」也都有一個「生產者(Farmer)」,該生產者是foaf中的「人(foaf:Person)」。此外,每一個「農產品產銷履歷 (Traceable Agricultural Product)」也具有一個XML schema格式之整數值的追蹤碼、一個XML schema之日期格式的包裝日期、和一個XML schema日期格式之驗證有效日期。

圖20: 農產品產銷履歷知識本體

三元組資料的轉換與資料查詢端點的建立

本研究是透過D2RQ將農產品產銷履歷資料轉換為三元組資料(triplify),且發佈三元組資料。D2RQ Server是用來發佈關連式資料庫內容在語意網上的一個工具,語意網即是一個包含鏈結資料的全球資訊空間,為達到鏈結的資料,資料需要被模型化且表達成三元組的編碼,D2RQ Server使用客制化D2RQ映對語言(mapping language)來對應資料庫內容和三元組資料編碼,並且可以讓這些三元組資料被瀏覽和透過SPARQL語言查找,這二個方式都是語意網開放近用(access)的典範。

三位組儲存庫(triple stores)是來儲存、管理、查詢RDF資料集的平台,而RDF的查詢語言為SPARQL,因此提供於網路上提供SPARQL來查詢和管理RDF的接口,因此,利用三元組儲存庫來提供SPARQL服務的平台,又稱為SPARQL端點(endpoints),目前已經有許多開源軟體的工具可以使用,如Jena、Virtuoso、Sesame、4Store、OWLIM、和BBN Parliament等,而為方便RDF資料在網頁上瀏覽,且可以直接透過網頁展示鏈結資料,目前也有數套前端鏈結資料服務的工具可以使用,如Pubby、TalisPlatform、Fuseki、和D2RQ等,值得注意的是Pubby和D2RQ是二個受歡迎的前端鏈結資料服務,但其資料處理與提供方式並不相同,D2RQ強調資料儲存於關連式資料庫中,透過turtle格式映對(mapping)編輯,D2RQ可以直接將關連式資料庫中之資料轉為RDF,並直接顯示於網頁上,而Pubby的後端則必需接上一個三位組資料庫來提供資料,如圖 21所示。
泉州白菜

圖21:D2RQ和Pubby之比較

D2RQ平台包含三大部份,分別是D2RQ 映對語言(D2RQ Mapping Language)、D2RQ 引擎(D2RQ Engine)、和D2RQ 伺服器(D2RQ Server),如圖22所示。映對語言是一種敘述性映對語言,用來描述知識本體和關聯式資料庫的資料模型之間的映對關係。D2RQ 引擎是Apache Jena 的外掛模組(plug-in),Jena API是接受SPARQL語言接口,而這個外掛模組即是用來重寫來自於Jena API的SPARQL語言查詢為SQL語言,使得查詢得以在關聯式資料庫中運作,另一方面,也將在關聯式資料所查詢的結果,轉成RDF資料,使得關聯式資料庫成為三元組儲存庫的使用,因此也可以透過這個外掛模組將關聯式資料庫中所有的資料,以RDF的格式倒出,或者再與其它JAVA的應用程式一起使用。D2RQ 伺服器則是一個HTTP的伺服器,提供鏈結資料的以HTML的方式瀏覽、查核RDF資料的正確性、和提供SPARQL的查詢。

圖22:D2RQ平台架構

 

圖23:產銷履歷農產品的D2RQ server

D2RQ Server是依靠映對檔將資料庫中的資料轉化成為三元組資料,進 一步地可將三元組資料顯示於網頁中,使資料可以容易用瀏覽器閱讀。為實現鏈結資料,本案將產銷履歷農產品、通路商、和餐廳三個資料集 ,分別建立SPARQL Endpoint,圖23即是產銷履歷農產品的D2RQ server,運作於 http://tap.linkedopendata.tw 上,包含作物(Crop)、生產者(Farmer)、產銷履歷達人(Expert)、 農產品經營業者(Producer)、產品名稱(Product Name)和產銷履歷農產品(Traceable Agriculture Product)等類別,除了瀏覽HTML和RDF資料的功能,D2RQ server亦提供SPARQL的查詢。

完整的映對檔在附錄中,此章節只解釋重點關鍵的宣告表達方式,圖24即顯示本研究所設計的映對檔中的一段,對於「產品名稱 (tap:ProductName)」和「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」二個類別(class)映對定義。在「產品名稱 (tap:ProductName)」類別(class)的定義中,第一段中說明了產品名稱本身被化為唯一的URL(urlify),如「http://tap.linkedopendata.tw/page/ProductName/小白菜(履歷)是唯一的,第二段中宣告了資料庫中產品名稱欄位的值並用於產品名稱的標記(label)。

但還是有許多產銷履歷農產品名為為「小白菜-履歷小白菜」,因此第三段宣告了所有具有相同產品名稱的產銷履歷農產品都歸於同一產品名稱,為確保唯一性,利用產品名稱和產銷履歷農產品的追蹤碼產生雜湊值(hash)來做為產銷履歷農產品的URL,確保產銷履歷農產品的唯一性,然後,再宣告這些具有相同名稱的產銷履歷農產品為產品名稱的「成員」(tap:member),如圖25 所示。

圖25: 映對檔中定義「「產品名稱 (tap:ProductName)」和「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」二個類別(class)的一部份第四段是宣告「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」類別的映對,第五段是宣告產銷履歷農產品之標記(label)是使用資料庫的的欄位,第六段是宣告「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」類別的屬性(property),這段所描述的是產銷履歷農產品具有一個追蹤碼。產銷履歷農產品的其它屬性的宣告方式與追蹤碼宣告方式相似,完整的映對檔可以參考附錄。

圖26:產品名稱「小白菜(履歷)」所具有的「產銷履歷農產品」之成員(tap:member)
圖27: 產品名稱為小白菜(履歷)且追蹤碼為10601020580的產銷履歷農產品

圖27即顯示追蹤碼10511150594及名稱為小白菜(履歷)的產銷履歷農產品,其驗證單位、追蹤碼、農產品經營業者、通路商、產地、生產者姓名、包裝日期、驗證有效日期、詳細栽種流程、詳細履歷資料、詳細加工流程、和其他驗證資訊皆一一列出。與產銷履歷農產品和產品名稱同樣的處理方式,生產者也可以透過唯一辨別的URL和產銷履歷農產品相互指涉,如圖27中的生產者「蘇軍達」,透過蘇軍達的URL即可了解這個生產者產出多少產銷履歷農產品,如圖28所示。同樣地,由於所有的農產品履歷中的事物皆已URL化,因此選擊「保證責任雲林縣漢光果菜生產合作社」的URL可以知道該單位所產出的農產品履歷,如圖29所示。

圖28:生產者「蘇軍達」所產出的產銷履歷農產品

 

圖29:農產品經營業者「保證責任雲林縣漢光果菜生產合作社」所產出的產銷履歷農產品

D2RQ平台提供SPARQL查詢,圖30顯示出產銷履歷農產品產地之查詢結果。

圖30: 產銷履歷農產品產地之SPARQL查詢

除了產銷履歷農產品的SPARQL endpoint,本研究亦建立通路商和餐廳二個SPARQL endpoint,分別在store.linkedopendata.twrest.linkedopendata.tw。在通路商的部份,如圖31所示,除了名稱、住址和經緯度坐標之外,經過名稱相似度比對後,利用owl:samaAs,連結衛福部食品業者登錄資料集,取得統一發票號碼後,再連結經濟部商業司公司登記資料,此外,從產銷履歷農產品資料中整理通路商和作物的關係,因此可以跨Endpoint,以通路商連結產銷履歷農產品,反之亦然。在餐廳的部份,如圖32所示,除了基本的名稱、地址和經緯度坐標,有使用的作物名稱,也有使用產銷履歷農產品的餐點。

圖31: 通路商Endpoint中的「家福樂板橋店」
圖31: 餐廳Endpoint中的「京華煙雲」

Chrome瀏覽器擴增模組的設計

Chrome瀏覽器擴增模組的建立容易,但核心其實是包含在其中JavaScript所執行的任務。RDFLib 是一套專為鏈結資料所設計的套件,其功能包含讀寫RDF資料、 在用戶端進行以SPARQL 讀寫Linked Data、解析 RDFa、建立在地端的查詢API、和處理owl:sameAs的結點,利用RDFLib,我們開發Chrome瀏覽器擴增模組「LinkedFood」。

iCook愛料理網站使用schema.org的語彙來編輯食譜,有利於資料的詮釋,LinkedFood即針對schema.org的語彙來設計資料的讀取,當LinkedFood擴增模組安裝後,開啟iCook的食譜時,LinkedFood即會自動地讀取到食材,透過讀 取的食材,LinkedFood則分別向產銷履歷農產品、通路商和餐廳的SPARQL Endpoint送出查詢,而得到RDF的三元組資料。當在LinkedFood的介面操作時,按了食材,後,在地端可在整合的RDF三元組資料進行查詢,如圖32所示,在那裡買的分頁中,按上方的食材後,如蕃茄,在下方地圖會顯示有賣這個食材的商店,同樣的,如圖33所示,也可以顯示出有那個餐廳可以吃到產銷履歷農產品,利用twfood.cc網站中所整理的價格資訊、產量、以及綜合二種資訊所得到的推薦指數,可以提供使用者購買的參考,如圖34所示,而食材所涉及的每一項產銷履歷農產品,可以在LinkedFood中的最後一個分頁瀏覽,如圖35所示。

圖32: Chrome瀏覽器擴增模組「LinkedFood」的那裡買

 

圖33: Chrome瀏覽器擴增模組「LinkedFood」的那裡吃
圖34: Chrome瀏覽器擴增模組「LinkedFood」的推不推
圖35: Chrome瀏覽器擴增模組「LinkedFood」的產銷履歷瀏覽

整個Chrome擴充模組的操作可見Youtube影片。

參考文獻

  1. 周念陵(2012),健康美麗產銷履歷,行政院農業委員會。
  2. 胡忠一(2006),建立我國農產品產銷履歷紀錄制度,安全農業生產體系研討會專集,13~40頁

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

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