[INDEX] [HOME]

index

TEI の役割[スライド一覧]

1998.11.
1998.11.23 現在 31 まで。
※ 目次に番号を付けた。


 <目次>
  1. 概観
  2. T. プロジェクトの段階
  3. 第1段階: 分析
  4. 文書の分析
  5. 文書の分析結果
  6. TEI のカスタマイズ
  7. TEI 主要 DTD タグ・セット
  8. 第2段階: 設計
  9. 認識基準
  10. 設計段階の成果
  11. 第3段階: プロトタイプ
  12. プロトタイプの型
  13. プロトタイプに学ぶ
  14. ユーザ・インターフェイスの実物大模型
  15. トイ・システム
  16. プロトタイプ段階の成果
  17. 第4段階: 実装
  18. スタッフの訓練
  19. 絶対安全なシステム
  20. ワーク・フロー
  21. データの把握
  22. データの拡充
  23. プロジェクトを辿る
  24. 実装段階の成果
  25. 第5段階: 検査/品質管理
  26. 品質保証
  27. 品質保証技術
  28. 第6段階: 普及と維持
  29. 交換流通
  30. 配布
  31. プロジェクト組織の問題
  32. プロジェクトの企画
  33. スケジュール設計
  34. 配布できるもの
  35. 更新計画
  36. 履歴管理
  37. 職員
  38. 誤りから学ぶ
  39. 実装ミスの4つの型
  40. 誤りを避ける
  41. 遠近両用レンズ
  42. 難題から戻る
  43. TEI によって困難になる場合
  44. TEI によって簡単になる場合
  45. TEI によって変わってしまう場合

TEI の役割

What the TEI Means for Your Project
C.M.スパーバーグ・マックウィーン

(C.M.Sperberg-McQueen)

1996.7 スライド、DRH talk
1997.6 増訂、CETH '97
1997.7.13 再訂、ミュンヘン

[TOP]

1 概観

  • プロジェクトの作業における TEI の効果
  • プロジェクトの組織
  • 失敗から学ぶ
  • TEI によって困難になるもの、容易になるもの、変わらないもの
[TOP]

2 T. プロジェクトの段階

「滝のモデル(waterfall model)」はソフトウェア開発だけに限らない。

  • 分析
  • 設計
  • プロトタイプ作り
  • 実装、制作、ワークフロー
  • 試験と完成
  • 維持と普及

組織と制御の問題は、「すべての」段階に影響する。

[TOP]

3 第1段階: 分析

  • 目標の分析(プロジェクトの範囲を定める。)
  • テキスト領域の分析(文書分析)
  • 全体計画
  • 必要な方策の分析
[TOP]

4 文書の分析

文書分析は、あらゆる重要なプロジェクトの第1段階として不可欠である。

  • 目標と背景を明らかにする。
  • 問題のテキストの特徴を見定める。
  • 特徴相互の内部関連を明らかにする。
    • 封入(containment)、連続、交替
    • 意味的グループ分け
    • 構文的グループ分け
  • 特徴セットの拡充
[TOP]

5 文書の分析結果

文書分析の結果は文書化するのがよい。

  • プロジェクトの目標を記述
  • ユーザの要求
  • プロジェクトの文書領域の記述
  • 文書の基本的構造
  • 頻度が少く、記述の困難な構造
  • 語句レベルの、構造に関わらない現象
  • 具体例
[TOP]

6 TEI のカスタマイズ

  • 文書分析
  • タグ・セットの選択
  • 要素の選択
  • 認識基準
[TOP]

7 TEI 主要 DTD タグ・セット

  • 6つの基本タグ・セット1
  • 基本タグ・セットの 114 通りの組み合わせ
  • 10個の付加タグ・セット2
  • 主要 DTD の約120,000通りの表現(views)
  • 要素と属性の数を抑え、変更し、付加する。
[TOP]

8 第2段階: 設計

設計は、高次の設計段階と低次の設計段階に分けられる(また、分けたほうがよい) 。以下のものを設計せよ。

  • 最終結果:引き渡し要件は何か。
  • 最終結果:データ(マーク付けされたもの)
  • ワークフロー
  • 途中で引き渡し可能なもの、里程標
  • ツール
[TOP]

9 認識基準

