首頁‎ > ‎電子期刊‎ > ‎Semantic MediaWiki‎ > ‎

再談Semantic MediaWiki(上)

作者:張騉翔

前言

Semantic MediaWiki簡介(上)Semantic MediaWiki簡介(下)這兩篇文章我們為讀者介紹了Semantic Web的觀念,以及Semantic MediaWiki這個MediaWiki的延伸套件,並舉個實際的例子如何加入Semantic MediaWiki中Ontology的語法。

在本文中我們會繼續深入探討Semantic MediaWiki的各項設計,以求讓讀者能完全掌握Semantic MediaWiki的架構。

離清Semantic MediaWiki語法

Semantic Wiki導入了Attribute及Relation的用法,再加上原本Wiki的分類工具有Category、Namespace、Subpage組成強大的知識管理工具,開始接觸時卻也容易混淆用法,我們再以表格離清這些意義:

語法 意義
Subpage
  1. 頁面資料量過大時,可分成許多的Subpage;意義上仍同屬於同個頁面,需視各個Namespace來啟用Subpage的功能,Subpage與一般的頁面並無差異,只是在Subpage中會自動加入上一層文章的連結。
  2. 需特別注意當上層文章改名時Subpage並不會自動重新命名,例如頁面[[連絡人]]有個Subpage[[連絡人/王小明]],在連絡人頁面用移動的功能重新命名為[[通訊錄]],此時[[連絡人/王小明]]並不會自動更名為[[通訊錄/王小明]]。
  3. 運用Subpage分類的意義為樹狀分類,而用Category是屬於網狀分類。
  4. Subpage較多的應用可以參考Wikibooks,其中一個範例為Airplane Modeling
Category
  1. Category可用來將文章進行分類或是標籤,分類後可視為某個領域的特定觀念,例如[[王小明]]與[[王爸爸]]都可分類至[[Category:人類]]這個頁面。
  2. Category亦可視為編輯者主觀性之分類,例如將[[王爸爸]]分類到[[Category:小朋友]]這個頁面。
Namespace
  1. 消極的意義可用來避免相同名稱的文章,但意義上卻不同,例如每個學校都會有教務處、總務處的頁面,為了避免重複,可以在頁面前加上Namespace以做區隔,例如[[台大:教務處]]、[[交大:教務處]]。
  2. 積極的意義將大量具有相同性質的文章放置到相同的Namespace當中,例如所有MediaWiki:開頭的文章都同屬於 MediaWiki的Namespace之下,用來管理MediaWiki軟體相關的設定;或是MediaWiki網站的註冊使用者,都會有User:開 頭的個人頁面,同屬於User的Namespace。
  3. Namespace亦可視為文章的預設分類(Default Category)。
Attribute
  1. Attribute可視為文章的關鍵字,但這樣的關鍵字份量不足以形成一篇文章;關鍵字為Attribute的值,再加上欄位名稱分類,就容易在多個文章間查詢。
  2. Attribute的運用範圍相當廣,如連絡人屬性、組織屬性…等。
Relation
  1. Relation的概念為Category for links,亦即將內部連結進行分類,將Category與Link的概念結合使用;目前Relation還不支援外部連結。
  2. 單以Link的概念來看,無法將連結進行分類;例如王爸爸頁面連結到王媽媽頁面與連結到王小明的頁面具有不同的意涵。
  3. 單以Category的概念來看,將王爸爸與王小明歸於父子關係的Category,雖然可以表達出父子關係的意涵,可是卻無法表達出誰是父親、誰是孩子。

Semantic Search

Semantic Search基本用法

用不同的方式組織資訊會有不同的好處;用Excel組織的好處是容易做統計、用Word組織的好處是容易排版及列印、用Wiki組織的好處是易於分 享;而用Semantic Wiki組織的主要好處之一是加上Attribute、Relation、Category的標記後可以很方便的搜尋。

在Semantic MediaWiki中的Semantic Search運用原本的Semantic Wiki語法來查詢;下面的語法會將頁面分類為同事的查詢出來:

 
 [[Category:同事]]

