鏈結農產品產銷履歷資料(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 所示。

# Class ProductName
map:ProductName a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriPattern "ProductName/@@agricultureProduct.ProductName|[email protected]@";
d2rq:class tap:ProductName;
#d2rq:condition "";
#d2rq:classDefinitionLabel "ProductName";
.
map:ProductName_label a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:ProductName;
d2rq:property rdfs:label;
d2rq:pattern "@@[email protected]@";
.
map:ProductName_member_TraceableAgriculturalProduct a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:ProductName;
d2rq:property tap:member;
d2rq:uriSqlExpression "CONCAT('http://linkedopendata.tw/tap/resource/TraceableAgriculturalProduct/', cast(MD5(CONCAT('Name:', agricultureProduct.ProductName, 'Tracecode:',agricultureProduct.Tracecode)) as char))";
.
#Class TraceableAgricultureProduct
map:TraceableAgricultureProduct a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriSqlExpression "CONCAT('http://linkedopendata.tw/tap/resource/TraceableAgricultureProduct/', cast(MD5(CONCAT('Name:', agricultureProduct.ProductName, 'Tracecode:',agricultureProduct.Tracecode)) as char))";
d2rq:class tap:TraceableAgricultureProduct;
.
map:TraceableAgricultureProduct_label a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:TraceableAgricultureProduct;
d2rq:property rdfs:label;
d2rq:pattern "@@[email protected]@";
.
map:TraceableAgricultureProduct_tracecode a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:TraceableAgricultureProduct;
d2rq:property tap:hasATracecode;
d2rq:column "agricultureProduct.Tracecode";

圖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」的那裡吃
圖35: Chrome瀏覽器擴增模組「LinkedFood」的產銷履歷瀏覽
圖34: 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資料的五星級。

關於米的冷知識

這幾個月來,一直在進行產銷履歷農產品資料的結構化的工作,為了農產品名稱和作物類別對映,對於作物的差異就會特別的關注,例如,大陸妹、A菜、萵苣的差別,而身為以米為主食的人,自然而然也會對於稻米農產品有所好奇,黑米和紫米是同一種米? 香米和馥米有什麼不同? 台灣的越光米是日本來的嗎? 對於種種的疑問,只能以Google Intelligence(GI)來處理,所以這些米的冷知識,其實是做產銷履歷農產品資訊結構化的一個副產品。

From Ozzy Delaney

「蓬萊米」一詞,代表一段台灣米歷史

在生物學上的分類,稻為禾本科稻屬(Oryza),含有22種,但只有非洲型稻(Oryza glaberrima)和亞洲型稻(Oryza sativa)為栽培種,其餘20種為野生種,其中亞洲型稻又有三個亞種,分別為爪哇型稻(javaonica)、印度型稻(indica)、和日本型稻(japonica)[1],而這三種亞種在台灣都有,而且和移民殖民的歷史有莫大的關係。

爪哇型稻為熱帶型梗稻,有可能在數千年前,由南島語系民族帶入台灣,也有一說是荷據時期由荷蘭人引進,但隨著中國東南沿海的移民和日本治理引來稻種,爪哇型稻數量也跟著減少,甚至消聲匿跡。

印度型稻,又稱為秈稻,廣泛分佈於熱帶和亞熱帶地區,明清時期由中國東南移民帶入的台灣,是日治時期之前,台灣的主要稻種。

日本型稻,又稱為粳稻,主要分佈於溫帶到亞熱帶地區,日治時期由日本人引進,經過不斷地雜交改良,把適於北方溫帶的梗稻成功地馴化於台灣的氣候環境栽種,而這種由日本米馴化的台灣米被命名「蓬萊米」,而原本廣泛栽種的秈稻,被稱為「在來米」,或者說是在萊米,即有本地米之意,因此在台灣才有梗稻為蓬萊米,而秈稻為在來米之說。這段蓬萊米歷史在磯小屋的網站上有清楚的介紹,也有來自於PTT版專業鄉民解說。附帶一提的是,台灣也有原生種稻,稱為「鬼稻」。

「蓬萊米」(粳稻),形狀圓短、顏色有些透明,有些品種的米粒有局部白粉質,煮熟後帶有Q度但不像再來米(秈稻)硬,有黏度但又不像糯米黏,是目前多數人偏愛的口感,我們吃的白飯多數是蓬萊米。而「在來米」(秈稻)的形狀細長、透明度高,煮熟後吃起來口感偏硬且乾鬆不黏,因此目前多數不是以白飯來食用,而是用於米類加工品是用,例如,碗粿、蘿蔔糕、粄條…等。

另外,常見的糯米其實是稻米的變種,稻米中含有直鏈澱粉和支鏈澱粉,而支鏈澱粉含量愈高,米就會愈粘,而糯米的支鏈澱粉超高,可達90%,直鏈澱粉含量就很低,平均在10%以下,而秈稻和粳稻都有糯米,粳糯,也就是圓糯米,直鏈澱粉在5%以下,煮熟很粘軟,多數被用來做粿和麻糬,而秈糯,也就是長糯米,直鏈澱粉在5%-9%之間,煮熟後雖然粘,但帶點秈稻硬的特性,一般吃的飯糰、油飯、米糕等,多數是用這種米。

稻米的加工

by ijnek29
紫米 (from ijnek29)

有顏色的米,紅米、紫米、或黑米,其顏色是來自於米糠層的花青素,換句話說,這些帶有顏色的米都是「糙米」,也就是這些稻穀只僅經過脫殼步驟,但又未把米糠層去除。根據陳琳臻營養師的調查,「市售的紫米其實就是為黑糯糙米,而黑米多數為黑糯糙米,但也有部份是黑秈糙米」。而紅米,即紅糯米或紅栗米,是阿美族的傳統作物,為爪哇型稻。

除了糙米,稻穀若去除多數米糠層但保留胚芽,即為胚芽米,如果脫殼後又去掉所有米糠層、胚芽,就成為白米。而日本的清酒則是磨到只剩米心來製酒,步米精合則是表示保留的程度,例如,步米精合為60%,表示一批米是被磨掉4成後,才拿來製酒,貴鬆鬆的獺祭二割三分,則是磨掉了77%,所以這個很好喝,價格不貲。

白米和糙米的等級

依照前面的介紹不難理解,國家標準(CNS)將白米和糙米分為梗型、秈型、圓糯以及長糯主要四種類型,其中梗型及秈型分成為三個等級,一等為最高等級,其次為二等和三等,分級之判定,白米是依據性狀、水分、夾雜物、稻穀、糙米、熱損害粒、被害粒、異型粒、碎粒、白粉質粒、及未變糯粒之百分比來判定,而糙米是依據水分、夾雜物、稻穀、熱損害粒、發芽粒、被害粒、異型粒、碎粒、未熟粒、及未變糯粒之百分比來判定。這個國家標準在網路上找到的資訊,內容都有一些差異,下面的表格是由標檢局發出的公文所附的國家標準文件中截錄出來。

目前市售包裝米都會標示品質等級資訊,這方面是隨個人喜好,等級高的米,價格自然貴一些,但品質真的比較好。

水稻品種

水稻育種和台灣農業發展有重要且密切的關係,在農委會的農業知識人口網中,稻米是百年農業發展史中重要農業育成品種之一,這個網站記載了從日治時代末永仁所發表的台中64 號到目前我們在市面上常見的米種。

名稱育成年別育成機關育種者
台中65號1936行政院農業委員會臺中區農業改良場末永仁、藪龜孟男、田村猛、大崎忠一、余慶東
臺稉2號1989行政院農業委員會臺南區農業改良場莊商路、林國清、吳文政
嘉農242號1956行政院農業委員會農業試驗所嘉義農業試驗分所吉瀨忠、楊遜謙、王茂康
台中178號1957行政院農業委員會臺中區農業改良場余慶東、洪秋增、林克明、簡招財、蔡民
高雄27號1957行政院農業委員會高雄區農業改良場王南澳、李新傳、蕭光輝、謝英鐸
高雄53號1957行政院農業委員會高雄區農業改良場王南澳、李新傳、蕭光輝、謝英鐸、黃金光
台中在來11957行政院農業委員會臺中區農業改良場余慶東、洪秋增、林克明、蔡民、林寶、楊儒榮
臺南1號1958行政院農業委員會臺南區農業改良場林朝杉、莊商路
臺南5號1965行政院農業委員會臺南區農業改良場林朝杉、徐進生、莊商路
台農61號1972行政院農業委員會農業試驗所黃真生、陳源泉、許東暉
台東27號1972行政院農業委員會臺東區農業改良場林弘造、陳榮輝
嘉農秈6號1973行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
嘉農秈選81973行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
嘉農秈11號1973行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台農62號1975行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
臺南6號1975行政院農業委員會臺南區農業改良場徐進生、莊商路
高雄139號1975行政院農業委員會高雄區農業改良場林富雄、吳育郎、鍾德月、蕭光輝
台中秈3號1976行政院農業委員會臺中區農業改良場林寶、江壬卿、宋勳、胡燦
台東28號1977行政院農業委員會臺東區農業改良場林弘造、陳榮輝、江瑞拱
台農67號1978行政院農業委員會農業試驗所黃真生、陳源泉、洪信雄、陳正昌
高雄秈7號1978行政院農業委員會高雄區農業改良場林富雄、吳育郎、黃金光、鍾德月、郭同慶
台農秈12號1979行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台中秈10號1979行政院農業委員會臺中區農業改良場林再發、江壬卿、曾勝雄
台東29號1979行政院農業委員會臺東區農業改良場林弘造、陳榮輝、江瑞拱
新竹64號1981臺灣省新竹區農業改良場(現行政院農業委員會桃園區農業改良場曾煥東、陳素娥、林芳洲、詹泉發
台農秈14號1982行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台農68號1982行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台中189號1983行政院農業委員會臺中區農業改良場林寶、曾勝雄、洪秋增、黃賢喜
台農69號1984行政院農業委員會農業試驗所黃真生、洪信雄、卜瑞雄、陳正昌、鄭清煥
台農秈18號1984行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台農秈19號1984行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台中秈17號1984行政院農業委員會臺中區農業改良場林再發
台中糯70號1984行政院農業委員會臺中區農業改良場黃賢喜、洪梅珠
台中秈糯11984行政院農業委員會臺中區農業改良場江壬卿、宋勳、黃賢喜
台農70號1985行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男
台農秈20號1986行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男、陳一心
台農72號1987行政院農業委員會農業試驗所嘉義農業試驗分所張萬來、楊遜謙、陳隆澤、趙政男、陳一心
高雄142號1987行政院農業委員會高雄區農業改良場林富雄、鍾德月、蕭光輝、邱運全、吳育郎
臺南15號2011行政院農業委員會臺南區農業改良場羅正宗、陳榮坤
臺稉糯1號1990行政院農業委員會臺南區農業改良場莊商路、郭金條
臺稉4號1990行政院農業委員會花蓮區農業改良場鄭明欽、李超運、劉瑋婷
臺稉5號1990行政院農業委員會高雄區農業改良場邱運全、鍾德月、林富雄、吳育郎
臺稉6號1991行政院農業委員會花蓮區農業改良場、農試所嘉義分所鄭明欽、劉瑋婷、林富雄、楊遜謙、陳隆澤、陳一心
臺稉8號1992行政院農業委員會臺南區農業改良場莊商路、林國清
臺稉9號1993行政院農業委員會臺中區農業改良場許志聖、張素貞、宋勳、林文龍、侯福分、張盛添
臺稉10號1993行政院農業委員會花蓮區農業改良場、農業試驗所林富雄、李祿豐、莊義雄、黃真生、陳正昌、曾東海、陳治官
臺稉11號1994行政院農業委員會高雄區農業改良場、農業試驗所邱運全、林富雄、吳育郎、劉大江、陳正昌、曾東海、陳治官、李長沛
臺稉糯3號1995行政院農業委員會臺南區農業改良場、農試所嘉義分所林國清、侯福分、陳隆澤、陳一心
臺稉14號1996行政院農業委員會桃園區農業改良場、農試所嘉義分所黃振增、陳素娥、林芳洲、陳隆澤、陳一心
臺稉16號1996行政院農業委員會花蓮區農業改良場、農業試驗所鄭明欽、李超運、劉瑋婷、黃真生、劉大江、陳正昌、曾東海、陳治官
臺秈2號1998行政院農業委員會高雄區農業改良場吳志文、邱運全、鄧耀宗、林富雄
臺農71號2000行政院農業委員會農業試驗所賴明信、李長沛、曾清山、黃惠娟、陳正昌、陳治官、郭益全
臺東30號2002行政院農業委員會臺東區農業改良場、農試所嘉義分所黃秋蘭、江瑞拱、陳隆澤、陳一心
台農秈22號2004行政院農業委員會農業試驗所嘉義農業試驗分所陳隆澤、羅正宗、陳一心
台農糯73號2004行政院農業委員會農業試驗所賴明信、李長沛、曾清山、顏信沐、陳治官
桃園3號2004行政院農業委員會桃園區農業改良場、農業試驗所黃振增、陳素娥、林孟輝、林芳洲、陳正昌、賴明信、曾東海、李長沛
臺南11號2004行政院農業委員會臺南區農業改良場林國清、侯福分
高雄145號2004行政院農業委員會高雄區農業改良場邱運全、吳志文、林富雄、鄧耀宗
花蓮20號2004行政院農業委員會花蓮區農業改良場宣大平、潘昶儒、余宣穎
桃園4號2005行政院農業委員會桃園區農業改良場黃振增、陳素娥、林孟輝、林芳洲
台東糯31號2005行政院農業委員會臺東區農業改良場黃秋蘭、丁文彥、江瑞拱
台農74號2006行政院農業委員會農業試驗所嘉義農業試驗分所陳隆澤、羅正宗、陳一心
台農75號2006行政院農業委員會農業試驗所賴明信、李長沛、曾清山、顏信沐、卓緯玄、曾東海、陳治官
臺農秈糯212006行政院農業委員會農業試驗所曾東海、鄭統隆、王強生
台中192號2007行政院農業委員會臺中區農業改良場呂坤泉、許志聖、楊嘉凌
花蓮21號2008行政院農業委員會花蓮區農業改良場宣大平、潘昶儒、余宣穎
台農76號2009行政院農業委員會農業試驗所嘉義農業試驗分所吳永培、曾東海、蔡武雄、王強生、林彥蓉、吳泓書
台農78號2009行政院農業委員會農業試驗所嘉義農業試驗分所吳永培、曾東海、蔡武雄、王強生、林彥蓉、吳泓書
台農80號2009行政院農業委員會農業試驗所嘉義農業試驗分所陳榮坤、陳隆澤、羅正宗
台中194號2009行政院農業委員會臺中區農業改良場許志聖、呂坤泉、楊嘉凌
臺南14號2009行政院農業委員會臺南區農業改良場陳榮坤、羅正宗
台東32號2009行政院農業委員會臺東區農業改良場黃秋蘭、丁文彥、江瑞拱
台農84號2010行政院農業委員會農業試驗所嘉義農業試驗分所陳隆澤、廖大經、黃守宏、卓緯玄、顏信沐、羅正宗、陳榮坤
高雄147號2010行政院農業委員會高雄區農業改良場吳志文、張芯瑜、邱運全
台農77號2011行政院農業委員會農業試驗所李長沛、賴明信、曾清山、顏信沐、卓緯玄、吳東鴻、陳治官、曾東海
台農82號2011行政院農業委員會農業試驗所嘉義農業試驗分所吳永培、曾東海、吳泓書
光復1號1947行政院農業委員會農業試驗所嘉義農業試驗分所吉瀨忠、楊遜謙

在Google Intelligence過程中,看到了農委會農試所建置了一個「水稻品種資訊系統」,上面列了160多種水稻品種,當興高彩烈地想進一步查看每一種水稻的資訊時,發現這個系統像一場騙局,網頁上所有的連結都是無效的,也沒辦法查進一步的資訊,失望透頂! 相信政府的農糧單位一定有許多水稻品種的資訊可以提供參考,如同農委會農糧署東區分署對於該轄區的水稻品種介紹,豐富的資料為什麼不開放呢?

在網路確實可以找到不少稻米品種的文章,例如,愛料理(iCook)配合掌生榖粒飯,粒特別企畫,挑選了10種台灣米以文創的方式就產地和特色來介紹,對於想從品種來選購白米,是一個不錯的指引。台灣米的經典品種一文,也對於台灣主要的幾個常見米種有所介紹。

在此,我就記錄一下個人覺得有趣的部份。

越光米

越光米(コシヒカリ)是原產於日本的水稻品種之一,亦是日本是栽種面積最廣的水稻品種,煮熟的白飯口感極佳,無論是粘性、彈性和甜度都很好,飯即使冷了,仍然保有Q彈口感,因此適合用於壽司,其實飯冷了還可以保有好的口感,一定是好米,因此很多米都會號稱自己的米是壽司米。宜蘭地區,特別是五結,每年都會進口日本原生米種栽種,但畢竟是日本米種,不適應台灣環境,不易栽種,產量也少。

台南16號,台版越光米

台南16 號是台南區農業改良場與台大農藝系合作,以「分子輔助選種技術」找出台灣水稻特有的「日長不敏感基因」,與日本越光米不斷回交選拔,讓越光米在台栽種不致於過快早熟,成為適合台灣環境生長的米種,而口感卻不失越光米,被稱為「晶鑽米」,而台大農場與彰化二林壽米屋合作,以台南16號所發展自有品牌則稱為「鹿鳴米」。 2016「全國名米產地冠軍賽」彰化二林的台南16號得到總冠軍,因此,本人以身試米,買了該地產的台南16號米,口感確實不輸給越光米,值得推薦。

講到台南16號、晶鑽米、鹿鳴米其實比較沒人知道這種米的品質有多好,說台版越光米容易吸引人,也讓人可以聯想到越光米的品質,所以現在可以看到很多款包裝米,都標榜自己是越光米,或是台版越光米,不過選購也得詳細看,是否確實為台南16號!

台梗9號,具有抗癌功效的米

台梗9號是我第一認識的米種,草屯鎮不但是南投縣栽種稻米最廣的地區,也栽種不少的台梗9號。這種米煮成白飯後,粒粒飽滿、口感Q彈,冷掉後也不失口感,也是壽司米等級。這個米種在前陣子因為有抗癌效果而聲名大噪,馬偕紀念醫院臺北總院和嘉義大學進行偕同研究,發現台稉九號中的醇溶蛋白成分具有抗白血病免疫功能,可刺激單核球等免疫細胞分泌細胞激素,抑制人類白血病細胞的生長和誘導巨噬細胞分化。也因為如此,台梗9號被混充的品牌眾多,農委會曾經抽檢市售包裝米,發現號稱台梗9號米的包裝米竟然連一顆都沒有。

台南11號,平易近人的便當米

台南11號是台灣栽種面積最廣的米種,佔全台水稻栽種面積近六成,主要栽種於嘉義、台南、雲林、 彰化、台中、屏東等地,因為產量多,品質又不錯,深獲自助餐和便當店喜愛,所以我們吃的便當之中,很多是台南11號米。據媒體報導,因2011年的福島核災和連日大雨水淹米鄉新瀉,使得日商來台購糧,在試吃完台南11號米後,驚為天人! 採購360噸,由彰化縣聯米企業產出的台南11號米,直接進入日本餐廳、學校、並且在超商販售,成為指定輸日的品種,這件事造成當時的轟動,因此台南11號又有「驚為天米」之稱。

2005-2014年主要良質米品種栽培面積前5名百分比排名(取自陳勵勤、羅正宗(2016),漫談水稻「臺南11號」之貢獻,臺南區農業專訊,97期,12-15頁)

 

年度\面積排名12345
92台稉8號(38.4)台稉14號(19.9)台稉16號(11.4)台中秈10號(8.4)台稉2號(8.0)
93台稉8號(37.8)台稉14號(21.3)台稉16號(19.4)高雄139號(6.5)台稉2號(5.9)
94台稉8號(31.9)台稉14號(20.8)台稉16號(14.3)臺南11號(10.4)台稉2號(6.2)
95臺南11號(30.8)台稉8號(22.8)台稉16號(12.0)台稉14號(10.0)台稉9號(6.0)
96臺南11號(52.5)台稉16號(12.5)台稉8號(11.8)台稉14號(6.6)台稉9號(4.4)
97臺南11號(55.4)台稉14號(10.3)台稉16號(7.0)台稉8號(5.9)台中秈10號(4.3)
98臺南11號(60.4)台稉14號(9.3)台稉16號(4.9)台中192號(4.6)台中秈10號(4.5)
99臺南11號(57.9)台中192號(9.0)台稉14號(8.9)台中秈10號(5.1)台稉16號(4.1)
100臺南11號(60.4)台稉14號(8.6)台中192號(5.4)台稉9號(5.1)台中秈10號(4.2)
101臺南11號(64.8)台稉14號(8.8)台中192號(4.9)台稉9號(3.7)台稉2號(3.4)
102臺南11號(62.7)台稉14號(8.8)台中192號(4.8)台稉9號(4.0)台稉2號(3.7)
103臺南11號(62.2)台稉14號(9.4)台中192號(6.4)台中秈10號(5.9)台稉2號(2.9)

高雄139號,花東米的主力

高雄139號是1970-80年代推廣的米種,成熟時結實纍纍,穀粒飽滿,抗稻熱病佳,又適合機械化採收,深受稻農好評,煮熟後的口感好,接近日本米口感,粘度適中且Q彈,但米粒較小,外觀不佳,心腹白多,不夠透明清澈,因而被稱為「醜美人」。這米種早期曾遍佈全台,目前只有花東一帶種植較多,主要是因為花東地區的土壤、氣候與日照,特別適合種植高雄139號。

高雄145號,醜美人的整型版

高雄139號雖然具有許多優點,但外觀處於弱勢,不易被品質要求高的日本商接受,因此農委會高雄區農改場於1997年以高雄139號為母本,與日本優質米絹光(Kinuhikari)雜交,經過多年的選拔改良,而在2004年命名育成新品種高雄145號。果真在2012年,日本的「ニボンアグリアクセス株式會社」,向屏東新園的「新豐稻米產銷專區」簽約採購500噸高雄145號。

台農71號 (益全香米),享譽盛名的香米

稱為香米,即是在煮熟後,米飯帶有芋香味。台農71號之所以又被稱為益全香米,是為了紀念該米種的育種者郭益全博士於品種發表前,因心肌梗塞過世,前總統陳水扁特別將台農71號命名為「益全香米」,成為國內第一個有商品名的稻米品種。而2003年大學學測作文題目「香米碑」以郭益全博士研發台農71號的過程為考題,讓台農71號廣為周知,加上無米樂的崑濱伯以台農71號於2006年奪下全國稻米品質競賽的冠軍,更讓這個香米聲名大噪

桃園3號,發展潛力高的香米

台農71號其實是一個日本混血兒,是由台稉4號(父)和日本絹光(母)育種而成,因此台農71號不但有特殊米香,並帶有日本米的品質與口感,而真正的純種本土香米則是桃園3號,其父本台稉2號、母本台稉4號,在2004年7月才通過命名審查,因發源地新屋鄉,被取名「新香米」。由於桃園3號是在環境較惡劣的北部濱海環境中育種而成,對於惡劣環境的耐受力也比台農71號高,是一個具有競爭力的米種。

台中139號,印度血統的馥米

香米是以芋頭香出眾,而馥米是以茉莉花香為主?! 農產品產銷履歷中看到「馥米」時,充滿困惑,心想這又是什麼推銷產品的花招,原來這是許志聖博士,也是台梗9號的育種者,所培育出來的米種,母本為台梗9號,父本則是巴斯馬帝(Basmati),也就是印度香米,而研發出了台中194號,一個和Basmati一樣帶茉莉香的米,外型飽滿、淨透光亮,口感上較軟、黏性較高,烹煮後淡雅清香,白飯放冷香氣更明顯。

台中秈10號,都市人的健康新選擇

根據台中區農改場的報告,台中秈10號是以抗病抗蟲產量高的「臺中秈試204號」為母本,與也是抗病抗蟲產量高「嘉農秈育14號」為父本進行雜交而成。秈米的口感一般較乾硬,但富含纖維質且低澱粉,而台中秈10號除了具有高纖低澱粉的特點外,米粒大而飽滿,晶瑩有光澤,在口感上不黏不膩,又軟又Q,細細咀嚼的淡淡香甜滋味別有一番風味,且吃下肚後,較不易產生飽脹感,都市生活勞力活少,熱量需求小,但追求健康,因此高纖低澱粉是適合於都市生活型態的人,好吃易消化,營養不發胖。

[1]呂坤泉、許志聖、楊嘉凌(2002),世界水稻的分類,臺中區農情月刊第 40期。

 

資料轉成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資料,無論在類別或屬性都有標準或既有的語彙,是可以考慮多使用這些語彙。

在火車誤點背後的資訊化落後問題

開放資料的問題常常是從自身的日常生活開始。二週前,從花蓮回到台北時,搭了一班假日加班車自強號253次,從花蓮出發,中途就只停松山,而終點站是台北,整個車程只有三站,但當日(12/18)的車次在抵達松山時已經是誤點3分鐘,遲到時間不多,但在深夜時段、沒有乘客上下車的情形下,還會誤點,這就很有問題。

台鐵其實很少準時

很好奇地在網路上著手查詢一下台鐵誤點資料,發現交通部統計查詢網中,可以找到歷年來各種火車類別的到站準點率,但有趣的是,其中有些資料,例如客運量,已經在政府資料開放平台上發佈,但準點率的統計卻沒有,為什麼呢?

透過各種列車的每月平均到站準點率之統計資料,把過去10年的資料攤開來看,結果很有趣,慢車比快車準時,普通車才有可能達到一整個月都準時,整體而言,準點到站率表現最好,其次是區間車,莒光號與自強號半斤八兩,這樣的結果難道沒有人覺得很不合理嗎?!

[d3-source canvas=”wpd3-910-0″]

是! 這個問題確是在2015年10月時,就有立法委員提出來要求台鐵改善,要求成立專責小組,當時的交通部長還要求台鐵在半年月內改善,然而,這件事就在總統大選與政府輪替後,又石沉大海,大家好像又習慣了台鐵的誤點,對於經常性的誤點只有無奈以對,或者是自嘲地挺過一次次等嘸車的無奈。

台鐵誤點讓使乘客等車等了”一年” (截圖於爆社公社臉書社團)

誤點原因

自由新聞報導台鐵早在2014年委託財團法人成大研究發展基金會,分析比對2014年1~6月間列車的ATP行車紀錄、班表紀錄及售票紀錄、和誤點紀錄,以調查造成誤點原因,其結果歸納出幾個,

  1. 發現旅客過多或個別旅客因素、
  2. 通過施工處減速、
  3. 列車會車避讓他車、
  4. 被先前列車延誤、
  5. 電車線故障。

這個分析的結果引發討論,並有人認為旅客過多,是台鐵本來應該利用路線設計和引導去解決的問題,不應該把責任推給旅客。

資料是提昇服務的關鍵

火車誤點一定會有一些不可抗力的因素,例如,上述所提到的因施工需要減速,或是突發狀況,例如設施故障或交通意外,對於一個乘客而言,事先了解發生什麼事而誤點,可避免這搭乘這些路線的列車,在車上的旅客了解誤點的原因,可以安心的搭乘。從台鐵委託成大的研究可以知道,台鐵都有這些資料,那為什麼不善用這些資料提供更好的服務呢? 即使台鐵本身沒有能力開發更好的服務系統(訂票系統令人失望呀!),只要把這些資料以結構化且開放授權的方式釋出,也一定有高人可以利用這些資料來開發應用程式。

相對於台鐵,荷蘭國鐵算準時,但也常誤點,對於施工所造成的誤點,不但會在手機APP上提醒,也會在火車時刻查詢系統中加入預估延遲的時間,在搭車前可以避免搭乘會誤點的列車,或是有延遲的心理準備

透明化的荷鐵施工資訊

 

整合施工資訊於火車時刻查詢系統

而荷鐵不但自已有APP和應用程式服務旅客,進一步地,荷鐵把提供服務的資料一併以API方式釋出,被視為開放資料,但授權方式不是很清楚,限制是每日不能超過5萬次查詢(request)。也因為有這樣的開放的API,其資料可被使用的方式就變得多樣,例如,NS API可以查詢到每一班火車的實際位置,因此有人利用這個資料結合OSM開發出即時的火車動態圖

利用荷鐵Open API 整合OSM 製作即時動態火車地圖

開放資料是台鐵轉變的契機!?

事實上台鐵委託成大的研究中,只用了6個月的資料,台鐵在交通部的統計資料至少有20年,6個月可以做的分析,20年為什麼不能做? 那若是利用完整的資料的分析,其結果又是如何? 對於一個好奇的人,會更想利用這些資料去了造成台鐵火車誤點的原因,為什麼慢車比快車準時? 為什麼看似沒什麼事發生、也沒停站,火車還是誤點? 數字能說話,但資料那裡呢? 提供成大分析的資料為什麼不能一併開放呢?

開放資料是一種文化,台鐵情況讓我想到台電在去年轉變的案例,在核能與缺電的議題下,對於缺電的原因,大家總覺得台電說的不清不楚,因此引來「開放台電」行動,想要從資料中討論缺電的原因。無論這個行動的過程中所發生的爭議是如何,為台電帶來的最大獲益應該是面對資料開放的態度和如何利用資料解決問題,同樣的,台鐵是否也能從開放資料開始來解決問題呢? 火車誤點在台鐵是司空見慣之事,但背後所隱含的恐怕是一個國營事業單位的資訊化落後,而無法發現問題、解決問題的窠臼。

WordNet-Similarity Installation

This logs my installation of WordNet Similarity.

The current version of WordNet::Similarity is 2.0.7, released on October 4, 2015. The install file in source code explains the installation well, however, some little problems occur with new Mac OSX, e.g. Sierra.

The WordNet-Similarity 2.0.7 works with the other packages:

  • WordNet-3.0
  • WordNet-QueryData-1.49
  • Text-Similarity-0.13

WordNet-3.0 needs to be installed firstly, and then the other two packages. Although WordNet 3.1 can be installed via Brew, my case is not successful to make WordNet 3.1 working with WordNet-Similarity 2.0.7.

As the installation of WordNet, a issue was occurred from the step of ‘make’ in stubs.c. The following is the error message.

stubs.c:43:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result =
~~~~~~ ^
stubs.c:55:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = bitfieldstr;
~~~~~~ ^
stubs.c:72:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: bit bitnum”;
~~~~~~ ^
stubs.c:78:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = bitfieldstr;
~~~~~~ ^
stubs.c:92:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result =
~~~~~~ ^
stubs.c:105:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = resultbuf;
~~~~~~ ^
stubs.c:117:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: glosses [1 | 0]”;
~~~~~~ ^
stubs.c:132:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: fileinfo [1 | 0]”;
~~~~~~ ^
stubs.c:147:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: byteoffset [1 | 0]”;
~~~~~~ ^
stubs.c:162:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: senseflag [1 | 0]”;
~~~~~~ ^
stubs.c:178:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: contextualhelp partofspeechnum searchtypenum”;
~~~~~~ ^
stubs.c:183:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = helptext[pos][searchtype];
~~~~~~ ^
stubs.c:193:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: reopendb”;
~~~~~~ ^
stubs.c:207:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: abortsearch”;
~~~~~~ ^

Google the issue. I found a solution from StackOverflow. One suggestion is modify the line using ‘interp->result’ to ‘Tcl_SetResult’, e.g.

from

interp->result = "usage: glosses [1 | 0]";

to

Tcl_SetResult(interp, "usage: glosses [1 | 0]", TCL_DYNAMIC);

After the modification, do configure and make again. WordNet 3.0 can be successfully installed. (You type wn in terminal for testing if the WordNet installation is successful).

With having WordNet 3.0, the WordNet-QueryData-1.49, Text-Similarity-0.13, and WordNet-Similarity 2.0.7 are installed well via following procedure:

  1. perl Makefile.PL
  2. make
  3. make test
  4. su
  5. make install
  6. exit

To test if WordNet-Similarity 2.0.7 is installed successful, you can go to the folder ‘samples’, and find sample.pl. Then, try ‘perl sample.pl cat#n#1 dog#n#1′. You will see the result like the following screenshot.

screenshot-2016-10-15-12-09-22

All functions of WordNet-Similarity 2.0.7 are in the folder ‘utils’. If you’d like to launch a web service of WordNet Similarity, you can use similarity_server.pl. Just execute it. Then, you can see as following screenshot.

screenshot-2016-10-15-12-21-40

2016年歐洲資料論壇(European Data Forum 2016)與會記行

1.歐洲資料論壇的背景

歐洲資料論壇(European Data Forum, EDF) 是每年一次的會議,聚焦在以資料為主的多個面向,如社會、經濟、研究、工程、和科學等,並著重於歐洲的資料趨動經濟之提昇,該會議自2012年起開始舉行,是由歐盟執委會(European Commission)中,連結的數位單一市場(Connected Digital Single Market)計畫下主導,但會議行政管理是由歐洲各國產官學相關人士組成指導委員會來執行,以確定每年會議主題與內容、目標、及預算支配,且評估歐洲各國提出舉辦會議的申請。

這二年的主題都以資料經濟(Data Economy)為會議主軸,來貫穿4個主題,

  • 巨量資料(Big Data),如何利用新的科學和工程方法,有意義的處理大量資料,
  • data_economy開放資料(Open Data),如何透過跨部門資料整併,以支援決策制定,提昇政府治理的透明度,
  • 鏈結資料(Linked Data),如何將鏈結資料技術與方法做為普遍的資料整合平台,
  • 由資料產生的價值(Data-driven value),由前三者去審視資料能產生的價值,並研析資料趨動經濟的方法和工具。

而基於數位經濟和數位化社會(Digital Economy and Society)的發展,會議本身也關注三個面向的發展,

  • 技術面,如何駕馭現今如此大量的、異質的、和動態的資料,面對這樣的資料世代,科技和基礎建設會是什麼樣貌?
  • 應用面,因為開放資料、鏈結資料、和巨量資料的快速發展,可能的新產品和服務會是什麼?
  • 社經面,在這個新的資料世代中,社會衝擊、法律問題、政府政策法規、商業模式、和創新方式的改變會是什麼?

歐洲資料論壇(EDF)是一個聚集歐洲各國的產官學人士,共同討論資料趨動創新的機會與挑戰的重要會議。所謂的資料趨動創新的機會與挑戰是著重在資料的基礎設施、工具、應用程式的發展潛力,及其所面臨之問題,因此資料趨動創新特別重視創新所可能帶來的社會和經濟面的影響。EDF這個會議所企圖吸引的參加者,是涉及資料價值鏈中的利益關係者(stakeholder),無論是從巨量資料技術方法之應用到創新想法的突破,或者是,各項進行中之政策的辯論到前瞻思維的演講中獲得啟發,在EDF中的意見與想法的交換,是會議的價值,這將為歐盟各國在未來資料經濟之研究課題的設計,和政策決定的方向上帶來影響,這即是推動資料趨動創新往前動力,強化歐洲資料經濟的力量,也是奠定歐洲資料經濟在全球地位的基礎,因此這屆的EDF將主軸定為 Scaling up the European Data Economy,換句話說,資料經濟的議題在歐盟並不是新的開始,而是進入到擴大並強化各個領域在資料經濟的應用規模。

By Rijksdienst voor het Cultureel Erfgoed, CC BY-SA 3.0 nl, https://commons.wikimedia.org/w/index.php?curid=37243214

本屆的歐洲資料論壇(EDF)是由荷蘭埃因荷芬科技大學(Eindhoven University of Technology )中資料科學中心(Data Science Center Eindhoven (DSC/e)) 肩負起主要籌辦的角色,因此會議舉辦城市即在荷蘭埃因荷芬,該城市即是一個工業城,是許多知名企業的根據地,如菲利浦、NXP、ASML…等,值得一提的是城市行銷是以Brainport為主題,有別於鹿特丹的海港和阿姆斯特丹的空港,所謂的Brainport即是集合整個區域的公司企業、大學、和研究中心,成為一個創新研發的城市,這樣的策略倒也很符合EDF主軸,是強調資料趨動的創新下的經濟動能。

而會議場館Evoluon則是一個很特殊外觀的建築物,這個飛碟造型的場館是原本是當地的科學館,在1966年就落成,已經有50年的歷史,後來成為菲利浦的會議中心。

2.會議內容

2.1.真槍實彈的鍵結資料應用

EDF2016會前有幾個工作坊和活動一同在Eindhoven舉行,巧好會議前一天(6/27)的早上看到有一個活動是荷蘭鏈結資料平台(Platform Linked Data Nederland)舉辦的荷蘭鏈結資料會議,在沒有事先報名的情況下就直接殺去會場,結果主辦單位很包容地讓我參加了會議,結果會議還沒開始就遇到老朋友,Simon Scheider,目前在烏特列支大學(Utrecht University)地理系任教,仔細一看,他上下午各有一個演講,一個是講的是地理資料在進行跨資料集連結時,如何除錯、確定地理實體的型別、正確的相互連結的工作流程,另一個是講鏈結資料和空間分析整合的潛力。更有趣的是,下午有一個講者居然是我的指導教授Rob Lemmens,他的演講是在介紹歐盟的一個計畫ENERGIC Project 中如何利用自願性地理資料進行Datathon,這真是太巧了!

其實會議中有一個案例很吸引我,講的是半導體企業NXP和Freescale合併時,產生資料整合的問題,雖然二個企業體都是做半導體,各自企業的資料架構是不同的,因此在企業整併的過程出現資訊系統整合的難題,為了解決這樣的困境,他們選擇使用鏈結資料的技術和方法來整併二家企業的資料,這個工作是由Semaku這家工公司承接,最後NXP和Semaku根據這樣的經驗建立了一個 NXP Enterprise Data Hub,這個鏈結資料的應用在去年接連拿到荷蘭鏈結資料應用的首獎和歐洲鏈結資料首獎

 2.2.企業善用資料,開創新商業模式

edf2016

由Keynotes的結構來看,這個會議確實是秉持產官學互動交流的原則,在8個Keynotes中有4個是來自於業界的分享,菲利浦總裁 Frans van Houten介紹自家許多家電產品已經收集消費者的使用行為資料,分析資料可以提供更好的服務,例如,電動牙刷利用藍芽和手機連結收集使用者的刷牙方式,若有使用者刷牙方式錯誤,手機應用程式可以自動提醒。西門子數位工廠部門工廠資料服務資深副總 Ralf Wanger則是介紹西門子賣出的機器中裝有感測器(sensor),可以消費者可以將機器連結上西門子的資料服務中心,系統可自動分析維修時間,並自動安排員工進行檢修。導航和地圖空間資料服務的知名公司TomTom之總裁Harold Goddijn 則是分享公司跨界轉型過程,單純買圖資或GPS導航的獲利已經不高,TomTom已將圖資應用在支援無人車研發。知名線上音樂公司Spotify,資料分析主任Andres Arpteg 以資料科學的角度來了解消費者使用行為,他們利用資料探礦的方法分析了解消費習慣以提昇音樂平台的服務。

第一天下午和第二天有三個時段各有三個平行的場次,主題分別是Automotive, Data-Driven Government, Agrifood, Urban Smart Living, Smart Industry,Novel Emerging Areas, Educations and Skills, Healthcare, 和 Media,這9個場次的講者來源,有政府官員、非營利組織、大學及科研中心,更有來自公司企業,不同領域在同一主題上所面臨的問題可能不一樣,但在同一個場所的討論則有助相互交流和經驗分享,與會者中有許多是來自於歐洲的中小型企業(SMEs),藉由研討的過程,他們有機會提供他們的技術與經驗和講者交流,也就創造他們參與大型計畫,以及和大型企業合作的機會。

2.3.政府部門主導資料經濟政策的制定img_0721

會議中有二個歐盟政府官員的Keynotes,都與EDF的組成有關,一個是來自歐盟執委會 在數位經濟和文化的專員,以錄影方式發表演說,另一個是Márta Nagy-Rothengass 歐盟網通科技總署 (DG Connect) 中資料價值鏈部門的主任,以「 Building a data-driven economy – The perspective of the European Commission」為題演說。

img_0722她的演講中清楚地勾勒出歐盟在資料政策上制定與推行,在多國組成的歐盟,不同制度文化下,資料的管理方式不同,造成資料整合應用上的障礙,一直是歐盟成立以來著重的問題,隨著開放資料、巨量資料和資料科學的風潮,歐盟也逐漸地在過去電子化政府運作中做出改變,開始著重於建立一個有效率的資料生態系統,朝向政府、科研、企業、公民等不同角色的公私部門夥伴(Public-Private Partnership)的合作架構,以促進資源與利益的共享、責任的共同承擔、並著重社會層面議題。

為了建立這樣的資料生態系統,開放資料的策略變得很重要,因為資料能開放地被近用,才有可能讓資料在不同的角色中相互流動,資料有流動就增加應用加值的可能性,在這樣的脈絡下,開放資料被視為資料經濟的一部份。因此歐盟不但極積的建立歐盟開放資料平台,2012年啟動,一開始只有歐盟本身的資料,去年(2015年)起開始要求各國開放資料匯入,另一方面也極積地調查歐盟資料市場的規模和潛力,透過歐盟經費補助,委由國際數據資訊(IDC)和Open Evidence 進行歐洲資料市場的調查,報告書在2015年發表,同時他們也建立了一個資料視覺化的工具,European Data Market Monitoring Tool,可瀏覽歐洲的資料市場情況。

2.3.學研機構提供資料治理的策略

img_0624
在Data-Driven Gvoernemnt場次中,JOHANN HÖCHTL 發表Performance-indicator based policy-making in Austria

會議中的展覽單位和參展海報中,不少是歐盟計畫的成果,如IQmulus,仔細調查可以發現,歐盟執委會在推動資料經濟,並不是單單只有制定政策,且提供許多經費給科研單位進行長期的研究,這些科研計畫是以解決問題為導向的研究,並重視跨國、跨領域間的協同合作,這些計畫過去也都參加過之前的EDF,在歐盟的網頁上可以看得到這些計畫

在Data-Driven Government場次中,有4個演講,除了論述政府如何應用資料治理的策略與方法,也包含了實務面的處理,荷蘭如何應用資料分析改善交通問題,奧地利如何運用開放資料制定指標以決定政策,法國如何透過培育計畫培殖更多資料科學人才。

fhg_193_ids_grafiken-eng-03Sören Auer是Fraunhofer IAIS 企業資訊部門主任,也是波昂大學企業資料系的教授,他在Smart Industry以Industrial data space digital sovereignty over data為題發表演說,提出 Industrial Data Space 是一個利用資訊標準和共同治理模式建構出一個虛擬的資料空間 ,這個構想之目的在於嘗試在商業環境中,讓資料的交換更安全且資料的連結更容易,這個構想想建立的系統也試圖提供一個基礎,以建立和使用智慧服務和創新商業流程,使得資料擁有者以確保他們的資料治理權 (digital sovereignty)。

透過使用情境,可以了解Industrial Data Space的架構和需求,這架構是在於創造資料價值鏈,以及調適以特定領域中鏈結資料的語彙以輕量化的語意表達,Industrial Data Space廣大地支援不同領域的情境,同時,也是下一代的工業生產 (工業4.0) 可以應用的範疇。此外,他也指出 Industrial Data Space 也是一個跨領域組織,包含商業、政府、和科研單位,於2014年底在德國成立,這個組織的目標清楚企圖建立一個歐盟、甚至是世界級的平台。

2.4.重視巨量資料科學研究、應用、與人才培育

EDF2016中二個Keynotes是來自於埃因荷芬(Eindhoven)附近的科研中心,分別是荷蘭提堡大學(Tilburg University)校長Emile Aarts和德國多特蒙德大學(TU Dortmund University)資料科學中心的主任Katharina Morik,他們各自介紹各自資料科學中心如何透過在企業合作以資料科學的方法解決問題,此外,也強調各自資料學中心的能力和潛力,以吸收更多人才的加入。加上埃因荷芬大學資料科學中心,似乎讓我有感覺有一個趨勢,就是這個過去以工業生產為主的區域,已經看清資料價值鏈中,傳統工業轉型後,所要扮演的角色,所以需要的人才,這些資料科學中心成為這個區域進入下一個工業世代的軍火庫,不但提供策略想法,也訓練人才。

3.會後心得

這次EDF的參與者有1070人,來自於48國家,參與人數最多的15國依次分別為,荷蘭、德國、比利時、英國、西班牙、希臘、奧地利、法國、義大利、愛爾蘭、匈牙利、挪威、盧森堡、芬蘭、萄葡牙等,有明顯的舉辦國優勢的傾向,以參與人員的行業類別而言,有40%是來自於工業界,32%是學術界、13%是公部門、和15%的其它,會議參與者多數是來自於業界,但科研單位的人也為數不少,這和我過去參與的學術會議巧好有點相反的情形,因此二天會議談論的事情,多是實務面的工作和面臨的問題,較少生硬的科學理論,相對而言,整體內容是比較能讓一般人進入的。

荷蘭North Brabant省的經濟經理Bert Puali,在會後的宣傳錄影中提到,「…在我們變得談論過多巨量資料的可能性之前,我們應該加入有執行力的那一方,藉由資料和資通訊相關的研究,以了解資料經濟的市場有多大…」,其實這就是EDF的主軸,整個會議雖然扣合歐盟「資料經濟」發展的政策,但不會讓人感到過多政策推動鑿痕,可以讓人感到的是,歐盟對於政策推動是根植於問題與挑戰的認知和了解,接著再提出解決問題的技術方法的一系列進程,反觀國內,通常把二件事情給壓縮了,常在政策推動的過程中,讓人看不清,解決問題的意識和方向是什麼? 而堆疊過多的技術名詞,沒有執行的實質內容,最後流於空洞。

在海報、展覽單位、以及與會會眾中,很多是資通訊產業的中小型企業(SMEs)的員工、甚至是老闆,試圖透過這個會議中尋找合作機會,這與歐盟資料經濟策略中重視中小型企業(SMEs)所扮演的角色有關,個人觀察,這就和公民科技在開放資料生態系中扮演重要角色是類似的,政府或大型企業在面對新問題和新挑戰時,由於組織體系的龐大,未必能及時適度確切的反應,而中小型企業較具有彈性,可以容易調整方向,調度人才,因此大型企業或政府單位和中小型企業合作,較能快速地解決問題,如之前提到NXP和Semaku的案例。

從許多EDF的演講中,可以發現有些研究是歐盟所補助的計畫,這些計畫無論是在智慧城市、物聯網或工業4.0上,都以資料為本,提出解決問題的架構、技術或方法,而這些計畫也不僅是單一科研單位所執行,而是跨國、跨領域協同合作,這種3-5年左右的研科計畫,也提供教育、研究資源,培養更多的人才,因此可以想像的,一個新興議題,如資料經濟,一開始大家都不熟悉,在這樣的情況下可以做出的策略自然保守且限縮的,而在補助科研單位的研究計畫中,利用博碩士生在深入研究推導,研究成果最終成為政府單位政策推動依據,這樣一個階段、一個階段的進行下,歐盟在開放資料、巨量資料、和鏈結資料逐漸形成策略,以面對不斷演變的挑戰,因此提出資料趨動經濟的論述,成為歐盟政策內容,形為今日如此的規模,這絕對不是把堆砌一堆技術名詞而缺乏解決問題方法的報告書重抄一遍,再重新包裝的政策內容。

看到歐盟對於資料相關的政策,反觀台灣,想問的是,面臨新的資料世代,台灣政府對應的政策是什麼?