それぞれの TEI 要素型 X を定めるには、
コーディング担当者がここで X をタグ付けするために、あるいはしないために以下のことをどう伝えるか、と問うのがよい。

  • TEI のカスタマイズ計画
  • プロジェクト・マニュアルに記録すること
  • TEI ヘッダの tagUsage 要素で表すこと
[TOP]

10 設計段階の成果

設計段階の結果は、数種の文書にまとめるのがよい。

  • プロジェクトの手引き: プロジェクトの作業計画と手続きを記述。
  • マーク付けのマニュアル: タグ付け方式の記述。実例、認識基準、あらかじめ用意した品質測定法(字体の割合、タグ付けの誤りの割合、他)も含む。
[TOP]

11 第3段階: プロトタイプ

  • 少なくとも1つのプロトタイプを実行する。(1%, 10%, 100%)
  • プロトタイプの型。
  • プロトタイプから学ぶ。
[TOP]

12 プロトタイプの型

  • 項目見本
  • ユーザ・インターフェイスの実物大模型
  • 作業用トイ・システム
  • 生産システムの試験見本

〔注意〕
生産計画とワークフローも生産物であり、設計・プロトタイプ作り・試験は必要だ。

[TOP]

13 プロトタイプに学ぶ

プロトタイプはいくつかの点で役に立つ。

  • コンセプトの実証
  • マーク付けやワークフローの問題点の検出
  • 設計の進み具合を計る。

プロトタイプを使うのはそこから学ぶためである。よく注意しておく(書いておく)。

  • 未解決の問題
  • 一時的な解決
[TOP]

14 ユーザ・インターフェイスの実物大模型

ユーザ・インターフェイスの実物大模型は、以下の点を解明するのに役立つ。

  • ユーザの要求
  • 求められる情報のエッセンス
  • ソフトウェアの特徴
  • 原案の有益な拡張と制限

〔参照〕 従来の辞書制作者の項目見本

実物大模型を作る3つの方法:

  • SGML ソフトウェアと特製スタイルシート
  • 模型制作用ソフトウェア
  • 紙と画鋲(ユーザ・リサーチ用)

細かい点は、適宜判断せよ。

[TOP]

15 トイ・システム(Toy Systems)

トイ・システムのポイントは全体システムを検証することである。

  • データ・ソース
  • データの流れとフィルタかけ
  • 出力

ただし、トイ・システムは、

  • 簡単なものでよい。
  • 不安定でもかまわない。
  • 処理が遅くてもよい。
[TOP]

16 プロトタイプ段階の成果

  • 一つないしそれ以上の作業プロトタイプ:
    • 稼働するソフトウェア
    • 夾雑物を含まないデータ
    • 基本的機能性を示すユーザ・インターフェイス
  • 一つないしそれ以上の文書:
    • プロトタイプの記述
    • 結果の評価
    • 次の段階への指示
[TOP]

17 第4段階: 実装

  • ワーク・フローを作る問題
  • データ取得
  • データへの付加情報
  • 問題の追跡
[TOP]

18 スタッフの訓練

  • SGML
  • TEI
  • プロジェクト手続き
[TOP]

19 絶対安全なシステム

  • 「遊び」を組み込んであるか?
  • スタッフのXが明日バスに轢かれたとしたら、プロジェクトは自動的に解体してしまうか。
  • それとも続いていくか。
  • アポロ13号のような危機(Mir氏)
[TOP]

20 ワーク・フロー

ワークフローを慎重に練る。以下の点に注意。

  • マーク付けは、一度に加えなくともよい。階層的にタグ付けする。
  • マーク付けは、同一人物による必要はない。専門的な処理過程でそれぞれタグ付けする。
  • 原本を参照する必要を最小限のものにする。
  • マーク付けそれ自体を活用する。
[TOP]

21 データの把握

  • スキャニングと OCR
  • 固有のキーボード規則
  • 外部の(互換)キーボード規則
  • 既存電子資料の入手

これらはすべて以下の問題を含む。

  • 品質の確保
  • 誤記訂正
  • タグの付け直し
[TOP]

22 データの拡充

TEI はデータ把握に使うことができるが、専用のデータ把握用 DTD があれば余分なキーストロークと時間を節約できる。次の点を確認せよ。

  • 定義の明確さ
  • アーカイヴ形式への置き換えが容易であること

