英國政府公部門的URI設計

英國政府將政府URI視為資訊基礎建設之一,是「跨政府部門總體架構」(cross-Government Enterprise Architecture, xGEA)一系列的政策和綱領中的一部份,因此英國首席技術辦公室(Chief Technology Officer, CTO)提出「設計英國公部門URI集合(Designing URI Sets for the UK Public Sector)」之報告。

而URI的設計與資料中的概念及其定義有關,有清楚的定義有助資料的分享,以及政府部門發佈和查詢鏈結開放資料。英國政府明確定義URI之目的也在於方便擁有參考性資料(reference data) 的部門,可以讓他們的資料可被再使用(re-use),並且給予那些有可被鏈結資料的部門,可以根據這些規則來使用 URI,因此,URI的定義對於一些與政府部門資料有關係的人更為重要,如在擁有參考資料政府部門、希望透過整併的URI來改善資料再使用(data reuse)的資料擁有者、以及政府部門解決方案的提供者。

報告中指出在2009年時,英國就有一些公部門著手進行URI設計,包含英國廣播公司 (BBC)、英國測繪局(Ordnance Survey)和英國公部門辦公室。經過建立和整合好的實務經驗,對於URI的設計,他們有三個主要重點:

  1. 使用data.gov.uk為URI集合的根網域,以利再使用(reuse)。
  2. URI集合是以部門或機構(如教育、交通、健康等)來分。
  3. 有一致的註釋資料用來描述URI集合的品質特性。

而該份報告所提出的就是一個英國公部門URI設計、架構和原則的技術規範,因此報告中對於URI的進行分類且給予定義,如表1。

表1: URI 類別

資源型態 URI的型態去命名資源 定義/範圍
真實世界的’事物’

Real-world ‘Things’

辨識碼 URI

Identifier URI

這些都是可以在宣告中被指涉的自然或抽象之事物。

自然的真實世界事物,舉例來說,可以是一間學校、一個人、或一條路; 而抽象的事物,舉例來說,可以是一個政府部門、一個族群、或一個事件。

文件或作品也是可以以包含的內容來區別的真實世界事物。

真實世界事物可以大寫的’Things’來表示

一個真實世界事物(Thing)不可能出現在網路中,而只有資訊形容它,因此很重要的是,當有一些宣告是用來指涉它時,事物本身和形容事物的資訊能被區別

在網路上關於真實世界事物的資訊 文件 URI

Document URI

這些命名了位於網絡上的文件,這些文件由每個辨識碼統一資源識別元的發佈者清楚地連接,以提供關於真實世界事物的資訊。
表示 URI

Representation URI

當一個文件URI提供超過一個格式,每一個格式可分別以表示URI來命名

基於格式,有些表示URI可命名機器可讀的文件,且因而可提供進一步關於命名資源的連結

每一個識別碼在一個集合中的索引 列表 URI

List URI

這些提供辨識碼URI的列表,其包含在一個集合中
概念的定義 知識本體 URI

Ontology URI

鑑於一個真實世界事物識別一個事物的個別實例,這是需要提供概念的定義,而知識本體URI可被查詢以提供定義。

 

事物間的關係 知識本體URI

Ontology URI

一個RDF宣告的每一部份可以使用URI來命名,這包含真實世界事物之間的關係。

 

而知識本體URI給予一個到知識本體的連結,可以提供關係和及其所關連的概念的進一步推理。

URI集合

URI Set

URI集合 是指參考資料以URI發佈的參考資料URI之集合,一個URI集休也是表達一個概念,由單一資源來管理,例如,學校公路、司法都是各自的集合

命名URI集合且可以被所解析以提供這個集合品質特性之辨識碼 URI的一個型態

 

該報告由既存的優良實作經驗中衍生且經由修改而導出一些符合UK公部門URI集合原則,如表2所示。

表2: URI設計原則

原則
使用HTTP所以URIs可以被解析 必要
使用固定路徑結構以明確指示出URI的型態 建議
URI集合是否被提升被政府或公眾的其它部份再使用,發佈者會把它弄的更清楚 必要
公部門URI集合應該發佈他們期待壽命和對於再使用的潛力 必要
這些被提升為再使用的公部門URI集合應該至少可維持10年 建議
如果超過有一個代表URI,提供一個文件URI其中內容協商(Content Negotiation)可以用來提供最合適的表示 建議
避免暴露在一個在URI結構中的技術實現(implementation) 建議
至少提供一個機器可讀的表示URI 必須
如果適當,提供一個人可以的URI在HTML中 建議
對於單一文件URI提供發現每一個可用的表示URI的方法 建議
一個URI集合會發佈它的授權、身份驗証、和使用共同語彙的資料品質特徵 必須
一個URI結構不會包含任何會改變的,例如session IDs 必須
一個URI路徑結構是可讀的,以致於人對於它的內容會有合理的了解 建議

 

報告中也提供了當公部門要建立URI集合時的原則和考量,如表3。

表3:  公部門要建立URI集合的原則和考量

