:::

你真的要來讀研究所嗎?

布丁布丁吃布丁

你真的要來讀研究所嗎?

最近是推甄的熱門時期,我也被問了很多關於推甄的問題,加上最近週遭朋友們的情況,這不禁讓我想回頭去問一個問題:「你真的要來讀研究所嗎?」

在我開始講之前,我想先舉幾個身邊朋友的例子,這不一定是本所同學,而且這是真的故事,而不是KUSO版或是四格漫畫的誇大橋段。

「我搞不好下學期就不唸了。」某碩一友人如此說著。他從大四開始被他老闆(指導教授,俗稱老闆)要求翻譯論文,想說至少直升相關研究所時可以獲得點好處,結果最後還是等備取。最近在跟我抱怨他不想幫他老闆寫出國報告、計畫書、甚至是記賬。

就如你看到的,唸研究所並不是只有讀書。當你找到指導教授──其實更多例子是,你被指導教授找上之後,你就開始了無止盡的...好吧,姑且稱之為研究準備工作。

「我開始想休學了,哈哈」一樣是碩一某友人。他進入碩一時就被老師找去幫忙作paper study(期刊論文研讀),一方面是訓練閱讀英文期刊論文的能力,一方面幫老師的研究做文獻探討。他那時候是每週閱讀一篇英文期刊論文,短則十頁不到,長則多達三十幾頁。當然,課堂作業不會因為他還要做這課外工作而有理由放空的。

在軍中有過一句話「合理的要求是訓練,不合理的要求是磨練」,對於可能一學期只看兩三篇paper的大學生來說,相信這種程度應該可以稱為「磨練」了。但是我不得不說的是,他現在讀英文paper的速度真的是我望塵莫及,不愧是磨練出來的。

「什麼是Web 2.0?」某考生這樣問我。

當我聽到這句話的時候,我愣了一下。很難想像一位準備要推甄圖書資訊與檔案學研究所的人不知道什麼叫做Web 2.0,那我大概可以直接猜測他連讀者服務跟技術服務的基礎都沒有。我知道圖書館學很多人都不太在意,大家都在看那華麗、有趣的技術。但是要來研究所讀書,如果連這點基礎常識都沒有,那大概只會在無止盡的專有名詞當中持續打轉。

「JAVA很簡單,你看書Study一下應該是ok。」某老師這樣說。

雖然我想這應該是很明顯了,但這也沒什麼好避嫌的,事實就是如此。我大學學過C++,自學過PHP、JavaScript,就是沒學過JAVA(如果不懂JAVA跟JavaScript的關係的人別在意,因為他們的確沒什麼關係)。每個大學唸完的人都跟我講寫程式好難,但是有些問題就是要用程式來解,或著是說,這是一塊頗為熱門且有趣的領域,如果你覺得YouTube很有趣、Google很強大,想往這方向研究,那麼學習寫程式是基礎能力。

在這邊我順便推薦一下「深入淺出JAVA程式設計」,O'REILLY出版,真的是好書。

「我們研究所一定得要念三年,兩年修課,修完課才能開始寫paper。」吾有某碩二生如此說著,至今仍未確定論文題目,雖然聽說他最近正忙於追求終生幸福當中。

「我本來是想走讀者服務研究的,可是老師希望我作另一個題目,我只好改作。」某碩二友人如此說的,最近剛計畫書口試通過,最後還是做了老師的題目。

通常一般認為碩士是兩年畢業,但依照各所不同的規定,可能會像上述的卡修課、或是卡資格考(看你有沒有資格寫論文),最後得到三年或是更久才能畢業,請不要意外。

我知道你可能已經在擔心一個問題:「怎麼辦?我不知道我該做什麼好耶。」那麼我會告訴你,趁年輕的時候什麼都去嘗試看看,去發掘一些之前沒看過的樂趣。

那麼最後我來講講我的例子吧。

要說進研究所,應該要從今年的一月多進入陳老師實驗室團體meeting開始。如果有關注我之前Blog的人,可以看到我會寫些感嘆、新發現,這也的確是大學時期沒體驗過的經驗。大概年中正式承接數位圖書館計畫的程式寫作,到現在為止還是過得沒日沒夜的寫程式生活。對我而言,除了寫程式本身很有趣之外,透過我的雙手將那些空口說白話的理論實作出來,才是真正的樂趣。

