散布図を用いた可視化の問題点として
,
データ数が増加した際の重なりの発生や視覚的混乱に よるデータ傾向の解釈困難性,
分析者の認知的負荷増大が問題となる.
具体的には,
各属性に対 する強調度合いを表現するパラメータωの比較分析は難しくなるため,
元データの特性と,
低 次元空間に可視化されたオブジェクト配置との関係を理解するタスクの困難性が指摘されている
[76].
属性数や時点数の増加に関しても同様の問題が想定される.
特に,
時系列データの時点数が増えた場合に
,
パラメータを時点ごとに調整し,
結果を検証するタスクは分析者にとって困難で ある.
そのため,
データ数,
属性数,
次元数に関するスケーラビリティの問題に対処するための,
提 案フレームワークの拡張可能性を議論する.
データ数に関する問題に対処するためには
,
オブジェクト集合をカテゴリや投影空間における 近接性に基づく集約表示や,
教師なしクラスタリングアルゴリズムの適用結果に基づく,
集約表現 による可視化が望ましい[76].
オブジェクトの集約表現に用いられる可視化手法の一例として,
凸包のようなポリゴン表現が存在する[90].
また,
図6
に示すような密度ベースの凸包表現のよ うな集約された表現を用いると,
データ数に依存せずに傾向を理解しやすくなる.
また,
それらを 集約領域内における個々のオブジェクトの可視化と重ね合わせることで,
個々のオブジェクトに 関するコンテクストを喪失せずにオブジェクト集合の特性を比較できる[90].
一方で,
指標構築 タスクでは,
データセットが含む全てのデータを視覚的分析の対象とするよりも,
データセットの 特性を保持するようにサンプリングされたデータを用いる分析手法も考えられる.
そのため,
サン プリングされた代表データのみを表示する手法も有効と考える.
また,
外れ値のみをオブジェクト として表示し,
他はクラスタごとに集約表現で表現するような集約・可視化手法も有効と考える.
属性数に関する問題については
, 2.4.1
節で示した指標形成プロセスの1
段階目[18]
における,
重要な属性値の選択・削減の適用が行える.
属性値の削減結果に対する提案フレームワークの適 用により,
ある程度スケーラビリティの問題を克服できると考える.
また,
画像や音声のような属 性数が多く,
各属性自体が明確な意味を持たないデータを対象とする場合には,
特徴量の抽出な どを適用した結果として得られる,
少数の属性に対して,
提案フレームワークを適用すべきと考 える.
時点数に対する問題については
,
一定区間ごとに対象データをサンプリングする手法や,
変化傾図
6.
オブジェクト集合の密度に基づく凸包の描画例向ごとにデータを分割するなどの前処理の適用が解決手段として考えられる
.
そのため,
提案フ レームワークと既存の多次元時系列データの前処理フレームワーク[11]
の統合が有効と考える.
4 プロトタイプインタフェース
3
章で提案したフレームワークの実現可能性や有効性を実際の視覚的分析インタフェースとし て実証するために,
フレームワークを主成分分析による次元削減結果に適用し,
可視化結果に対す る指標構築を目的としたプロトタイプインタフェースを実装した.
本章では,
本インタフェースの 実装の詳細と,
想定される分析タスクを支援するために実装した各機能の詳細を述べる.
4.1 インタフェースのシステム概要
プロトタイプインタフェースのシステム構成を図
7
に示す.
本インタフェースは可視化インタ フェース,
コントローラ, API
の3
つの要素から構成される. API
は,
コントローラより渡された パラメータα,ωやデータセットの情報に基づき,
多次元データに対するパラメータ調整処理や オブジェクトの検索機能を実行し,
結果をコントローラへ返す.
コントローラでは,
可視化インタ フェースから呼び出された,
ファイル入出力に関係する各機能を実行する.
例えば,
パラメータや ラベル情報の入出力や,
操作履歴情報の保存,
操作内容の解釈結果に基づくAPI
の呼び出し,
ロ グの出力などを行う.
可視化インタフェースではコントローラより渡されたJSON
データやパラ メータ情報,
ラベル情報に基づき多次元時系列データを可視化する.
また,
操作ログを記録し,
パ ラメータ調整機能などのリクエストをコントローラへと非同期通信で送信する.
コントローラはRuby on Rails 5
を用いて実装した.
可視化と可視化インタフェースのUI
に関する処理はD3.js
v5
とjQuery 3.3
を,
コントローラと可視化インタフェース間のデータの送受信はAjax
を用いて実装した
.
初期時点におけるパラメータωに対応する次元削減結果の獲得や,
パラメータ調整機能は
Python 3
で実装されたスクリプトをFlask
*5API
により呼び出すことで実行される.
データは
JSON
形式でコントローラ(
バックエンド)
から可視化インタフェースへと渡され,
可 視化処理が適用される.
また, JSON
の形式として,
リスト1
に示すようなフォーマットを想定す る.
多次元データの各オブジェクトは複数の属性から構成される.
属性には,
次元削減の適用対象 以外にもオブジェクト自体の名称やカテゴリなど,
時間的な特性を持たないメタデータを含む.
そ のため,
配列vec
に格納された属性値のみを次元削減の対象として扱う.
このとき,
各オブジェク トは次元削減の対象となる3
つ以上の属性を持つと想定する.
例えば, 5.3
節のケーススタディで 用いる野球ドメインのデータでは打席数や防御率が次元削減対象となるデータ属性に対応し,
投 手名や所属チームがメタデータに相当する.
配列
time array
の中に, time-stamp
に対応する各時点におけるデータが時系列順に格納される.
各
time-stamp
における個々のオブジェクトは,
配列内のインデックスにより識別される.
各時点の配列の長さ
(
オブジェクト数)
は固定長であり,
全ての時点において同数のデータを持つ.
読み 込んだJSON
内の各オブジェクトについて,
時点(time-stamp)
ごとに散布図上へデータを可視化する
. name
属性はオブジェクトの名称として扱われる. time-stamp
の名称は各時点の識別子となり
, UTC time
の形式(YYYY-MM-DDTHH:MM:SS(,MS))
*6により記述されると想定する.
アニメーションの再生間隔は
, time-stamp
間の時間差からシステム側が自動で解釈して決定する.
例え ば,
データに含まれるtime-stamp
が2019-01-01
と2019-01-02
の場合,
日付部分をtime-stamp
の*5http://flask.pocoo.org/
*6https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global Objects/Date/UTC
名称として
,
日ごとにアニメーションを再生する. 2019-01-01T10:25:34
と2019-01-01T10:25:35
の場合は,
時間以降の部分を名称として,
秒ごとにアニメーションを再生する. JSON
ファイルに 記載されたtime-stamp
がUTC time
に従わない場合には,
文字列をそのまま名称とする(
例: 1
年 目).
データがあらかじめカテゴリ情報を持つ場合
, JSON
ファイルのcolor
属性に値が指定される.
color
属性値には数値型かテキストを指定でき,
システム側でデータ型を判断した上で,
各データの
color
属性値に基づき,
カテゴリをオブジェクトの色と対応づけて表現する. color
属性値に基づくオブジェクトの配色は
, D3.js
のカラースキーム*7に基づき決定される.
リスト1:提案インタフェースにおける入力JSONデータの形式
1 {
2 " time_array ": [
3 {
4 " time - stamp ": [
5 {
6 " name ", string ,
7 " color ", string ( or number ) ,
8 ... ,
9 " attr1 ": number ,
10 " attr2 ": number ,
11 ... ,
12 " vec ": [ number , number , ...]
13 }
14 , ...
15 ]
16 }
17 , ...
18 ]
19 }
視覚的分析 パラメータ調整
調整結果の フィードバック
データ パラメータ
操作の解釈結果 操作ログ
調整, 検索結果
データセット 調整済パラメータ
図
7.
プロトタイプインタフェースのシステム構成*7https://github.com/d3/d3-scale-chromatic
ドキュメント内
首都大学東京
(ページ 47-51)