原則 考量
負責真實世界的事物的部門或機構應該負責定義URI集合和命名URI集合的實例,合適部門的代表 URIs應該被組織進具有領頭部門或構機的部門

領頭部門/機構應該與利益關係人接觸以確保這集合是能足以符合廣泛的需求

從一個被提昇為再使用的集合的URIs不應該包含現正負責它的部門或機構之名稱 這涉及到政府部門的改變,一部門或機構可以停止或改變業務範圍
圖1: URIs整合到集合之概念圖

一個URI集合可以包含4個部份(如圖1):

  1. 一個命名集合和描述它的品質特徵的URI
  2. 在單一概念中,對於真實世界事物的每一個識別碼URI
  3. 選擇性的,定義綱要的概念和關係的知識本體URI
  4. 選擇性的,列出在集合中的識別碼URI的列表URI

基於上述的定義和原則,該報告提出各個URI類型的案例,如表4所示。

URI 類型 URI結構 案例
識別碼 http://{domain}/id/{concept}/{reference}

or

http://{domain}/{concept}/{reference}#id

http://education.data.gov.uk/id/school/78 http://education.data.gov.uk/school/78#id http://transport.data.gov.uk/id/road/M5/junction/24
文件 http://{domain}/doc/{concept}/{reference} http://education.data.gov.uk/doc/school/78
表示 http://{domain}/doc/{concept}/{reference}/{doc.file-extension} http://education.data.gov.uk/doc/school/78/doc.rdf
綱要概念的定義 http://{domain}/def/{concept} http://education.data.gov.uk/def/school
綱要識別碼列表 http://{domain}/doc/{concept} http://education.data.gov.uk/doc/school
集合 http://{domain}/set/{concept} http://education.data.gov.uk/set/school

 

下圖則是顯 示URI如何被解析,例如http://transport.data.gov.uk/id/road/M5 即代表的是M5高速公路,而http://transport.data.gov.uk/doc/road/M5 則是關於M5高速公路的資訊。

圖2: URI如何解析的案例

 

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

各國在開放地理資料(Open GeoData)發展的一些觀察

花了一些時間,看看幾個開放資料(Open Data)先進的國家,對於開放地理資料的做法,希望對於開放地理資料有興趣的人可以激發一些想法和互動。

1.美國

在美國由聯邦政府所轄之地理空間資料是免費且以公眾領域(Public Domain)的狀態釋出,也就是這些資料原則上已不受到法律的任何保護,使用者可以拿來做任何他喜歡的事,甚至是拿來販售,或者衍生出更有價值的資料來牟利。世人較熟知的資料,如美國人口調查局 (US Census) 的 TIGER 即是此類。此外,因為 geodata.gov 已經整併入 data.gov,在 data.gov 網站上目前也匯集有大量美國聯邦政府釋出的地理資料,除了聯邦政府,亦有各州政府、大學研究機構、非營利組織和其它機構等,提供不同來源的地理資料,這些資料可能也會以不同的開放授權方式在data.gov中釋出。

由於美國州政府具有極高的地方自治地位,各州政府對於地理資料開放的態度可能會相當不同,州政府所收集或生產的地理資料亦可能會有不同的商業應用模式,加州政府即是一個顯著案例。〈加州公共檔案法」(California Public Records Act, CPRA) 規定加州州政府和各地方政府必須提供給任何需要公部門資料的人,且只能收取不超過資料複製成本的費用。加州司法部長根據資料主管單位的意見將數值地籍圖 (digital parcel basemap) 歸在加州公共檔案法下管理。倡議言論自由的非營利團體「加州第一修正案聯盟」(California First Amendment Coalition, CFAC),向聖塔克拉拉郡 (Santa Clara County) 政府以複製資料成本來申請數值地籍圖時,被該郡政府拒絕,CFAC 轉而至加州最高法院提起訴訟,結果最高法院認為郡政府數值地籍圖符合公共檔案法規定,應該提供公眾使用且只可以收取複製資料成本,這個裁決成為美國開放地理資料推動上的重要案例,這個事件的始末可參考OpenDataConsoritum的記錄。

2.英國

過去英國中央政府的地理資料和其它地方政府生產的資料一樣都受到皇家版權 (Crown Copyright) 的保護,使得地理資料無法被免費使用、再製和散布,事實上,開放街圖(OpenStreetMap)就是因應這個受限的制度而發展出來。受到開放資料運動的影響,英國測繪局於2010年4月啟動 OS OpenData 服務,這項服務中的地理資料是由英國地圖集中選擇常用項目來開放,如行政界線和郵遞區號,這些資料可作商業或非商業使用沒有任何限制。在 OS OpenData 的地理資料是以 Open Government License for Public Sector Information 的方式釋出,其授權方式與 Open Data Commons Attribution License (ODC-By) 相似,但對於資料提供者的角色宣告更為明確,且清楚指出那些資料不在授權條款的拘束範圍內,更重要的是對於所釋放的資料若有錯誤,亦註解了相應的免責聲明,這與英國過往的傳統作法大不相同。現在 OS OpenData 的資料也整併入 data.gov.uk。此外,英國測繪局也著手將地理資料依照「資料連接」(Linked Data) 的原則,將地理資料以「開放資料連接」(Linked Open Data) 定義的方式進行發布,如具有行政界線的英國地名資料即為一例。

