詮釋資料的互通形式

不 同 的 詮 釋 資 料 結 構 (Metadata Schema) 可 用 兩 種 方 式 達 到 互 通 的 效 果 (Caplan, 2003)：

1. 利用欄位對照(Crosswalk)的方式；

2. 採用對映方式(Authoritative Mapping)讓詮釋資料能彼此相對映。

美國國會圖書館利用 Dublin Core 來對 MARC 做對映的工作見圖 2- 10，在 圖 2- 10 中可以看到無修飾詞都柏林核心集(Unqualified Dublin Core)的貢獻者 (Contributor)欄位是對應到 MARC 的 720 段。

圖 2- 10 美國國會圖書館利用 Dublin Core 來對 MARC 做對映的工作

資料來源：Network Development and MARC Standards Office(Library of Congress) . (2001, May).

Dublin Core/MARC/GILS Crosswalk. Retrieved December 23, 2003, from http://lcweb.loc.gov/marc/dccross.html

(一) 欄位對照(Crosswalks)

對照(Crosswalks)最主要的用途在於讓不同的資料格式在進行資料交換時做 對照，以至於可以應用在聯合目錄與擷取詮釋資料。然而實作起來是非常困難 的，因為並沒有一展現詮釋資料規格(Metadata Schemes)的標準機制。

王麗蕉（2000）國際上關於多種詮釋資料間的對映與轉換的研究計畫也已進 行多時且頗具成效，舉例說明如下見表 2- 6：

Contributor

An entity responsible for making contributions to the content of the resource.

MARC 21：

Unqualified：

• 720 ##$a (Added Entry--Uncontrolled Name/Name) with $e=collaborator (or other term used as value of role qualifier)

Qualified：

• Personal: 700 1#$a (Added Entry--Personal Name) with $e=collaborator

• Corporate: 710 2#$a (Added Entry--Corporate Name) with $e=collaborator

• Conference: 711 2#$a (Added Entry--Conference Name) with $e=collaborator

• Role: 720 ##$e (Added Entry--Uncontrolled Name/Relator term

• Role (Personal): 700 1#$e (Added Entry--Personal Name/Relator term)

• Role (Corporate): 710 2$e (Added Entry--Corporate Name/Relator term)

Note： The above qualifiers have not been approved by DCMI.

GILS：

• Contributor

表 2- 6 多種詮釋資料間對映的相關研究計畫

Dublin Core/MARC/GILS 的對照 - 由美國國會圖書館網路與 MARC 標準辦公室 發展；

- 產生以下項目之間的對照表：

y DC 的 15 項要素；

y MARC21 的書目資料項；

y GILS 屬性之間的語意互通。

GILS 與 USMARC 的對照 - 是 GILS 核心項目與 USMARC 的對映。

Dublin Core 與

EAD/GILS/USMARC的對照

- 為 Monticello 數位書館計畫高層次資料庫設計 的基礎；

- 藉由 DC 核心元素的運用，提供多種數位媒體 與記錄類型的資料庫間語意互通；

- 產生的對照表是 DC 與 EAD/GILS/USMARC 間高層次語意的定義。

資料來源：王麗蕉（2000）。檔案資訊描述標準 MARC AMC 與 EAD 之比較與格式對映研究。未 出版之碩士論文，國立政治大學圖書資訊學研究所，台北市。

也因為所有的詮釋資料都有自己專指的欄位屬性，要對照就要完成以下幾項 處理，如欄位是否必備、可否重複等，相關的處理簡述如下(Pierre , 1998)：

1. 一對多(One to Many)：這種情況是很少見的，但一發生時就需要相當的智 慧，如在服務系統端的關鍵字欄位是不可重覆，但在各資料庫系統端卻是可 重覆的，如 GILS 的「Contact Name」如果要與 DIF(Directory Interchange Format)對照就要對到兩個欄位：「First Name」和「Last Name」；

2. 多對一(Many to One)：較難處理的就是要應該如何展現和附註說明；

3. 服務系統所沒有的欄位(Extra Element in Source)：即服務系統與各資料庫系 統間完全無法對應時，這時要增加新的欄位，且要有說明；

4. 各資料庫系統間未分析是否未必備(Unresolved Mandatory in Target)：在各資 料庫系統的欄位為必備時，在服務系統卻不是時，有以下幾點要解決：

