鏈結資料 – GeoCyber

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

問題與分析

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

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

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

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

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

(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對映。

自然語言處理

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

知識本體

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

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

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

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

Gruber(1995)提出用框架和第一階邏輯(First Order Logic)來建立知識本體，並定義 5 種基本要素:類別(Classes)、關係(Relations)、功能(Functions)、正規的原則(Formal axioms)和實例(Instances)。而知識本體(Ontologies)根據表達方式有不同的正規化 (Formal)程度，如果表達成自然語言，知識本體可以是高度非正規的;如果表達在一個限制和結構的自然語言形態中，則是一個半非正式的; 如果表達在人工和正規定義的語言，如 RDF 和 UML，是一個半正規知識本體，而如果一絲不苟地以正規的屬性的語意(Semantics)、定理(Theorems)和證據(Proofs)來定義知識本體中的詞，則是一個完全正規的知識本體，如第一階邏輯(Uschold and Gruninger，1996; Gómez-Pé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所示。

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

系統架構

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

資料擷取與清理

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

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

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

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

產銷履歷達人資料的處理

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

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

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

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

三元組資料與應用系統

知識本體的建立

為清楚解釋農產品產銷履歷資料，知識本體的設計分為三個部份，產地之地理空間、農業概念、和產銷關係，如圖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日期格式之驗證有效日期。

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

本研究是透過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所示。
泉州白菜

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的查詢。

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所示。

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

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

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

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所示。

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

參考文獻

周念陵(2012)，健康美麗產銷履歷，行政院農業委員會。
胡忠一(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資料「座標對位影像五萬分之一分幅地質圖‭ ‬‭(‬頭城‭)‬」之銓釋資料

在這個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資料的五星級。

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

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

1.歐洲資料論壇的背景

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

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

巨量資料(Big Data)，如何利用新的科學和工程方法，有意義的處理大量資料，
開放資料(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.企業善用資料，開創新商業模式

由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.政府部門主導資料經濟政策的制定

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

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

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

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

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

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

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

Sö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年左右的研科計畫，也提供教育、研究資源，培養更多的人才，因此可以想像的，一個新興議題，如資料經濟，一開始大家都不熟悉，在這樣的情況下可以做出的策略自然保守且限縮的，而在補助科研單位的研究計畫中，利用博碩士生在深入研究推導，研究成果最終成為政府單位政策推動依據，這樣一個階段、一個階段的進行下，歐盟在開放資料、巨量資料、和鏈結資料逐漸形成策略，以面對不斷演變的挑戰，因此提出資料趨動經濟的論述，成為歐盟政策內容，形為今日如此的規模，這絕對不是把堆砌一堆技術名詞而缺乏解決問題方法的報告書重抄一遍，再重新包裝的政策內容。

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