3. 加拿大

GeoBase 是加拿大聯邦政府的計畫,採用 GeoBase 專屬的使用者條款 (GeoBase Unrestricted Use Licence Agreement) 來釋出地理資料以提供公眾使用,同樣以路網資料為主。GeoBase 中的路網圖主要是加拿大道路資料,其基礎的授權架構與著名的社群共工地理資料專案 OpenStreetMap 有許多相似的地方,兩者皆沒有限制資料的使用目的,但在資料再散布上的規則卻是不盡相同。GeoBase 條款對於使用者再散布資料時僅要求姓名標示 (atttribution) 這個基礎義務,但如繼續使用 GeoBase 的方式來散布,則此散布行為是不能收取授權金費用的,而如果使用者決定不再全盤依循 GeoBase 的既定授權方式來散布地理資料,那其亦可以將相關資料的授權模式轉為自訂的其他方式。因此,GeoBase此種得以轉換授權條款的模式,對於商業使用可能較為友善,商業公司可以利用GeoBase 釋出的相關地理資料來產出衍生作品,同時更改後續授權的條件以進行專屬性質 (exclusive) 的販售模式(Saunders et al., 2012)。

4. 澳洲

「昆士蘭政府資訊授權架構」(Queensland Government Information Licensing Framework, GILF) 是由「昆士蘭空間資訊委員會」(Queensland Spatial Information Council) 所提出,目的在於簡化公部門資訊的使用權利,GILF 可供選擇的授權模式,包含6款創用CC的核心授權模式,以及一項限制性授權的模式 (Fitzgerald, 2010)。一開始只有昆士蘭政府關注公部門資料的開放授權議題,在逐漸推展之後,如今澳洲各地方政府皆以「澳洲政府開放存取和授權架構」(Australian Governments Open Access and Licensing Framework, AUSGOAL) 的方式來作為資料提供上的參考基礎。

5. 荷蘭

在荷蘭的基礎設施和環境部 (Ministry of Infrastructure and the Environment) 收集的地理資料中,有些可免費取得,但授權方式有待釐清。事實上,荷蘭政府的許多地理資料是收費的,如大比例尺地形圖 (Grootschalige BasisKaart Nederland, GBKN)。但是,在荷蘭的 OpenStreetMap 專案社群成員的請求下,荷蘭政府在2012年1月起陸續開放了地籍資料、道路資料、和郵遞區號等重要的地理空間資料,以「創用CC 姓名標示 3.0」的方式釋出,這些資料總值據評估可達5萬歐元,其同時也釋放衛星影像,允許使用者對這些影像進行下載和重製,在荷蘭太空事務辦公室 (Netherlands Space Office, NSO) 的衛星影像服務平台上可以接觸到這些資料,我國福衛二號所攝製的相關資料也在收錄之列。

6.德國

德國聯邦地圖測繪局 (Bundesamt für Kartographie und Geodäsie, BKG) 於今年(2013)的4月9日宣布將 1:250000 的數值土地利用圖,和相類於此的數值地形圖以開放資料的方式釋出,此一舉措為德國聯邦政府的開放政府倡議 (Open Government Initiative) 提供了重要的貢獻。以大方向進行觀察,德國聯邦政府為推動開放資料,配套修改了「地理資訊取用辦法」 (Geodatenzugangsgesetz, GeoZG) 及其補充辦法 (Verordnung zur Festlegung der Nutzungsbestimmungen für die Bereitstellung von Geodaten des Bundes, GeoNutzV),此舉使 BKG 所釋出的資料,得以採行符合開放授權精神的模式來被使用。

7.日本

日本的產業和學界相當支持開放資料活動,以產學為主共同舉辦了一系列「日本連結開放資料挑戰」(Linked Open Data Challenge) 的活動,促進日本政府對於開放資料的著力與推動。日本國家等級的政府地理資料可由國土交通省國土地理院取得,日本政府也每年編列預算給國土地理院進行地理資料的測量、收集,與維護。由「地理空間情報活用推進基本法」和「地理空間情報活用推進基本計畫」來看,日本政府公部門所轄的地理資料,是可以讓民眾以合理的價格取得。值得一提的是,在2012年於日本東京舉辦的全球性 OpenStreetMap 研討會(State of the Map, SotM 2012)中,國土地理院地理空間情報部長村上廣史 (Hiroshi Murakami) 在會中特別述明與日本 OpenStreetMap 專案社群的合作,讓國土地理院的資料可以被 OpenStreetMap 專案所使用,而國土地理院也可以利用OpenStreetMap 專案自主維護的資料,來進行其轄下管理圖資的除錯與更新。

特別感謝 lucien.cc 和trc對本文中部份文字做適度的修正。

Enhanced by Zemanta