(1) 階層(Hierarchy)：如 USMARC 和 GILS 與 SDSM(Survey Design and Statistical Methodology)與 FGDC。

(2) 單一或多種描述物件的觀點(Single versus Multiple Objects)：如 SDSM

時採用多種觀點，所以對於描述物件的欄位，會比其他詮釋資料要多。

(3) 邏輯觀點(Logical Views)：即為只要處理得當，其詮釋資料可以因為使 用對象的不同，進而提供不同的資料予以使用。

而使用對照的困難在於：

1. 將服務系統(Source)和各資料庫系統(Target)的詮釋資料架構對映至一共通 的格式，以使二者的資訊組織屬性是相似的；

2. 接著是必需詳細說明二者間有些詮釋資料的對應欄位如：一對多或多對一的 情形，是如何使一致的，乃至於著錄格式的方式都需要注意(如英文人名的 著錄方式及是否有權威控制)；

3. 然而語意的問題是最難以處理的，例如在出現 DC 時 MARC 並沒有欄位與 之相對照，如其他作者(Contributor)；而 MARC 根據 AACR2 而有的主要款 目(Main Entry)及附加款目(Added Entries)是沒有出現在 DC 裡的。

想要達到整合檢索的境界，就要建立一個對照表(Map)，讓各個系統可以參 照，以使得可區分彼此的不同，甚而達到互通；對照可以讓使用者在一環境下瀏 覽來自各資料庫系統間的資料。

但即使如此，仍沒有必要一定要有制式的規範。因為沒有一定的規範所以整 合詮釋資料的工作就有點像是轉譯(Translating)；而對照就是擔任這翻譯的工 作，然就像語言的翻譯一樣，所以對照也是會有一些漏洞，Caplan(2003)指出產 生這些漏洞的情形，有以下三種：

1. 系統間概念的不一致會造成移轉時的問題；

2. 只有一些通用的欄位可以自在地轉移；

3. 並不是每個系統間的概念都可以轉換到其他系統。

於是在管理與維護詮釋資料的時間最好是不要太多，而且比較好的方式是可 以透過一個標準的詮釋資料，就可以知道其他相關領域的詮釋資料內容，要達到 這個境界，就要對各種詮釋資料做整合(Harmonization) ，使其能互通；以下介 紹各資料庫系統間的資訊組織模式在整合與對照時，要注意的事項：

(二) 整合(Harmonization)

雖然有許多要注意的地方，但整合仍不失為一個好方法；而要做整合的第一 步為擷取詮釋資料中的專門用語、屬性、組織及處理方式以建立一可發展、修正 現行的詮釋資料。這個過程不會很艱辛但有些面向要注意(Pierre , 1998)：

1. 專門用語(Terminology)：要有共通的專門用語，整合才得以確實實現；其困

難處在於要建置一相同的詮釋資料，就必須要對各自詮釋資料在整合時有一 共同規範，因此有一可遵循的詞彙表述是很有助益的；

2. 屬性(Properties)：很多詮釋資料都用相同的欄位來描述，因此當對照時要注 意詮釋資料的屬性有：

(1) 每個元素(Metadata Element)的唯一識別號，如識別號、欄位名稱；

(2) 每個元素的語意定義；

(3) 在某些情況下，元素會呈現的諸如：是否可重複、是否為必備等；

(4) 元素是否會多次(Multiple Times)的出現；

(5) 元素間彼次是以階層式的關係做意義相連；

(6) 元素是有預設值的(如是填數字類型、日期、控制詞彙等)：

(7) 有些元素是可以自行定義合乎所需的。

3. 組織(Organization)：對照時通常會遇到的麻煩是因為詮釋資料是由各個不同 的組織所設計，而要增進效益；因此要找主題相近的詮釋資料來做對照，使 即使是對照處理過的，仍有其專指的特性；

4. 處理過程(Process)：利用同主題性的詮釋資料作對照，也助於整合的品質；

5. 語意對映(Semantic Mapping)：語意對映是智慧的結晶，因為需要對每個標 準的屬性有一明確和精確的定義是不容易的。

透過以上的處理，當然最希望的就是可以有一機制是可以自動來對照，而這 就目前的資訊技術來說不難，因為可以使用 XML DTD 的機制，讓服務系統與各 資料庫系統間有一自動轉換彼此 DTD 的方式。

