文章分類 ‘觀察室歷史文章’

資料與知識

星期二, 一月 8th, 2008

內容發展分項計畫 / 曾鈺絜

  數位典藏在過去五年的不斷努力之下,已累積許多寶貴的經驗與豐富的數位內容,如何將這些片段資訊串連成更具結構的知識,是第二期數位典藏的首要任務,預計會以「主題式知識庫」來表現台灣特色,並嘗試加入Web 2.0的共建、共享精神,使其數位內容更加完整。

  然而在現今資訊爆炸的網路時代,經由網際網路找尋知識已相當普及,只是在這訊息的銀河,何謂知識庫?不外乎是將內容經過篩選過濾,然後匯集而成。知識庫並不限定任何領域,皆能擁有其專有的知識庫,小至一般的FAQ,大至整個電子圖書館藏,主要功能就是協助解決問題,讓以往前人的經驗能夠繼續傳承。

  資料檢索與知識檢索看似相同,但實質卻相異的不同個體,這之間的差異有待更精確的探討,如圖一所示。數位典藏國家型科技計畫在一期的重點產出之一,聯合目錄公共展示系統,它的資訊檢索功能已經不能滿足我們的需求,然而在二期計畫的知識庫,我們期待它能在知識層級裡有更明確的組織分類,加強精確性及個人化,並提供更具有價值性的輸出。

                       圖一、檢索層次圖

…詳全文

搭上Web2.0便車? (文/林芳志)

星期一, 一月 7th, 2008

        前陣子參加了「台灣多樣性知識網工作坊」,提到建置知識庫,讓人第一時間想起目前堪稱規模最大的「共筆知識庫」-維基百科(Wikipedia),以及如火如荼進行中的「生命大百科」(Encyclopedia of Life)。第一次接觸到所謂的「生命大百科」,很驚訝於這個計畫大刀闊斧的程度,也為他們宏觀的視野和遠大的目標感到非常敬佩。此次工作坊中也請到維基百科的人員前來演講,因而觸及到一些關於建構知識網的議題。

 

wiki

      …詳全文

國立台灣博物館人類學組專訪稿—文物拍攝

星期六, 十二月 15th, 2007

 

  內容發展分項計畫 / 陳美智95.12.25

 

  實際深入了解民俗文物數位化工作流程,在此將台博館所進行文物拍攝之相關經驗記錄下來,以輔助民俗文物工作流程指南撰寫之豐富性與正確性。
專訪內容:文物拍攝前,需先完成校色與清查工作等。一切就緒,工作空間也確定後,接下來要安排考量的就是拍攝順序。拍攝順序會是文物拍攝的重點,如何在拍攝過程中,安排進行拍攝的文物也是一大門學問。拍攝順序會牽涉到兩個層面,一為攝影層面,二為文物特性。
      

一、攝影層面的考量

1. 牽涉到攝影平台的搭建:大部分的文物拍攝盡量使用斜版平台,或將相機與被攝物保持一定距離,進行斜角拍攝,這樣是避免文物拍攝時,相機或攝影器材不慎直接掉落於文物上,除了一些必要的細節拍攝,不然都盡量使用斜版平台來進行拍攝。在使用斜版平台進行拍攝時,要注意文物與鏡頭必須保持水平,以避免文物邊緣曲線化。

 

圖一、配合拍攝所搭建的斜版平台。

…詳全文

以「數位化」觀點談台灣老照片保存

星期五, 十二月 7th, 2007

 

 

文:國家台灣文學館典藏組助理研究員 羅鴻文
E-mail:hungwen@nmtl.gov.tw
以臺灣為研究主題,似乎在近年已成為熱門的顯學之一。為了要瞭解臺灣文化的脈絡與變遷情勢,必須仰賴完整的文獻資料,而攝影照片因其獨有的時間性與紀實性,便成為學術研究時不可或缺的輔助資料。
臺灣攝影的演變史至今仍未有具體的研究成果,原因包含了對攝影史、攝影家,以及攝影材料等全面性研究工作的不足,而社會大眾普遍對攝影材質仍一知半解,除了無法建構出完整的臺灣攝影史外,更遑論最基本的保存工作。

…詳全文

資料庫初體驗

星期五, 十二月 7th, 2007

 文/黃國倫