我知道有些人似乎不太喜歡我這種生活,認為枯燥、乏味,沒有樂趣。「你真的生活沒有娛樂耶」,因為我不知道周杰倫的新歌,所以被這樣批評。看前面的吾友人眾,我也知道不會有人喜歡幫老闆報帳、寫paper,而不是做自己的東西。

那又如何?

既然來到了這個環境,那麼就接受這邊的價值觀,找尋這種生活方式的樂趣。坐這山望那山對我來說太過困難,至少我是如此。其他人怎麼看,那就是另一回事了。

最後我再舉一個例子,用簡單的方式來敘述好了。

我發現研究生很少在說「不」,而都是很乾脆地接下了老師交待下來的工作,最厲害的是,最後都還順利做得完!以上面提到的JAVA看書學來說,我也不會跟老師說:「老師我沒學過!」而是抱著一種挑戰的心情去答應這個工作,最後把它完成。

這種不斷接受各種挑戰的準備,我想這才是讀研究所最應該具備的能力吧。

(more...)

實作DC資料,Dubline Core metadata editor

布丁布丁吃布丁

實作DC資料,Dubline Core metadata editor

Dublin Core metadata editor,一個網路線上服務,可以取得指定網址的資料並生成為DC(Dublin Core)欄位,可選擇輸出為HTML的<meta>標籤或是RDF(描述網路資源的標記語言)/XML,嵌入到<head>...</head>區段內即可使用。

此metadata(詮釋資料)產生器也可以選擇輸出到其他格式,如USMARC(美國的圖書機讀格式)、SOIF、IAFA/ROADS(網路發行者使用)、TEI headersGILS(全球資訊定位服務)或是IMS(IP多媒體子系統)。

DC是一種metadata元件,目的是為了讓電子資源更容易被找到。原始的構想是提供給作者產生網站資源的敘述,它引起了正規資源描述社群的注意,包括博物館、圖書館、政府機關部門以及商業組織。

以上都是翻譯自該頁面的介紹。

講了這麼多,到底這個編輯器能夠幹麻呢?最簡單的應用如下:

  1. 取得指定網頁的資料
  2. 分析成為DC格式
  3. 修正該網頁的資料,讓網站能見度更高(例如SEO,我猜)

讓我們一步一步來做做看吧。


DC metadata editor與網頁的關係

該網頁當中就只有一欄表單,本次的實驗對象,就填進「布丁布丁吃?」的網址吧。

天啊,好多亂碼。我相信Blogger在幫我寫metadata的時候應該是用Unicode,那麼就是這個用perl寫成的編輯器是用其他編碼寫成的囉?

網頁下面可以看到他抓了網頁的資料來跟DC作配對,為了方便起見,我把它複製過來看看。

Title
Creator (author)
Subject or keywords
Description
Publisher
Contributor
Date
Type
DCMI Type:
Format
Identifier
Source
Language
Relation
Coverage
Rights management
Version: DC-dot $Id: dcdot.pl,v 1.107 2005/03/02 23:55:27 lisap Exp $

你可能會很好奇,到底他是從哪裡取得這些資料的。讓我們打開布丁布丁吃?的原始碼來瞧瞧<head>區段裡面有些什麼。排除掉一些CSS跟JavaScript連結之後,我們可以看到以下內容:


   <head>
   <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'/>
   <meta content='true' name='MSSmartTagsPreventParsing'/>
   <meta content='blogger' name='generator'/>
   <link rel="alternate" type="application/atom+xml" title="布丁布丁吃&#65311; - Atom" href="http://pulipuli.blogspot.com/feeds/posts/default" />
   <link rel="alternate" type="application/rss+xml" title="布丁布丁吃&#65311; - RSS" href="http://pulipuli.blogspot.com/feeds/posts/default?alt=rss" />
   <link rel="service.post" type="application/atom+xml" title="布丁布丁吃&#65311; - Atom"
   href="http://www.blogger.com/feeds/16607461/posts/default"
   />
   <link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://www.blogger.com/rsd.g?blogID=16607461" />
   <title>布丁布丁吃&#65311;</title>
   </head>

很短,對,很短。除了那個「&#65311;」大概是「?」之外,<head>區段裡面找不到這麼多資料的樣子。好,讓我們再仔細地看一次上面有填資料的表格與該網頁之間的關連,也許可以發現什麼有趣的東西。

Title 標題,從<title>區段擷取
Subject or keywords 關鍵字,似乎是從網頁裡面資料去斷字斷詞出來的結果
Date 網頁的更新日期
Type 網頁的型態,因為是文字為主的Blog,所以他判斷成為Text吧
Format 格式分成兩個子欄位,編碼可以從<mate>標籤裡面找到,長度則是程式去計算出來的
Identifier 網址,就是你輸入的網址

