簡單都柏林核心集和著者著錄趨勢

吳政叡 (Cheng-Juei Wu)

輔仁大學圖書資訊系專任副教授

E-mail: lins1022@mails.fju.edu.tw

中文摘要

本文首先介紹都柏林核心集的最新發展情況,接著闡述自第一次研討會以來即確立的制定原則與重要特色,這些原則與特色正是都柏林核心集的靈魂,使其得以和其他元資料有所區分。再過來是15個基本欄位的逐一詳細介紹,此即是所謂的「簡單都柏林核心集」(Simple Dublin Core,不使用修飾詞的都柏林核心集),此部份的都柏林核心集自1997年3月的第四次研討會即已確立,目前已經在標準化的過程中。最後作者闡述「著者著錄」趨勢的興起背景,簡單都柏林核心集正是因為能緊扣著這個「著者著錄」的時代趨勢而日漸受到重視。

關鍵字:元資料,簡單都柏林核心集,MetadataSimple Dublin Core

一、前言

1990年代網際網路和WWW的結合,對資訊傳播的方式產生了重大的衝擊。網際網路是連結全世界的巨大網路,透過此網路資料得以日夜不息的在全世界流動。WWW則以其易寫作和方便連結文件的優點,在短時間內蔚為風潮,從全球性跨國公司到個人,莫不爭相建立自己的首頁,來善用這二十四小時不停的訊息傳播工具。因此網際網路和WWW的相互結合,大幅降低了資訊傳播的障礙,其所引發的效應之一,即是造成資訊量的激增。

資訊傳播障礙的移除,引發了二個看似迥異卻又相關的問題,一是如何來有效率的過濾資料,一是如何來有效率的描述資料。就前者而言,目前在使用 WWW 上的搜尋引擎來收集資料時,大家經常會面臨到的問題之一,是所得到的資料回覆量太多,經常可有上萬條款目,實無法一一來加以過濾,更糟的是,排在前面的款目,又往往不是你所真正需耍的,頗使人進退維谷,祇有瞎猜亂挑。很明顯的,我們需要更多的資訊,來從回覆的款目當中,挑選我們真正需要的資料,而這些資訊必須由資料提供者來提供,因此如何制定一套資料描述格式,來有效率的描述收藏的資料,成為一個重要的課題,這正是元資料(Metadata)日漸受到重視的原因。因此元資料是因應現代資料處理上的二大挑戰而興起的

(一) 電子檔案成為資料的主流。

(二) 網路上大量文件的管理和檢索需求。

都柏林核心集(Dublin Core)為備受矚目的元資料之一,是 1995 年 3 月由國際圖書館電腦中心(Online Computer Library Center,簡稱OCLC)和 National Center for Supercomputing Applications(NCSA)所聯合贊助的研討會,經過五十二位來自圖書館、電腦、網路方面的學者和專家共同研討下的產物。目的是希望建立一套描述網路上電子文件特色的方法,來協助資訊檢索。研討會的中心問題是--如何用一個簡單的元資料記錄來描述種類繁多的電子物件?[註 1] 主要的目標是發展一個簡單有彈性,且非圖書館專業人員也可輕易了解和使用的資料描述格式,來描述網路上的電子文件,所以都柏林核心集祇規範那些在大多數情況下,必須提及的資料特性。

自1997年10月6-8日在芬蘭的赫爾辛基舉行的第五次研討會後,都柏林核心集的最新發展情況為:[註2]

(一) 區分簡單和複雜兩種都柏林核心集格式簡言之,所謂簡單(simple)和複雜(complex)格式的區分,一般而言主要是以有無使用任何修飾詞作為標準來劃分的。由於都柏林核心集的15個基本項目已有共識,因此簡單都柏林核心集的標準化過程將會較早開始。

(二) 加快標準化的腳步由於都柏林核心集的15個基本項目架構,自第四次研討會以來已普遍獲得認同,同時都柏林核心集也得到世界各國很多研究者的肯定,並且嘗試建造系統,此時若無一定的標準來遵循,將使系統的建造者無所適從和系統的更改頻繁。因此基於都柏林核心集已趨成熟的共識,決定推派代表撰寫RFC的草案,呈交給 IETF進行標準化的過程。

(三) 語法上採用HTML和RDF格式為主HTML的格式目前是使用4.0版本,(含修飾詞的)寫法如下:[註3]

