煩惱:資料、資料維度超展開
前言
多謝 @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 的差別。
前者似乎更為輕量。