其中重要的「Description」欄位無法自動產生,那麼就由作者(我)來為他撰寫吧。從下面表單填入了Description,並修正其他欄位的亂碼之後,re-submit的結果是:

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
   <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
   <meta name="DC.title" content="布丁布丁吃?" />
   <meta name="DC.subject" content="RSS; Atom; friends; PHP5$HTTP_GET_VARS; OK; LCD; K300; Picasa; Vlog; Writer;
   11/24/2007; Inno; OK─A.R.K; Wikipedia; Sitebar; CNET; Album; Zoomify; 11/25/2007; Creator; WLW”:Zoundry; main; Albums; Loading; 2.5轉IDE;
   Google; Alpha; Engadget; Aglaia; Zoundry; Raven; Feeds; Page; 32GB,15100; SSD; Setup; LG; Blog; Caduceus; WebFTP; MUSASHI; Web; Dear;
   BBS‧RSS; Vii; Reader; sidebar; skip; ACG; GUN; Decaview; Blogger" />
   <meta name="DC.description" content="布丁個人BLOG" />
   <meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2007-11-25" />
   <meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" />
   <meta name="DC.format" content="text/html; charset=UTF-8" />
   <meta name="DC.format" content="126737 bytes" />
   <meta name="DC.identifier" scheme="DCTERMS.URI" content="http://pulipuli.blogspot.com/" />

讓我們把這些標籤加入原本的Blog,看看有什麼不同。

外表上看不出有什麼差別的。

書籤...也沒有差別。Description欄位沒有發揮功效。其實應該是要填入<meta name="Description" content="布丁個人Blog" />才對。

好吧,讓人高興的是這編輯器總算不會呈現亂碼了(這也是他說明裡面寫到的用處)。


不同輸出格式

接下來我們來看看不同的輸出格式會有什麼結果,並比較一下它們之間的差異吧。

XHTML:單一標籤結尾加上/,這是XML的規範


   <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
   <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
   <meta name="DC.title" content="布丁布丁吃?" />
   <meta name="DC.subject" content="RSS; Atom; friends; PHP5$HTTP_GET_VARS; OK; LCD; K300; Picasa; Vlog; Writer;
   11/24/2007; Inno; OK─A.R.K; Wikipedia; Sitebar; CNET; Album; Zoomify; 11/25/2007; Creator; WLW”:Zoundry; main; Albums; Loading; 2.5轉IDE;
   Google; Alpha; Engadget; Aglaia; Zoundry; Raven; Feeds; Page; 32GB,15100; SSD; Setup; LG; Blog; Caduceus; WebFTP; MUSASHI; Web; Dear;
   BBS‧RSS; Vii; Reader; sidebar; skip; ACG; GUN; Decaview; Blogger" />
   <meta name="DC.description" content="布丁個人BLOG" />
   <meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2007-11-25" />
   <meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" />
   <meta name="DC.format" content="text/html; charset=UTF-8" />
   <meta name="DC.format" content="126737 bytes" />
   <meta name="DC.identifier" scheme="DCTERMS.URI" content="http://pulipuli.blogspot.com/" />

HTML:跟XHTML的差別就只有結尾沒有/


<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
   <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/">
   <meta name="DC.title" content="布丁布丁吃?">
   <meta name="DC.subject" content="RSS; Atom; friends; PHP5$HTTP_GET_VARS; OK; LCD; K300; Picasa; Vlog; Writer;
   11/24/2007; Inno; OK─A.R.K; Wikipedia; Sitebar; CNET; Album; Zoomify; 11/25/2007; Creator; WLW”:Zoundry; main; Albums; Loading; 2.5轉IDE;
   Google; Alpha; Engadget; Aglaia; Zoundry; Raven; Feeds; Page; 32GB,15100; SSD; Setup; LG; Blog; Caduceus; WebFTP; MUSASHI; Web; Dear;
   BBS‧RSS; Vii; Reader; sidebar; skip; ACG; GUN; Decaview; Blogger">
   <meta name="DC.description" content="布丁個人BLOG">
   <meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2007-11-25">
   <meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text">
   <meta name="DC.format" content="text/html; charset=UTF-8">
   <meta name="DC.format" content="126737 bytes">
   <meta name="DC.identifier" scheme="DCTERMS.URI" content="http://pulipuli.blogspot.com/">