(1) <META NAME=DC.Subject

SCHEME=LCSH

LANG=EN

CONTENT=Computer Cataloging of Network Resources>

(2) <META NAME=DC.Date.Created

SCHEME=ISO8601

CONTENT=1998-03-05>

(四) 成立工作小組針對一些尚未有定論的議題,組成工作小組進行研討,主要有

(1) 內容或格式尚未有定論的基本項目,如Date、Relation、Rights Management等項目。

(2) 修飾詞。

(3) 特殊性議題,如都柏林核心集和Z39.50間的互換。

(五) 北歐元資料計畫是一個由北歐五國─挪威、瑞典、芬蘭、丹麥、冰島等學者共同合作的計畫,主要負責的研究者有Ole Husby(挪威)、Juha Hakala(芬蘭)、Traugott Koch(瑞典)、Anders Geertsen(丹麥)、Sigbergur Fridriksson(冰島)、Preben Hansen(瑞典)等,計畫期間是1996年10月到1998年3月,其合作組織是丹麥圖書館聯合中心。[註4]

(六) 丹麥政府決定自西元1997年起將所有政府的出版物上網,系統的主要規格之一,是採用都柏林核心集來描述文件和協助查詢。

(七) 荷蘭國家圖書館將發展一種新的全球資訊網服務,系統的主要做法是要在所有已蒐集的網頁中,加入都柏林核心集的資料,新的網頁將要求提供者先自行加入都柏林核心集的資料後再送呈,將來荷蘭國家圖書館的搜尋引擎會利用這些元資料來協助檢索。

(八) 英國的UKOLN正在推行一個名為BIBLINK的計劃,在出版社和國家書目中心間建立一條網路通訊管道,來直接交換書籍紀錄和資訊,這套系統是使用都柏林核心集作為其基本的格式。

(九) 澳洲的分散式系統技術中心(DSTC)正致力於推動一些與資訊管理和檢索相關的計畫,而分散式系統技術中心(DSTC)所推動的這一系列計畫,其中三個跟都柏林核心集最密切相關的計劃為TURNIP [註5]、HotOIL [註6]、MetaWeb [註7]。DSTC所推動的這一系列關於全球資訊存取(Global Information Access)的研究計畫,都是採用都柏林核心集做為描述資源的格式,因此是以都柏林核心集來協助使用者在WWW和網際網路上搜尋資料,並以都柏林核心集來和其他的檢索技術(如URN)、網路協定(如HTTP和Z39.50)等相結合,可以說是將都柏林核心集的檢索效用發揮的淋漓盡致。[註8]

綜觀以上的發展,顯示都柏林核心集已漸成熟和廣受肯定,以系統的實作而言,歐洲和澳洲可說是居於領先的地位,歐洲較注重都柏林核心集在圖書館相關服務上的應用,澳洲的DSTC則較偏重都柏林核心集在WWW相關服務上的應用。

本文首先介紹都柏林核心集自第一次研討會以來,即確立的制定原則與重要特色,這些原則與特色正是都柏林核心集的靈魂,使其得以和其他元資料有所區分。再過來是15個基本欄位的逐一介紹,此即是所謂的「簡單都柏林核心集」(Simple Dublin Core,不使用修飾詞的都柏林核心集),此部份的都柏林核心集自1997年3月的第四次研討會即已確立,目前已經在標準化的過程中。有關修飾詞的部份,請參考「都柏林核心集與元資料系統」一書。[註9]

二、重要特色與制定原則

都柏林核心集的設計原理,有意義明確、彈性、最小規模三種特色。在設計上所秉持的原則是:內在本質原則、易擴展原則、無必須項原則、可重覆原則、和可修飾原則。以下是這些原則的簡要敘述:[註10]

(一) 內在本質原則(Intrinsicality):祇描述跟作品內容和實體相關的特質,例如主題(subject)屬於作品的內在本質。但是收費和存取規定,則屬於作品的外在特質,原則上不屬於核心資料項,將透過其他機制來加以處理。

(二) 易擴展原則(Extensibility):應允許地區性資料以特定規範的方式出現,也應保持元資料日後易擴充的特性,以及保有向後相容的能力。

(三) 無必須項原則(Optionality):所有資料項都是可有可無的選擇項,以保持彈性和鼓勵各種專業人士參與製作。

(四) 可重覆原則(Repeatability):所有資料項均可重覆。

(五) 可修飾原則(Modifiability):資料項可用修飾詞(qualifier)來進一步修飾其意義。

現在針對以上各原則分析如下:[註11]

(一) 內在本質原則:因為著錄資訊全來自資料本身,並不須要再額外去找其他的參考來源,很顯然的可以大幅減輕著錄者的負擔,對各種專業人士來說,也是較可被接受的一種方式。

(二) 易擴展原則:此原則是為了適應全球網路的作業環境,因眾多的站台各有自己獨特的資料種類和需求,因此必須有適當的彈性。

(三) 無必須項原則:這可能使得某些人覺得非常驚異和不適應,傳統的圖書館著錄格式如 MARC,和其他的元資料格式,如 FGDC的地理元資料內容標準 [註 12]、GILS [註 13]、DIF [註 14]等,都有必須著錄項,如題名項和作者項等,主要不外乎是要維持一定的著錄品質。但為了鼓勵著錄,和強調有資料總比沒資料好的原則,都柏林核心集決定不硬性規定任何必須著錄項,作者頗認同此一原則。為了能適應各種非圖書館專業人員的背景和能力,必須著錄項若不能全部免除,也應盡量減少,以減輕著錄者的負擔。

(四) 可重覆原則:此原則進一步簡化許多著錄規則,如在此一原則下,將不區分作者的排名。傳統上為了決定第一作者或是題名,著錄規則中往往有很多的篇幅來規範。事實上,從檢索的角度來看,讀者何嘗在意一本書內的排名次序,眾多的題名,也可藉由電腦的輔助,輕易來加以檢索或處理,實無在著錄格式上,加以嚴格區分的必要。這些從卡片目錄時代為了排片需要所遺留下的產物,有必要加以檢討和去除。

(五) 可修飾原則:這原則使都柏林核心集非常有彈性,可同時滿足圖書館專業和非專業人員的需求。對於非專業人員來說,他們基本上不須要去查專業書籍來進行著錄的工作,這將大大減輕項目的著錄成本和時間。另一方面,對欲維持一定品質的專業人員而言,透過在附加修飾詞的方式,可明確指出所使用的資訊來自何處。作者非常贊同這個可同時兼顧專業和非專業人員的設計理念,由於未來圖書館勢必與全球網路的資訊傳播系統緊密結合,成為全球網路資訊系統的一份子,自不可能採用獨特的資料描述格式,所以一套能同時兼顧各種專業人員的資料描述格式,將是時勢所趨。

三、基本欄位

本節主要是介紹都柏林核心集的15個基本欄位,不包括修飾詞的介紹,此即是所謂的「簡單都柏林核心集」(Simple Dublin Core)。根據1997年10月公布的資料著錄項目 [註15],和簡單都柏林核心集使用指引,逐一介紹15個基本欄位如下:(以下範例以HTML格式呈現)

(一) 主題和關鍵詞(Subject):作品的主題和關鍵字(詞)。

著錄要點:鼓勵使用控制語彙,並以架構修飾詞(scheme)註明出處,如 LCSH(美國國會圖書館主題標題表)。圖書館使用的分類號如杜威十進分類號(Dewey Decimal Number)等亦置於此欄位。避免使用太過於一般化的字(詞),可從欄位題名(Title)和簡述(Description)中尋找適當的字(詞)。若關鍵詞是人或機構名稱,則以不重複在其他欄位如著者(Creator)等已出現的字詞為原則。

例子:<META NAME=DC.Subject CONTENT=都柏林核心集>。

(二) 題名(Title):作品名稱。

著錄要點:如果有數個可能的名稱可選擇,則以重覆欄位的方式來逐一著錄。如果著錄的對象為HTML文件,則應將<HEAD></HEAD>中<TITLE></TITLE>的字串收入此欄位。

例子:<META NAME=DC.Title CONTENT=都柏林核心集與元資料系統>。

(三) 著者(Creator):作品的創作者或組織。

著錄要點:如果有數個著者,則盡量以重覆欄位的方式來逐一著錄。著錄時以姓先名後的方式填寫。若是機構名稱的全名,則在可截斷處切割,並以由大到小排列方式,排列時以實心小黑點或句點為分割符號。

例子:<META NAME=DC.Creator CONTENT=吳政叡>。

例子:<META NAME=DC.Creator CONTENT=Abeyta, Carolyn>。