不過雖然技術有了，語意的互通仍是個相當棘手的問題，因此有一可以管理 權威、廣泛詮釋資料的單位是不錯的。該單位可以負責來自不同系統的定義、架 構；當然也要有一機制來做對映的工作，而 ISO11179 就是這方面的標準。以下 敘述詮釋資料註冊處(Metadata Registries)是如何扮演其角色的：

(三) 詮釋資料註冊處(Metadata Registries)

詮 釋 資 料 註 冊 處 是 一 個 用 來 記 錄 來 自 不 同 資 料 內 容 的 詮 釋 資 料 元 素 (Metadata Element)的權威資訊(Authoritative Information)。

藉由記錄其名稱、定義和詮釋資料元素的屬性，詮釋資料註冊處讓詮釋資料 元素在辨識、再使用性(Reusability)與互通性更便利。另外隨著愈來愈多種型式 的詮釋資料出現，詮釋資料註冊處也成為另一種管理資料的工具。

目前開發詮釋資料註冊處的組織大都是遵循 ISO/IEC 11179 這標準的，此標

旨就是希望能藉由一高階的資訊組織模式讓所有各資料庫系統的資訊組織模式 能有一統一(Consistent Fashion)的對映樣式，以使得基本元素(Elements)能被辨 識、瞭解與再利用(Reuse)。以下簡述二個實作計畫：

1. ROADS(Resource Organization And Discovery in Subject-based services)：是英 國 JISC(Joint Information Systems Committee)的 eLib (Electronic Libraries)計 畫；此計畫提供一軟體使參與的單位可以遵循標準的範本來對詮釋資料記錄 做 一 主 題 的 規 範 設 定 ， 此 範 本 所 界 定 類 型 有 公 文 (Documents) 、 影 像 (Images)、聲音(Sounds)、收藏品(Collections)和其他資料類型。

然而 ROADS 詮釋資料註冊處的機制，就只是範本的清單與其所涵括的 基本元素，並不像 ISO/IEC 11179 裡所規範的登錄機制，因為 ROADS 不但 沒有可供檢索的元素名稱，也沒有可與其他不同資訊組織模式相呼應的元 素；

2. DCMI(Dublin Core Metadata Initiative)：是詮釋資料註冊處的組織，此組織所 研發的一個工具最為人所知：詞彙管理系統(Vocabulary Management System) 和註冊系統(Registry)。

一個完全專指性的對照，是可以提供與維護一組詮釋資料，進而提供一對映 方式，使具有主題相關性的詮釋資料，有一對照依據，對照可以讓各種詮釋資料 間彼此相溝通，然而卻無法更進一步對知識加值，因為每個領域的詮釋資料都有 其獨特性、專指性及處理方法，甚而在維護對照的品質上也是難上加難。

不過仍可由上述得知各種詮釋資料對映的最終目的即在於可跨詮釋資料的 語意架構執行各資料庫系統的整合檢索，以滿足使用者的資訊需求。

第六節 綜合討論

對使用者而言，互通的數位圖書館代表了彼此間能夠透通地溝通以及分享資 料，為此 Arm(2000)指出各資料庫系統間要達到互通的需求涵蓋三個層面如下所 述，才能使各資料庫系統間能達上述的功能以滿足使用者的資訊需求：

1. 技術層面(Technical Agreements)：包含資料的格式(Format)、協定(Protocol) 和安全系統(Security System)，是使資料能夠相互流通的機制；

2. 內容層面(Content Agreements)：包含資料與詮釋資料，以及其語意(Semantic) 上的協議，為使流通的資訊能夠被解讀的機制；

3. 組織層面(Organizational Agreements)：包含資料存取權限、付費、認證機制 等等。

另外 Warnick(2001)指出美國國家科學基金會(National Science Foundation)認 為互通模式可以區分成三個型態見表 2- 7(轉引自徐代昕，2003；余顯強，2003)：

表 2- 7 各資料庫系統的互通模式

聯盟(Federation) 收集(Gathering) 擷取(Harvesting) 內涵 最傳統的互通模式；指所 crawler 來收集其公開存取 的資訊，如網路搜尋引擎。 (application-independent)可以互通的架構，其運作流程如下圖 2- 1211 與圖 2- 12：

圖 2- 11 OAI-PMH 的運作流程圖(I)

資 料 來 源 ： Main Technical Ideas of OAI-PMH. (2003, Oct). Retrieved Jan 18, 2004, from http://www.oaforum.org/tutorial/english/page3.htm

服務