查詢分類為同事,並且與王小明為父子關係的頁面:

 
 [[Category:同事]][[父子關係::王小明]]

查詢分類為同事,與王小明為父子關係,並且手機號碼為12345的頁面:

 
 [[Category:同事]][[父子關係::王小明]][[手機:=12345]] 

要下查詢條件有兩種方式,第一種是在Special Pages下Semantic Search:

另一種方式是直接在頁面裡嵌入查詢語法:

 
 <ask>[[Category:同事]]</ask>

在Semantic MediaWiki 0.6版還有Simple Semantic Search的介面,不過在0.7版就消失了,建議讀者在查詢時以下查詢語法為主,介面為輔;因Semantic MediaWiki目前還在發展中,可能在每個版本都會有大幅變動。瞭解語法是最基本也能應用最廣泛及深入。


Semantic Search範例

語法 說明
[[手機:=+]] 查詢所有有手機屬性的頁面,其中+為特殊符號,代表所有頁面。
[[父子關係::+]] 查詢所有有父子關係的頁面。
[[Category:+]] 查詢所有有分類的頁面。
[[User:+]] 查詢User這個Namespace下所有的頁面。
[[Category:同事]] 查詢分類為同事的頁面,若是同事下有子分類,會循環將子分類下的頁面也查詢出來。
[[王爸爸||王小明]] 查詢出特定頁面,其中雙直線代表的意思,將頁面為王爸爸或王小明的頁面查詢出來。
[[Category:同事||親人]] 查詢分類為同事或是親人的頁面。

上述為查詢的條件,會以頁面名稱條列的方式呈現:


我們可以加入一些語法,讓顯示的結果是否要出現頁面的屬性、分類及關係:

 
[[Category:王家庭]][[生日:=*]][[Category:*]][[父子關係::*]]

我們也可以運用分隔符號 | 來決定顯示的欄位名稱:

 
[[Category:王家庭]][[生日:=*|出生年]][[Category:*|分類]][[父子關係::*|兒子]]

Semantic DataType

在Semantic MediaWiki的每個屬性都要被宣告為適當的型態才可以使用;Semantic MediaWiki支援許多的資料型態,也可以自行定義新的資料型態;有了完整的Semantic DataType有幾個優點:

  1. 在儲存資料時用更有結構化的方式儲存,Semantic MediaWiki可以將匯出成Semantic Web標準格式RDF;可與其它系統進行整合。
  2. 有了Semantic DataType可以讓不同的型態有不同的顯示方式,最常用到的例子就是日期。
  3. Semantic DataType可以做簡單的邏輯比對加強Semantic Search的功能。

以下以表格的方式來說明Semantic DataType:

型態 說明
Type:Integer 整數型資料型態
Type:Float 浮點數型資料型態
Type:String 文字資料型態
Type:Enumeration 列舉資料型態,在Attribute裡加入以下的列舉值語法,那麼在使用該Attribute時只能出現列舉值:
 [[allows value:=列舉值一]]
[[allows value:=列舉值二]]
[[allows value:=列舉值三]]

Type:Date 日期的格式為YYYY-MM-DD HH:MM:SS,舉例1999-05-23 08:55:22。
Type:Geographic coordinate 用來表達經緯度,範例為52°31'N; 13°24'E。
Type:Temperature 氣溫型態,共有K, kelvin, kelvins、°C,Celsius, centigrade、°F, Fahrenheit三種表達方式,範例如下:
  [[temperature:=100 kelvin]]  
[[temperature:=100 Fahrenheit]]
[[temperature:=100 Celsius]]

Type:Email 電子郵件資料型態,在輸出時Semantic MediaWiki會將電子郵件轉為HTML的mailto語法。
Type:URI URI代表某個概念的識別位置,例如Wikipedia的識別位置為http://www.wikipedia.org
Type:URL 與URI不同的地方在於URL只是單純用將識別位置用字串的方式用文字來儲存,並無對應到任何的概念。
Type:Annotation URI Annotation URI是個特別的型態,用來表達一個頁面的註解,最常使用到的就是See also這個屬性。


Comments