例子:<META NAME=DC.Creator CONTENT=中華民國。外交部>。

例子:<META NAME=DC.Creator CONTENT=United States. White House>。

(四) 簡述(Description):文件的摘要或影像資源的內容敘述。

著錄要點:盡量簡短,濃縮成數個句子。

(五) 出版者(Publisher):負責發行作品的組織。

著錄要點:若是人或機構名稱與著者欄位重複,則不再著錄。其餘著錄要點參考著者欄位。

例子:<META NAME=DC.Publisher CONTENT=漢美出版社>。

(六) 其他參與者(Contributors):除了著者外,對作品創作有貢獻的其他相關人士或組織。〔註: 如書中插圖的製作者。〕

著錄要點:參考著者欄位。

(七) 出版日期(Date):作品公開發表的日期。

著錄要點:建議使用如下格式 YYYY-MM-DD和參考下列網址:http://www.w3.org/TR/NOTE-datetime。在此網頁中共規範有六種格式,都是根據國際標準日期暨時間格式 ISO(國際標準組織)8601制定而成,是ISO 8601的子集合(subset),現在列舉和解說如下以供參考:[註 16]

(1) Year(年)-- YYYY。

例子:<META NAME=DC.Date CONTENT=1997>(西元1997年)。

(2) Year and Month(年、月)-- YYYY-MM。

例子:<META NAME=DC.Date CONTENT=1997-09>(西元1997年9月)。

(3) Complete date(完整日期)-- YYYY-MM-DD。

例子:<META NAME=DC.Date CONTENT=1997-09-07>(西元1997年9月7日)。

(4) Complete date plus hours and minutes(完整日期加時、分)-- YYYY-MM-DDThh:mmTZD

〔註:T用來隔開日期和時間,TZD表示本地時間和國際格林威治時間的差距(時間差)。〕

例子:<META NAME=DC.Date CONTENT=1997-09-07T19:05+08:00(西元1997年9月7日台灣下午7點5分,而台灣所屬的中原標準時區與國際格林威治時間差8小時)。

(5) Complete date plus hours, minutes, and seconds(完整日期加時、分、秒)-- YYYY-MM-DDThh:mm:ssTZD

例子:<META NAME=DC.Date CONTENT=1997-09-07T19:05:25+08:00>(西元1997年9月7日台灣下午7點5分25秒)。

(6) Complete date plus hours, minutes, and seconds(完整日期加時、分、秒)-- YYYY-MM-DDThh:mm:ss.sTZD

例子:<META NAME=DC.Date CONTENT=1997-09-07T19:05:25.25+08:00>(西元1997年9月7日台灣下午7點5分25又1/4秒)。

(八) 資源類型(Type):作品的類型或所屬的抽象範疇,例如網頁、小說、詩、技術報告、字典等。

著錄要點:建議參考下列網址 http://sunsite.berkeley.edu/Metadata/types.html。在上述網頁中將作品的類型粗分成以下數種,現在列舉和解說如下:[註 17]

(1) Text(文字)-- 作品的內容主要是文字(可夾帶影像、地圖、表格等),例如書籍、文集、技術報告、小冊子等。

例子:<META NAME=DC.Type CONTENT=Text>。

(2) Image(影像)-- 相片、圖形、動畫、影片等。

(3) Sound(聲音)-- 各式各樣的聲音,例如演講、音樂等。

(4) Software(軟體)-- 可執行的程式(二進制檔)和程式的原始檔,但不包括各種互動式應用程式。

(5) Data(資料)-- 各種文字或數據資料的集合體,例如地理資料、書目記錄、統計數據、遙測資料等。

(6) Interactive(互動式應用)-- 設計給一個或多個使用者的互動式應用,例如遊戲軟體、線上聊天服務、虛擬實境等。

(7) Physical Object(實物)-- 三度空間的實物,例如人、汽車等。

(8) Compound/Mixed(混合型態)--含數種不同種類。

以上的六種類型又以第一種類型(Text)最為繁複,可再細分如下:

(1) Abstract(摘要)-- 其他文件的簡要敘述。

例子:<META NAME=DC.type CONTENT=Text.Abstract>。

(2) Advertisement(廣告)-- 如徵人啟事。

(3) Article(論文)。

(4) Correspondence(書信)-- 可再細分為討論、電子郵件、信件、明信片四類。

例子:<META NAME=DC.Type CONTENT = Text.Correpondence.Email>。