資料庫(Database)廣義來說,為一個具有相關隱含意義的資料集合,通常為了特殊目的而建置,因此會有預定的使用族群,而資料庫可大可小、可簡單亦可複雜。舉例來說,一個班級的通訊錄,可能僅僅只有數十筆記錄,每筆只紀錄簡單姓名、電話、住址…等文字結構;而以數位典藏聯合目錄而言,則涵蓋了上百萬筆數位典藏資訊,數位格式包含文字、聲音與影像,資料關係更是錯綜複雜。無論資料量如何,皆可歸納為資料管理的一種,必須能針對資料進行組織、分類與儲存,並盡量滿足使用者檢索、統計分析、維護…等等需求。

<目錄>
3. 資料庫初體驗
3.1 資料管理的好幫手:資料庫
3.2 選擇適合的關聯式資料庫
3.3 資料庫設計DIY
3.4 書同文,編碼大不同

 

文/黃國倫

3. 資料庫初體驗
3.1 資料管理的好幫手:資料庫

什麼是資料庫?
什麼是關聯式資料庫?
關聯式資料庫可以幫我們解決什麼問題?
 
資料庫(Database)廣義來說,為一個具有相關隱含意義的資料集合,通常為了特殊目的而建置,因此會有預定的使用族群,而資料庫可大可小、可簡單亦可複雜。舉例來說,一個班級的通訊錄,可能僅僅只有數十筆記錄,每筆只紀錄簡單姓名、電話、住址…等文字結構;而以數位典藏聯合目錄而言,則涵蓋了上百萬筆數位典藏資訊,數位格式包含文字、聲音與影像,資料關係更是錯綜複雜。無論資料量如何,皆可歸納為資料管理的一種,必須能針對資料進行組織、分類與儲存,並盡量滿足使用者檢索、統計分析、維護…等等需求。
 
一般對於資料量需求不大、關係簡單之資料,是可以採用Word、Excel…等文件格式紀錄,這也算是廣義資料庫的一種;但若資料彼此間關係稍微複雜,就會有不少維護困難與著錄限制。以人名權威資料庫為例,若以Excel紀錄姓名與參考書目關係可以簡單表示如下:
 

表一

姓名

參考書目

編著者

文徵明

明人傳記資料

國立中央圖書館

蘇東坡

中國歷代人名大辭典

沈起煒

王錫爵

明人傳記資料

國立中央圖書館

王安石

中國歷代一百名人傳

沈起煒

以此表格資料為例,可以整理出欄位彼此關係如下︰


 

 

 

 

 

 

 

 

 

 

  

其中『姓名』與『參考書目』為多對一關係,如『文徵明』與『王錫爵』同時參考自『明人傳記資料』;『參考書目』與『編著者』也為多對一關係,如『中國歷代人名大辭典』與『中國歷代一百名人傳』皆為『沈起煒』所撰寫。 

乍看之下很合理,但實際著錄時卻有可能會發生一些問題,如『姓名』與『參考書目』也有可能是一對多關係,如『文徵明』有可能同時參考自『明人傳記資料』與『中國歷代人名大辭典』,在關係圖中可以很簡單加入參考關係,而在表格之著錄也很直覺就會將『參考書目』改成如下,但問題來了,『編著者』要如何著錄,才能清楚區分此『編著者』屬於哪個『參考書目』呢?

 
表二

姓名

參考書目

編著者

文徵明

明人傳記資料、中國歷代人名大辭典

國立中央圖書館、???

而在資料維護上,同樣也會有一些困難,如發現資料著錄錯誤,要將所有『明人傳記資料』改為『明人傳記資料索引』,將所有『中國歷代人名大辭典』的『編著者』由『沈起煒』改為『張撝之、沈起煒、劉德重』,若要修改筆數有成千,甚至上萬筆時,那實在也只能說是一件苦差事了。

表三

姓名

參考書目

編著者

文徵明

明人傳記資料索引

國立中央圖書館

蘇東坡

中國歷代人名大辭典

張撝之、沈起煒、劉德重

王錫爵

明人傳記資料索引

國立中央圖書館

王安石

中國歷代一百名人傳

沈起煒

……

中國歷代人名大辭典

張撝之、沈起煒、劉德重

……

明人傳記資料索引

國立中央圖書館

……

……

……

……

……

……


