資料をデータにするとき、何を実体として立て、何を属性とし、何を実体間の関係とするかの選択は、後でどんな問いを立てられるかを決めてしまう。この選択は技術上の選択であるより前に、解釈上の選択である。

何を実体とするかという選択

力士を実体とするか、番付上の出現を実体とするか。公演を実体とするか、演目を実体とするか。この区別によって、後でどんな集計ができ、どんな比較が可能になるかが決まる。相撲番付のアーカイブでは、宝暦7年(1757年)から慶応4年(1868年)までの110年210場所の番付を翻刻し、登場するすべての力士の名前をリスト化して、延べ48,300行を超えるデータリストを構築した [UC-036 §従来型の人文学型DH：相撲番付と祇園のアーカイブ]。この設計では力士の名前が索引可能なエントリとして立てられており、その結果、データは力士検索データベースとして機能するものになった [UC-036 §従来型の人文学型DH：相撲番付と祇園のアーカイブ]。祇園のアーカイブでは絵画資料420件と花街舞踊公演の上演記録456件がそれぞれ別個に登録されており [UC-036 §従来型の人文学型DH：相撲番付と祇園のアーカイブ]、資料の種別ごとに実体の粒度を決めたことが設計の軸になっている。

構造が問いを先取りするということ

資料を画像にするだけでは研究基盤にならない。デジタル化は抽出の技術であり、資料が持つ情報の多くは欠落する。そのため、いつ・どこで・誰によって作られたのか、他の資料とどのような関係にあるのかを示すメタデータを付与し、研究上の問いと結びつける必要があるという整理がある [UC-036 §デジタル・アーカイブからDHへ：ARCが積み重ねてきたもの]。この整理は、構造の設計が問いを内包することを示している。どの属性を記録し、どの関係を明示するかが、後でその資料に向けられる問いの射程を規定する。

バム遺跡の事例では、資源をクラスとして体系化して記述するオントロジー的なメタデータの付け方が採用された [UC-020 §メタデータの管理と公開]。オントロジーは実体の種類とそれらの関係をあらかじめ定義する枠組みであり、その定義が「何と何が関係しうるか」についての解釈を固定する。語彙にはDublin Coreなどの標準が組み合わされ、国際標準のメタデータとしてObject IDも利用された [UC-020 §メタデータの管理と公開]。標準語彙を用いることは他のデータセットとの接続可能性を設計の段階から確保する選択であり、構造の設計が後の利用を規定するという関係をよく示している。語彙とスキーマの選び方そのものは「メタデータ」を参照されたい。

本文から切り離して注釈を持つやり方

バム遺跡の復元では、遺跡の正確な構造(ジオメトリ)を作る作業と、それを記述するメタデータの作成とが分かれていた。メタデータはオントロジーエディターのProtégéを用いて作成され、公開にはRDFストアにPostgreSQL、RDFのAPIにApache Jenaが用いられた [UC-020 §メタデータの管理と公開]。モデルそのものと、そのモデルについての記述とを別個に持つ設計は、資料本体と注釈を切り離して扱う考え方の一例といえる。こうした分離には、記述を後から追加・修正しやすくなる利点がある。一方で、本体と記述の対応関係を維持する管理が別に必要になる。

同じデータ構造から複数の見せ方を生成するという問題もある。祇園のアーカイブでは、研究者向けのデータベースと、解説付きのカタログ型で幅広い層を想定したバーチャル・インスティテュートとが分けて提供されている [UC-036 §従来型の人文学型DH：相撲番付と祇園のアーカイブ]。構造を設計する段階で想定する利用者と問いの種類を意識することが、後の公開形態に影響する。

構造設計が解釈である、ということ

3次元復元では、欠けている部分を補う際にペルシャ建築として妥当な構造かという観点が求められ、突起物や窓、門の形などを適当に決めるわけにはいかないという [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。この事例では当初、コンピューターの専門家がモデリングも担い、遺跡の専門家は指示を出すだけだったが、うまくいかなかった。そこで遺跡の専門家がモデリングを担う形に改めたところ、正確な画像が作れるようになった [UC-020 §モデリングとレンダリングの分担と精度・コストの調整]。欠損のある資料を構造として表現するとき、何を補いどう補うかは、対象についての専門的な解釈を前提とする。構造を決める作業は、中立な記録行為ではない。