(5) Dictionary(字典)。

(6) Form(表格)。

(7) Homepage(WWW首頁)。

(8) Index(索引)。

(9) Manuscript(手稿)。

(10) Minutes(會議紀錄)。

(11) Monograph(專論) -- 如書籍。

(12) Pamphlet(小冊子)。

(13) Poem(詩)。

(14) Proceedings(會議論文集)。

(15) Promotion(促銷文件)。

(16) Serial(連續性出版品) -- 可再細分為期刊、雜誌、報紙、時事通訊四類。

(17) TechReport(技術報告)。

(18) Thesis(學位論文) -- 可再細分為碩士、博士二類。

例子:<META NAME=DC.Type CONTENT=Text.Dictionary>。

例子:<META NAME=DC.Type CONTENT=文字.技術報告>。

(九) 資料格式(Format):主要用途是告知檢索者在使用此作品時,所須的電腦軟體和硬體設備。

著錄要點: 例如text/html、ASCII、Postscript(一種印表機通用格式)、可執行程式、JPEG(一種通用圖像格式),建議使用MIME格式的表示法,有關MIME格式的詳細資訊,請參考RFC 1521。亦可擴展至非電子文件,例如book(書本)、叢書、期刊。必要時亦可將檔案大小、圖形解析度、實體尺寸等資料納入。

例子:<META NAME=DC.Format CONTENT=text/html>。

例子:<META NAME=DC.Format CONTENT=image/gif 640 x 480>。

例子:<META NAME=DC.Format CONTENT=叢書>。

(十) 資源識別代號(Identifier):字串或號碼可用來唯一標示此作品,例如URN、URL、ISSN、ISBN等。

著錄要點:系統代碼或內部識別號亦可置於此欄位。

例子:<META NAME=DC.Identifier CONTENT= http://www.blm.gov/gis/meta/barney/tut_met1.html>。

(十一) 關連(Relation):與其他作品(不同內容範疇)的關連,或所屬的系列和檔案庫。

著錄要點:請參考關連工作小組的草案報告,網址是http://purl.oclc.org/metadata/dublin_core/wrelationdraft.html。[註18]

例子:<META NAME=DC.Relation CONTENT= http://www.blm.gov/>。

(十二) 來源(Source):作品的衍生來源。

著錄要點:作品從何處衍生而來(同內容範疇),例如莎士比亞的某個電子書出自那個紙本。

(十三) 語言(Language):作品本身所使用的語言。

著錄要點:建議遵循 RFC 1766 的規定,請參考下列網址:http://ds.internic.net/rfc/rfc1766.txt,RFC 1766 是使用 ISO 639的二個字母的語言代碼。[註 19]

例子:<META NAME=DC.Language CONTENT=en> 。(English)[註 20]

(十四) 涵蓋時空(Coverage):作品所涵蓋的時期和地理區域。

著錄要點:請參考涵蓋時空工作小組的草案報告,網址是http://www.alexandria.ucsb.edu/docs/metadata/dc_coverage.html。[註21]

(十五) 版權規範(Rights):作品版權聲明和使用規範。

著錄要點:可能值如下:[註22]

(1) 空白(Null):無特別聲明,使用者須自行參考其他來源。

(2) 無限制(No Restriction on Reuse):可複製再傳播。

(3) 參考處(URI or Other Pointer):使用的相關說明,在所指定的出處。

例子:<META NAME=DC.Rights CONTENT=無限制>。

結語

1990年代在資訊的處理和檢索相關領域中,幾個最耀眼的名詞是:網際網路(Internet)、全球資訊網(World-Wide Web)、搜尋引擎(Search Engine)、國家資訊基礎建設(National Information Infrastructure)、電子圖書館(Digital Library)、元資料(metadata)。網際網路是自1969年以來連結全世界的一個大網路,全球資訊網是1990年代初誕生的一種建基於網際網路上的加值型服務,全球資訊網的主要貢獻,是將網際網路從學術界帶入一般人的日常生活中,而搜尋引擎則是因應全球資訊網網頁檢索需求的一種檢索工具。在未來的發展上,國家資訊基礎建設將成為網際網路的後繼者,電子圖書館將逐漸取代傳統圖書館所扮演的角色,成為一個資訊處理和提供的統合中心,而元資料將在未來的電子圖書館中,扮演如同目錄在傳統圖書館中的角色,提供處理和檢索電子資料所需的必要資訊。