所以有發現真正問題所在嗎?其實癥結點就在於『姓名與書目彼此間關係可能會有一對一、一對多、多對一、多對多的關係存在,若單純使用Excel這類電子文件著錄,試圖只用一個表格去表達姓名與書目,在很多情況下是無法適當呈現出資料彼此間之關係的』。所以應該重新考慮表一,將其拆成如下之表四、表五兩個表格,再加上表六去紀錄姓名與書目之間的關係。

 
表四

PEOPLE_ID

NAME

1

文徵明

2

蘇東坡

3

王錫爵

4

王安石


表五

BOOK_ID

BOOK

BOOK_AUTHOR

1

明人傳記資料

國立中央圖書館

2

中國歷代人名大辭典

沈起煒

3

中國歷代一百名人傳

沈起煒


此外,SQL依照用途可簡單區分為三大類:資料定義語言(Data Definition Language,簡稱DDL)、資料操作語言(Data Manipulation Language,簡稱DML)及資料控制語言(Data Control Language,簡稱DCL)。資料定義語言可以用來定義資料庫的資料結構,就像資料表名稱、欄位名稱、以及各欄位屬性等等;資料操作語言則是用來進行資料操作,例如:資料庫中新增、刪除、更新、與查詢資料的操作功能;而資料控制語言可以針對資料庫內部進行交易處理及系統效能維護。因此只要學會這三大類的SQL語言,幾乎就可以應付各種資料庫管理工作。但礙於篇幅關係,本章節並不詳細介紹SQL用法,有興趣者可參考SQL相關書籍。<目錄>
  

3.2 選擇適合的關聯式資料庫

有哪些關聯式資料庫可供選擇?
優點為何?限制為何? 

目前市面上常見之關聯式資料庫有Microsoft Office Access、Oracle Database、Microsoft SQL Database、MySQL、PostgreSQL,基本上都具備關聯式資料庫基本功能,茲分別簡介如下:

n         
Microsoft Access

MS Office Access適合資料量小,需求不大之使用者。其單一表格可支援2GB資料量、支援基本的交易鎖定(Transaction Lock)、支援與MS Office套件作一些功能上的結合,更重要的是也支援SQL結構化查詢語言。但只支援255個使用者同時上線,無法使用預存程序(Store Procedure)或觸發(Trigger)…等功能,只能執行於Microsoft Windows作業系統上,更多產品相關資訊可參考http://www.microsoft.com/access/。 

n         
Oracle Database
商業資料庫,由專業資料庫廠商Oracle推出,一般常見功能皆具備,可說是目前市面上功能最齊全的資料庫。也因其功能眾多,其所提供之資料庫管理者介面相當複雜,甚至有些進階功能無法透過介面去管理,只能透過命令列(CommandLine)方式進行設定,價格昂貴。其除可與Java做緊密結合,亦可於Linux、FreeBSD、MSWindows、Solaris…等作業系統上執行。更多產品相關資訊可參考http://www.oracle.com/database/

 
 

 在選擇資料庫時,除了根據資料管理的需求外,也要考慮資料量規模、預算、作業系統平台、資料庫功能…等等實際專案需求;若以作業系統平台為考量,僅限制在Linux上運作,則MS Office Access、MS SQL Database就無法列入考慮;若非商業用途,而預算又不足時,就可以考慮MySQL或PostgreSQL,端看不同需求,而有不同資料庫選擇。在這裡提供幾個評估因素,讓各位在選擇資料庫產品時可以先進行自我需求分析,以了解資料庫應具備的特性:

評估因素 說明
資料複雜度

 

是否支援有多對多的關係?

是否提供欄位格式限制?日期、數字、長文字?

資料量 最大的資料儲存筆數?
資料查詢需求
是否支援SQL查詢?

是否提供AND、OR、部份符合、大於、小於條件查詢?

使用者數量 同一時間最多使用人數?
跨平台要求 是否能在Windows、Linux或其他平台運作?
商業用途 是否用於公司營利之目的?

 


 

 

 

 

 

 

 

 

 

 

…詳全文

  • Loading...


    Loading...

    Login






    註冊 | 忘記密碼

    Register





    A password will be mailed to you.
    登入 | 忘記密碼

    Retrieve password





    A confirmation mail will be sent to your e-mail address.
    登入 | Register