熱門論文
最新論文
語義網技術在產品信息管理中 的應用研究
發布時間：2023-07-22 16:32
目錄
圖錄 VIII
表錄 X
注釋表 XI
第1 章 緒論 1
1.1研究背景和意義 1
1.2國內外研究現狀 2
1.2.1語義網技術應用研究現狀 2
1.2.2信息管理現狀分析 4
1.3本論文的主要工作 5
1.4論文結構安排 6
1.5本章小結 7
第2 章 產品信息管理系統分析 8
2.1系統可行性分析 8
2.2系統需求分析 9
2.2.1功能接口需求 9
2.2.1開發工具需求 10
2.3系統功能設計 11
2.4本章小結 11
第3 章 信息的語義表示與處理技術研究 12
3.1語義網技術棧 12
3.2RDF 圖數據建模及存儲訪問 14
3.2.1RDF 數據模型 14
3.2.2RDF數據的存儲 16
3.2.3RDF數據的查詢 18
3.3本體構建及推理技術 20
3.3.1本體構建方法及工具 20
3.3.2本體公理推理 24
3.4本體推理引擎 26
3.5Prolog 語言 26
3.6多圖聯合推理操作方法 27
3.7語義推理機整合 28
3.6本章小結 30
第4章 產品信息語義化處理及實現 31
4.1產品信息語義化處理的整體結構 31
4.2開發工具及數據流 32
4.3產品信息管理的語義建模 34
4.3.1語義對象本體建模 34
4.3.2語義對象屬性關聯 36
4.3.3語義屬性公理推理 37
4.4基于語義網技術及Prolog語言的信息管理應用 39
4.4.1基于Prolog的產品信息屬性擴展方法 39
4.4.2基于產品本體知識的信息一致性檢測方法 41
4.4.3基于中間類結構的產品篩選與推薦方法 42
4.5基于RDF模型的信息管理系統實現 45
4.5.1系統用戶管理 45
4.5.2產品及訂單信息管理 47
4.5.3生產及設備信息獲取 50
4.6本章小結 51
第5 章 產品信息語義化處理系統及測試 53
5.1語義信息測試平臺搭建 53
5.1.1系統結構 53
5.1.2軟硬件基礎 53
5.2基于B/S結構的數據庫訪問接口開發 54
5.2.1B/S 交互模型介紹 54
5.2.2Rest風格架構 56
5.2.3服務端 Servlet 技術 57
5.3功能模塊設計與實現 58
5.3.1系統用戶管理實現 58
5.3.2產品及訂單管理實現 59
5.3.3生產警告信息獲取 60
5.4B/S交互后端接口功能測試 61
5.4.1系統用戶管理測試 61
5.4.2產品信息管理接口測試 62
5.4.3生產信息獲取接口測試 63
5.5產品信息管理語義化方法測試 64
5.5.1基于規則的產品屬性擴展測試 64
5.5.2產品本體推理功能測試 65
5.5.3產品訂單一致性檢測測試 66
5.5.4分圖存儲方式性能對比測試 68
5.6本章小結 69
第6章 總結與展望 70
6.1課題總結 70
6.2未來展望 71
參考文獻 72
致謝 75
攻讀碩士學位期間從事的科研工作及取得的成果 76
圖錄
圖 1.1 鏈接開放數據云 LODC 3
圖 2.1 產品信息管理功能結構 10
圖 3.1 語義網技術棧層次結構 12
圖3.2 一個“Cup”的RDF模型表示 15
圖 3.3 兩種圖存儲模式 17
圖 3.4 “七步法”本體構建流程 20
圖 3.5 本體中的類結構層次 22
圖 3.6 多圖聯合推理操作模型 28
圖3.7基于Java語言的推理機整合方式 29
圖 4.1 產品信息語義化處理的技術結構 31
圖 4.2 基于語義網技術的信息管理開發工具及結構 34
圖 4.3 生產設備對象屬性 35
圖 4.4 產品對象屬性 35
圖 4.5 訂單對象屬性 36
圖 4.6 產品周邊對象關系圖 36
圖 4.7 多圖聯合操作模型 37
圖 4.8 傳遞性屬性定義 37
圖 4.9 設備地址的數量約束公理定義 38
圖 4.10 訂單歸屬的數量約束公理定義 38
圖 4.11 產品歸屬屬性擴展 40
圖4.12基于Prolog規則的產品顏色屬性擴展 41
圖 4.13 本體一致性檢測流程 41
圖 4.14 基于中間類結構的產品推薦方法流程 43
圖 4.15 預整理的產品類型結構 44
圖 4.16 基于中間類的產品類型推理結果 44
圖 4.17 用戶屬性注冊信息 45
圖 4.18用戶注冊程序流程圖 46
圖 4 . 1 9用戶登錄流程圖 46
圖4.20基于SPARQL的訂單查詢處理流程 48
圖 4.21 產品屬性修改前 49
圖 4.22產品屬性修改 49
圖 4.23 物料信息查詢結果 50
圖4.24 SPARQL預警信息查詢結果 51
圖 5.1 產品信息化管理結構圖 53
圖5.2 B/S結構的三層開發模型 55
圖5.3 一種Rest風格架構模型 56
圖5.4 Servlet的生命周期 57
圖 5.5 用戶訪問界面 62
圖 5.6 產品信息接口測試 62
圖 5.7 產品信息查詢接口 63
圖 5.8 產品屬性擴展測試結果 65
圖 5.9 屬性推理測試結果 66
圖 5.10 推理獲取得到的三元組知識 67
圖 5.11 本體不一致的解釋 68
圖 5.12 兩種圖數據存儲方式測試結果 69
表錄
表 3.1 語義開發環境 14
表3.2 OWL公理描述語法 25
表 4.1 信息管理語義化開發工具 33
表 4.2 預置的產品顏色屬性 43
表5.1 REST請求的簡單描述示例 56
注釋表
SWT Semantic Web Technologies,語義網技術
WWW World Wide Web,萬維網
W3C World Wide Web Consortium,萬維網聯盟
RDF Resource Description Framework, 資源描述框架
RDFS Resource Description Framework Schema, 資源描述框架模式
CAD Computer Aided Design,計算機輔助設計
CAM computer Aided Manufacturing, 計算機輔助制造
PIM Product Information Management, 產品信息管理
OWL Web Ontology Language, Web 本體語言
SPARQL Protocol and RDF Query Language, SPARQL 協議和 RDF 查
SPARQL 詢語言
SQL Structured Query Language,結構化查詢語言
Prolog Programming in Logic, 邏輯編程語言
SWRL Semantic Web Rule Language,語義網規則語言
AMD Advanced Micro Devices,美國超微半導體公司
LOD Linked Open Data,鏈接開放數據
HTML HyperText Markup Language, 超文本標記語言
JSON JavaScript Object Notation，JS 對象標記
AJAX Asynchronous Javascript And XML, 異步 JavaScript 和 XML
OWA Open World Assumption,開放世界假設
CWA Closed World Assumption,封閉世界假設
URI Uniform Resource Identifier,統一資源描述符
URL Uniform Resource Locator,統一資源定位符
XML Extensible Markup Language, 可擴展標記語 言
CRUD Create, Read, Update and Delete,增刪改查
RIF Rule Interchange Format,規則交換格式
Integrated Development Environment, 集成開發環境
HyperText Transfer Protocol,超文本傳輸協議
Application Programming Interface, 應用程序編程接口
Representational State Transfer,表述性狀態轉移應用程序編程接口
第1章緒論
本章對語義網技術的應用研究情況和信息管理中存在的問題進行了分析，探討 了在產品信息管理中應用語義技術的研究背景和意義，并就在產品信息管理中應語 義網技術的實踐進行了介紹。
1.1研究背景和意義
計算機技術的快速發展，不僅給人們的日常生活帶來了巨大變花，也給企業實 現高效的自動化管理帶來了良好機遇。企業使用科技手段來管理，實現辦公自動化， 能夠快速的進行信息交流與處理，以提高管理效率，降低管理成本。計算機技術的 應用已成為提高企業經濟效益的必然趨勢［1］。包括計算機輔助設計，計算機輔助工 藝過程設計，產品信息管理，企業資源計劃，客戶及供應管理等在內的計算機技術 成為了自動化管理的重要成分［2,3］。
產品信息化系統是企業內部管理產品數據的一種方式，它根據實際管理的產品 對象情況進行編寫。較早產品信息管理主要以人為記錄的方式完成，而這種方式往 往因為人力管理的周期過長，且容易出現疏漏等原因而造成高昂的資源成本和經濟 損失。隨著計算機和數據庫管理技術的不斷發展，人們逐漸開始使用數據庫來實現 產品信息的管理，并通過操作桌面級可視化程序來對大量的產品信息進行自動化、 系統化管理［4,5］。產品信息化系統的運作，不僅保證了整個管理過程準確無誤和便捷 操作，而且還可以利用相關的查詢對產品數據進行分析，為企業大數據分析與處理 提供了數據支撐［6］。
產品信息化管理的重要技術組成是數據庫，而優良的數據庫設計成為產品信息 管理的關鍵。在產品信息的精細化管理中，為了實現對產品信息數據及其周邊關系 進行監測管理，往往需要建立諸如客戶與產品，產品與生產設備，甚至產品與操作 員等多對象之間的各種關系。然而，按照以往的情況，使用傳統的關系數據庫對這 些對象實體進行建模時，我們首先需要建立表示客戶、產品、設備、操作員等對象 實體的一系列表，然后逐個建立各個實體之間關系的關聯表。并且在引入更多的實 體及其關系后,這樣實體間的關聯表可能超過實體表本身,導致信息的存儲效率降 低［7,8］。
為了構建這些復雜多樣的對象之間的關系,我們可以參考使用語義網技術 （Semantic Web Technologies）來實現上述關系模型的構建。與傳統的對象關系構建 方式相比，以資源描述框架（RDF）為基礎的語義網建模技術不需要建立復雜的關 聯表,從而使得開發和應用變得簡單高效［9］。
同時，基于RDF數據模型描述的資源及其屬性具有靈活的屬性擴展能力，可以 在任何時候添加單個關聯描述,而不影響其他數據結構。使用不同標識符描述的同 一主題也可以使用。并以此互聯數據為基礎，運用本體和規則推理技術，使得數據 能夠實現語義共享，讓知識檢測推理成為可能。因此，應用語義網技術實現信息化 處理的意義在于：
1.RDF資源描述框架作為一種圖數據模型，能夠與關系數據庫一樣方便的表示 資源信息，且易于機器理解；
2.作為語義網技術構成的一部分,RDF數據結構能夠帶來更加靈活的數據建模 和操作性，減少信息結構修改和維護上的困難；
3.使用語義網技術體系中的本體推理技術，能夠保證實例數據與本體知識的一 致性；
4.運用基于規則的推理技術，能夠推理出對象隱藏的屬性信息，為企業數據分 析提供支撐。
1.2國內外研究現狀
1.2.1語義網技術應用研究現狀
語義網技術是伴隨著 web3.0 這一概念誕生的一系列技術。 web3.0 是由 Tim Berners-Lee于2001在《科學美國人》雜志上提出來的概念問，旨在實現web上信 息資源的共享與機器可“理解”，以便計算機能夠根據數據的語義描述對web信息 進行理解和處理。
語義網的主要技術構成包括資源描述框架（RDF ）及其數據儲存技術、
SPARQL（simple protocol and RDF query language）查詢技術、本體技術（Ontology Technology）、規則（Rules）及推理（Reasoning）等。盡管該系列技術誕生于Web, 但其應用領域卻不限于此。該系列技術在知識圖譜，醫療數據共享，圖書管理，地 圖導航等方面依然得到普遍運用。
維基百科（Wikipedia）是全球范圍內合作和奉獻的一個自由的百科知識庫，也 是人類分享知識的平臺，然而由于這些知識通常使用文本來表示，使得計算機應用 通常難以理解。為此，由歐洲發起的DBpedia項目［11］從維基中提取結構化知識卡片 信息，并轉換為RDF數據，將其發布到萬維網上（圖1.1中紅色散射線的中心即為 DBpedia數據集）。其覆蓋領域包含地理信息、公司、人員、電影、音樂、醫藥、書 籍等。這些RDF數據可以用來查詢，比如根據屬性值進行分面式瀏覽，通過RDF 的屬性“邊"鏈接，可以發現更多的知識。現在以DBpedia為中心的linked open data 已經逐步壯大，形成如圖 1.1所示的鏈接開放數據云。
圖 1.1 鏈接開放數據云 LODC
在醫藥數據應用中,為了給醫療工作者提供一種集中的醫療藥物及產品獲取方 式，Charles University in Prague研究者使用語義網技術（RDF資源描述格式和鏈接數 據原理），開發了一個名為Drug Encyclopedia的web應用［12］,在此應用中，醫務人 員通過檢索可以查找到大多數的醫療產品、藥物的相關信息,并且其相關數據的呈 現方式是根據用戶需求來設計的。該應用自2013年開始運行起來，吸引了成千上萬 的使用者。
在國內，白海燕等人利用RDF數據關聯豐富了同類別圖書資源之間的關聯關系, 使得圖書資源的管理更加細粒度化，圖書分類和檢索更加準確［13］。黃映輝等人將本 體概念引入到物聯網中，為使用者（主要是機器）提供物聯網數據的上下文理解， 方便物的使用者理解其數據的含義，以此提出了“語義物聯網”的概念［14,］。此外， 在百度的人物關系圖譜中，也用了語義技術對名人及其之間的各種關系進行了描述 和鏈接，并支持問答式的檢索［15］。
在使用語義網技術的應用中，大多都從文本信息中抽取結構化數據，形成 RDF 數據，也有應用從關系型數據中提取信息轉換成RDF數據，并結合本體的使用，賦 予數據良好定義和機器易理解的含義，使得信息集成在語法和語義推理上都能夠暢 通進行，以提供更好的信息服務。因此，對于具有信息統計和檢索應用需求的場景 來說，只要信息適合于表達成結構化的數據，語義網相關的技術及實踐就能夠發揮 其優勢和能力。
1.2.2信息管理現狀分析
產品信息管理是從 80 年代從 CAD/CAM 和項目管理領域產生出來的，它可以 把與產品相關的信息統一管理起來，并將信息按照不同用途分門別類的進行管理。 產品信息化管理涉及到對產品生命周期內相關信息和過程的管理，而數據庫技術的 發展在其中扮演了重要角色。
數據庫存儲數據信息時，第一步是將物理世界中的各種狀態轉換為信息世界中 的對應的結構模型，然后將信息世界中的結構轉換為計算機可操作的數據模型。信 息世界是現實世界中的各種事物對象在人們頭腦中的反映。數據模型是一種表示物 理對象的類型及對象之間關聯的模型。以各種數據模型開發的數據庫技術提高了數 據共享能力和復用能力，使得人們可以通過計算機來長期保存和檢索數據。其中， 以MySQL［16］, SQL Server^］為代表的關系型數據庫更是長期以來占據著數據庫市場 的大部分份額。
然而，以為實體建模這一基礎思想來設計和實現的關系型數據庫并沒有直接支 持這些實體間關系的表示。這樣就使得在需要描述這些實體關系時，通常需要提前 創建一個關聯表以映射這些數據之間的關聯關系，而這些關聯表一般不用來存儲除 外鍵之外的其它信息，這樣就容易造成數據的冗余，使數據庫存儲效率降低。這些 關聯表也僅僅是通過關系型數據庫所已有的功能來模擬實體之間的關系。這種模擬 可能導致非常不好的結果：數據庫需要通過維護關聯表的同時也維護實體間的關系， 導致關聯表的數量容易急劇上升。
近年來，NoSQL數據庫及其技術的發展逐漸成熟，其大數據量下讀寫的突出性 能及簡單的數據結構使其越來越多的被使用到企業信息存儲中。 NoSQL 數據庫種 類繁多，邏輯模型和物理實現上千差萬別，有采用健值存儲模型的 Redis、DynamoDB 等；使用列式存儲模型的 Apache HBase、 Cassandra 等［18,19］；文檔存儲模型的 MongoDB、CouchDB 等［20,21］；基于圖模型的 Neo4j, AllegroGraph 等［21,22］。在 NoSQL 中，基于圖模型的數據庫在表示語義化數據時，其與RDF數據模型十分契合，據有 原生的優勢。首先，在構建實體信息關聯時，直接使用有向圖連接，不需要維護關 聯表。其次，在對RDF實體進行屬性信息擴展時，基于圖模式的信息結構能夠在不 通過增刪字段的情況下豐富實體信息。因此本文在產品的信息管理中使用了這種圖 數據模型及其相應的數據庫來實現數據信息的管理。
1.3本論文的主要工作
前文分析了目前產品信息化過程及處理時主要存在的問題，根據存在的問題， 本文在閱讀大量相關參考文獻的基礎上，主要研究基于圖數據模型的信息管理方法 及其使用到的語義網技術。首先，根據研究內容，闡述了研究的背景意義和國內外 應用研究現狀；其次，對使用語義網技術來管理產品信息進行了可行性分析和接口 功能分析；然后深入研究了產品管理中運用到的語義網各項技術，包括：RDF的儲 存與查詢，RDF數據多種存儲方式的對比驗證；本體及推理技術，特別對在開放世 界假設下的本體推理技術進行了研究和分析，并對本體相關的推理機進行了功能整 合，使其滿足多種需求；最后利用實驗室資源，對語義網技術在產品信息管理上進 行了實現，并搭建訪問平臺進行驗證。
本文的主要工作涉及以下幾點：
1.研究語義網技術棧，理解和掌握該棧各層涉及的技術；
2.以語義網 RDF 技術構建產品及其相關信息的對象模型,提供產品信息化管 理的數據操作模型；
3.研究語義網 RDF 數據的存儲方式,并對其不同方式對數據庫訪問性能的影 響進行對比和分析；
4.學習和使用RDF數據查詢語言SPARQL及AllegroGraph圖數據庫訪問API, 對產品信息管理中的各個功能模塊進行程序化設計；
5.基于Prolog規則語言，對信息管理中的產品屬性實現擴展，豐富實體的屬性 信息；
6.結合本體構建技術對產品信息進行建模和知識一致性管理,對推理中使用的 推理機進行學習和功能整合；
7.就產品信息管理的軟件實現,搭建測試平臺對系統功能進行測試驗證。
1.4論文結構安排
本文一共六個章節,各章節內容如下： 第一章,緒論。本章主要介紹課題研究的背景和意義,分析了當前語義網技術 的研究應用現狀及信息化管理技術的發展情況,并對論文需要做的主要工作內容進 行了闡述。
第二章,產品信息管理系統分析。本章主要對使用語義網技術產品信息管理的 可行性進行分析。根據開發目標,列舉管理模塊中需要設計的相關功能及其結構。
第三章,信息的語義表示與處理關鍵技術研究。本章就語義網技術棧進行分析, 并研究其主要技術成分，包括RDF模型，本體技術，語義推理技術等，并以構建產 品模型為例詳細闡述這些技術在產品信息管理中的應用。
第四章,產品信息語義化處理及實現。本章首先給出了語義網技術下的產品信 息管理的技術棧構成,然后運用這些技術對產品信息管理的功能進行開發和實現。
第五章，產品信息語義化處理系統及測試。本章利用B/S結構搭建系統管理平 臺,提供信息管理的后臺訪問接口,并對相關技術應用的正確性進行了驗證。
第六章,總結和展望。對論文工作進行了總結并闡述其中的不足與需要進一步 研究的地方。
1.5本章小結
本章首先介紹了產品信息化的發展過程，分析了產品信息化過程中使用傳統型 數據庫在構建對象模型及操作過程中存在的困難，其次概述了語義網技術在發展、 研究和應用狀況及其可應用的場景特點。然后分析了語義網技術在產品信息管理中 的應用將解決的問題，同時給出了本文的主要工作內容及組織結構。
第2章產品信息管理系統分析
本章對使用語義網技術進行產品信息管理的實現進行了可行性分析,并在已有 的開發條件支持下,以制造系統下信息管理中的功能需求列舉了本文的實現目標和 基本任務。語義化信息管理系統的分析基于Java的開發環境及數據庫操作API,其 他開發語言的系統分析不在本文范圍內。
2.1系統可行性分析
針對傳統關系型數據庫在構建多對象關系的時候,需要構建大量的關系表來管 理這些關系,構建繁瑣且易降低數據庫的實際使用率。結合實驗室智能制造課題的 研究環境,對制造產品的信息管理平臺開發的可行性進行分析：
技術可行性分析 本文以基于圖數據模型的Allegro Graph［22］數據庫為基礎, 支持以 RDF 為數據模型構建的產品及其周邊對象關系的圖數據存儲；以 TBC 和 Protege為本體編輯工具進行本體開發和推理［23］； AllegroGraph數據庫支持的 AGProlog 語言能夠提供規則匹配,使用 java 語言和前端技術來開發基于 B/S 模式 的產品信息管理平臺。
經濟可行性一一隨著計算機的普及，其造價也越來越低，基于B/S的產品信息 管理系統能夠提高管理效率,減少工作強度,因此可以通過減少人力資源開銷來降 低專業管理成本。
易用性一一本管理平臺將通過web的方式實現對產品的管理操作，開發了相應 的后端 REST 訪問接口,一些專業的概念和操作對應用開發者來說是屏蔽的,開發 者只需要遵循REST風格交互模式就能夠完成其相應的管理工作。因此，即使對于 非專業圖形數據庫管理人員,在較短的時間內也能夠快速熟悉和使用這樣的模式。
綜合上述分析,使用語義網技術的產品信息管理系統具備實現條件,可以對其 進行實現。
2.2系統需求分析
2.2.1功能接口需求
在產品信息管理平臺的可行性分析基礎上，結合實驗室相關課題的研究，需要 實現以下的開發目標：
即按照語義技術的原理和實現方法，采用RDF數據模型，利用實驗室現有的軟 硬件條件，搭建一個制造產品過程的信息管理平臺。在此平臺上，將完成產品訂單 管理、產品生產信息監測，產品物流查詢等功能接口，以提高產品管理工作的現代 化水平。通過平臺提供的訂單管理接口，用戶通過交互完成產品的個性定制需求， 通過定單號進行物流信息的查詢和產品追蹤溯源，使得用戶擁有自己的產品的豐富 信息。對管理者，在產品為中心的對象關系模型上，提供產品訂單確認及下派，產 品屬性的增刪查改，產品物流信息的更新等操作接口。
產品信息管理模塊功能歸為系統管理、產品管理、訂單管理三大部分，具體的 管理功能接口如下：
(1). 系統認證管理：對用戶的登錄驗證及操作權限進行管理。
(2). 用戶信息管理：包括用戶信息的添加，修改和查詢操作以及用戶訂購信息的 查詢及統計。
(3). 產品類型管理：實現對產品的屬性進行添加，修改和查詢操作以及產品庫存 量查詢及統計等；產品管理：部件庫存預警(規則判斷)，產品數量預估/訪問控制 (類型推理)。
(4). 產品實例管理：對訂單產品的生成、增加、屬性修改和查詢操作以及產品屬 性擴展等。
(5). 訂單管理：實現用戶的訂單增加，訂單修改操作，支持訂單的查詢及狀態信 息追蹤。
此外，根據需要，設計和實現設備信息模塊和日志記錄模塊。設備信息模塊用 于對生產產品的設備及其環境信息進行記錄并綁定相關產品，日志記錄模塊將完成 重要操作的備份記錄。
2.2.2開發工具需求
根據本平臺的設計要求及實際環境，本文以Java語言作為編程語言，主要用于 數據庫編程操作(編程環境為 MyEclipse)。
Java語言具有如下特點:(1)面向對象特性——Java SDK語言提供了類、接口、 和繼承等編程及復用原語，是一種面向對象的程序設計語言。支持基本的數據類型， 同時提供優良的對象及其封裝。(2)平臺無關性一一Java語言采用解釋執行的方式 編譯程序，使編譯成 class 字節碼的 Java 對象能夠在多平臺上運行，做到了“一次 編寫，跨平臺運行”，不局限于操作系統。同時，語義網技術中推理機的實現大多 也是基于Java語言，對語義化推理提供良好的支持。
基于開發工具和語義圖形數據庫服務器的運行要求，該平臺的運行環境如下:
(1) 硬件開發環境:處理器: AMD 皓龍 6200 系列或更高；運行內存: 32G 或 以上；硬盤空間:滿足系統運行和常規存儲即可。 (2) 軟件開發環境:操作系統: CentOS6.0；數據庫：Allegro Graph數據庫。
圖 2.1 產品信息管理功能結構
2.3系統功能設計
產品信息管理功能結構如圖2.1所示，系統管理部分實現用戶的登錄、信息修改 等功能接口；產品信息管理部分負責對產品的屬性進行添加和更新，也可對產品信 息進行查詢；訂單管理模塊完成用戶的訂單生成與關聯，支持訂單的查詢；設備信 息模塊主要對生產產品的設備及其環境信息進行監測記錄并綁定相關產品。
2.4本章小結
本章首先基于Java語言基礎，對語義化信息管理系統進行了可行性分析，在實 驗室已有的語義開發資源和制造處理系統平臺下，分析了使用語義網技術要實現的 產品信息管理任務和目標。
第3章信息的語義表示與處理技術研究
本章首先對語義網技術棧進行分析，研究其主要技術構成，RDF數據建模，本 體技術，語義推理技術等。然后，以構建產品模型的方式詳細闡述了 Prolog語言在 產品信息管理中的應用。最后，對基于 Java 語言的本體推理機進行了分析與整合， 并出了多圖聯合操作及其推理方法。
3.1語義網技術棧
為了讓應用系統更好的處理日益增長的web信息，W3C在逐漸發展了多種用 于構建web3.0的技術。它是一種數據網格，它們可以通過機器而非人類操作員輕松 進行處理。W3C提出了將web數據包含在RDF文件中，使計算機程序或web蜘蛛 能夠搜索，發現，收集，評估和處理web上的數據，形成語義網(Semantic Web)。 語義網為網頁擴展了計算機可處理的語義信息。web創始人Tim Berners-Lee在1998 年提出了語義網這一概念，并于 2000年進一步闡述了實現語義網的方法，之后又對 其進行了技術層次的補充說明［10］。
圖 3.1 語義網技術棧層次結構
在如圖3.1所示的體系結構中：
第一層,URI和Unicode,在遵循現有WWW的重要特征下用于唯一標識資源。 Unicode 是一種國際字符集的編碼標準,它允許所有人類語言都可以使用一種標準 化的形式并在網絡上使用。在語義網技術棧中用于標識信息資源,需要注意的是, 在某些條件下也存在不使用URI的情況。這種情況將使用一種稱為空白節點或匿名 節點作為輔助節點來表示多值關系,但是這種空白節點不能用于標識資源。
第二層，具有XML名稱空間和XML模式定義的可擴展標記語言（XML）層 確保在語義網中使用通用語法。XML也是包含結構化信息的文檔的通用標記語言。
第三層的 RDF 是一種以“圖”模式來表示資源信息的框架。它主要用于表示 WWW資源的元數據，例如網頁的標題，作者和修改日期，但可用于存儲任何其他 數據。它基于形成數據圖形的三元主-屬性-客體。語義網中的所有數據都使用RDF 作為主要表示語言。序列化RDF的規范語法是RDF/XML格式的XML,還有Trutle, N-Triple等。正如第一章所述的，類似RDF這樣的基于圖模式信息建模，不僅可以 用于表示網絡資源,也可以用于其他信息化領域。因此,對于具有信息集成和搜索 等應用需求的領域，只要信息適合于表達成結構化數據，RDF資源描述框架提出的 這種圖結構建模思想及技術就可以發揮其優勢和作用。
第四層中，RDFS, OWL及SPARQL分別用于描述本體和本體及實例查詢。
RDF 本身用作三元組形成的圖形的描述。 任何人都可以定義用于更詳細描述的術 語詞匯表。為了對分類法和其他本體結構進行標準化描述，在RDF中創建了 RDF 模式（RDFS）及其形式語義。RDFS可用于描述類和屬性的分類，并用它們來創建 輕量級本體。
OWL是一種從描述邏輯派生而來的語言，并通過RDFS提供了更多的構造，使 用OWL本體語言可以創建更詳細，更加系統化的本體。它在語法上嵌入到RDF中， 就像RDFS 一樣，它提供了額外的標準化詞匯表。OWL有三種：用于分類和簡單約 束的OWL Lite,用于支持全面描述邏輯的OWL DL,以及用于RDF的最大表達和 語法自由的OWL Full-由于OWL基于描述邏輯，因此給此語言定義形式語義并不 令人驚訝。
為了使用知識庫查詢RDF數據以及RDFS和OWL本體，可以使用簡單協議和 RDF查詢語言（SPARQL）。SPARQL是類似于SQL的語言，但使用RDF三元組 和資源來同時匹配部分查詢和返回查詢結果。由于RDFS和OWL都是基于RDF構 建的，所以SPARQL也可以直接用于查詢本體和知識庫。需要注意的是，SPARQL 不僅是查詢語言，它也是訪問RDF數據的協議。
第六層和第七層將所有的語義和推理規則層（第五層）在 Proof 下面的圖層中 執行，并且結果將被用來證明推演。為了可靠的輸入，要使用加密手段，例如數字 簽名來驗證信號源的來源。在這些層之上，可以構建帶有用戶界面的應用程序。
表 3.1語義開發環境
語義建模 建模方法
建模工具 斯坦福七步法、Meaven方法等
Protege、Jena、TopBraidComposer
存儲 SQL MySQL、Oracle、SQL server 等
數據庫存 儲與查詢 NoSQL Neo4j、AllegroGraph 等
查詢 依據數據庫而定，Neo4j推薦使用Cypher, AllegroGraph支 持 SPARQL...
語義推理 推理機 Hermit、Apache-Jena、AGReasoner、Pallet 等
以上七層技術棧涵蓋了語義數據的表示、存儲、查詢及推理等多個方面，表3.1 中對這些語義網技術的實踐進行了歸納和匯總。其中，語義建模工具的Jena為命令 行編輯模式，Protege[24]和TopBraidComposer[25]具有可視化操作界面；數據庫存儲在 數據量較小的時候，也可以使用序列化文件來存儲；語義推理機中，HermiT、Jena、 AGReasoner、Pallet 均基于 Java 語言。
3.2RDF圖數據建模及存儲訪問
3.2.1RDF數據模型
RDF （Resource Description Framework） [34],即資源描述框架，是 W3C 推薦的 用來描述WWW上的信息資源及其之間關系的語言規范。RDF也是Web3.0上數據 交換的標準模型。RDF數據模型類似于經典的概念建模方法（如實體關系或類圖）， 但它基于在主體謂詞對象形式的表達式中表達關于資源(尤其是網絡資源)的觀點， 主體表示資源，謂詞表示資源的特征或方面，表示主體與客體之間的關系。
這種用于描述資源的機制是 W3C 語義網活動中的一個主要組成部分，也是萬 維網的一個重要演化階段：使智能軟件可以存儲，交換和使用分布在整個Web中的 機器可讀信息，從而使用戶能夠處理信息的效率和確定性更高。RDF的簡單數據模 型和對不同抽象概念建模的能力也導致其在與語義網項目無關的知識管理應用程序 中的使用日益增加。
在描述資源上，RDF更像一種數據模型。該模型以“資源一屬性一屬性值”的 三元組(Triple)形式描述信息資源。其中的資源、屬性和屬性值在RDF中分別用 術語主語(Subject) ＞謂語(Predicate)、賓語(Object)表示，由主語、謂語、賓 語構成的三元組稱一族陳述(Statement)。如果把“資源”和“屬性值”看作是節 點，“屬性”看成是一條邊，則一個簡單的RDF陳述就可以表示成一個RDF有向 圖。如圖3.2所示的一個Graph表示了一個Cup具有的組件及組件顏色說明，在具 體的應用中，還可以隨時定義和添加任何所需的“邊——值”關系。與傳統的關系型 數據庫的信息建模相比，RDF這種模型能夠沒有固定的表結構，因而在需要增加實 體屬性的時候，無需增加字段，具有靈活的信息擴展能力。
RDF Schema (資源描述框架模式，簡稱為RDFS, RDF (S) , RDF-S或RDF/S)
是一組使用RDF可擴展知識表示數據模型的具有特定屬性的類，為描述提供了基本 元素本體，或者稱為RDF詞匯表，旨在構造RDF資源。這些資源可以保存在三元 組中存儲，以查詢語言SPARQL訪問它們。
為構建更加規范的語義網，W3C提出了以下RDF描述原則：
1） 使用URI來描述任何事物資源；
2） 當訪資源時，提供更多有用信息；
3） 盡可能的提供信息資源之間相互鏈接，使人們可以發現更多的事物信息。
3.2.2RDF 數據的存儲
關于存儲 RDF 數據，具有很多的不同方式，既可以使用系統文件的形式來保 存，也可以根據需要使用數據庫來儲存。現有的研究中，既有使用傳統關系型數據 庫來存儲這種 RDF 數據的。隨著技術的發展，越來越多的企業應開始使用 NoSQL 數據庫，尤其是RDF原生的圖形數據庫來存儲這些數據。
將RDF作為可保存在磁盤上的字節串保存的術語是序列化。我們使用這個詞而 不是“文件”，因為已經運行系統沒有使用術語“文件”來保存數據的命名集合。 而在實踐中，到目前為止所有的RDF序列化都是使用不同語法的文本形式代表三元 組。雖然它們可以是在磁盤上的文件，但它們也可能是動態生成，就像很多HTML 頁面一樣。目前支持表示RDF數據的序列化格式有Turtle, RDF/XML, N-Triple等。 而一旦要存儲大規模數據時，就需要使用數據庫系統來儲存和訪問RDF數據。
RDF數據的原生存儲技術是指不依賴于現有的數據存儲系統，而是從文件結構 開始重新設計和實現整套的RDF數據存儲系統。而關系型數據庫在技術成熟度上的 較大優勢也讓人想到使用它來搭建RDF數據的存儲系統。由于關系型數據庫并不是 使用圖結構來表示實體信息，因此許多使用這種數據庫的方案都需要設計一系列的 映射規則來存儲RDF數據，具有可行性。但是，從基于關系型數據庫的各種存儲方 式來看，為了提高查詢性能，則必會以犧牲存儲空間為代價，這樣將造成數據的冗 余；而為了節省數據空間，則必會以犧牲查詢性能為代價，因此高性能和低冗余在 關系型數據庫上無法很好得到權衡，在具體的應用中，需要根據實際需求進行抉擇 [27]。
而面向文檔的 NoSQL 數據庫將數據庫中行列模型換成更加靈活的文檔模型， 這種方式更適合存儲半結構化數據。MongoDB[20]和CouchDB[26]等面向文檔型數據 庫支持JSON格式的數據存儲，但是JSON這種文檔格式目前還沒有被W3C組織
推薦用于序列化 RDF 數據，因此，如何實現 RDF 與 JSON 數據之間的映射及對 JSON數據的高效查詢是使用文檔數據庫存儲RDF數據的關鍵所在。
RDF天然的圖模型結構自然引起了研究者對圖數據庫(NoSQL的一種)的關 注。從根本上說，RDF數據模型可以看成是圖模型的一種特例，因此采用圖形數據 庫更加順其自然。目前，市場上可用的圖形數據庫既有開源的Neo4j,也有商業的 AllegroGraph。但Neo4j并沒有提供對RDF數據查詢語言SPARQL的直接支持，需 要開發者自行開發中間件以提供適用于SPARQL的操作接口，這樣才可以作為一個 三元組數據庫來使用。由Franz公司開發的AllegroGraph圖形數據庫在RDF數據支 持以及SPARQL標準支持上表現出很強性能，在本文中作為產品信息數據的儲存倉 庫使用。此外，基于圖數據的存儲方式，本文就基于使用默認圖和具名圖的存儲方 式這兩種方式進行了對比研究，并通過實際測試分析了這兩種方式對數據庫查詢性 能上的影響。圖數據庫中，兩種不同的存儲方式示例如圖3.3所示。
Named Graph : Default Graph
<http://cqupt/graph_order>
Default Graph
圖 3.3 兩種圖存儲模式
在第一種使用具名圖(NamedGraph)的存儲方式中，將訂單和人這兩個類型的 對象分別使用兩個Graph來存儲，其中一個使用了具名圖<http://cqupt/graph_order> 來存儲訂單這一相關獨立的類型實例數據，另一個則使用默認圖(Default Graph)來 存儲Person這一類型的實例數據。而在第二種中，使用默認圖的方式來存儲上述的
兩種類型對象的實例數據。實驗對比表明(見 5.5 分圖存儲測試部分)，使用具名 圖的方式來存儲和管理RDF數據能夠減少數據庫查詢引擎的檢索空間，從而縮短查 詢時間。
3.2.3RDF 數據的查詢
W3C 標準定義了 RDF 的 SPARQL(simple protocol and RDF query language)查詢 語言的語法和語義［28］。SPARQL可用于在不同的數據源中表示查詢，不論數據是否 本地存儲為RDF或通過中間件作為RDF查看。SPARQL還支持可擴展的值測試和 通過源RDF圖約束查詢。SPARQL查詢返回的結果支持多種格式，可以是JSON結 果集或 RDF 序列化格式。
SPARQL 定義了 ASK、Construct、Select、Delete、Insert 等數據訪問的語法形 式,配合where限定圖查詢范圍，用來實現對數據庫的CRUD (Create, Read, Update and DELETE)操作。其中：Select,用于查詢數據，這是最常用的數據庫訪問方式。 SELECT直接返回變量及其綁定的結果。語法“SELECT *”是一個縮寫，用于選擇 查詢中的所有變量。查詢返回的結果集可以通過本地API訪問，但也可以序列化為 XML或RDF圖。XML限定在SPARQL查詢結果XML格式中進行了描述，在對 如下的Data數據文件進行SPARQL查詢后，得到了 XML結果集。
Data File：
@pre行x foaf: <http://xmlns.com/foaf/0.1/> .
cqupt:a foaf:name "Alice".
cqupt:a foaf:knows cqupt:b .
cqupt:a foaf:knows cqupt:c .
cqupt:b foaf:name "Bob".
cqupt:c foaf:name ”Clare".
cqupt:c foaf:nick ”CT".
SPARQL查詢語句:
PREFIX foaf: <http://xmlns.com/foaf70.1/>
SELECT ?nameX ?nameY ?nickY
WHERE
{ ?x foaf:knows ?y ; foaf:name ?nameX .
?y foaf:name ?nameY .
OPTIONAL { ?y foafnick ?nickY }
RDF/XML 格式化結果：
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results #">
<head>
<variable name = ' 'nameX"/>
<variable name = ' 'nameY"/>
<variable name = ”nickY"/>
</head>
<results>
<result> <binding name = "nameX"> <literal>Alice</literal> </binding> <binding name = ' 'nameY"> <literal>Bob</literal> </binding>
</result>
<result> <binding name = ' 'nameX"> <literal>Alice</literal> </binding> <binding name = ' 'nameY"> <literal>Clare</literal> </binding> <binding name = ' 'nickY"> <literal>CT</literal> </binding>
</result>
</results>
</sparql>
不同的語義處理引擎對 SPARQL 查詢提供一種或者多種的結果返回格式，如 JSON、RDF/XML, N-Triple等。在上一節中的存儲查詢即使用了 Select多值匹配查 詢方式，來研究兩種儲存方式訪問時間。其他查詢語法如：
Construct：用于構建數據新的三元組數據；
Ask：用于詢問數據，返回YES或No的結果；
Delete/Insert：用于刪除/插入數據。
此外，SPARQL還定義了邏輯函數，數據類型判斷函數，數據類型變換函數, 等用于修改字面量類型值。
除了標注查詢語言外，有些數據庫提供商還單獨開發了相應的數據庫操作 API［29］,不僅提供SPARQL語言的訪問支持，還為用戶提供SPARQL以外的高性能 特殊查詢，甚者推理查詢。
3.3本體構建及推理技術
本體是語義技術棧的核心。目前在計算機領域內，對本體的定義為：共享概念 模型的形式化規范說明［30］。即對資源歸類的明確的形式化定義，對資源進行知識化 的描述和表達，在RDF(S)基礎上描述應用領域的知識、各類資源及其之間的關系， 揭示更為豐富的語義關系，增強知識表達的準確性和表達能力。我們可以將本體理 解為某個領域內概念及其關系的集合，在這個集合框架內，對一個特定術語領域真 正存在的實體的類型，屬性和相互關系進行正式命名和定義。生物醫學信息學，圖 書館學，信息檢索等領域都創造了相應的本體來限制復雜性和組織信息［12,13,15］。
3.3.1本體構建方法及工具
本體的構建目前主要為人工構建上，也有一些研究者提出了自動構建的方法， 但應用中卻很難實踐。本體的概念如前所述，本體構建的完備性將直接影響本體知 識的有效應用，因此這里詳細介紹一種使用 OWL 語言的本體構建方法。該方法主 要依據如圖 3.4 所示的斯坦福大學的七步構建流程［31］，并在最后增加了本體一致性 檢測步驟。
該方法的本體構建流程可具體解釋為：
1.決定本體的領域和范圍
通過定義本體領域及將要應用的范圍，作為本體構建的開始。首先可以先參考 思考以下問題：
a.本體將涵蓋的領域是什么；
b.對于我們要使用本體的哪些有用內容；
c.本體中的信息應該將用來回答哪些類型的問題；
d.誰將使用和維護該本體；
在本體設計過程中，這些問題的答案可能會發生變化，但是在任何時候，這些 問題都有助于限定本體模型的應用范圍。
考慮產品管理這里特定場景下的應用，我們需要提供的內容分為兩個方面：普 通用戶面，管理用戶面。對應的需要為普通用戶提供訂單信息，產品信息，生產情 況等信息。而管理用戶而言，需要為其提供各類產品的各種屬性信息以便為用戶提 供個性化的服務，同時也需要生產各種產品的物料信息以便能夠及時采購原料，按 計劃完成任務。
2.考慮復用現有本體的可能性
考慮使用其他研究者開發的本體也是很有價值的，通過檢查是否可以改進和擴 展現有的本體來源，為我們的特定領域和任務服務。如果我們的系統需要與其他已 經致力于特定本體論或受控詞匯表的應用程序進行交互，那么重用現有本體可能是 一項要求。即使知識表示系統不能直接與特定的形式主義合作，將本體論從一種形 式主義轉化為另一種形式主義的任務通常也不是一件困難的事情。如果系統需要和 其他平臺進行互操作，而這個平臺又與特定的本體及詞匯聯系在一起，那么復用現 有本體是較為可行的方法。
對于產品信息化領域而言，其具有很強的應用場景相關性，與實際業務關聯非 常密切，因此對于本文而言，我們假定沒有相關性較強的本體，并從頭開發本體。
3.列出本體中的重要術語
構建希望向用戶陳述或向用戶解釋的所有術語的列表是有用的。思考本體想要 表達什么樣的事實，這些事實有哪些屬性，這些事實能用來做些什么等問題。
例如，重要的產品信息相關術語將包括產品及其組件，訂單及其用戶，生產設 備及其位置，組件顏色，風格等；不同類型的組件，如主身和手柄等等。最初，獲 得全面的術語列表非常重要，而不必擔心它們表示的概念之間的重疊，術語之間的 關系或概念可能具有的任何屬性，或者概念是類還是其子類。
4.定義類及其層次結構
在開發階級層次結構時有幾種可能的方法：
自上而下的開發過程首先定義域中最一般的概念，然后再對概念進行專門化。
例如，我們可以從為產品和用戶的一般概念創建類開始。然后，我們通過創建一些 子類來專門化產品類：具有白顏色的產品，具有藍顏色的產品，具有混合顏色的產 品等。
自下而上的開發流程從定義最具體的類，層次結構的葉子開始，隨后將這些類 分組為更一般的概念。例如，我們首先為圓形杯身和心形手柄定義類別。然后，我 們為這兩個類創建一個共同的超類——水杯組件，而水杯組件又是組件的一個子類。
組合開發過程是自頂向下和自下而上的方法的組合：即先定義更突出的概念， 然后進行適當的擴展和分類。
圖 3.5 本體中的類結構層次
5.定義類的屬性
僅僅這些類還不能提供足夠的信息來回答步驟 1 中的能力問題。一旦我們定義
了一些類，還需要描述概念的內部結構。在步驟3 中創建的術語列表中選擇了一些 類，其余大多數術語可能都是這些類的屬性。例如，這些術語有：產品具有組件， 具有歸屬人員以及加工信息等屬性，而組件也具有顏色，風格等屬性。
6.定義屬性的約束限定
一個屬性的約束限定指屬性取值的類型、容許取值的個數和有關屬性取值的其 他特征。例如，名稱約束限定的值（如“產品的名稱”）是一個字符串。也就是說，
“name”屬性的值類型為String限定類型。其他的限定類型可以限定屬性的定義域 和值域，可能的取值有數值、布爾值、枚舉類型、實例類型等。
7.創建實例
最后一步是在層次結構中創建各個類的實例。定義一個類的單個實例需要選擇 一個類，創建該類的單個實例，最后填充屬性值。
完成上述七步之后，最后需要使用推理機對本體進行一致性檢查，以驗證本體 構建的正確性。如果出現一致性錯誤，則需要根據錯誤提示，修改本體。例如，在 定義產品-訂單的約束條件時，需要保證某一個訂單只能屬于某一個用戶，可以使用 曼切斯特語法進行約束，定義Order為：
:belongsTo max 1 Person.
即最大所屬人數為1，當檢測到某個訂單的所屬用戶不唯一時，將出現一致性檢 測錯誤。其他數量約束的定義可以使用 some、min、only、exactly 等約束詞。使用 OWL描述的本體公理由推理機檢測并完成推理。
本體的構建工具有很多，其中比較知名的可視化構建工具是斯坦福大學研發的 開源工具Protege和美國TopQuarant公司開發的企業集成本體開發環境 TopBraidComposer。Protege是一款免費公開的本體編輯器和知識管理系統，他提供 了良好的可視化本體構建用戶接口及一致性檢測功能。Protege目前已更新至5.1版 本，支持W3C推薦標準，此外Protege內置了 Hermit本體推理機，以支持本體公理 定義中的推理。TopBraidComposer作為一款商用的本體開發軟件，其在一些常見的 類型推理上做了優化，能夠高效的得到相應推理結果，同時支持本地的SPARQL查 詢與推理。但是TopBraidComposer僅支持數量約束公理的定義，而不支持數量屬性 公理的推理，使用數量約束定義時需要采用額外的方式來進行數量約束公理推理。
本文中，同時使用了 TBC來構建本體和查詢，并結合了 Protege中的Hermit推理機 實現相關功能的整合。
3.3.2本體公理推理
本體論和知識庫中的推理是規范需要形式化的原因之一。通過推理我們的意思 是明確地推導未在本體或知識庫中表達的事實。本節討論的所有形式主義都是在自 動處理的前提下創建的，但是由于它們的屬性，例如可判定性或計算復雜性，或者 由于形式化程度，它并不總是可能的。在本節中，討論的是基于描述邏輯的推理， 這也是Protege和TBC中支持的推理方式。
描述邏輯的創建重點在于使邏輯易于推理。推理過程需要完成幾個任務如下：
(1)一個概念的可滿足性：決定一個概念的描述是否不矛盾，即一個個體是否可 以存在，如果可存在，則這個個體就是某個概念的實例。例如，在某個產品制造信 息中，組成水杯這一類產品需要有杯身及手柄這兩種組件時，那么實例對象必須同 時具備以上兩種屬性，才能滿足該本體下水杯這一概念的定義。
(2)概念的包含關系：確定概念C是否包含概念D,即C的描述是否比D的描 述更普遍。當描述手柄這一概念時，其形狀造型各異，可進一步分類為方形造型， 心形造型等，這些子類概念被父類概念所包含。
⑶ABox與TBox的一致性：確定ABox中的個體是否違反TBox描述的描述 和公理。
(4)判斷個體類型：檢查個體是否是一個概念的實例。這是一種問詢的檢索方 式，這種問詢的結果在推理之下，可能給出True或者false的結果。
(5)個體檢索：查找所有屬于某個概念實例的個體，如統計出水杯的數量，或原 材料的數量，為生產計劃提供保障。
(6)概念檢索：找出個體所屬的所有概念，特別是最具體、最直接的屬性概念。 這些任務在語義上并不完全不同。例如，可滿足性可以通過包含關系來測試：
如果沒有個體可以存在這個概念，則概念是不可滿足的。對于所有任務來說，能夠 檢查演繹后果或者推導理論的所有演繹后果就足夠了。然而，對于推理機中的不同 任務，可能會有特殊的優化算法。
在本體推理中，本文主要研究基于RDFs和OWL定義的公理推理。其中OWL 定義的形式語法及語義兼容了 RDFs,下表列舉了 OWL語法中定義的公理語義和描 述邏輯語法，其中類公理定義本體中類與類之間等價關系，子父類關系、不相關關 系等公理；數據屬性公理定義字面量屬性的取值域、量詞約束等公理；對象屬性公 理定義對象屬性的取值域、數量約束等公理［32］。表3.2中列舉了 OWL公理的抽象 描述語法及其描述邏輯表達。
表3.2 OWL公理描述語法
OWL DL抽象語法 描述邏輯語法
類公理 Class(c partial ci...Cn) Class(c complete c「..Cn) EnumeratedClass(c oi-oj
SubClassOf(c1 c2) EquivalantClasses(c1-cn) DisjointClasses(c1-cn) Datatype(d) c匚cf…Hcn
c = C]口 •…De宛
c = ｛。1，…oj
5匚C2
5 =…=cn
CtDcj =丄」j,1 < i,j <n
數據類型
屬性公理 DatatypeProperty(瀘) super(硏)...super 傷 $) domain(c?)... domain(cm) range(d1).range(dl) [Functional]
SubPropertyOf(p¥ 泌) EquivalentProperties(pi …泌) pd 匚 pf, 1< i < n >1pd 匚 q, 1< i < m T 匚 Vpd.dif1 <Kl T <1pd 硏匚泌
Pl =…=P2
對象屬性
公理 ObjectProperty(p 0) super(pf )...super 傷£) domain(c1).domain(cm) range(c1).range(cl) [InverseOf(p°)] [Symmetric] [Functional] [InverseFuncational] [Transitive] SubPropertyOf(pf 鍛) EquivalentProperties(pf …詭) 卩。匚 pf,1< i < n >1p。匚 ct,1 < i <m T 匚 Vp°. ct,1< i < I 儼=(~Po) p° = (—p°)
T <1 p°
T <1 (p°)~ (p°)+ 匚 p°
Pi^Pz
Pl =…=詭
目前的本體推理機都是基于開放世界假設(Open World Assumption) ［33］,開放 世界的假設是假設一個陳述的真值可能是真實的，而不管它是否被認為是真實的。 與之對應的是CWA,即封閉世界假設(Closed World Assumption) □因為Web的開 放性，在語義網環境下的相關的知識很可能分布在Web上不同的場所，因此在語義 網上推理，用CWA是不是非常恰當的。所以，如果要在語義網中聚集不同來源的 知識，應該采用OWA。基于描述邏輯實現的推理機剛好是采用OWA的，所以適合 作為語義網的推理基礎，而現在已有的推理引擎也多是遵循OWA模型來實現推理 的。
3.4本體推理引擎
已存在的的本體推理引擎中，HP Labs實驗室基于規則的前向推理，開發了 jena 本體推理系統［約，其包含一個本體子系統，提供的API支持OWL、DAML+OIL和 RDFs的本體數據。同時能夠支持SPARQL語言。由美國馬里蘭大學實驗室開發的 Pellet本體推理機［35］以描述邏輯作為理論基礎，完整的支持OWL-DL推理，其顯著 特點是效率較高，但是缺乏對其他本體語言(如SWRL)的支持，一般只在進行A- BOX推理的時候考慮用Pellet,而在查詢的時候通常考慮使用Racer。Racer推理機 由德國漢堡大學開發，也是一個基于描述邏輯系統的知識表達系統，但是其核心采 用的是 SHIQ 描述邏輯。具有較強的本體一致性檢查功能，但是不支持枚舉和用戶 自定義數據類型的推理。這些推理機大多都是針對具體本體描述語言的，屬于專用 的本體推理機，其推理效率較高，但是難以實現到其他語言的擴展。斯坦福大學開 發的Protege5.1中內置的開源HermiT推理機提供了高效的OWL公理推理實現，是 一款較為實用的推理引擎。本文中使用的推理及結果綜合使用了 HermiT 推理機和 Jena推理機的演化版本AGJena推理機來研究和實現產品信息管理。
3.5Prolog 語言
Prolog (Programming in Logic) ［36］是一種與人工智能和計算語言學相關的通用 邏輯編程語言，起源于一階邏輯(一種形式邏輯)。與許多其他編程語言不同，Prolog 主要是作為一種聲明式編程語言：程序邏輯是用關系的形式表示的，用事實和規則 來表示。通過對這些關系運行查詢來執行計算。這種語言最初是由法國馬賽 Alain Colmerauer 周圍的一個小組在 1970 年代初設想的，第一個 Prolog 系統是由 Colmerauer與Philippe Roussel在1972年開發的。Prolog是最早的邏輯編程語言之 一，并且仍然是當今這類語言中最受歡迎的語言，有幾種免費和商業實現。該語言 已被用于定理證明、專家系統、術語重寫、類型推斷、自動化計劃等方面，現代Prolog 環境支持創建圖形用戶界面以及管理和網絡應用程序。
例如，當在Prolog中聲明以下事實時：
product(cupA001).
component(bodyB002). hasComponent(cunA001,body1).
這意味著杯子是一種產品，而杯體 1 是一個組件，杯子有一個組件體 1。特別 地，“< -”用于連接AGProlog規則語法中的條件和結論。
基于形式邏輯的 Prolog 編程語言與三元組描述事實的方式具有異曲同工之妙， 而且Prolog支持自定義的規則匹配和查詢，能夠更加方便的擴展出已知信息之外的 知識。本文中使用了基于自定義的Prolog規則進行產品屬性的擴展研究和實現。
3.6多圖聯合推理操作方法
語義圖形數據庫支持多圖存儲的同時，也提供了基于Java的多圖聯合操作方法。 每一個單獨的圖數據集使用一個Jena圖模型接口，其中還有一個基本圖，作為推理 結果保存來使用。Graph是一個內部Jena接口，支持RDF三元組的組合。可能已經 從本體論文檔讀入的斷言陳述保存在基本圖中。推理機或推理引擎可以使用基本圖 的內容和語言的語義規則來顯示更完整的基本集合和必要的三元組。這也是通過 Graph 接口呈現的，所以本體模型 Model 只與最外層的接口一起工作。這種規律性 使我們能夠非常輕松地構建具有或不具有推理者的本體模型。這還意味著基本圖可 以是內存中的存儲，數據庫支持的持久性存儲或者其他一些存儲結構。
我們將使用術語“文檔”來描述以某種語法（例如RDF/XML、Turtle、N-Triple、 JSON-LD等）序列化的本體。這個術語不被OWL或RDFS標準使用，但是它是引 用手工編寫的一種便捷方式。每一個本體文檔可以被導入到一個Jena圖操作模型中， 如圖 3.6 所示，同時還會導入該本體文檔中引用的網絡本體。每個被導入的本體都 被組織在一個單獨的圖模型中，需要注意的是，修改和更新將在基本圖中得到執行。 其他針對導入圖的修改，需要重新進行多個圖的聯合操作，才能在新的聯合圖中使 用。
圖 3.6 多圖聯合推理操作模型
在本文的產品信息管理中，研究了圖形數據庫下兩種圖數據存儲管理方式，根 據對比分析結果，采用分圖存儲方式能夠提高數據訪問的效率，測試方式及結果在 本文第五章進行了闡述。因此本文劃分了產品本體，訂單本體等并分別在不同的數 據庫圖集中進行存儲和管理。
3.7語義推理機整合
語義推理的順利執行需要有推理機（或推理引擎）的支持，本文在研究語義技 術的同時，對推理機也做了深入研究，其中頻繁運用到的推理機有 Protege5.1 內置 的HermiT推理機和AGJena推理機。HermiT1.3.8推理機遵循OWL接口開發，實 現了 OWL2 中定義的公理接口，而 AGJena 雖然也完備支持 OWL 所有推理，但是 在語義中常常應用到的子父類、量詞約束、等價類型推理中表現得十分耗時。因此 本文對AGJena和HermiT進行了推理機的整合，將各自的功能合二為一。如圖3.7 所示，owlapi.reasoner.OWLReasoner定義的接口由HermiT推理機進行了實現，而 hp.jena.reasoner.Reasoner 接口則由 AGJena 進行了實現。
圖3.7基于Java語言的推理機整合方式
其中，owlapi.reasoner. OWLReasoner定義了如下主要接口方法以支持本體推理:
isConsitent():用于檢測本體的一致性； isDefined(OWLCalss):是否支持指定的OWL類型； isSameIndividual(OWLNamedIndividual one & two):判斷兩個個體實例是否共指/等價； getSubClassof()：獲取指定類的子類、孫子類 getDisjonitClass():獲取指定類的不相關類； getEquilantClass():獲取指定類的等價類； hasObjectProperty():判斷指定主語、屬性、值是否存在；
而hp.jena.reasoner.Reasoner定義的主要接口包括:
supportsProperty():判斷是否支持某個屬性； bind(Graph arg0):與某一個圖綁定； getReasonerCapabilities():獲取推理機支持的能力； getGraphCapability():獲取圖所支持的容量/能力； hasObjectProperty():判斷指定主語、屬性、值是否存在;
實現步驟：
Step 1. 接口繼承
統一接口下，繼承兩個推理機各自的推理接口。該接口具有各自推理機應具有 的功能方法，但未提供具體實現。MyReasoner繼承上述兩個接口，形成統一的推理 機接口，具體推理機根據需要實現該接口中的所有方法。
Step 2. 委托代理實現機制
利用已有的推理機 HermiT 和 AGJenad 針對上述兩個接口的具體實現， MyReasoner 的實現類中擁有這兩個類型對象，當需要實現推理機繼承類 com.reasoner.MyReasoner中的方法時，使用HermiT和AGJena這兩個對象中各自的 實現方法。使用 HermiT 和 JenaReasoner 代理 com.reasoner.MyReasoner 中的接口實 現。
Step 3. 工廠方法創建推理機 使用工廠方法，對實現了上述接口的推理機類創建一個工廠，在需要的時候， 由此工廠返回具體的推理機類型，以供使用。
3.6本章小結
本章首先介紹了語義網技術棧的各個層次及其相關概念，然后詳細闡述了 RDF 建模概念，分析了這種圖數據存儲的多種方式，特別的，對圖數據庫中的兩種數據 存儲方式進行了研究分析。同時，本章還介紹了圖數據的SPARQL查詢語言；另外， 對語義網技術中的本體、本體構建方法以及本體推理進行了研究，并以產品及其相 關信息為本體，對這些技術的應用進行了舉例說明。在對語義網技術棧的研究過程 中，應用Prolog規則語言為數據屬性擴展帶來了自動推理上的便利；此外，本章在 分圖存儲的方式上，研究和實現了多圖聯合操作及其推理的方法；最后對已有的推 理機及進行了功能整合。
第4章 產品信息語義化處理及實現
本章將首先介紹產品信息語義化處理的整體結構，然后使用相關構建工具對產 品信息管理中的對象進行語義建模，并結合Prolog規則語言，進行產品信息管理的 屬性擴展、本體實例的一致性檢測以及多圖聯合操作等。最后，對基于RDF模型的 信息管理相關功能進行了設計和實現。
4.1產品信息語義化處理的整體結構
產品信息語出化處理的整體結構如圖 4.1 所示，分為四個層次：對象個體層、 建模與關聯層、查詢推理層、服務應用層，下面分別對這四個層次進行說明。
圖 4.1 產品信息語義化處理的技術結構
第一層，對象個體。這一層中的對象個體指具體應用環境下的實體，這些實體 是數據的生產者。既指客觀存在的物理個體，如人，設備，建筑物等，也指現實中 的邏輯個體，如虛擬的訂單，環境信息指數等。這是實體之間可能存在著某種特定 的關系，如訂單與人之間存在著某種歸屬關系，某個設備安置在某個建筑物里，設 備具有改變環境數據的能力等。這些對象個體屬性改變的感知與獲取可由自動化裝 置提供，部分對象屬性也可人為配置。
第二層，對象建模與關聯層。這一層將上述實體對象及其之間的關系通過一定 知識表達方式展現在數據/信息世界中，成為實體對象在數據/信息世界中的映射，反 映實體對象的狀態及實體之間的關聯變化。對象實體之間的關系將在這一層通過知 識系統進行表達和構建，使得計算機更易于處理。例如，在人與訂單的關系中，一 個人可以同時擁有多個訂單實例，但是一個訂單卻只能歸屬到一個人物實體，不能 出現一個訂單同時屬于2個及以上的不同人物個體。在OWL本體構建中可以使用 Order hasOwner max 1 Person來表達這種固有關聯。這一層利用RDF數據模型，實 現對第一層中的對象個體進行信息建模，使用的開發工具有Protege和 TopBraidComposer 等。
第三層，查詢及推理層。這一層主要面向用戶側，為User提供相應的服務支撐。 通過第二層數據模型的進行抽象，這一層可以進行對基于RDF數據模型構建物理對 象的信息查詢和獲取；也可以在規則推理或本體推理下，獲取知識信息。這一層中， 對RDF數據的查詢需要使用SPARQL查詢語言或相應數據庫提供的訪問API。在 推理方面，需要運用支持本體推理的推理實現，如Jena, HermiT等推理機。上述的 這兩種推理機都是基于 Java 語言的實現，本文還對這兩種推理機進行了功能整合。
第四層，服務應用層。這一層為具體的服務提供相應的接口形式。對產品管理 者，提供產品信息的更新和維護接口；對產品的消費者，提供系列的產品服務訪問 接口。在本文中，使用JavaEE集成開發環境，將構建基于B/S的產品信息服務接口 并完成測試。
4.2開發工具及數據流
上一節介紹了產品信息語義化的整體結構，本節對構建上述結構中運用到開發 工具及其之間的關系做出說明，使用的開發工具及其用途如表4.1所示。
表 4.1 信息管理語義化開發工具
編號 工具名稱 用途 備注（版本）
1 TopBraidComposer 本體構建 Standard Edition
2 Protege 本體一致性檢測 5.1
3 AllegroGraph 作為本體及數據存儲倉庫 Version6.1.2
4 EclipseJee 語義編程處理開發環境 Oxygen
5 AGJena 語義推理SDK Agraph-6.2.0
6 AGWebView 作為數據庫訪問控制web界面 6.1.2
7 Xmanager 遠程訪問工具 4Build 0138
8 CentOS 服務器操作系統 6.9Final
9 Gruff 數據庫可視化訪問工具 6.3.3
10 HermiT 推理機Jar工具包 1.3.8
在表4.1中，TopBraidComposer及Protege是用于本體編輯和推理的工具， TopBraidComposer 提供了良好的圖形化本體編輯方式，并且支持拖拽式關聯構建， 而Protege較TopBraidComposer而言，支持更加豐富的公理屬性推理，如量詞約束 推理等，還為本體構建過程提供了一致性保證。因此，在實現語義化處理的本體構 建階段同時使用了這兩款集成開發工具。
AllegroGraph 是由美國的 Franz 公司開發的一款語義圖形數據庫，用于存儲和 管理各種三元組（Triple）數據。其特點是讀寫能力強、多用戶操作、支持W3C查 詢語言以及 Prolog 查詢，還具有社會網絡分析、地理空間和時序推理功能。 AGwebView是該數據庫商提供的一個基于瀏覽器web的數據庫訪問操作界面化工 具，支持大文件上傳，批量數據導入，重復數據刪除，SPARQL數據庫查詢等。
AGJena 是 AllegroGraph 數據庫提供的一套 Java 語言開發包，基于開源項目 Apache Jena進行了性能優化以滿足實際應用要求。在該開發包的支持下，可以直接 對數據庫進行遠程訪問已經CRUD操作。與AGwebView提供的web操作相比，該 工具包更適合業務的程序編程開發，而AGwebView提供了一套基于HTTP協議（而 不是編程語言）的數據庫操作方式。
HermiT推理機內置在Protege5.1中，為了開發編程的需要，將其開發包獨立出 來，用以支持更高效的推理支持。
本體構建中綜合使用了 Protege和TopBraidComposer兩款本體編輯工具，形成 owl 本體文件，存儲于數據庫中；本體中數據實例的更新將依據本體中的屬性描述 詞匯來修改，刪除或增加新的三元組實例，更新的執行使用數據庫操作接口 Jena及 SPARQL 語言；為用戶提供訪問接口的服務器基于 TomcatWeb 服務器搭建，與 AllegroGraph 數據庫在同一物理機器上運行；本體數據的查看，可通過數據庫訪問 的方式，也可使用Gruff圖形化工具來查看。
AllegroGraph 是美國 Franz 公司開發的一款語義圖形數據庫，是一個用于構建 語義網應用的圖形數據庫和應用框架。不同于傳統關系型數據庫以表的方式進行數 據存儲，AllegroGraph以三元組的方式存儲數據和元數據，使用多種查詢API （例如 SPARQL和Prolog）查詢RDF數據，通過內置推理機支持RDFS++推理。另外， AllegroGraph支持數據聯合、社會網絡分析、地理空間能力和時序推理。AllegroGraph 及相關語義開發工具的運用結構如圖 4.2所示。
4.3產品信息管理的語義建模
4.3.1語義對象本體建模
依托語義網技術，結合實驗室智能制造課題的研究，對各個生產環節（訂單生 成、訂單匹配、用戶關聯、物料存儲、產品物流等）、生產設備、生產環境及用戶 等進行語義描述，增強生產過程相關數據與人、設備及生產環境之間的聯系。并通 過語義推理，為上層提供豐富的知識。對于應用語義技術的場景來說，需要對描述 對象及其屬性特征提前進行規劃和分類。對象分類：大體上分為四類對象——設備 對象及其生產環境(實際生產過程中的物理環境可能對設備的工作狀態甚至產品的 質量產生一定影響，收集這些動態數據并對其進行相應的分析將有利于提高產品質 量)、產品對象(產品的加工標準、外形要求，規范標準等)、和客戶訂單對象等； 使用RDF數據模型來描述產品信息管理中的主要對象。
(1)設備本體對象： 生產設備用于完成訂單產品的生產。結合產品信息，初步定義了如圖4.3 所示 的設備對象屬性。實際生產過程中的物理環境可能對設備的工作狀態甚至產品的質 量產生一定影響，收集生產環境數據并對其進行相應的分析有利于提高產品質量。
圖 4.3 生產設備對象屬性
(2)產品本體對象： 主要屬性：工序、部件、序列號、生產線號、包裝等。
開始時間
圖 4.4產品對象屬性
(3)訂單本體對象
主要屬性：訂單的歸屬客戶、交貨地址、完成狀態、訂單ID等。
除了上述基本對對象以外，產品信息化的語義對象還包括管理用戶以及消費客 戶。
4.3.2語義對象屬性關聯
以產品為中心的對象間關系的建立：以產品為中心，建立產品與生產設備的關 系,產品與加工環境的關系，產品與訂單的各種關系模型。使用TopBraidComposer 為產品對象添加主要的屬性，并限定屬性的定義域和值域，最后通過AGwebview可 直接將本體文件上傳至數據庫。如果需要進一步添加相關屬性，可以使用JavaAPI 實現數據庫編程。
如圖4.6所示構建了產品、訂單、客戶、機器等多對象本體模型及其關聯關系。 使用分圖存儲方式來進行管理時，需要使用聯合圖來對這些相互關聯的對象進行查 詢和操作。操作模型如下圖4.7所示：
4.3.3語義屬性公理推理
(1)傳遞性屬性公理
在產品——訂單——客戶，這三個類型的歸屬(BelongsTo)關系中，存在著傳 遞性推理，因此可以將其定義為 TransportProperty 的一個屬性實例。在 TopBraidComposer中，使用曼切斯特語法定義傳遞性屬性的操作如圖4.8所示。
(2)設備所在地址唯一性公理
一般而言，設備所在地址具有唯一性，即只能在某一個具體的位置，不同同時 處于兩個不同的位置。除非這兩個不同的位置說明實際上指向的是同一個位置，即 這兩個位置實例是等價的。
曼切斯特語法定義的等價公理為：hasLocation max 1 Location，在Protege中的
定義如圖4.9所示。
(3)訂單歸屬客戶唯一性公理 在前述的訂單歸屬中，需要定義訂單的歸屬客戶只能為一個。即同一個訂單不 能屬于兩個不同的客戶，與(2)中所述的設備地址唯一性類似。在圖4.10中定義了訂 單的等價公理以及一個訂單實例：021321。
I * II ▼* I I 小~“
▼ ■ owl:Thing
Product
Description: Order
Equivalent T(• +
• BelongsTo max 1 Client
SubClass Of (Anonymous Ancestor)
In stances
021321
圖 4.10 訂單歸屬的數量約束公理定義
4.4基于語義網技術及 Prolog 語言的信息管理應用
基于語義網的信息管理可從以下幾個方面研究和應用：結合 Prolog 規則語言， 對產品信息屬性進行擴展；運用本體推理技術，完成產品信息本體與實例數據的一 致性檢測；基于產品屬性，對產品進行分類，實現產品篩選和推薦。
4.4.1基于Prolog的產品信息屬性擴展方法
對物理世界中的各種對象，或資源進行信息化的最終目的是為人提供滿足需求 的服務。關系數據庫中構建的信息對象，具有很強的結構性，導致對象個體信息固 定，缺乏靈活的屬性擴展能力。數據屬性的擴展，是在已有的個體屬性數據之上， 通過資源之間的相互關系，得到某些更加豐富的屬性申明，從而滿足本體應用和數 據處理的需求。
例如，在產品的歸屬屬性，belongsTo是一種具有傳遞邏輯的對象屬性：
1、已知：
pid:W10051 :belongsTo o:1699;
且存在歸屬事實：
o:1699 :belongsTo u:guan2345;
申明屬性為傳遞性屬性：
belongsTo rdf:type owl:transitiveProperty
2、推理得出（傳遞性推理）：
pid:W10051 :belongsTo u:guan2345
3、進一步應用：
由推理結論得出，這一產品屬于guan2345這一用戶；進一步的查詢該用戶的顏
色喜好（如圖4.11所示），可以指定這一產品的包裝顏色，提高用戶體驗。
再者，產品的顏色構成與組件顏色之間存在著依賴關系。產品的顏色依賴于其 下組件顏色的構成，因此可通過屬性擴展得到其產品的顏色。在產品顏色取決于組 件顏色這種情況下，可以使用Prolog規則擴展得到產品的顏色構成。
1、已知：
產品的各個組成部件，及部件的顏色屬性；
2、定義：
產品的顏色組成=組件1的顏色+組件2的組件顏色，使用Prolog語言定義的推 理規則如下：
<--(hasColor ?product ?color) 〃規則頭，下面為規則體
(?product !:hasComponent ?Component)
(?Component !:hasColor ?color)
擴展后的到的產品信息如圖4.12所示。
3、進一步應用：
根據用戶對顏色的偏好，推薦具有相應色彩的產品，具體產品推薦方法將在下 文中介紹。
4.4.2基于產品本體知識的信息一致性檢測方法
一致性檢測是本體中檢測本體構建的正確性的途徑，同時也是檢測實例數據與 本體知識模型不相違背的過程。以上是一致性檢測的兩個基本目的：本體一致性檢 測及本體實例一致性檢測。一致性檢測具體應包括但不限于：類層次結構的正確性， 沖突類定義錯誤檢查，實例的屬性約束與本體中定義是否一致，實例的屬性量詞與 本體中定義是否一致等。一般情況下，本體的一致性檢測在本體構建階段完成，或 是在本體更新維護階段同步進行，而本體實例（Instance）數據的檢測，則是在數據 產生時同步完成，對產生的不一致數據進行統計和匯報。本體實例數據的一致性檢 測方法如下圖4.13所示。
圖 4.13本體一致性檢測流程
以產品訂單一致性檢測的詳細步驟，說明圖4.13 所示的實例數據的一致性檢測 流程：
Step 1: 獲取訂單本體和實例數據； 根據應用知識，本體建模中，使用公理定義了訂單的一個必要條件，即訂單定 義需滿足如下規則，否則不能將其認定為一個訂單實例：
:belongsTo max 1 person.（即一個訂單只能屬于1個人）
定義的訂單本體可以存放于數據庫，也可以存放于本地文件系統，當需要執行 本公理時，導入到相應的推理操作模型（OntologyModel）中。
Step 2:本體模型中，配置相應的推推理機（HermiT）；
根據 OWL 定義的本體公理，必須在推理機支持下進行印證，支持本體公理的 推理機有Jena、HermiT等。本文研究、整合后的推理機實現了 JenaReasoner接口和 HermiT 接口，通過強制類型轉換即可完成兩種推理機之間的切換。
Step 3:聯合推理模型與實例數據，組成推理Model；
實例數據的操作模型Model，能夠提供對已知三元組數據的查詢，檢索，修改 等操作，但通常不具備推理功能，因此需要與推理Model進行聯合，以完成推理檢 測。多圖聯合的操作方法在后文中介紹。
Step 4: 對推理 Model 執行一致性檢查，并獲取檢查結果； 在開放世界假設下，推理機執行一致性檢測推理。推理得到的事實在通過審核 之后，可以直接添加到數據操作模型中。
Step 5: 對檢測結果進行分析和處理。
對推理結果進行審查，根據結果，執行本體更新或者實例數據的修改。一般來 講，在一個良好構建的本體中，推理出來的三元組申明也是正確的。一旦出現實例 數據與本體知識之間的沖突，那么就要重新檢查本體的正確性，或審查實例數據的 正確性。
4.4.3基于中間類結構的產品篩選與推薦方法
圖 4.14 基于中間類結構的產品推薦方法流程
基于中間類結構的產品篩選與推薦方法以本體推理為基礎，主要分為六個步驟： 類型預整理、需求定義、構建中間類、類型再整理、中間類結構分析、推薦結果， 如圖4.14所示。具體的操作和執行以產品的顏色屬性信息進行闡述，在表4.2中是 通過屬性擴展得到的產品信息，按照下述的Stepl到Step6可完成產品帥選和推薦。
表 4.2 預置的產品顏色屬性
產品名稱 具有的顏色屬性值
Product 1 white
Product_2 white & black
Product_3 black & green
Product_4 white & green & gray
Product_5 black & green & gray & yellow
Product_6 white & black& green& gray& yellow
Product 7 blue
Step 1: 產品類預整理：根據已獲取得到的產品信息，在推理機的支持下，進行 產品類型推理，得到產品類型結構圖如，根據前述定義的各個產品顏色屬性值，使 用推理得到：以顏色分類的產品“樹”結構，如圖4.15所示。
Step 2: 定義需求：根據用戶信息，獲取符合其需求的產品屬性。這些屬性信息 的來源可以是多方面的，既可是用戶個性偏好信息，也可以是歷史消費信息。
例如，根據消費記錄，為用戶推薦具有白色屬性的產品。
Step 3: 構造上述需求的產品中間類：在本體中，根據步驟2中的需求分析結果， 定義滿足需求的產品類型，該類成為中間類。例如，在產品本體類中，定義白色類 型產品以滿足需求，在本體中，使用曼切斯特語法可表示為：
Product with white= 3:hasColor some :white.
Step 4:類型再整理：由步驟3 中添加了一個滿足需求的中間類到本體中，本體 類型結構可能發生改變，需要重新進行步驟1 的類型整理，得到類似的類型結構。 例如，將step3中定義的產品中間類，添加至本體中，再次執行類型推理，得到該中 間類在本體中的結構，如圖4.16所示。
圖 4.16基于中間類的產品類型推理結果
Step 5:中間類結構分析：對再次進行類整理的中間類結構進行分析，分析該類 在此本體中的位置結構，存在的等價類以及子父類關系。例如，在上述的產品本體 結構中，中間類(Product_with_white)具有一個等價類：Product」，兩個直接子類： Product_2 和 Product_4,同時還有一個孫子類：Product_6。
Step 6: 結果推薦：在開放世界假設的類型結構推理下，結合步驟5中分析中間 類的結構，逐層推薦滿足需求的產品類型。
4.5基于RDF模型的信息管理系統實現
依據前述目標，需要完成的信息管理包括用戶管理、產品管理、訂單管理、設 備信息查詢等模塊，并分別對這些模塊使用語義網技術進行實現。
4.5.1系統用戶管理
該部分首先要完成的功能是操作員和管理員用戶的注冊登記，然后是注冊用戶 的登錄驗證。在語義建模的基礎上，普通用戶的類型定義為User,管理者的類型定 義為 Administratoro
(1)用戶注冊
用戶數據屬性包括：URI、rdfs:label、:address> :fhllname、:phonenumber 等，用 戶類型屬性：rdf:type為User或Administratoro使用TBC構建的用戶信息圖形化展 示如圖4.17所示。
圖 4.17 用戶屬性注冊信息
用戶的注冊及其驗證程序流程，如圖4.18所示。
(2)登錄驗證流程
通過Web訪問，提供用戶名和密碼兩個輸入框，以及確定與取消執行動作。當 操作者輸入用戶信息后，系統進行加密處理，然后根據其用戶名調用 AllegroGraph 語義圖數據庫中預存的用戶數據，執行驗證。根據驗證結果，執行返回驗證或跳轉。
(3)用戶信息更新
根據SPARQL語言規范，用戶的每一個屬性信息都對應一條三元組聲明，當需 要更新用戶的某個屬性時，首先需要先定位這一屬性，然后刪除這一條屬性申明， 最后針對這個屬性-值對，修改其值。例如，更新cqupt:Guan這一用戶的address屬 性值，使用的SPARQL語句如下：
PREFIX cqupt: <http://cqupt.edu.cn/person #>
DELETE
{ cqupt:Guan cqupt:address ?a.
}
INSERT
{ cqupt:Guan cqupt:address "cqupt33-420".
}
WHERE
{ cqupt:Guan cqupt:address ?a.
}
其中，首行的PREFIX定義了 URI的前綴縮寫，WHERE中定位需要更新的個 體屬性-值，DELETE用于刪除WHERE中定位的屬性及值，INSERT語法中為定位 的個體添加新的屬性及值。
用戶的刪除操作可以參照使用上述的DELETE語法執行，只需要將WHERE中 的三元組定位為某個具體的用戶實例即可。
4.5.2產品及訂單信息管理
(1)產品訂單關聯
面向User,進行訂單生成，狀態查詢，同時，根據用戶偏好信息，為其推薦個
性化產品。訂單生成通過數據庫操作API來實現。首先，需要進行數據庫連接、數 據圖操作Model接入:
AGGraphMaker maker=example1(false);〃 獲取 examplel 中的數據倉庫
AGGraph aggraph= maker.getGraph();〃獲取默認的圖來管理資源，也可以指定一個具名 圖來操作
AGModel model=new AGModel(aggraph);
需要創建一個訂單資源實例，并為其配置一個URI唯一標識此訂單:
Resource newOrder=model.createResource("http://cqupt.edu/order/O001");
訂單具有歸屬用戶這一屬性，因此需要將新建訂單與用戶進行屬性關聯,且申明
該屬性為傳遞性屬性：
Resource newOrder=model.createResource("http://cqupt.edu/order/O001");
Property belongsTo=model.getProperty("http://cqupt.edu /belongsTo"); model.add(newOrder, belongsTo, user);
model.add(belongsTo, RDF.type, OWL.TransitiveProperty);
下一步是將用戶選定的產品與此訂單關聯，執行方式與上述關聯類似。上述執 行結果可使用SPARQL語句來查詢。
(2)訂單查詢
該部分完成的主要功能是為用戶提供訂購產品的信息追蹤，提供產品信息的處 理情況。查詢流程如下圖4.20所示。
圖4.20基于SPARQL的訂單查詢處理流程
(3)產品屬性修改
屬性的修改，涉及到本體中使用詞匯的修改，因此首先需要查找到要修改的屬 性詞匯及其使用情況。
PREFIX cqupt: <http://cqupt.edu.cn/product #>
DELETE {
?product cqupt:hasComponent ?component.
}
INSERT{
cqupt:hasBody rdf:type rdf:Property. #屬性申明
cqupt:hasBody rdfs: subPropertyOf cqupt:hasComponent. # 子屬性申明 ?product cqupt:hasBody ?component.
}
WHERE
{
?product cqupt:hasComponent ?component.
?component rdf:type cqupt:Body.
J
上述 SPARQL 語句中 DELETE 刪除了一項已有的關于產品屬性的描述，然后 在INSERT中申明了另一個屬性，并使用該屬性來描述在DELETE中刪除的三元組 信息。需要注意的是，這里增加了兩項修改：一是針對實例，即針對WHERE中所 有滿足條件的實例，屬性都進行了更新；二是針對本體的修改，在這里添加了一個 新的屬性描述詞cqupt:hasBody,并且將這一屬性申明為cqupt:hasComponent屬性的 一個子屬性。
圖4.21和圖4.22展示了產品屬性修改前后的對比。
4.5.3生產及設備信息獲取
生產信息管理以面向管理者方面的物料查詢，環境預警為例說明使用 SPARQL 進行信息的增、刪、改、查操作方法，其他信息的查詢和維護可以根據SPARQL定 義的語法來編輯和執行。
(1) 物料信息查詢 在本體構建過程中，對各種組件及其歸屬的類型均進行了定義，因此對某一類 組件數量的查詢，可構造如下的SPARQL語句：
PREFIX cqupt: <http://cqupt.edu.cn/product #>
SELECT C0UNT(?b)
WHERE
{
?b rdf:type cqupt:Body.
J
其中，PREFIX定義前綴縮寫，WHERE語句中，綁定了將要查詢的組件類型, 即cqupt:Body。COUNT()函數是SPARQL中用于統計返回結果數量的函數，綁定 WHERE中定義的“?b”變量，將統計得出滿足指定申明的三元組主語數量。查詢結 果，如下圖4.23所示，返回一個整數值(Integer)。
Query Editor Query Library [.1]
PREFIX cqupt: < http://cq upt.edu.cn/product#>
SELECT (COUNT(?b))
WHERE |D2
rdf:type
圖 4.23 物料信息查詢結果
(2) 規則預警
生產設備所處的環境信息使用無線網絡進行監測和預警，需要預先設定各項檢 測參數的預警閾值，如：
定義預警規則1：溫度傳感器_1采集的數值>70并且光照強度傳感器 _2>1000
系統會提示警告及具體數據信息:
PREFIX cqupt: <http://cqupt.edu.en/product#>
SELECT *
WHERE
{
{
SELECT ?v1
WHERE
{ cqupt:Sensor_1 cqupt:hasValue ?value. FILTER(?value>35) #閾值過濾 BIND(?value AS ?v1)
}
}
{
SELECT ?v2
WHERE
{ cqupt:Sensor_2 cqupt:hasValue ?value. FILTER(?value>1000) #閾值過濾 BIND(?value AS ?v2)
}
}
BIND("溫度光照警告#1" AS ?警告)#將警告信息進行綁定
}
其中，兩個SELECT查詢分別用于綁定Sensor1和Sensor2的數據輸出值。最 后的BIND對同時滿足以上兩個SELECT的結果進行綁定，如果上述兩個SELECT 變量沒有同時滿足，則不進行變量綁定。上述規則查詢到警告信息如圖 4.24 所示。
vl v2 歸］
Q42 Q 1145 目溫度光照曹育#1
圖4.24 SPARQL預警信息查詢結果
4.6本章小結
本章對產品信息化處理的技術結構以及相關的開發環境、工具進行了介紹，構 建了產品信息化所需要的本體，包括產品，訂單，客戶對象本體。使用多圖聯合的 方式對這些本體進行聯合操作。結合 Prolog 語言，對產品的相關屬性進行了擴展， 并在此擴展屬性基礎上，提出了基于中間類結構的產品篩選與推薦方法，為用戶提 供產品的篩選能力。此外，本章還對如何使用SPARQL和數據庫操作API進行產品 信息管理進行了詳細闡述。
第5章 產品信息語義化處理系統及測試
本章對產品信息管理語義化平臺進行了搭建，并完成相關功能的實現和測試。 首先，介紹了測試平臺的B/S結構及其相關開發技術，然后對在平臺下實現了信息 管理功能接口的開發及測試。同時，本章還完成了前述的產品信息擴展及一致性檢 測方法的測試。
5.1語義信息測試平臺搭建
5.1.1系統結構
基于 B/S 的語義信息測試平臺的基本結構如圖所示。在該結構中，客戶端使用 支持HTTP協議的web瀏覽器。而服務器端采用的Web服務器為Tomcat &5,圖形 數據庫為Allegro Graph 6.1.2,且web服務器與數據庫服務器部署在同一物理機器上 運行。
5.1.2軟硬件基礎
產品信息語義化的驗證過程中需要許多軟硬件的支撐，包括本體存儲數據庫和 Web開發軟件及其運行環境，本體構建工具、本體操作API等。以下說明了系統測 試運行的硬件及軟件環境。
1）硬件基礎：
曙光服務器A840-G10：用于承載Allegro Graph圖形數據庫軟件及相關的web 服務器開發和運行軟件。
無線傳感器網絡設備：無線傳感器節點，用于工業設備環境的信息采集；網關 作為匯聚節點，上傳處理數據。
PC機：用于接收網關出口的數據（來源于底層網絡）和工業現場的數據并對其 進行語義處理，同時完成數據庫更新，并作為 browser 軟件，支持管理和用戶的行 相關操作；承載本體及web應用程序的開發環境。
2）軟件平臺
Protege本體構建與推理工具：版本5.1,內置HermiTv1.3.8推理機。
Allegro Graph語義圖形數據庫：作為數據倉庫使用，支持RDF模型數據的存儲 和訪問，并支持相關的推理機制。
TomcatWeb8.5服務器：用于承載web應用程序，即作為Servlet容器使用。
Eclipse Jee Oxygen集成開發環境：用于開發和部署Java web應用。
AllegroGraph數據庫API：用于實現數據庫的編程操作，支持多種編程接口一 —JeanAPI、HTTP 訪問等。
RDF數據圖形化查看工具Gruff：圖示化數據查看器，可以直觀顯示對象及其 之間的關系及拓撲。
本體模型構建客戶端TopBraidComposer:用于構建基于圖模型的對象及其之間 的相互關系。
5.2基于B/S結構的數據庫訪問接口開發
5.2.1B/S交互模型介紹
B/S結構是一種以Web技術為基礎的新型系統平臺模式。它把傳統C/S結構中 的服務器部分分解為一個數據庫服務器與一個或多個應用服務器，從而構成了一個 三層結構的客戶端/服務器結構（如下圖5.2所示） 。在這種結構中，主要的命令執 行、數據計算都由服務器端完成，應用程序在服務器端運行，客戶端通過HTTP協 議的瀏覽器來完成交互［37］。
在B/S結構中，由瀏覽器作為統一的客戶端，服務器端由web服務器和數據庫 服務器及其中間應用程序組成。在本文的設計中，web服務器由PC端搭建，數據 庫服務器運行在CentOS6.5 上,構成服務器端。當用戶通過客戶端瀏覽器向web服 務器發出HTTP請求信息，web服務器再向數據庫服務器請求相應的數據，數據庫 服務器完成web服務器的請求后，向web服務器發出回復信息，然后web服務器將 數據庫服務器提供的有用信息使用HTTP協議傳給瀏覽器，通過瀏覽器解析響應的 數據用戶就可以看到自己想要瀏覽的信息。
瀏覽器
業務邏輯層
圖5.2 B/S結構的三層開發模型
除了描述對象的數據模型以及圖形數據庫編程操作外，B/S結構的實現還需要 相關web技術的支持——HTML語言、HTTP協議、Servlet技術、web應用服務器、 數據庫服務器等。HTML是超文本標注語言的縮寫，能夠提供帶有超鏈接功能的文 本，在本文的設計中，它將實現用戶看到的頁面內容。HTTP是客戶端瀏覽器或其 他程序與web服務器之間的應用層通信協議。在Internet上的web服務器上存放的 都是超文本信息，客戶機需要通過HTTP協議傳輸所要訪問的超文本信息-HTTP協 議是服務器與用戶瀏覽器進行溝通的橋梁，基于B/S結構的服務提供都參考此協議 來完成，是web使用的基本協議。Servlet為創建動態的web應用提供了開發支持。 本文中使用的Servlet容器是Tomcat服務器，它是一個免費的開放源代碼的Web應 用服務器，屬于輕量級應用服務器，在中小型系統和并發訪問用戶不是很多的場合 下被普遍使用，是開發和調試Servlet程序的首選。
5.2.2Rest風格架構
圖5.3 一種Rest風格架構模型
REST （Representational State Transfer）,即表述性狀態轉移，本質上是使用URL 來訪問資源的一種方式。圖5.3展示了實現REST資源訪問的一種方式，其中使用 AJAX （Asynchronous JavaScript and XML）向控制器（Controller）發送異步的請求， 業務模型（Model）使用JSON （）返回該請求的數據。比較常見的請求方式是GET 與POST,但在REST中又提出了幾種其它類型的請求方式，匯總起來有六種:GET、 POST、PUT、DELETE、HEAD、OPTIONS-尤其是前四種，正好與 CRUD （Create- Retrieve-Update-Delete,增刪改查）四種操作相對應，例如，GET （查）、POST（增）、 PUT （改）、DELETE （刪），這正是REST與CRUD的異曲同工之妙。表5.1展示 了使用REST進行請求操作的示例。需要強調的是，REST是面向資源的，這里提 到的資源，實際上就是我們常說的領域對象，在系統設計過程中，我們經常通過管 理對象來進行數據建模。
表5.1 REST請求的簡單描述示例
REST請求 描述
GET: /Repositories 獲取所有倉庫信息
GET: /Repositories/Guan 獲取Guan這一倉庫的信息
POST: /Repositories/GuanO 1 創建一個名為Guan01的倉庫
PUT: /Repositories/Guan01 更新一個名為Guan01的倉庫
DELETE: /Repositories/Guan01 刪除名為Guan01的倉庫
5.2.3服務端 Servlet 技術
Servlet是一個縮寫詞匯，由Server與Applet的簡寫而來，是服務端小程序的意 思。Java Servlet在Java EE中處理或存儲符合Java Servlet API的Java類，這是用于 實現對請求做出響應的Java類的標準。原則上Servlet可以通過任何客戶端-服務 器協議進行通信，但它們通常與HTTP協議一起使用。因此，Servlet通常用作HTTP Servlet的簡寫。因此，軟件開發人員可以使用Servlet將動態內容添加到使用Java平 臺的web服務器-Servlet生成的內容通常是HTML,但也可以是其他數據，如XML、 JSON 等。
要部署和運行Servlet,必須使用web容器。web容器（也稱為Servlet容器）本 質上是與Servlet交互的web服務器的組件。web容器負責管理Servlet的生命周期， 將 URL 映射到特定的 Servlet 并確保 URL 請求者具有正確的訪問權限。提供了 Servlet 功能的服務器，叫做 Servlet 容器。常見的 web 容器有很多，如 Tomcat， WebLogic Server，Websphere，JBoss 等。如前所述，本文中使用的 Servlet 容器是 Tomcat。圖5.4為Servlet處理一個HTTP請求的生命周期。
圖5.4 Servlet的生命周期
在Java包層次結構javax.servlet中的Servlet API定義了 web容器和一個Servlet 的預期交互，Servlet是一個接收請求并基于該請求生成響應的對象接口。基本的 Servlet包定義了用于表示servlet請求和響應的Java對象，以及反映Servlet的配置 參數和執行環境的對象。包javax.servlet.http定義了通用Servlet元素的特定于HTTP 的子類，包括跟蹤 Web 服務器和客戶端之間的多個請求和響應的會話管理對象。 Servlet可以作為Web應用程序打包在WAR文件中，然后由Servlet容器直接加載 和部署。
5.3功能模塊設計與實現
5.3.1系統用戶管理實現
用戶管理主要進行用戶信息的參數輸入和數據庫驗證。通過 Servlet 中的 HttpServletRequest參數可以獲取得到前端輸入的用戶信息，然后對此用戶信息進行 封裝，使其成為用戶數據模型的一個具體對象。控制用戶驗證的Servlet核心處理代 碼如下：
/**
* @see Http Servlet # doGet(HttpServletRequest request, HttpServletResponse response)
*/
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// TODO Auto-generated method stub
String email=request.getParameter("username");
String password=request.getParameter("password");
User user=new U ser(email,password);
if(AGUserService.c方fcPLtey(user)) { response.sendRedirect("/TestDemo1/main.html");
}else {
response.sendRedirect("/TestDemo1/login.html");
}
}
其中，AGUserService類對用戶信息在語義數據庫中的校驗進行了方法封裝，參
數為User Class, checkUser(User user)返回在數據庫中校驗的結果。User類的數據模 型定義如下：
User
-address -phoneNumber -fullname -password -email
5.3.2產品及訂單管理實現
產品訂單管理的添加方法在第四章中闡述，其查詢管理使用 SPARQL 標準語
言，具體的SPARQL查詢方法在Servlet中的封裝實現如下：
AGGraphMaker maker = null;
try {
maker = MyExamples.openRepository(Repository);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
ArrayList<TripleINF> list=new ArrayList<TripleINF>();//用 于存儲結果的 List if(maker!=null) {
AGGraph graph=maker.getGraph();
AGModel model=new AGModel(graph);
try{
String queryString=query;
AGQuery sparql=AGQueryFactory.creote(queryString);〃 執行查詢 QueryExecution qe= AGQueryExecutionFactory.create(sparql, model); try{
ResultSet results=qe.execSelect();
while(results.hasNext()){
QuerySolution result=results.next();
RDFNode s=result.get("s");
RDFNode p=result.get("p");
RDFNode o=result.get("o");
list.add(new TripleINF(s.toString(), p.toString(),
o.toString()));〃對結果進行圭寸裝
}
}finally{
qe.close();
}
}finally{
model.close();
}
}
return JSON.toJSQMStringQisrtrue);
返回的每一個獨立結果對應一個三元組，并將其封裝為 TripleINF 對象
TripleINF的類型結構如下：
TripleINF
-subject -property -object
例如，查詢產品的歸屬客戶時，可以將如下的SPARQL語句作為上述Servlet中 的QueryString,然后進行數據庫的查詢操作:
SPARQL查詢語句：
PREFIX cqupt: <http://cqupt.edu.cn/product #>
SELECT ?p ?name
WHERE
{
?p cqupt:BelongsTo ?o.
?o cqupt:BelongsTo ?u.
?u rdfs:label ?name.
}
5.3.3生產警告信息獲取
根據上述一節中實現的SPARQL查詢封裝方法以及環境設備對象本體，對生產
信息的獲取，提供給Servlet調用的警告查詢服務實現的主要方法如下：
public static String queryAlermINF(String Repository,String query) { AGGraphMaker maker = null;
try {
maker = MyExamples.openRepository(Repository);
} catch (Exception e) {
// TODO Auto-generated catch block e.printStackT race();
}
ArrayList<AlermINF> list=new ArrayList<AlermINF>(); if(maker!=null) {
AGGraph graph=maker.getGraph();
AGModel model=new AGModel(graph);
//構建的SPARQL字符串語句
String queryString=query;
AGQuery sparql=AGQueryFactory.create(queryString);
QueryExecution qe=AGQueryExecutionFactory. create(sparql, model);
try{
ResultSet results=qe.execSelect();
List<String> vars=results.getResultVars();
int num=vars.size();
for(int i=0;i<num;i++) {
System.out.println("i=:"+vars.get(i));
} while(results.hasNext()){ //獲取執行結果
QuerySolution re sult=re sults .next();
RDFNode v1=result.get("v1");
RDFNode v2=result.get("v2");
RDFNode alerm=result.get("alerm"); list.add(new
AlermINF(v1.toString(),v2.toString(),alerm.toString()));
}
}finally{
qe.close(); }
}finally{
model.close();
}
} return JSON.toJSONString(list,true); 〃返回數據集
}
在上述方法中，構造的查詢語句首先放入置一個查詢執行器中，由詢器設定查 詢類型并執行，返回結果將存儲在一個List中，最后使用JSON工具將List中的返 回結果進行格式化轉換。
5.4B/S 交互后端接口功能測試
5.4.1系統用戶管理測試
(1)測試目的：
驗證所搭建的 B/S 訪問平臺能夠訪問語義圖形數據庫，并對用戶進行驗證。
(2)測試步驟：
運行 TomcatWeb 服務器，發布 TestDemo1 Web 應用程序，順利啟動后，使用 “localhost:8080”進行主機和端口號的訪問，然后輸入用戶名和密碼進行登錄和驗 證，信息正確將會跳轉至主功能界面，否則將重新登錄。
(3)測試結果：
依照上述測試步驟，web應用的訪問頁面如圖5.5所示。可以看到，該系統提
供了較為友好的登錄界面，能夠進行數據庫驗證。
圖 5.5 用戶訪問界面
(4)測試結論： 通過瀏覽器能夠對信息管理系統進行登錄訪問。
5.4.2產品信息管理接口測試
(1)測試目的： 驗證所構建的訪問系統能否進行產品信息的交互訪問。
(2)測試步驟： 將構建好的本體及實例數據導入語義圖形數據庫中，使用如圖 5.6 所示的
SPARQL查詢語句，對數據庫進行信息訪問。
圖 5.6 產品信息接口測試
(3)測試結果：
以下結果集展示了 Product與User之間存在歸屬關系。
JSON數據集：
[
{
"productURI":"http://cqupt.edu.cn/product #waterCup", "userURI":"guan"
},
{ "productURI":"http://cqupt.edu.cn/product #product_3", "userURI":"guan"
}
]
(4)測試結論：
基于 Servlet 技術和 SPARQL 語言能夠對語義數據庫進行數據交互，并提供良 好的 B/S 訪問接口及數據交互格式。
5.4.3生產信息獲取接口測試
(1)測試目的： 驗證所構建的訪問系統能否進行生產警告信息的獲取。
圖 5.7 產品信息查詢接口
(2)測試步驟：
根據構建的環境信息結構及SPARQL查詢語句，使用Servlet技術和HTTP協 議通過瀏覽器進行查詢交互，使其返回JSON格式化的數據。圖5.7所示為后端接 口的測試界面。
(3)測試結果：
基于JSON格式的返回結果集如下所示，說明存在一個上述的警告對象及其具 體的數值信息。
JSON數據集：
[
{ "alerm":"?????? #1",
"light":"1145AAhttp://www.w3.org/2001/XMLSchema#integer", "temp":"42AAhttp://www.w3.org/2001/XMLSchema#integer"
}
J
(4)測試結論：
該后臺管理系統能夠對生產中的環境信息進行訪問，并且能夠使用SPARQL的 Bind語法實現警告服務。
5.5產品信息管理語義化方法測試
語義化相關的技術及方式的測試包括基于規則的屬性擴展測試、產品本體推理 功能測試、本體的一致性檢測測試以及分圖存儲性能測試。本節對這些技術和方法 進行了測試驗證。
5.5.1基于規則的產品屬性擴展測試
(1)測試目的：
驗證基于 Prolog 規則的產品信息屬性擴展方法能夠對產品信息進行有效擴展。
(2)測試步驟：
使用Prolog語言，構建產品屬性的擴展規則，并將該規則導入產品數據操作模 型中進行Prolog規則匹配，然后，對該操作模型進行擴展屬性的Prolog查詢。
自定義的產品屬性規則：
String rules 1 =
"(<-- (hasColor ?product ?color) ; IF\n" +
" (q ?product !pro:hasComponent ?component)\n" +
" (q ?component !pro:hasColor ?color))";
Prolog 查詢語句：
String queryString =
"(select (?product ?color)\n" +
"(hasColor ?product ?color))\n";
(3)測試結果：
在上述Prolog語句的查詢下，自定義產品屬性的擴展結果如圖5.8所示。
Available catalogs: [/, system]
Available repositories in catalog /: [111, 201711028, GuaN, Guan, GuanOl, GuanPIM, Gua Got a repository?
Initializcd repository.
Got a connect!on.
Repository Guan_Pro is up! It contains 157 statemerrt5?
Got a graph maker for the connection*
、All valid triDla indites: 『sdori, so良oi? sodei, so耳Di? sgpoisgopi^ psogi, psgoi^ pos ^Jhttp://cqupt,edu,cn/product#uaterCup hasColor: red |
Elapsed time: 1.03 seconds.
圖 5.8產品屬性擴展測試結果
(4)測試結論：
使用 Prolog 規則，能夠方便的擴展出產品的隱藏屬性，使產品信息更加全面。
5.5.2產品本體推理功能測試
(1)測試目的：
驗證基于屬性推理的產品推薦方法能否根據定義的需求得出滿足要求的產品。
(2)測試步驟：
根據第四章中提到的基于中間類結構的產品信息篩選與推薦方法和預定義的 產品屬性信息，在Protege中構建相關的本體，按照該方法所提出的步驟，使用推理 機執行推理，并獲取結果。
(3)測試結果：
當定義了一個具有白色屬性這樣的一個產品是時，使用 HermiT 推理機得到的 中間類“Product_with_white”的結構如圖5.9所示：該中間類具有一個等價類，兩 個直接子類以及一個孫子類，這些子類結構是滿足預定的屬性需求的，且“距離” 越近的子類，越滿足預定義的需求，從而形成推薦的層級結構。
(4)測試結論：
從上述結果圖中可以看出，該方法能夠得到滿足定于需求的產品類型，據此可 進行產品推薦。
5.5.3產品訂單一致性檢測測試
(1)測試目的：
驗證本體知識對實例數據的錯誤檢查能力
(2)測試步驟：
構建產品訂單本體，并定義本體中“Order"這一類對象具有“EquivalentTo"屬 性，且其值為:BelongsTo max 1 person。然后構建Person實例，并將此實例與Order 實例進行關聯，分別使用多個等價和不同的Person實例來進行一致性檢測。
(3)測試結果：
在申明某個訂單實例“Order_1"同時歸屬到“Guan"和“GuanOl"兩個Person 實例時，在開放世界假設(OWA)下，得到的與本體知識相匹配(不沖突)的推理 結果如下所示：
“Guan” Same Individual As “GuanO1”
即這兩個 Person 實例共指，為等價實體，在 Protege 中推理出的三元組事實如 圖5.10所示。這里體現了本體推理機是基于OWA這一事實，即對未知陳述不做否 定判斷。
而在執行一致性檢測之前，如若事先聲明兩個互不相同的 Person：
“Guan” Different Individuals “Qing”
且” Guan"與“Qing"同時被"Order_1"的“BelongsTo"屬性所指，依據本體 知識進行檢測，得到如圖 5.11所示的本體不一致情況的具體解釋。
(4)測試結論：
根據定義的本體類型公理屬性，能夠檢測出實例數據與本體知識相沖突的情況 保證數據的一致性。
畫 Show regular justifications ® All justifications
O Show laconic justifications O Limit justifications to
Explanation 1 □ Display laconic explanation —
Explanation for: oral:Thing SubClassOf owl:Nothing
Qing Type Person
Orderl BelongsTo Qing
Order EquivalentTo BelongsTo max 1 Person
Guan DifferentFrom Qing
Guan Type Person
Orderl BelongsTo Guan
Orderl Type Order
Il 礙 II "
圖 5.11 本體不一致的解釋
5.5.4分圖存儲方式性能對比測試
(1)測試目的：
測試分圖存儲方式對數據庫訪問性能的影響。
(2)測試步驟：
在同一數據規模下，分別對Default Graph和Named Graph存儲方式進行相同的 查詢，使得返回結果相同，并將兩種查詢方式分別執行20次，最后統計20次查詢 的平均耗費時間。此次試驗測試中，分別對50萬、100萬、200萬、400萬和 800萬 三元組數量規模下進行了測試。
(3)測試結果：
依照上述測試步驟，使用SPARQL對上述規模的數據倉庫進行查詢后，得到各 個數量級規模下的查詢返回時間如圖 5.12 所示，其中 Default-Graph 表示僅使用默 認圖的方式來存儲，Named-Graph則將對象數據集分割，使用具名圖的方式來存儲 和管理。由圖可知，使用具名圖的存儲方式進行數據訪問時，其平均返回時間較使 用默認圖方式要少。
(4)測試結論：
使用具名圖的存儲方式進行圖數據訪問時，由于檢索空間的縮小，使搜索引擎 能夠在較短的時間內返回結果，提高查詢效率。
5.6本章小結
本章首先介紹了產品信息語義化的系統結構及測試平臺，緊接著對基于B/S結 構的信息管理交互功能進行了設計和實現，并對用戶管理、產品信息管理和生產信 息獲取進行了測試驗證。測試表明，本文應用的語義網相關技術能夠實現對信息的 有效管理。最后還對產品信息管理中的語義化技術和方法進行了測試及結果分析。
第6章總結與展望
6.1課題總結
在使用語義技術進行信息管理的研究和實現過程中，通過對國內外相關學術成 果的學習和理解，結合RDF數據建模、本體技術、Prolog等技術提出了語義化信息 管理的基本處理架構，并結合應用的需求，搭建了基于B/S交互模式的信息管理系 統，完成相關功能的驗證。研究了語義網技術棧的基本技術構成，包括描述資源的 URI、RDF資源描述模型、RDF數據的存儲與查詢、本體構建方法、本體推理技術 等。并在產品信息化管理中應用了這些技術，其中RDF數據的存儲使用了分圖存儲 的方式，有效減少了搜索空間從而帶來時間收益；使用了 Franz公司的語義圖形數 據庫AllegroGraph；本體構建采用了 “七步法”，并在此基礎上提出了一致性檢測 方法，對本體進行一致性驗證；此外，本文還結合Prolog語言，提出了基于Prolog 規則的對象屬性擴展方法，在已有屬性基礎上，能夠豐富產品信息描述。本文基本 實現了基于語義網技術的產品信息管理系統，使得信息管理更加高效、數據操作更 加靈活，主要研究內容如下：
1．研究了國內外語義網技術的發展及其應用現狀，結合實驗室的產品制造平臺 及其語義技術基礎，仔細研究了語義網技術棧中的相關技術，并將其應用到產品的 信息管理中；
2.針對以往的信息管理中使用關系型數據庫帶來的對象屬性擴展困難、關聯關 系構建繁瑣這一問題，提出了使用 RDF 數據模型來進行信息管理，并提出了基于 RDF數據模型的信息管理語義化處理架構。該架構涉及多個語義網技術，并使用了 Prolog形式邏輯語言以豐富基于規則的信息獲取能力；
3.在使用語義圖形數據庫進行數據存儲的過程中，對使用默認圖(DefaultGraph) 和使用具名圖(NamedGraph)這兩種存儲方式進行了對比研究，使用具名圖的存儲 方式能夠有效減少數據的搜索空間，提高訪問性能；
4.基于分圖存儲的研究中，對于多圖的訪問和管理技術，提出了基于多圖的圖 數據操作及推理方法。該方法使用 JenaGraph 操作模型，實現對多個圖數據集的聯 合操作及推理。
5研究了已有的語義本體推理機（Reasoner），使用Java開發語言，將內置在 Protege的開源HermiT推理機和AGJena推理機進行了功能整合，為語義推理提供 了更加多樣的推理功能支持。
6. 針對本體構建和實例數據管理的問題，研究和實現了基于本體知識的實例一 致性檢測方法。在構建和應用本體知識庫中，該方法能夠檢測出任何與本體知識相 沖突的實例聲明。
6.2未來展望
在本文的研究及實現過程中，對語義網技術棧有了基本的理解和認識，但是整 個信息管理及其到的相關技術還需要不斷的進行優化和改進。要使得語義網技術在 信息管理中的應用更加有效，還需要很多工作要做，后續的研究工作可以圍繞以下 幾個方面展開：
1.信息管理中的本體構建及其維護，本體的構建需要有較強的信息管理知識背 景作為依托，且是一個不斷豐富，不斷優化的過程。因此，本文中所提的本體構建 及維護還需要在應用開發和使用時周期性的進行，不斷豐富本體的表達能力和本體 知識的應用能力；
2.使用 TBC 進行本體構建時，對本體的一致性檢測沒有很好的支持，而這在 Protege中作為檢測本體正確性的基本方式。在下一步的研究中，可以結合Protege的 HermiT和TopBraidComposer,將HermiT作為外部插件使用，從而實現快速便捷的 本體構建；
3.本文中使用的RDF數據查詢語言SPARQL1.1不支持推理查詢，導致在使用 父類概念詞匯來進行查詢時，不能夠將子類屬性包含也進去，使得查詢結果不完備， 沒有聯合本體知識。因此，進一步的研究可以考慮在SPARQL標準語言的推進和發 展方面，將本體推理整合到查詢中；
4.本文的信息管理采用了基于B/S的模式實現人機交互，隨著智能技術與應用 的發展，可以將圖數據模型與語言語義分析進行融合，使用更加先進的語音交互模 式。
參考文獻
[1]楊丹.企業信息化管理[J].電子商務,2011(11):40-41.
[2]Web-based product data management system[J]. Modular Machine Tool & Automatic Manufacturing Technique, 2010.
[3]Wang H L, Jin H. Development and Performance Improvement of Enterprise Information Management System[C]// International Conference on Intelligent Computation Technology and Automation. IEEE, 2015:186-189.
[4]Mozgaleva P I, Zamyatina O M, Gulyaeva K V. Database design of information system for students' project activity management[C]// International Conference on Interactive Collaborative Learning. IEEE, 2015:886-890.
[5]Wu M. Design and Implementation of J2EE and MVC Model Based Enterprise Information Management System[C]// International Conference on Intelligent Transportation, Big Data & Smart City. IEEE Computer Society, 2016:424-427.
[6]Jenas Lehmamm, Robert Isele, Max Jakob. DBpedia—A Large-scale,Multilingual Knowledge Base Extracted from Wikipedia [J]. Semantic Web, 2012,1570-0844.
[7]Gusynin A V, Selezneva H, Stendyk A. Object-oriented approach for database design of information system[C] International Scientific-Practical Conference «modern Directions of Theoretical and Applied Investigations. 2012.
[8]Ghayvat H, Mukhopadhyay S C, Liu Jie, et al. Internet of Things for smart homes and buildings: Opportunities and Challenges[J]. Australian Journal of Telecommunication and the digital Economy, 2015, 4(3): 33-47.
[9]易雅鑫，宋自林，尹康銀.RDF數據存儲模式研究及實現[J].情報科學，2007, 25(8):1218-1222.
[10]Shadbolt N, Berners Lee T, Hall W. The Semantic Web Revisited[J]. Intelligent Systems IEEE, 2006, 21(3):96-101.
[11]Auer S, Bizer C, Kobilarov G, et al. DBpedia: A Nucleus for a Web of Open Data[M]// The Semantic Web. Springer Berlin Heidelberg, 2007.
[12]Kozak J, Necasky M, Pokorny J. Drug Encyclopedia — Linked Data Application for Physicians[C]// International Semantic Web Conference. 2015.
[13]白海燕•關聯數據及DBpedia實例分析J].現代圖書情報技術，2010,190(3).
[14]黃映輝，李冠宇•語義物聯網：物聯網內在矛盾之對策J].計算機應用研 究,2010,27(11).
[15]李濤,王次臣，李華康.知識圖譜發展與構建J].南京理工大學學報,2017, 41(1),22-
34.
[16]Widenius M. Mysql Reference Manual[M]. O'Reilly & Associates, Inc. 2002.
[17]Delaney K. Microsoft SQL Server 2012 Internals[J]. Microsoft Press Corp, 2013(7).
[18]Apache HBase[EB/OL]2017-12-09.． https:/ /hbase． apache． org/．
[19]Apache Cassandra[EB/OL]2017-12-09． http:/ /cassandra． apache． org/．
[20]MongoDB[EB/OL]2018-03-19． http:/ /www． mongodb． org/．
[21]Neo4J[EB/OL]2018-03-19． http:/ /www． neo4j． org． cn．
[22]AllegroGraph [EB/OL] 2017-12-09. https://franz.com/agraph/allegrograph
[23]Stojanovic L, Motik B. Ontology Evolution within Ontology Editors[C]// Econ: Evaluation of Ontology-Based TOOLS. 2002:53--62.
[24]TopBraidComposer [EB/OL] 2017-12-09.
https://www.topquadrant.com/tools/modeling-topbraid-composer-standard-edition/.
[25]Protege [EB/OL] 2017-12-09. https://protege.stanford.edu/.
[26]Anderson J C, Lehnardt J, Slater N. CouchDB: The Definitive Guide[J]. Andre, 2010, 215(1):pags. 76-80.
[27]佟強，張富，程經緯等.RDF在關系數據庫中的存儲研究[J].東北大學學報(自然 科學版), 2015, 36(3):346-349.
[28]Prud'Hommeaux E, Seaborne A. SPARQL query language for RDF, W3C Recommendation[J]. 2008.
[29]Carroll, Jeremy J, Dickinson, et al. Jena: implementing the semantic web Recommendation[J]. 2004.
[30]Studer R, Benjamins V R, Fensel D. Knowledge engineering: principles and methods. Data Knowl Eng 25(1-2):161-197[J]. Data & Knowledge Engineering, 1998, 25(1- 2):161-197.
[31]Natalya F. Noy and Deborah L. McGuinness. Ontology Development 101: A Guide to Creating Your First Ontology. [EB/OL] 2017-12-09. https://protege.stanford.edu/publi-cations/ontology_development/ontology101-noy- mcguinness.html
[32]Smith M K, Welty C, Mcguinness D L. OWL Web Ontology Language Guide W3C Recommendation[J]. 2004.
[33]Porello D, Endriss U. Ontology merging as social choice: judgment aggregation under the open world assumption[J]. Journal of Logic & Computation, 2014, 24(6):1229- 1249.
[34]Resource Description Framework (RDF). [EB/OL] 2017-04-09. URL: https://www.w3.org/RDF/.
[35]Sirin E, Parsia B, Grau B C, et al. Pellet: A practical OWL-DL reasoner[J]. Web Semantics Science Services & Agents on the World Wide Web, 2007, 5(2):51-53.
[36]尹晗.基于Web企業信息管理系統設計與實現[D].吉林大學,2013.
[37]魏娜.基于REST架構的Web服務的研究與實現[D].北京郵電大學,2011..
下一篇：沒有了
相關標簽:
