On data browser for users

=Representation Browser for users=


 * Function requirement: User can reach to the parts they want by 3 steps max.
 * Tree menu is too deep and time consuming. FMA deapth.


 * 1) USE PHYSICAL FEATURE OF CONCEPT TO DIVIDE-- "boundary cuboid"
 * 2) USE LARGE CONCEPTS TO NAVIGATE:  Start from bigger concepts and break it down to elementally parts.  大きなサイズのアイコンを使ってナビゲートする


 * 共通の基本動作としてLogicalIconをたたくと下位のアイコンに分解できないか？　これができれば適当なレベルの上位概念のアイコンをタイリングしておくだけでブラウザになると思うんですけど
 * 提供されている上位概念から、深い階層にある要素に辿りつく場合、下位概念への分解で発生する不要なパーツが累積していくことで、扱いにくいインタフェースにならないでしょうか？(imuto)
 * 全身みたいなあまり大きな塊を提供せずに20個くらいのアイコンを包含してるものに限定しておけばコントロール可能かと思います（大久保）

=Data processing=


 * Art file
 * |<--    Left right middle judgement from the data
 * |---> WebGL viewer
 * |<--    tentative mapping to concept (inference from file name mainly)
 * |<--    Body version assignment
 * |<--    Shift, Mirror, tilt (Art in context)---> Icon?
 * Art in context
 * |--->  WEbGL polygon viewer
 * |<--Inspection, approve or change concept label
 * AIC with approved concept ---> Icon
 * |<--expansion to upper concept representation <---Ontology
 * Logical-AIC >Icon

=Data management= To identify one data as one and to provide their unique features.
 * 1) Art (Raw polygon file): Polygon data provided from outside (input to system) Concepts are tentatively given by inference form the file names
 * 2) *Art ID:
 * 3) *original file name:
 * 4) *Creation date:
 * 5) *Creator:
 * 6) *Left/right/middle
 * 7) *tentative concept:
 * 8) *tentative mapping table:
 * 9) Art in context :Art files modified to be A part of human body. Tentatively mapped Concepts to Arts are approved or altered by human inspection in the concept.
 * 10) *AIC-ID:
 * 11) *Art ID:
 * 12) *Process#1: null, or mirror
 * 13) *Process#2: shift 01
 * 14) *Process#3: tilt 01
 * 15) *date of Processing:

Representation management
Reprentationは変化するがrepresentationにも値があるのが難しい点です IDのある概念とIDのあるAICの関係ですから　それぞれの特徴として管理することも可能です しかしながら非常によく呼び出されるのであらかじめクラスタを作ってそれを管理することも可能です
 * 1) Direct concept representation:これはAICの属性として管理したほうがいいかも
 * 2) Direct Representation ID
 * 3) *Concept ID:
 * 4) *AIC_ID:
 * 5) *boundary cuboid volume:
 * 6) Logical concept representation: これが非常によく変化する"A unique group of E-AIC" logically combined to represent a concept.  One LAIC may represent many concepts.  different L-AIC have different combinations of P-AIC.?
 * 7) Logical concept representation ID
 * 8) *concept ID
 * 9) *contributing concepts with P-AIC
 * 10) *mapped AIC (L-or P) ID
 * 11) *ontology ID
 * 12) *Representation density:formula

=Expected queries to the system=
 * what data is this icon made of ? tree name, answer in concept names/AIC names
 * If one can break down the icon(of a concept) into icons of component concepts, this is achieved.
 * Change the AIC-concept map ---> automatically change ICON for the concept and Logical representations above it.

=HOW to make Logical AIC=
 * oboファイルから全concept_idの親子関係をツリー毎（conventional、is_a、part_of）にデータベースに取り込み（treeデータが変わらなければ更新不要. Conventionalはobjファイル群のバージョンが変わるとTree構造も変わる）
 * concept_id、parent_concept_idを項目として持ち、親から子、子から親の両方向に辿れるデータ構造としておく
 * artにconcept_id 対応付け（人手による）
 * 全てのconcept_idに関してsubordinateをleafもしくはconcept_idが存在する中間ノードまで辿り、それらを全てのパーツを用いて描画した画像を作成
 * この際に、同時に表現密度、boundary cuboid volume、xyz max/min、volume等を計算し、利用したconcept_id（およびobjファイル名）を保持
 * Physical-Logical 対応をはく

=HOW to update Logical AIC=
 * artの更新ないし、concept_id対応付けを更新（concept_idとの新規対応付け、対応付けの変更・削除も対象）
 * 変更のあったconcept_id（id付け替えの場合、付け替え元と付け替え先の両方）からルートに辿りつくまで親を辿り、途中経路にある全ての中間ノードの画像を更新する
 * leafではなく中間ノードであるconcept_idに新たにartが対応付く場合もあるため、同時に表現密度等の再計算と利用したconcept_id（およびobjファイル名）を改めて保持しなおす
 * Physical-Logical対応を更新

BodyPartsWiki

 * Data(AIC) --- ---> {concept 1, cencept 2, ...}
 * Concept --- > {Data (AIC), Data 2, Data 3, ...}
 * Data have various features : cuboidal volume, art name,
 * A group of data have features of data: