Manage Correlated Data Across Services ?

利用不同的 Services 來存放不同的 Data, 然後在一個統一的 Blog 展示是目前 BSP 系統的標準設計模式. 然而 BSP 對於整體 Data 的管理策略可能還有值得討論的地方.

無名的例子來說, 進行 Blogging 的使用者可能同時利用他的網路相簿跟網路影音服務, 但基本上該兩項服務的 Data 跟 Blog 本身是分開的, 只是在 Blog 上提供可以存取該 Data 的介面. 有時候使用者如果因為特殊原因要暫時關閉該 Blog, 原則上相關的 Data 應該也無法取得才對.

例如無名的 tiger302 這個 Blog, 因為某些理由被使用者關閉, 因此相關的相簿影音等資料也無法取得. 但是如果你從 無名影音 進行搜尋的話, 事實上還是找的到相關的 Index, 只是連結進去後一樣是無法讀取.


然而, 雖然無法透過尋常的 Blog 或是搜尋介面看到影片資料, 如果有心人在 Blog 開放時留下影片連結的話, 居然是可以直接看到理應被禁止存取的影片 Data, 例如同樣是 tiger302 上傳的這隻影片 :


顯然地, 無名是利用禁止某些 Service 被執行, 來達到禁止 Data 被取得, 但是這樣作就會產生上面的這種漏網之魚 -- 也就是某些公開的 Service 還是可以取得該資料.

同樣的情況在其他的 BSP 上也可能出現, 如果 BSP 沒辦法讓使用者把相關的資料都綁在一起作管理的話, 就可能出現文章被禁止存取了, 圖片跟相關影片卻還是可以被取得的情況. 然而, 以使用者的角度來說, 文章就包含了圖片跟影片, 而非只有文字而已. 因此相關 Data 都應該被禁止存取.

在無名的例子中對於此問題還算好解決, 只要 BSP 願意多花點心思調整一下 Data Model 或是 Access Model, 提供給使用者在發表文章時作選擇即可. 然而當這個問題是跨服務 (Across Services) 時就會複雜許多.

在幾年前的台灣 BBS 也存在類似的問題. 當時全台灣大大小小的 BBS 可能有上千個, 透過 Mailing List 原本的機制, 彼此轉信變成一種風潮. 但是轉信的看板之間卻出現一種問題, 當有使用者錯發文章, 或是不恰當的文章要被刪除時, 只有原本的發信站做了刪除, 其他收信站還需要該站或看板的管理者再做一次判斷. 造成垃圾文章需要花費大量的人力管理刪除. 後來的 BBS 發展出 control.cancel 協定, 只要支援該協定, 可以透過轉信機制自動刪除在發信站已被刪除的垃圾文章.

但這要在不同的 Services 之間, 支援共同的 Protocol 似乎難度大的許多, 況且允許的動作也不是簡單的刪除而已.

3 意見:

Cox 提到...

我覺得你舉的例子不見得每次都是那樣的情況. 就好像, 有人用 Word processing app 編輯文章, 插入的圖片會變成一個 clone 存在文章的 container 裡, 而和原本的圖片獨立. 但是有的人不希望最後變成有兩份圖片, 或是修改原圖之後, 希望文章裡的圖片也跟著修改. 這就是 service model 與 data model 的 mismatch problem.

我覺得問題是出在於 service-oriented usage 與 data-oriented usage 兩者的整合上面. 簡單的說, 就是現在還沒有 object-oriented service 阿. 但是, 也不是有了 OO 就可以解決. 有了 OO, 我們照樣面臨 abstraction granularity 的問題.

關於 digital data management, 我最近剛好有在想一些東西, 與這個有點相關. 有使用 Flickr 的話應該會知道使用者可以為每個圖片設定它的 license. 但是, 這樣的設定其實只是宣稱. 當我在某個 blog 想要引用別人的圖片時, 我可能要利用 HTML 語法 hyper link 到那個圖片, 或是我把圖片存下來上傳到我的 blog, 然後註明原作者是誰. 但是, 這些情況都顯示, data 與 metadata 是分開的, 尤其是管理 accessibility 的 metadata.

我覺得現在需要的是一種 digital media host, 它不只提供 storage 來放這些 digital media, 它還提供了 accessibility control, 而且是 cross service 的 accessibility. (又回到 7-11?)

seLain 提到...

是否可能在 這篇 : A Component Model and Infrastructure for a Fluid Web 的基礎上建立呢 ?

感覺上不只是把 Internet 視為一個 Database, 而是更進一步在其上建立 DBMS ?

Cox 提到...

eh, 我們總是可以這樣想. 例如, 某某 model 真是好用 (FAMIX for example), 我們用它來表達 forward engineering 中的 design model, 也可以在 rev. eng. 的時候當作 program analysis 的 result. 如果你是那 model 的發明者, 我覺得你可以很廣泛的應用你的 model 在許多不同 application domain 上, 這或許是件好事. 但事實上, 它真的那麼 powerful 嗎? It might be good to reuse a technique, but is it the best way we can do? 我們是是圖解決一個新的問題, 還是我們只是想廣泛應用既有的東西?

Think small, think every problem a unique one. 就像你最新文章裡面提到的, 我覺得這也是一種研究的方式或態度. 至少在 approach 一個 problem 的一開始, 把它當作是新的, 我覺得會更容易看見問題的本質, 而不會受關聯性的思考影響.

Designed by Posicionamiento Web | Modified by seLain | Bloggerized by GosuBlogger | Blue Business Blogger