再從資訊傳播方式的角度來看,網際網路和WWW盛行前,圖書館可以說是主要的媒介者,來溝通資料提供者(如出版社)和資料使用者(如個人),所以圖書館扮演了資料儲存和傳播者的主要角色。如今網際網路和WWW提供了一條直接的管道,使資料提供者和資料使用者可以直接接觸,毋須透過圖書館來作為媒介者。這固然降低了資訊傳播的障礙(少了一個中介機構),但另一方面,資料提供者如今必須自己擔負起圖書館所提供的一些功能,其中之一是對所擁有的資料加以描述(著錄)。

但是圖書館所發展出來的資料描述格式,雖然完整和嚴謹,但卻較適合圖書館專業人員使用,對大多數的非圖書館專業人員而言,是過於繁瑣和不易學習的。都柏林核心集(Dublin Core)即是在這一背景下興起的產物,試圖提供一套簡易的資料描述格式,來滿足大多數非圖書館專業人員的需求,以符合「著者著錄」趨勢的需要 [註23],簡單都柏林核心集正是因為能緊扣著這個「著者著錄」的時代趨勢而日漸受到重視。

註釋

註 1:吳政叡,「三個元資料格式的比較分析」,中國圖書館學會會報 57 期(民 85 年 12 月),頁39。

註 2:B. Rajapatirana, The 5th Dublin Core Metadata Workshop: a report and observations, 2 Dec. 1997, <http://www.nla.gov.au/nla/staffpaper/helsinki.html>.

註 3:吳政叡,「元資料實驗系統和都柏林核心集的發展趨勢」,國立中央圖書館臺灣分館館刊 4 卷 2 期(民 86 年 12 月),頁17-18。

註 4:吳政叡,都柏林核心集與元資料系統,(台北市:漢美,民國 87 年5 月),頁107-119。

註 5:R. Iannella and H. Sue, Basic URN Service (BURNS), <http://www.dstc.edu.au/RDU/TURNIP/burns.html>, p. 3.

註 6:N. Ward, HOTOIL, <http://www.dstc.edu.au/BDU/APAP/HotOIL/HotOIL.html>, (26 Jan. 1998).

註 7:D. Campbell, The MetaWeb Project, 22 January 1998, <http://www.dstc.edu.au/RDU/MetaWeb/ >.

註 8:同註4,頁120-130。

註 9:同註4。

註10:同註1,頁39-40。

註11:吳政叡,「從都柏林核心集看未來資料描述格式的發展趨勢」,圖書館學刊 26期(民86年5月,頁16-17。

註12:同註10,頁38。

註13:吳政叡,政府資訊指引服務國立中央圖書館臺灣分館館刊 3 4 期(民 86 6 月)頁18

註14:吳政叡,目錄交換格式台北市圖書館館訊 14 3 期(民 86 3 月)頁52

註15:S. Weibel and E. Miller, Dublin Core Metadata Element Set: Reference Description, 2 Oct. 1997, <http://purl.oclc.org/metadata/dublin_core_elements>.

註16:M. Wolf and C. Wicksteed, Date and Time Formats, 15 Sept. 1997, < http://www.w3.org/TR/NOTE-datetime>。

註17:R. Tennant, Dublin Core Resource Types, 23 Sept. 1997, < http://sunsite.berkeley.edu/Metadata/minimalist.html>.

註18:D. Bearman et. al, Relations Working Group, <http://purl.oclc.org/metadata/dublin_core/wrelationdraft.html >, (20 Sept. 1998).

註19:H. T. Alvestrand, Tags for the Identification of language, March 1995, < http://ds.internic.net/rfc/rfc1766.txt>, p. 2.

註20: Guide to Creating Core Descriptive Metadata, 13 April 1996, < http://www.ckm.ucsf.edu/people/jak/meta/mguide3.html>, p. 7.

註21:M. Larsgaard, et. al, DUBLIN CORE ELEMENT: COVERAGE, 30 Sept. 1997, < http://www.alexandria.ucsb.edu/docs/metadata/dc_coverage.html >.

註22:S. Weibel and E. Miller, Image Description on the Internet: A Summary of the CNI/OCLC Image Metadata Workshop, D-Lib Magazine (Jan. 1997), <http://www.dlib.org/dlib/january97/oclc/01weibel.html>, p. 5.

註23:同註1,頁40。