This document is CC BY 4.0 https://g0v.hackpad.com/YHxxVL4xTfZ
Date: 03-04 15:00
Location: 文化部南海工作坊（台北市南海路20號9F）902會議室
Participants:
緣由
這是 EY 虛擬世界研習會後，由與會者 HHWang 於 2015-03-02 邀集的討論會議。由於與 open data 相關，因此秉持公開透明原則，製作全程紀錄並將 hackpad 放在 g0v 的 workspace 底下，也邀請有興趣的朋友一起參加。
Reference: MOC Open Data, MOC iCollection
Agenda:
紀錄
HHWang> 看到 g0v 對資料業務的關注，是紮根的工作。文化部目前有共構 19 機關的目錄，共 60 萬筆之中，26 萬筆有對外開放。之前有將 archiving 用內部資料庫，我 1992 年開始做數位典藏，2011 組改時推共構，台博館說各式 metadata 很難統一，但我們最後克服了這個問題。傳統藝術、人權博物館、台南文學館、新竹生活美學館（原社教館）等這些館藏資料，電影資料館最近也納入典藏了。技術上，我們是把博物館典藏的作業，從徵集開始就已經放上來，包含數位和實物的資料。台史博、國美館未來也會整合進來。Metadata 當然不一定完全完整，但每個博物館的典藏管理至少能夠統一結構，對我來說是很重要的工作，也推動很久了。
文化部希望有前台的呈現端，所以建置了 iCollection。此外，授權平台去年加了進來，傳藝和台史博先行，希望把 300~500 個重要文物的數位權利，比照數位典藏的方式，修正過之後，清理好它的權利。
為什麼 Open Data 資料集較少、欄位較少呢？因為智財局沒有修法完之前，連小圖都要重新取得作者的數位授權，這很麻煩... 「博物館法」草案目前正在立法院審議。我有一個夢想，剛好教育部有六個館，其中一個願意和我們合作，把博物館的 metadata 建置起來，比照 OAI 模式，取用者自由選擇呈現的方式，而教育部和民間的博物館也可以上傳自己的資料來聯播（「博物館法」草案第九條）。
我們目前的困難是，數位授權的方式還未澄清，並且不確定要如何展開協作，邀集民間的老照片、現有的民間博物館，來登入資料，像大英博物館那樣。
另一個困難是，前端的呈現太過呆板，上次看到葛如鈞對 3D Scanning and VR immersion 的展示，很希望有合作的空間，做一個數位呈現。
另外就是博物館講的是 Curation，所以也希望能透過素材和開放授權，文化部提供軟體，讓使用者在前台自己策展出主題故事來，分享給社群朋友看。當然有自行上傳上來的，需要一個標準的授權條款，這也是要請教的。
其實這就是博物館的核心功能，也就是保存文化的功能。古蹟、歷史建築，這些在 iCulture 網站都有，我們之後再可以細談。
我們合作的模式，想確定一下，雖然都可以 CC，但想請問各種 CC 裡，g0v 有沒有偏好哪一種。當然 CC BY 的原出處標示是一定要的。然後上載的著作權，文化部其實不會拿去營利，但還是需要標示清楚。
另外，我們有現成的英文資料，博物館界說 first or unique，first 我們不一定可以，但台灣的多元文化確實是 unique。目前英文有一萬筆，我很想做像 lodlam.net 或 openglam.org 這樣，去和國際接軌，把台灣的故事串起來，用「人事時地物」最簡單的 metadata axis，找到說故事的元素，串接成新的活動和作品。
之前想做 Linked Open Data，一直卡在 infrastructure 和 licensing 上，前面的盤點終於做完了，後面的比較保守，目前是用出版品、招標、抽成的方式和廠商合作，都是實體的想法，包括包裝、發貨退貨。之後也許會招標邀請律師事務所合作，幫忙商業用途的授權，再給予他們抽成。
GMC> 舉個例子，剛才處長有講到藝文活動，以兩廳院來說，都有節目單，也有固定的格式，有活頁孔可以收藏。那些部份如果一開始在建置上，有一種系統可以做結構化的登錄，後面可以跳過很多事後的工作，也就是「參與即典藏」和「發生即典藏」的概念。很多人的數位載具都可以在看展覽、活動時載入。
HHWang> 兩廳院和我們有介接。但目前只有基本文字，圖樣都需要分開取得授權。有些展演團體的素材會希望有限時間內才開放授權。另外 Digital Government 的概念，也就是在無紙化的同時，在工作流程中間去自然產生 Open API。
雲端平台的 stakeholder 也很多，設計師、通路商、觀賞者... 我們很希望提供一些 system call，看平台能不能用 API First 的方向，讓廠商去接這個 API。但我覺得可能要 2~3 年。
我們和宏碁合作藝文活動，秒殺報名... 這個如果也能在 Open API 的方式解決，就太好了。無論是對一個「人、事、時、地、物」想做利用，我們都希望先開放 API 介接。像是沃土一樣，看每個應用的人要澆水，長出什麼東西完全是軟體開發者決定，這樣軟體工作者才有可能趕上硬體的 ecosystem。在行動裝置裡，IoT 特別適合用來串接這些 API。
但特別是兩廳院活動的例子，要說服他們還要一點時間。
au> 參與即典藏，就是說用文化部的系統做 primary storage，系統已經是這樣嗎？
HHWang> 我們非常注重 data consistency，uptime 非常重要，maintain window 不多於 30 分鐘，所以除了台史博、國美館對 uptime 的要求很高，還沒有用部裡的系統做 primary storage 之外，其他都已經 onboard 了。
GMC> 視盟從去年開始做藝術家資料庫，從多年前的文化大百科到今天，我覺得逝者已矣來者可追，也就是未來是「發生即典藏」，我們再開放民間自行補充過去來不及典藏的資料。如果有一種模組可以吻合這些機制，那種就可以大幅降低程式工作的需求和門檻，讓一般人都可以取用、上載這些 open data，因為之前的數位典藏或 Web 2.0 往往都因為對特定技術過度依賴，所以過幾年就被替換了。我們也希望程式的欄位可以保持彈性，全民參與時才可以更充足。
HHWang> 如果上載時，系統界面要每個人都滿意，太困難了。Google、eBay 並不是全部都自己來，而是用現成的資料來索引，必要欄位還是保存，才能有多元的商業模式，但是也開放使用者自定的額外的語意欄位。
關於藝術家的 profiling，我最近剛拿回了 Facebook 帳號... 發現他界面更新了，會一直主動問我一堆個人資訊，等於引導我建立了自己的 linked open data graph。所以我才體會到這簡直是大者愈大、小者愈小，networking effect 非常的明顯。
所以我跟同仁講，人員維護資料的工作不如直接連到人員的 social media profile，確認他是帳號的持有者，這樣才會即時更新，不然我們自己維護一套，一下子就過時了。我建議公協會也可以這樣去維護人員的資料庫。
李家祥> 剛才提到 FB 或 Blog，都是開放上傳資料，但是要做 metadata 檢索的時候，像是「近期有展覽的藝術家有哪些人」，用 Google、FB 找都要花非常久的時間。一個簡單的「藝術節參展的人是哪些人」或是「這位藝術家的作品很有趣，有沒有其他藝術家類似的作品」，雖然可以連來連去，但都需要自己來探索，當然現在有個詞是叫資料探勘，可是目前的技術難度太高了。目前 FB 的欄位比較固定，至少可以做初步的檢索，但一超過這個限度就做不到了。
HHWang> 我們的 iCulture 目錄就是想解決這個問題，表演者的 metadata、地址、類型上面都有，但可能我們行銷做得不太好，幾乎沒有什麼人知道...
我以前在檔案局，有很多時間看歐洲推薦的資訊結構，覺得那真的是很好，因為是實際使用的人在做的，就很想做出類似的事情。但是如果我們硬定規定一定要有哪些欄位，很容易 A 說這樣，B 說那樣...
GMC> 其實我覺得重點是在雙向收藏，像是我參與過哪些活動、我的興趣和其他人的興趣有什麼異同，我能不能透過我的參加的紀錄來找朋友... 這些都是加值的可能性。
HHWang> 文化部要不要做這些活動的典藏和欄位定義，這個是我今天新聽到的，也就是模組化、格式標準化，很值得好好討論... 可以有一個 version 1，之後 data spec 再擴充，保留基本的向下相容就可以了，就是不要讓使用者做白工，不會官網一改版之後，所有的程式要重寫這樣。也很謝謝你們提醒我，影像的裁切和標準格式我們也會注意，會在 open data 的伺服器端處理。
李家祥> 之前做老照片、空拍的時候，在 2002-2003 的時候，有做到齊柏林的，拿了一千張來數位化，每張照片的詮釋資料要手動去建置，當時空拍還沒有類別和欄位定義，所以花了很多時間，讓它變成可以被檢索，並且定義必填和選填欄位。
HHWang> 這是我們老傳統的做法，這個我很熟悉...
李家祥> 但是現在 FB 有打井號的想法，只要標注 #tag，就可以串接（folksonomy）。
HHWang> 但這樣就要再後處理同義詞、多義詞的問題。我們之前的想法是有最基本的 abstract、description、date、location 這些，其他的才開放用 tag 或 folksonomy。
之前數位典藏時有做一個詞庫，有了詞庫就可以自動推薦關鍵字，像「陳水扁」「阿扁」「陳總統」，經過資料正規化之後就可以統一檢索。
au> 建議 CC BY 或 CC BY-SA，目前使用規範有一個特別不友善之處：
HHWang> 藝文活動類型是跟民間取得（54 系統），兩端的介接 push/pull 都有，像是 ibon 來介接，可是有時候還是手動丟 Excel 上來，我們的維運團隊做正規化。
關於第二點，國家文化資料庫，我之前也參與蠻深的，有些授權是跟華藝買的，都有期限，一到期就必須下架，還有中央社... (off record)... 所以有很多上游的限制，我們要推一個通用式的授權，就必須留一個空間，讓原作者（像畫家常常也沒有那麼好說話）如果說要多久下架或再續約，我們也把它納入資料集裡。
au> 「資料授權截止日」如果目前未標注，是否就表示是不可撤回之授權？會不會日後忽然授權截止或下架？
HHWang> 原則是不會，更正資料會有，但是不會回溯式的撤回。所以有些下屬的館，文字部份先出，保證不會撤回，圖片之後慢慢推，等副院推動修法看有進度再回來克服這一塊。
au> (demo of drugs.olc.tw and ER and EHNABF) 這是多重資料整合和個人履歷的例子。
HHWang> 這樣聽起來，以活動為主軸，來串接活動場地、藝術家、再串接回展品和文物，從社群來看，會比單純呈現文物來得有興趣？
GMC> 只是說有比較切身的應用。
HHWang> 我們 iCulture 有 App，網站也會做 RWD，目前我們完全沒有個人化的功能... 有想過滿意度問卷、電子票券整合，但是沒有力氣做。
au> 文物展品典藏，像藥物資料庫一樣是最基本的，但一般使用者是因為去參加某個展覽或活動，才會有興趣去探索，很少人會一下去瀏覽 60 萬筆。
GMC> 這樣的話，展演者和上游資料提供者也比較有動機來提供額外欄位的資訊，因為可以觸及比較多的人。
HHWang> 表演場地、公共藝術、古蹟、獨立書店、商店，我們都有系統和建檔。綜理一下，我們如果做活動或是 iCulture 的 App，可不可以做一個社群的版本示範給我們看。
au> 我想愈切身的事情，愈會有社群朋友幫忙做。今天只是一個討論的窗口，讓大家看到共筆，之後在共筆上交換意見。
HHWang> 合作的議題可以思考一下。授權是統一規範，所以使用時不用擔心上游主張侵權，我們都處理好了。業界已經在做的是一部份，但我們希望社群幫忙的是，可以解決大家平常碰到的問題的事情，然後用一個共同享有的心態來做。
GMC> 像是聰明的衣櫃這樣，知道你平常愛穿的衣服搭配，有新款式時通知你...
HHWang> 聽起來這個想法不是營利的，而是每個人自己想要的東西，可以放在自己的時間軸裡保留下來，再選擇要分享的部份公開，讓更多朋友可以接觸到。
au> (demo of 萌典字圖) 很多朋友學到了新的台語的詞，可以用字圖張貼在自己的時間軸上。這也是一種個人學習的記憶庫，所以如果文化部的單項資料可以用 Open Graph 等結構欄位加上註解，分享起來也比較容易。
HHWang> 這也可以取代紙本的小冊子、介紹、導覽，從我們自己的館所，例如兩廳院來推行，這樣有一定的格式、個人化，有參與感時，比較可能有完整的生命周期。
GMC> 這也是有利於表演者的宣傳的。
HHWang> 這也符合文化部的業務和主要工作，就是提高大家對文化的參與度。
GMC> 很多專案的範圍是跨部會的，在既有的補助款架構上，一定要國藝會、文化部擇一... 從資訊端來說，這件事是可以不用限制在單一的部會上，而是大家試著用類似的方式來做資料交換。
HHWang> 作業方式大家可能不同，但資料交換是有必要的。這是要建立共識的，也讓流通變得更方便。
shjan> https://event.culture.tw/ 是共用的報名系統，Open Data 的活動統計資料是從這裡產生的。雖然下屬機構有不同的版型，前台看起來是不同的網站，但其實後台已經一致化了。
au> 我之前只有看到單項活動的，沒有看過這個總目錄。
HHWang> 所以除了所屬機構之外，也希望可以談讓其他館藏單位來提供。我一直想推動這個報名系統給其他部會用，就可以互通了。報名系統的網站軟體也可以授權給民間使用。
au> 軟體授權倒是其次，坦白說對參與 g0v 的朋友來說，架設、使用報名系統的難度並不高。但重要的是後設資料欄位的統整，單筆事件有自己的固定網址即可做聯播。
（中間電腦沒電，之後補上）
au> 另外，固定網址的概念也適用在典藏資料上，例如Open Data 典藏資料集每筆雖然有（不確定是否 unique）的 Identifier 欄位（如 TMMA0001），但沒有鍵連到網頁 URL（如 SYSUID=13&RNO=VE1NQTAwMDE=），分享就變得比較困難。
希望如果有原本的網頁單筆網址的話，可以補上這一塊。
HHWang> 這我們會加強，有網址的話一定把它補上。
後續更新