煩惱:資料、資料維度超展開

前言

多謝 @clkao 分享 sdmx-json,一個關於資料維度的定義。

也感謝 @au、@clkao 的訂正,我先前搞錯上面的連結的意思了。我以為是跟資料定義有關。

我認真閱讀了 w3.org 關於資料的文件。 我自已對於閱讀標準蠻排斥,但是因為 SheetHub.com 已經有相當的實作,所以讀起來很有感覺。

關於 URI

URI 應該永遠不要改變。所以這跟我們現在 SheetHub 的做法不一樣,我們現在可以讓使用者自由的更改名字。我們現在有兩個地方會改變,一是使用者可以改資料集的名字,二是使用者加索引的時候,名字會從 ID 變成標籤。

所以這兩件事都不太好,原因是因為別人會連到你的資料,假如你容許可以改變的話,東西就會爆掉。

我們原本的初衷,是希望超連結可以方便理解,對於改 URI 我們先前的想法,是可以把舊的 URI 記錄下來,讓就的使用者還是可以連結的到。這有一點像是 Hackpad 有的功能,你假如連到一個名字被改掉的 pad,他還是會幫你導向到正確的。

不過這一個文件的確讓我思考:在最極端的情況下,我們可以針對每一個資料集提供一個 ID,沒有意義,且永遠不能更改,有一點像是 permantlink。

另一方面,針對語意的部份,我們有另外一個平行的 API,這些 API 全部都是pointer,所以比方: sheetHub.com/muyueh/台灣GDP 可能會指到 3% 之類的數字。sheetHub.com/muyueh/台灣 2015 年GDP 也會指導一樣。但是當明年變動的時候,sheetHub.com/muyueh/台灣GDP 就會指到 2016 年的。這些 pointer 隨便指什麼東西都可以。

所以假如需要進行語義搜尋的時候,就使用語義 API,假如是需要連結資料的時候,就使用不會更動的 ID。

Data Vocabulary / 資料定義

所以這裡有幾個不同的定義,分別是資料自己的定義,資料維度 (Data Cube)的定義,資料目錄 (Data Catalogue)的定義,以及(資料組織)的定義。

資料定義 / Data Vocabulary

JSON-LD (JSON-Linked-Data) 是 JSON 版支援這一個格式的東西。所以簡單解釋的話,JSON-LD 在做這一件事情:

{
  "@context":
  {
    "name": "http://schema.org/name",  ← This means that 'name' is shorthand for 'http://schema.org/name' 
  }
}

想像我們表格的表頭,或著是 JSON 裡面的 key 會亂取名字。這裏的解決方法,就是每一個名字都會有一個定義。這也是我原本所說的東西:

資料應該區分為最小單位,有一個好的定義,並且可以以各種形式組合。

文件下方有一些詳細的定義。這跟我們原本接下來要做的事情很像:針對各種資料型態做定義。但這一件事情其實有一點困難。

所以比方電話號碼、經緯度、人名、地址、統一編號等都是一些跨資料集都有,而且應該可以定義的東西。

假如我們每一個東西都有一個嚴苛的定義的話,我們可以做 type-check,所以比方我們可以寫一個 regex 來解析說一組號碼是不是手機號碼。但假如我們今天有固定電話,那麼這一個 regex 就會長得稍微不一樣。而除了台灣,假如考慮這一個定義要在全球都可以使用的話,那我們可能還要加上國際碼。還有比方說出現轉分機的情況,那又是不同的情形了。

所以我們現在好像考慮所有的情形了,但又不是那麼確定。完美的定義會是我們已經知道所有事情的所有狀態,我們可以有一個很一致性的方法統整這些資料。

重點是這一個方法有一點行不通,因為我們資料一直在變動。我們可以預期接下來會越來越多我們未曾看過的資料型態。

我懷疑未來的資料定義不會是中央式的管理標準,而是分散式的:一個會隨著資料越來越多,而定義會變成越來越清楚的方式。

隱約的感覺解決這一個問題,Linked Data 就可以被優雅的做掉了。

假如你去看 Schema.org,就可以看到超級長的定義,每一個定義裡面,又有超級長的子定義。所以萬物都有一個標準的名字。光是看比如說「電影」這一個類別就嚇死人。比方說: "accessibilityHazard: A characteristic of the described resource that is physiologically dangerous to some users."

這樣的 approach 是讓世界上的萬物都有一個清楚的位置。在資料真的多的時候,資料彼此會串成一串,或許最後在連會去 Schema.org 會簡單許多?

資料維度

w3c 的標準是 Data Cube、另外還有 JSON-stat以及sdmx-json

關於資料維度,我還沒細讀,但我今天終於瞭解為什麼這一件事情很重要。資料維度是在討論資料集的問題。也就是資料可以有不同的方式展開。有趣的地方,在於假如我們可以定義好幾個固定的展開方式,就表示有幾種可能的資料結構,有幾種可能的資料結構,我們就可以設定一個有效的視覺化。

而這或許是為什麼 @clkao 一開始貼給我的原因。

所以 Google Spreadsheet 裡面應該就有做這一件事情,才可以自動針對資料展開。

Observations are grouped together into a "data set". However, there can also be an intermediate grouping. For example, all exchange rates for the US dollar against the euro can be measured on a daily basis and these measures can then be grouped together, in a so-called "time series". Similarly, you can group a collection of observations made at the same point in time, in a "cross-section" (for example, the values of the US dollar, the Japanese yen and the Swiss franc against the euro at a particular date)

所以我現在只知道資料可以針對時間、空間、類別展開。應該還有其他的方式。改天再就繼續研究資料維度可以怎麼樣展開。

關於 JSON-stat 以及 SDMX-json 的差別

前者似乎更為輕量。