RDF:完全是XML的架構

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF SYSTEM "http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd">

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="http://pulipuli.blogspot.com/">
    <dc:title>
      布丁布丁吃?
    </dc:title>
    <dc:subject>
      RSS; Atom; friends; PHP5$HTTP_GET_VARS; OK; LCD; K300;
      Picasa; Vlog; Writer; 11/24/2007; Inno; OK─A.R.K;
      Wikipedia; Sitebar; CNET; Album; Zoomify; 11/25/2007;
      Creator; WLW”:Zoundry; main; Albums; Loading; 2.5轉IDE;
      Google; Alpha; Engadget; Aglaia; Zoundry; Raven; Feeds;
      Page; 32GB,15100; SSD; Setup; LG; Blog; Caduceus; WebFTP;
      MUSASHI; Web; Dear; BBS‧RSS; Vii; Reader; sidebar; skip;
      ACG; GUN; Decaview; Blogger
    </dc:subject>
    <dc:description>
      布丁個人BLOG
    </dc:description>
    <dc:date>
      2007-11-25
    </dc:date>
    <dc:type>
      Text
    </dc:type>
    <dc:format>
      text/html; charset=UTF-8
    </dc:format>
    <dc:format>
      126737 bytes
    </dc:format>
  </rdf:Description>
</rdf:RDF>

XML:跟RDF相比的差別只有最外面幾層的標籤,XML標籤描述就很直接地使用metadata,不像rdf使用名稱空間(namespace)的rdf:RDF

<?xml version="1.0"?>
<metadata
  xmlns="http://www.ukoln.ac.uk/metadata/dcdot/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.ukoln.ac.uk/metadata/dcdot/ http://www.ukoln.ac.uk/metadata/dcdot/dcdot.xsd"
  xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>
    布丁布丁吃?
  </dc:title>
  <dc:subject>
    RSS; Atom; friends; PHP5$HTTP_GET_VARS; OK; LCD; K300;
    Picasa; Vlog; Writer; 11/24/2007; Inno; OK─A.R.K;
    Wikipedia; Sitebar; CNET; Album; Zoomify; 11/25/2007;
    Creator; WLW”:Zoundry; main; Albums; Loading; 2.5轉IDE;
    Google; Alpha; Engadget; Aglaia; Zoundry; Raven; Feeds;
    Page; 32GB,15100; SSD; Setup; LG; Blog; Caduceus; WebFTP;
    MUSASHI; Web; Dear; BBS‧RSS; Vii; Reader; sidebar; skip;
    ACG; GUN; Decaview; Blogger
  </dc:subject>
  <dc:description>
    布丁個人BLOG
  </dc:description>
  <dc:date>
    2007-11-25
  </dc:date>
  <dc:type>
    Text
  </dc:type>
  <dc:format>
    text/html; charset=UTF-8
  </dc:format>
  <dc:format>
    126737 bytes
  </dc:format>
  <dc:identifier>
    http://pulipuli.blogspot.com/
  </dc:identifier>
</metadata>

但是後兩者拿來擺在HTML或XHTML裡面就很奇怪,對吧。


結論:網站設計者所關心的不是DC

這個編輯器能協助我們用統一的方式去描述網站資源,並且方便你更新資料。從另一個角度來看,他用DC的方式描述網頁資料跟網頁平常在描述的方式不同(如前面的Description欄位與書籤),那麼這個編輯器產生的資料到底能不能對於網站有所幫助?甚至提升SEO?這就很難說了。

如果能夠再跟網頁描述做緊密結合的話,那麼相信會有更多網站會喜歡參考這個標準規範的。

(more...)

低速雲霄飛車──貓空纜車搭乘感想

布丁布丁吃布丁

低速雲霄飛車──貓空纜車搭乘感想

貓纜自夏天開通以來已經數月,經過了颱風、地震等多次停擺事件,至今仍不減人們對它的好奇心。

這週我有圖檔所大出遊以及輔漫社團出遊,剛好都選擇以搭貓纜進行,於是乎我就在這週內連續搭了我的第一次跟第二次貓纜。本回感想是以第一次搭貓纜時的照片為主。

2007年11月21日星期三上午10點55分1秒,貓纜前的紅龍分隔線已經有三排站滿了人龍,我忽然開始懷疑今天到底是不是非假日。然而事實證明,週六社遊時排隊的長度,則是照片中的兩倍。

我不知道是不是旁邊就是動物園的關係,這條路上的遊覽車非常的多,當然,從遊覽車下來特地來坐貓纜的人也不少。

從外面玻璃窗上貼著的票價來看,坐到貓空總站需要50元,來回則是100元。雖然這樣比較很奇怪,但這足以騎摩托車上下來回三次的油錢吧。

另一張海報,宣傳著貓纜的可靠性,但是這可靠性老是被媒體不斷抨擊。而且我相信海報這種寫法,幾乎沒幾個排隊的人看得懂它是什麼意思。

剛剛看到很長的列隊,到我排到門口之前,其實也不過花了五分鐘左右而已。其實照一般的載客量來說,貓纜是不需要這樣排隊的。然而大家都把它當作觀光景點來坐,最後演變成得拉紅龍來整隊,原本的用意都改變了。

讓我介紹一下,這位可愛的工作人員是進門後第一關的守門員。什麼意思?在踏上手扶梯之前,你還要再等一段時間,以免排隊人數過多。

貓纜動物園站有四層,就是要你排四次的意思。雖然佩服他們的控管方式,但是這樣排的確是很考驗人們的耐心。

四樓,你看到的還是一堆人。讓我們看看照片上的時間紀錄,到目前為止已經花了二十分鐘了。果然,門外只是表象,裡面排隊才真是花時間。

好吧,至少來到四樓可以遠眺景色,這是讓人覺得開心的地方。

靠近貓纜了!眼前看到的這個捷運常見的出入口並不是真正的出入口,要從右邊在繞一下才會到,不知道為何是這樣設計。

真正的出入口,隨時打開的團體票出入口表示有很多人是用團體票進來的。這層樓的工作人員特別戴著口罩,其他人卻沒有,這到底是為什麼呢?

在排進貓纜之前,再讓我們眺望一下遠方的景色吧。

喔喔喔!來了來了!

巨大的機械構造,身為男生通常都會對這個感到熱血十足吧。

終點(?)就在前面了!

這張照片很動態,因為貓纜是邊轉邊坐上去的,他不會停下來等你喔。還好速度很慢,老年人上去也不成問題。

搭上貓纜之後往後看。有沒有感覺到玻璃霧霧的差別啊?

風さそう木陰に俯せて泣いてる......プリン、行きます!

窗外景致...反正就是樹樹樹樹樹。

但這種角度,可就不只是樹了。這裡不是遊樂園,下面沒有籃網喔。

再來一張,有沒有像是在看衛星圖的感覺啊?

打開的氣窗。貓纜上是沒有冷氣的,溫度調節只依賴天氣。最近天氣陰陰涼涼的,貓纜內坐起來也頗為舒服,但也不是不能體會那些夏天來坐貓纜而形容它為烤箱的乘客的心情啦。

貓纜串一串,我很喜歡這種景色。

支撐點,整條路上有許多這樣子的支點,經過的時候貓纜會稍微抖動,有點恐怖。

好會撞上去的感覺!

貓纜中間會轉彎喔,圖中為轉彎的地方。

我一個人搭乘的時候,是與另一家人共乘一車。成員為兩位社會人士的姊姊,兩位小妹妹,以及一位膽子很大的老婆婆。小妹妹們一直望著窗外,十分興奮,讓大姊姊要拍照的時候都得說謊騙她們,她們才會轉過來。聊天的時候得知他們是從台中來的,是同鄉呢。

「請乘客不要在車內站立、晃動...」廣播忽然從天花板的喇叭發出聲音,嚇的小妹妹們安靜了一陣子。

窗外,霧霧的,雖然看不清楚,但也換來了涼爽的舒適感。

這邊算是文山區吧,可以找到政治大學的綜圖大樓喔。

遠方是六張犁,我不久前才去過的。

搭了好久卻才只搭到指南宮站。貓纜共有四站,個別是動物園站、動物園內站、指南宮站、貓空總站。到達指南宮站約花了二十幾分鐘。入鏡人物是同車的老婆婆,右圖則是指南宮。

再搭一下子,總算到了貓空總站。貓空站附近吃飯都不便宜,而且好吃的似乎不多,本來那家人還想說要請我帶她們去吃飯的,最後還是在站前揮手道別了。


週吃完飯之後,回程又是搭貓纜。六的時候,人群是現在的三倍之多吧。

借用吾友某誠的相片一張XD 大概是這種震撼感

照片也都貼得差不多了,本回的感想就到此為止囉。

(more...)