Category: 開放資料

食品安全是現今社會的課題，歐美日等先進國家為確保食品安全，已先後實施食品「可追蹤系統」(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)認為建立知識本體應該定義

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

 

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)，這段所描述的是產銷履歷農產品具有一個追蹤碼。產銷履歷農產品的其它屬性的宣告方式與追蹤碼宣告方式相似，完整的映對檔可以參考附錄。

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

參考文獻

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