いったん把握すれば、データというものはバッチ処理または双方向的なツールを使って仕上げ、処理し、フォーマットし直し、拡充することができる。

  • SGML 対応エディタ
  • 自動タグ付けソフト
  • 分野別専用分析ツール(POS タグ付けソフト、照合プログラム、他)
  • SGML 相互変換ツール
[TOP]

23 プロジェクトを辿る

プロジェクト進行中、以下の諸点を見失わないようにする。

  • プロジェクト・マニュアル(処理手続)
  • タグ付けマニュアル(タグ付け方針)
  • 懸案の問題と暫定的解決の一覧
  • マーク付けの対象(what)問題点(problem) という要素の型
[TOP]

24 実装段階の成果

  • 実際の製品(たいがいは開発途上のもの)
[TOP]

25 第5段階: 検査/品質管理

検査を別の段階として切り離して扱うことは体のいい虚構である。計画時には有効でも、本当に実行に移したら危険である。4つの戒律を挙げておく。

  • 当初から検査と品質管理をワークフローに組み込んでおくこと。
  • エラーの出現割合その他に対して量的に明確な目標を立てておくこと。(ゼロもまた数値である。)
  • データを清潔に保っておくこと。もし、それが出来ないなら、少なくとも、
    • 何が清潔で、何が汚いかをはっきりさせておく。
    • スケジュールの中にクリーンアップ又は変換のステップを付け加える。
  • 早めに、ちょくちょく検証すること。
[TOP]

26 品質保証

  • SGML にかかった費用ではない。
  • SGML の検証。
  • SGML に支援された照合。
  • SGML の助けを借りない照合。
[TOP]

27 品質保証技術

  • 原文と照合しての校正
  • 単語リストのチェック(スペル・チェック)
  • 番号の並びのチェック
  • 要素サイズのチェック(ページ、詩行、他)
  • 構造的一貫性のチェック
  • 原文情報の保守(名前、日付、標題、他)
[TOP]

28 第6段階: 普及と維持

  • 交換流通
  • 紙による配布
  • 電子的配布
[TOP]

29 交換流通

システムは様々である。ネットワークのゲートウェイは当てにならないことがある。従って、以下のように計画する。

  • テスト文書を送る。伝送の過程で残る文字はどれか。
  • 伝送のため圧縮する。確かでない文字を確かな文字列(実体参照)に置き換える。
  • 受け取ったら解凍する。伝送用の文字列を機種依存文字に置き換える。

書記(文書特性記述)システム宣言は、テキストの圧縮・解凍の自動化をサポートするためのものである。

[TOP]

30 配布

紙による配布に必要なもの。

  • SGML 依存のフォーマッタ(DSSSL、FOSI)
  • SGML 対応のフォーマッタ
  • 他のフォーマッタへの変換

電子的配布に必要なもの。

  • SGML 依存のブラウザ
  • SGML 対応のブラウザ
  • 他のブラウザのマーク付け方式への変換(HTMLへの変換を含む。)
[TOP]

31 プロジェクト組織の問題

  • プロジェクトの企画
  • 更新計画
  • 誤りの類型
  • 誤りから学ぶ
[TOP]

32 プロジェクトの企画

[TOP]

33 スケジュール設計

[TOP]

34 配布できるもの

[TOP]

35 更新計画

[TOP]

36 履歴管理

[TOP]

37 職員

[TOP]

38 誤りから学ぶ

[TOP]

39 実装ミスの4つの型

[TOP]

40 誤りを避ける

[TOP]

41 遠近両用レンズ

[TOP]

42 難題から戻る

[TOP]

43 TEI によって困難になる場合

[TOP]

44 TEI によって簡単になる場合

[TOP]

45 TEI によって変わってしまう場合


/←1/
/←2/

補注

    • 散文
    • 韻文
    • 戯曲
    • 談話資料
    • 辞書
    • 語彙データ
    • リンク、区分分け、配置
    • 簡単な分析
    • 特徴的構造
    • 信頼性と責任
    • 原文の転写
    • 本文批判
    • 名前と日付
    • ネットワークとグラフ
    • 数値、数式、グラフィック
    • 言語コーパス
[以上]