データは成功の鍵 - JACIC CALS/EC のホームページ

“. . . データレベルでの
相互運用性を持つことが必
要である”
-- U.S. Department of Navy
http://www.chips.navy.mil/archives/00_jul/data_interoperability.html
データは成功の鍵
Jerry Smith
DISA 相互運用性委員会
CALS/EC 国際シンポジウムにおけるプレゼンテーション
2001年1月
東京
概要
•
•
•
•
•
•
•
相互運用性の重要性
困難な課題
技術の向上
これまでの取り組み
最近の重要事項
今後に活かすべき事柄
まとめ
2002年1月、東京にて Jerry Smith
2
適切なデータを ….
適切な相手に ….
適切なタイミングで!
2002年1月、東京にて Jerry Smith
3
仮想企業の情報共有
最終目標
要件
„
„
„
„
„
„
シームレスなアー
キテクチャとシス
テム統合
対応する情報の
収集、処理、普及
攻撃的・防衛的
情報闘争
センサー
網
提携
網
共同計画
システム
ネットワーク
中枢
情報網
2002年1月、東京にて Jerry Smith
ネットワーク化
されたセンサー
強化された
C2システム
等々...
実現のため
の概念
共通操作の
図式
情報の優位性
精密な
戦場の知識
4
世界的情報網
(Global Information Grid：GIG)
共有
サーバー
KG
KG
KG
データ
サーバー
アプリ
ケーション
サーバー
クライアント
クライアント
Intel
Intel リーチバック
アプリ
ケーション
サーバー
クライアント
ISSE
センサー
クライアント
共有
サーバー
データ
サーバー
アプリ
ケーション
サーバー
クライアント
クライアント
JTF 配備
C2 リーチバック
KG
KG
データ
サーバー
KG
LOG リーチバック
アプリ
ケーション
サーバー
FW
アプリ
ケーション
サーバー
PERSONNEL リーチバック
アプリ
ケーション
サーバー
C2G
SECRET/REL
データ
サーバー
データ
サーバー
SBU/REL
NIPRNET (SBU)
シューター
インターネット
2002年1月、東京にて Jerry Smith
5
共同作戦にも 多国籍の軍隊間での
相互運用性が必要
米国軍
センサー
NATO 軍
その他の
連合国部隊
DB
GCCS
コマンドセンター
DB
タンク
ヘリ
船
飛行機
ミサイル
戦闘グループ
• 多国籍共同の相互運用性の成功はデータ共有能
力にかかっている。現実的な評価には使用するIT
標準の有効性評価が含まれる。
国防省の統合参謀本部 の情報技術問題についての最高顧問（LTG Kellogg, J6）は、
連邦法は軍隊に独自の武力を備える権利を与えているが、軍隊にデータの共有 が可
能なシステムの購入を義務付けるように改訂されるべきである、と言っている。
2002年1月、東京にて Jerry Smith
6
相互運用性の欠如
戦術弾道ミサイルの防御例
• 「データレベルではなく、情報（コンテキストの中のデ
ータ）レベルで現在の状態をみると、次のような問題
が起こる」
例：
– 最新のシステムからのデータは相互に関連したり、融合し
たりすることが困難。つまり、異なったセンサーが異なった
精度のレベルで、重複した領域をカバーすることが頻繁に
見られる。
– 重複、あるいは時に矛盾するデータは混乱や誤解の原因と
なる。
– 限られたデータしか管理することができない、異なったシス
テムは、情報が一貫せず、不正確で、また簡単に紛失する
などの可能性があることを意味する。
資料: Carmen Corsetti による引用、 “Roving Sands”：http://www.mitre.org/pubs/showcase/roving_sands.html
2002年1月、東京にて Jerry Smith
7
いまだに進歩していないデータ交換
• 運用:
湾岸戦争の際、空軍への指令は「フロッピーディスク」を船に届けて伝達し
た。誤った標的の指定は、民間施設を破壊する結果となった。
• 物流:
支援物資よりも食料を多く積んだConexコンテナ
• 医療:
撤兵行動の際、怪我人の位置や状態を探知することができないシステム
• 収集:
製品の使いはじめから終わりまで、製品データを共有することができない
2002年1月、東京にて Jerry Smith
8
なぜ STEPが重要か?
適切なデータを適切なタイミングで得ることの
重要性を過小評価してはならない
2002年1月、東京にて Jerry Smith
9
PLCS
製品寿命までのサポートに関する国際的な情報
標準を開発するための共同企業や政府決議。
3年以内に業務データモデルおよび標準案を作成
するために企画された国際プロジェクト
ISO 10303 STEPを使用したPLCS
（STEP：STandard for the Exchange of Product
model data - 製品モデルデータの交換に関する
標準）
問題の解決
問題の解決
目標
目標
どんなバージョン、システム構成なのか。
保守管理情報は最も必要なときに、旧式であった
り、不正確であったり、使用不可能であることが多
い。在庫を減らし、費用を削減したい。
どうすれば正確な、インサービス フィードバックを
得られるか?
サポート能力を改善することで製品の可用性を
大きく向上させる。
製品のライフサイクルサポート情報の費用、品
質、入手のしやすさを改善する。
ISO標準の技術開発を促進する。
商業ベンダーの早期実施を奨励する。
製品寿命までのビジネスモデル
運用
有効性
状態
サポート
エンジニアリング
機構
設計
例外
タスク
要件
ID
システム構成
状態
適用
文書作成
継続的な提携
および参照
システム構成
管理
製造
管理情報
管理情報
2002年1月、東京にて Jerry Smith
リソース
管理
コアとなる概念
および参照
システム構成
製品
ID
対象領域
対象領域
サポート
システム構成
管理
製品のライフサイクルを通した変化
の管理。規定の問い合わせ用製品
番号を付ける。
サポート
エンジニアリング サポートインフラの供給と維持
Inventory
リソース
管理
有形の製品の購入、在庫、梱包、
移送、供給および廃棄
保守管理と
フィードバック
スケジュール、リソース、フィード
バックなど、有形の製品の保守管
理、試験、診断、検度、修理およ
び変更
維持および
フィードバック
10
製品データの例
問題: 製品データのソースが
縦横に統合されていない
エンジニア
リング図面
JEDMICS
-- 4 Tech
Order
CAD
データベース
業者 カタログ
2002年1月、東京にて Jerry Smith
個人のファイル
仕様書
共有
方法は？
テスト
仕様
技術及び
評価
報告書
製造過程の
説明
11
情報の爆発
データの津波！
西暦2000年までは
情報は3年ごとに倍になった
z データは今後6年で20倍以上
にもなる
z
デ
ー
例えば、今や「文書」とは電子化された
次のものをいう：
タ
つまり、6年のうちに
データは情報の125,000倍になる！
文章
写真
グラフィック
音楽
色
アニメーション情報
今後6年間
映像
資料: George Gilder著、 “Life After Television”
2002年1月、東京にて Jerry Smith
相互運用性にかかわる問題点
• 多元的な環境の中での可搬性と信頼性が必要
とされている
• めざましい技術進歩にもかかわらず、データ交
換は依然として初歩的段階にある
• 「データそれ自体が重要であること」が運用の問
題や相互運用性の欠如によって証明された
• コンテキストの中のデータの意味が過小評価さ
れすぎていた
2002年1月、東京にて Jerry Smith
13
CALS/EC
• CALSの 起源
• CALSの 見通し: 物流の仮想事業を行う
• 名前の 進化:
•
•
•
•
Computer Aided Logistics Support
Continuous Acquisition and Logistics Support
CALS/EC
“Commerce At Light Speed!”
• 米国国防総省（DoD）におけるCALS/ECの現在
多少の組織的な変化はあったが、現在も本来の
目標および目的を追求している
2002年1月、東京にて Jerry Smith
14
CALS
DoDの調達およびライフサイクルのプロセスの改善
CALSの見通し
CALSは、統合されたデジタル操作への移行を促進する。また付加価値のある技術情
報、ビジネス情報を利用し、生産性を向上させる
CALSの目的
•
•
•
•
•
•
•
統合されたデータ環境の実現
システム構成とデータ管理の手法を統合
国際競争力の向上
実現化策としてのISO標準を開発
仮想物流事業の実現
運用・支援コストの削減
ペーパーレスの契約をサポート
共有情報は21世紀の生産性のための基盤である
) 統合されたデータ環境:
– 協力
– 事業の連結性
) 生産性向上を実現する要因:
– 共有情報へのアクセス
–プロセスの改善
– 共通のインフラ
2002年1月、東京にて Jerry Smith
進歩はしたけれど・ ・ ・
• コンピューティング
• 通信
• システム、ソフトウェアおよび
データエンジニアリング
• 標準
コンテキストの中の
データの意味の交換は
いまだに重要な課題！
2002年1月、東京にて Jerry Smith
16
コンテキストの中のデータ
• コンテキストが非常に重要 . . 単なるコミュニケーシ
ョン・リンクではない
• 武器の追跡と送達などを行う、戦闘システムやデー
タ・リンク の重要部分
• 正確でタイムリーなデータ共有は技術目標であり、
プログラムの中心である。さらに、最も重要な点とし
て、データ共有は作戦要件である。 (軍備配置）
資料: 2001年3月30日、31日、National Defense Industrial Association、Naval Interoperability Workshop 概要
プレゼンテーション より： http://www.ndia.org/committees/syseng/pdf/NIOMay01SumPres.pdf
2002年1月、東京にて Jerry Smith
17
意味あるデータは成功の鍵
• 「相互運用性の均等化において、データは非常
に重要な役割を果たしている。」
• 「相互運用性の問題の解決には、データ統合、
データ参照テーブルの同期およびデータの標
準化をさらに研究する必要がある。」
• 「データ管理およびデータの標準化は今後の研
究で重要な領域とするべきである。」
資料: Worldwide DoD CIO Conference、2000年頃
http://www.c3i.osd.mil/doc/dodcio-2000conf/New%20Pages/RTFinal_Interoperability.htm
2002年1月、東京にて Jerry Smith
18
データの相互運用性の課題
均質でないことを覚悟する!
• 唯一の標準を決めるのは困難！
• 防衛関連の団体は複数の「標準」を採用する
ことがあり得る
– 政府 (メッセージ、データベース、コード)、商用、国際、デフ
ァクト/レガシーなど
• 同一組織のシステム相互間でも異なった標準
を採用することがあり得る
2002年1月、東京にて Jerry Smith
19
過去の決議事項
データ標準化の指令
DoD 5000.2-R 「 DoD方針では標準データの使用に基づいてソフトウェアシステム
を開発する。 DoDD 8320.1には追加指示が盛り込まれている。」
DoDD 8000.1 「DoD方針では、 標準
のDoDデータ定義は、すべてのISに使
用されるもので、武器システムとISの間
のインターフェースも含む 。」
共同技術アーキテクチャ
「指令のあったDoDデータ定義の標準は
DoD 8320.1-M-1およびDDDSである。」
DoDD 8320.1
DoD データ管理
データ管理: 企業内でのデータの定義、
組織、管理、保護についての責任
DoD 8320.1- M - 1
データ標準化の手順
データ要素の
ライフサイクル
開発
候補
修正
承認
否認
防衛データ ディクショナリ システム (DDDS)
2002年1月、東京にて Jerry Smith
「武器システムや関連のテスト機器
に不可欠な、機器の操作およびソフ
トウェアだけのデータ要素や値に導
入される。」
完成
「課税の負担および標準外のデータに
変換する費用の負担。標準外のデー
タを使用していれば、コンポーネントの
情報の要求元に関係なく負担があ
る。」
責任:
• 機能的領域
– USD (A)
– USD (C3I)
– ...
• コンポーネント
– 陸軍
– 海軍
– 空軍
– 防衛機関
20
過去の決議事項
標準データ要素
C3（指揮・統制・通信）
諜報
1,678
317
情報管理
物流
737
物流
2,235
要員および準備
外部標準
1,335
1018
7.3%
DDR&E（防衛研究・エンジニアリング）
2,589
要員および準備
1018
健康問題
769
財務
449
調達
652
導入
230
環境保全
684
その他
628
合計
13,321
1999年3月9日現在
2002年1月、東京にて Jerry Smith
2,235
17.8%
環境保全
684
5.1%
諜報
317
2.4%
情報管理
737
5.7%
調達
652
4.8%
財務
C3
1,678
13%
449
2.6%
健康問題
769
5.3%
その他
DDR&E
2,589
18.7%
導入
230
1.7%
外部標準
1,335
10.3%
AISにて実施: 6,937
628
4.7%
何が問題なのか?
• 複数の標準化への多様な取り組み
- データ標準
- 記号標準
- 用語管理標準
- メッセージ標準
- デファクト標準
- 商用標準
成果: 異なったCMサイクル（および廃棄されたリソース）の中で発展した多
様な用語、定義、構造
• 脆弱なメタデータのサポート
– その場では有用なデータを見つけにくく、また分配しにくい
– 既存のGOTS（国庫技術）およびCOTS（民間技術）のデータリソースと
の連携が困難
– どのシステムがどのデータを使用するかを示す一貫した方法がない
• 緩慢な変革メカニズム
多すぎるプロセス − 不十分な成果
2002年1月、東京にて Jerry Smith
22
データ問題についての
最近のDoD取り組み例
• データ・エンジニアリング (COE SHADE – 共
有データ要素)および決議事項
• 市場主導型のデータ管理
• XMLリポジトリ
• PDMLプロジェクト
• セマンティックメディエーション（p.41に再掲）
• DAML (DARPA Agent Markup Language)
• PLCSプロジェクト
2002年1月、東京にて Jerry Smith
23
共有データエンジニアリング
(SHADE)
国防総省内でのシステムの相
互運用性およびデータ共有の
Data Engineering
(COE SHADE)
目標を達成するために必要なデ
ータ問題に取り組む
• 情報の普及を促進するDII COE
向けのデータ・サービス・インフラ
– 共有
– 相互運用性
– ソフトウェアの再利用
•
. . . 安全で、信頼性があり、世界的
な環境において行われる
• インフラが以下の要素のセットとし
て実行される
– 共有スキーマ
– サービス
– ツール
– 運用手順
. . .COEベースのミッション・アプリケ
ーションをサポート
UNCLASSIFIED
2002年1月、東京にて Jerry Smith
人員
材料
施設
特徴
リレーショナル
組織
複数の形態の共通セマンティクス
18
24
市場主導のデータ管理
目的
• ネットワークコンポーネントが「システム」
の完全な再基本設定や再認定を必要とせ
ずに独立して改良される、データ・リソース
の「認定」計画
– データソースやサービスの追加/削除
– コミュニケーション・パスの追加/削除
新しいデータソース
新しい
コミュニケー
ション･パス
新しい軍部
アプリケーション
– インフラストラクチャ・コンポーネントの更新
– アプリケーションの追加/削除
改良されたインフラ
(COTS & GOTS)
¾データ･リソースに対する「公開と承認」
のアーキテクチャを定義する
2002年1月、東京にて Jerry Smith
25
市場主導のデータ管理
新しいインフォメーションシステムの例
¾ 公開と承認の課題
– どこで、どのように、どのデータ・リソースが公開されるのか?
– ユーザーはどのようにリソースを見つけ、承認するのか？
– データ製品やサービス提供はどのようになされるのか？
• 背景: グローバルインフォメーショングリッド (GIG)
–
–
–
–
大規模にネットワーク化された環境
多くの複雑な相互接続
大量で、頻繁に変化するデータ・リソース
動的なネットワークアーキテクチャ
(例：危機状況に合わせた対応)
柔軟で反応の速い管理が重要!
2002年1月、東京にて Jerry Smith
26
市場主導のデータ管理
GIG 電子市場
顧客は製作者の宣伝する特徴に基づいた情報を簡単に発見し、
検索し、管理する。
その結果:
• 情報の製作者は、DoD標準のメタデータ、データ･スキーマ、 製
作者のプロファイリング メカニズムを使用して情報の入手しやすさ
や可用性を宣伝する。
• 情報の認識、アクセス、送信が促進される。・・・ 製作者のプロフ
ァイルやソースレジストリなどの共通のメカニズム。
• 信頼できる情報のリポジトリが確立され、組織はそこでデータお
よびメタデータの作成、コンパイル、分配、廃棄を行うよう指定され
、権限を与えられる。
DoD CIO G&PM No. 7-8170-082400 Global Information Grid (GIG) Information Management (IM)
2002年1月、東京にて Jerry Smith
27
市場主導のデータ管理
ビルドタイム
市場規則
データコンポーネントの登録
• 新規にコンポーネントを作成する前に市場を調査し、実際的な
ものについては既存のデータを再利用する。
• 正式な承認により、コンポーネントの計画的利用を示す。
• 追加コンポーネントまたは推奨モードを登録する。
研究会（Communities of Interest ：COI） の構成
• 運営に同意する者がいるとき、「必要に応じて」作られる
• 新しいCOIのスタッフへの要件:
– 既存のCOIマネージャー
– 上級サービス/エージェンシー エンジニア
– フラッグレベル審議会
2002年1月、東京にて Jerry Smith
28
市場主導のデータ管理
ランタイム データ市場関係者
• データの製作者
– 自分のデータ製品およびサービスを「宣伝」し、アクセス情
報を伝える
• データの消費者
– 一覧化されたメタデータを使用して、高精度の検索行い、ま
た修復ツールを動作させる
• 運用データマネージャ
– ランタイム市場取引で示されたユーザの要求に合わせてネ
ットワークコンテンツを調整する
• 防衛調達スポンサー
– 市場メトリクスを利用して調達管理をする （例：特定のデー
タサービスの利用データによって、プログラムの本当の価
値を反映する）
2002年1月、東京にて Jerry Smith
29
XML
COI ネームスペースの管理
• ネームスペースとは、様々な、重複したXMLの蓄積に識
別ラベルをつけることができる技術的なメカニズムのこと。
• DoD XMLの管理目的で、ネームスペースはCOI内で共通
のコンテキストを共有するデータ構造のセットを構成する。
– これらの蓄積は、「ネームスペースワークグループ」にサポ
ートされた「ネームスペース管理者」と呼ばれるチームリーダ
ーによって管理される。
– ASD/C3I向けにDISAによって設立されたCRCB (The
Configuration Review and Control Board)はネームスペー
スを認可し、それらに管理者を指定する。
2002年1月、東京にて Jerry Smith
30
データの交換の問題とXML
• XMLだけではデータエンジニアリングおよびアプリケーション
の相互運用の問題を解決することはできない。
– データについての既存の問題は今後もなくならないであろう。さ
らに、悪化することも考えられる。
• 重大な問題は、スキーマの意味論にある。
– スキーマは個別に開発されており、意味論的に別のものと一貫
していないので、データは「スキーマ間」で一貫して交換または翻
訳することはできない。
– XMLはその場限りのDTDの開発を促進するので、問題を悪化さ
せてしまう。
2002年1月、東京にて Jerry Smith
31
XMLの賢い利用
• XMLは素晴らしく画期的な技術だが、特効薬では
ない。つまり、既存のデータの問題がXMLですべて
解決するわけではない。
• XMLが唯一問題の解決に役立ったのは、交換デー
タの物理的構文、つまりマークアップされたASCII
テキストについての問題だけである。
– XMLがシステム間の交換フォーマットで世界的標準
になりつつあるという点においては貢献している。
XML バベルの塔
• DoDにおけるデータの問題は依然として解決されていない：
•人材の問題 – 対人的なコミュニケーション
•スキーマの問題 – システムの統合
• データ交換が問題なく機能することと、アプリケーションの相互運用性は、
同じことではない。
• XMLのような技術をうまく採用するには、業務過程の根本的改革
(BPR)を必要とする。
2002年1月、東京にて Jerry Smith
32
XML リポジトリ制御
DISA エンジニアリング
スタッフ
ネームスペース
管理者のフォーラム
サポート
運営、
維持
参加
管理
ホスト
Namespace
Namespace
ネームスペース
Managers
&&
Managers
管理者
および
WGs
WGs
ワークグループ
DISA XML レジストリ
Web上で管理、表示する
レジストリ運営スタッフ
DATATWG
SSD-MD
SUB PANEL
XMLレジストリへのコンサ
ルト、提出、XMLレジスト
リからのダウンロード
参加
参加
DOD 開発者
• 登録を完成し、クリアリングハウス機能を果たすための管理配置
• 開発者は組織およびその処理過程において、以下の直接的な方法を与
えられる
• 登録要求に準拠する
• 詳細なXMLの技術情報を取得する
• DoD XMLの方向性の策定に影響力をもつ
2002年1月、東京にて Jerry Smith
33
John Zachmanによる、
「ナレッジベース」情報時代における変化の管理
• ナレッジベース情報時代の企業にお
いて変化に対応するためのキー要素
– 企業モデルの構築および管理についての
「エンジニアリング」規律
– 企業の運営のなかで、[アーキテクチャフレ
ームワークにおいて]モデルを採用するた
めの文化的規律
• モデル構築、モデル格納、モデル管
理（実行）、モデル変更、 [構築された
ナレッジフレームワークでのモデル使
用]... 合理的な企業のみが、 「情報
時代」の中での変化に対応できるの
で [競争に有利になる]。
2002年1月、東京にて Jerry Smith
34
EIA ベンダーのアーキテクチャ
プロセスの自動化
企業のアプリケーション
コネクタ
•カスタムアプリケーション
コネクタ
•レガシーシステム
コネクタ
アナライザ
コネクタ
発行および申し込み
発行および申し込み
•パッケージアプリケーション
コネクタ
•データベース
コネクタ
コミュニケーター
2002年1月、東京にて Jerry Smith
資料: Pete Everitt
35
1. インフラストラクチャ
2. 既存の記録からの正式な
データキャプチャ
3. データの相互運用性
4. データ認証
5. セキュリティ
2002年1月、東京にて Jerry Smith
36
情報の統合
データベース
レベル
イベント
レベル
データマート/
データウェアハウス
?????
レガシーの有効化の
欠如 および
外部情報ソースからの
コンテキスト管理の
欠如
ERP ベンダー
統一された見方
引用元: Michael Stonebreaker - EAI Journal
2002年1月、東京にて Jerry Smith
EAI ベンダー
システム間の一貫性
資料: Pete Everitt
37
情報の統合
データベース
レベル
データマート/
データウェアハウス
ECI
有
イベント
レベル
報
ERP ベンダー
EAI ベンダー
統一された見方
システム間の一貫性
引用元: Michael Stonebreaker - EAI Journal
2002年1月、東京にて Jerry Smith
効
情
化
資料: Pete Everitt
38
PDML
方法論
ソースデータ
EXPRESSでのPDI
統合スキーマ
• Mil-Std 2549
• JEDMICS
• TechOrder-4
label
label
class
drawing_
document
product_data_ty pe
document_with_
class
document_
ty pe
• PDM Sys
id
revision_id
kin d
identifier
description
text
document
label
name
file_name
• PDM Enablers
label
source
relating_document
digital_file
subject_element_value
identifier
related_document
text
name
• PDM Schema
associated_
program
Seq
#
1
Field Name
PDI S pecification
Mapping Specification
Part Material design enterprise type code
group.name
2
Part/Matrial design enterprise identifier
identification_assignment.id
{[group_assignment on organization
role.name = ‘enterprise type code’]
[organization_assignment on product
organization_role.name = ‘designer’]}
{[identification_assignment on organization,
organization =>
cage
identification_role.name = ‘com cage’, ‘gov cage’]
[organization_assignment on product
organization_role.name = ‘designer’]}
3
4
5
6
Part/Material Identifier
Material identification parameter list
Part/Material name
NSN
product.id
product.id
product.name
identification_assignment.id
7
Product tracking-basd source code (13TRK1)
8
Product-tracking base-identifier
9
Defining document identifier and type code
10
can be substituted for/replaces part/material source, or
has company stock number assigned by
11
can be substituted for/replaces part/material identifier, or
is company stock number of
product.id
12
can be substituted for/replaces part/material identification
parameter list
product.id
group.id
[document.id]
[document_kind.name]
organization.id
description
description
document_usage_
constraint
subject_element
document_
relationship
name
text
EXPRESSでの
PDMLトランザク
ションセット
XMLでのPDML
トランザクション
セット
XML DTD
XML
DTDD> .......
<Pr
oduct_I
<Pr
oduct_I
<Pr
oduct_I
D>D> .......
<Pr
oduct_I D> ...
<Pr
oduct_Name>
<Pr
oduct_Name> ...
.<
Product_Name>
.. .<
. . Product_Name>
..
<NH_Pr
oduct.I D> ..XML DTD
oduct.ID>
D><Pr
..XML
..<<NH_Pr
NH_Pr oduct.I
DTDD> .......
oduct_I
..< NH_Pr oduct.I D><Pr oduct_I D> .......
<Pr oduct_I D>
<Pr
oduct_I D> ...
<Pr
oduct_Name>
<Pr oduct_Name> ...
...< Product_Name>
. ..< Product_Name>
..
<NH_Pr
oduct.I D> ..
oduct.ID>
D>XML
..
..<<NH_Pr
NH_Pr oduct.I
DTD
..< NH_Pr oduct.I D>
XML
DTDD> .......
<Pr
oduct_I
<Pr
oduct_I
<Pr
oduct_I
D>D> .......
<Pr
oduct_I D> ...
<Pr
oduct_Name>
<Pr
oduct_Name> ...
Product_Name>
..<
.. .< Product_Name>
...
<NH_Pr
oduct.I D> ..
oduct.ID>
D> ..
..<<NH_Pr
NH_Pr oduct.I
..< NH_Pr oduct.I D>
Product Structure
2549
product => material
identification_assignment on product
identification_role.name = ‘NSN’
group_assignment on product
group_role.name = ‘tracking base source code’
{group.name = ‘D’,’drawing’,’C’,’configuration item’,
’U’,’Specification’, ‘S’, ‘standard document’,
‘P’, ‘product’, ‘M’, ‘material’}
group_assignment on product
group_role.name = ‘tracking base source code’
product_definition_with_associated_document.documents [i] ->
document
or drawing_document
{is the org that has orgnaization_assignment on the product that is
the related_product_definition in product_definition_relatioship
where the relationship.name = ‘substitute’
{is the related_product_definition in
product_definition_relatioship
where the relationship.name = ‘substitute’
{is the product => material and
the related_product_definition
in product_definition_relatioship
where the relationship.name = ‘substitute’
分析ツール
2002年1月、東京にて Jerry Smith
size
label
最新の統合モデルへの
ソースデータのマッピング
group.name
viewer
Etc.
自動ツール
39
データ メディエーションと
セマンティック メディエーション
データ メディエーション
対象
システム
データ表
ソース
システム
セマンティック メディエーション
label
label
class
drawing_
相互運用性エンジン
product_data_ty pe
document
document_with_
class
document_
ty pe
id
revision_id
identifier
kin d
description
text
document
label
name
label
file_name
source
relating_document
digital_file
subject_element_value
identifier
related_document
document_usage_
text
name
viewer
constraint
size
description
ソース
システム
2002年1月、東京にて Jerry Smith
意味論解釈
subject_element
document_
associated_
relationship
description
name
program
text
label
中立的統合
コンテキスト変換
対象
システム
40
セマンティック メディエーション
がもたらすものは・・・・・
既存の知的資源から意味的に情報を取り出し
再構築するための秩序である
¾新しい知識を既存の知識に
関連付ける
¾迅速な起動を可
能にする
¾段階的な処理過程の向上
をサポート
2002年1月、東京にて Jerry Smith
¾W3C推奨のXML
スキーマに準拠
¾XMLモデルの他の
データと容易に相互運
用できる
¾人的、機械的翻訳をサポート
41
DAML
(DARPA Agent Markup Language)
DAMLがめざすのは、
セマンティックウェブの概念を
わかり易くする言語やツール
を開発 することである。
– ソフトウェアエージェントが情報ソースを動的に
識別し、理解できるような技術を作り出す
– エージェント間に意味論的な方法での相互運用
性を提供する
2002年1月、東京にて Jerry Smith
42
STEPに欠けているもの
• 企業データモデル
– 完全にはなり得ない
– 必要なデータを全て網羅しているわけではない
• データベースのための標準
– インターフェース(SDAI)や多くの定義、関連データを提供す
る
– しかし内部スキーマを標準化することは不可能であり、また
標準化にとって適正とは言えない
• 図形標準
– 図形をサポートするデータが含まれる
資料: Eurostep、1999年
2002年1月、東京にて Jerry Smith
43
今後に活かすべき事柄
• CALS/EC
• 技術
• 標準
• DoD データプログラム
• STEP
2002年1月、東京にて Jerry Smith
44
CALS/EC
• 効果的な変化は、変化を必要とする個人から始まる。
外部から押し付けられるものではない。
• 変化はユーザーから、また必要性から起こるものであ
る。
• 長くゆっくりとしたプロセスとなる。 – 覚悟が必要
• 上級管理者の同意、サポート、直接参加についての
「実行チーム」を構成する。
– 全体の責任を引き受けるプロセスオーナーを特定する
– 意味のある意欲的な目標の策定、プロセスの確認、困難なスタッフ配置
や組織的な問題の決定、実行方法の開発、実行のかじとりを行う
– 効果的な関係の維持、 全員参加の要請、 フィードバックの要求を行う
資料: Dr Herve’ LeBoeuf 他
2002年1月、東京にて Jerry Smith
45
CALS/EC
• 商業分野の賛同が必要 – 汎用性のない技術はレガ
シーの問題を悪化させるだけである。
• 調達と供給の実行
– 調達ではすべての流通事業の処理過程をサポートする必要がある
•
•
•
•
管理
供給
訓練
輸送
• 上層部からの命令は、そのための資金とボトムアップ
による賛同およびサポートがなければ実行できない。
資料: Dr Herve’ LeBoeuf 他
2002年1月、東京にて Jerry Smith
46
今後に活かすべき事柄
• 近代化は既存データの有効性によって
左右される
• 既存の能力を利用し、そこから採用する
• 必ずユーザーを最初から参加させる
• ライフサイクル全体にわたる文書化およ
び管理は非常に重要である
2002年1月、東京にて Jerry Smith
47
ERP/ERP II
• 既存の機能およびDoDコンポーネントの構造は、汎用性のないシステムソ
リューションを招き、 協力を阻害し、DoD全体に焦点を当てることの妨げと
なる
• ERP/COTSアプリケーションの効果的な利用はプロセスの変化を促す …
そうでなければ意味がない
• 隠された問題点 − 所有権 − に気をつける
• ITソリューションの「しきたり」、DoD固有のニーズ、「ここでつくったもんじゃ
ない」症候群を克服しなくてはならない
• 変化には多くの議論や苦痛を伴うものである
• コンポーネント、機能、 DoDエンタープライズの最高レベルでの変化を支持
しなくてはならない
• 全員が参加することで各々の成功のチャンスを増大させる
• ベンダーやツールメーカーから企業データを回収し、企業に返却する
資料: Zach Goldstien 他
2002年1月、東京にて Jerry Smith
48
XMLの可能性/利点/限界–
XMLの限界
XMLは偉大だ！しかし・・・
• 魔法ではない
• それだけでは全てのデータの
問題を解決するものではない
• 管理しなければ、バベルの塔は XMLのバベルの塔
倒れる！
• データ交換が問題なく機能することとアプリケ
ーションの相互運用性は同じことではない!
ソリューション: 「XMLの賢い利用」を実現するため、モデルおよび登録
されたXMLコンポーネント（スキーマ, DTD, TAG）の適切な使用に向け
49
た業務の根本的革新が求められている。
2002年1月、東京にて Jerry Smith
XMLの賢い利用
要件 . . .
•
•
•
•
•
•
•
•
•
•
•
適切な利用と実施
（専制的ではない） 「バランスの取れたアプローチ」
断片化の防止
一貫性のある導入
整合
サービス、政府機関の同意およびサポート
我々のデータや業務要件に合わせてXMLコンポーネントを
構築する必要性
「送信者」と「受信者」間の合意の必要性
共同開発
語彙の再利用
賢い利用のための教育
2002年1月、東京にて Jerry Smith
50
データ管理
管理オプション- 対照的なスタイル
きつい
どのような管理スタイルが最
も効果的か？
制御範囲
上層部からの「命令」型
ゆるい
2002年1月、東京にて Jerry Smith
対
市場主導型
推奨されるアプローチ:
ある程度の制御を伴う市場主導型
51
標準
• 法制化対コンソーシアム
• 組織は実際には競争しているわけではない：
それぞれが役割、範囲、目的をもっている
– コンソーシアムは技術開発の一番の近道である
– 正式な法的プロセスは合意形成の最善の方法
である
– しかしその逆は真にあらず！
• PLCS & SC4
– 例えば両方の長所を利用する、など
2002年1月、東京にて Jerry Smith
52
情報資源
• 「国防省がITを武器システムのひとつと位置づ
けたことにより、防衛経費の情報技術への支
出が促進された。」
– データはITの「弾薬」である。では、ITのアプリケーションは
その弾なしで機能できるだろうか？
• 情報は資源である
– 重要な財産として管理する
資料: Michael Kush, EDS Corp, quoted in http://www.washingtontechnology.com/news/14_13/federal/818-1.html
2002年1月、東京にて Jerry Smith
53
STEP
• 転送構文から独立した方法でデータ形
式を文書化する
• 複数の実施アプローチをサポート
• 実施の自動化をサポート
• データが満たすべき規則を含む
• 固有の要件を満たすための標準の選択
をサポート
資料: Stefan Lindahl、Eurostep
2002年1月、東京にて Jerry Smith
54
STEP
• 共同の、また同時の設計および開発によって、多く
の変化が起こり、多数の製品コンポーネント、人、シ
ステムに影響をもたらす。
• 多くのシステム、プロセス、地理的境界にわたって
変化を制御する必要がある
• 変化のプロセスでは、アプリケーションとエンジニア
リングドメイン全般が調和する必要がある
資料: Stefan Lindahl、Eurostep
2002年1月、東京にて Jerry Smith
55
まとめ
データ、意味および通信
• データの目的
– 人間またはソフトウェアに情報を伝達する
– 人間に配信することが目的ではないデータも、最終的
には人間への情報の配信を実現するように意図され
ている
• 人間の通信能力の微妙さはデータに適用
できない
– 言語学､哲学、社会学は全て無視されている
– 「意味」とは認識されたデータが関係者に影響するもの
である
• これらの問題を認識する必要がある
2002年1月、東京にて Jerry Smith
56
まとめ
• 真の相互運用性が必須
– データの問題を解決することが成功の鍵となる
• 多くの重要な進歩
– しかしデータの問題はまだ存在する
• データの問題に一層の注意を払うことが必要
どのようにしてコンテキストの中のデータの
意味を維持し、互いに伝達するか？
2002年1月、東京にて Jerry Smith
57
（軍事力ではなく）情報が
21世紀の戦場を
（軍事力ではなく）情報が21世紀の戦場を
支配する
• 歴史的に、高地を支配した部隊は最大の強み
を持っていた。 「高地」とは、今では衛星や航
空調査システムからの情報などを意味する –
Cohen前国防長官
ナレッジマネジメントとは、「自分の知識を他者が棄てる前に棄て、他者がまだ考えついていな
いような挑戦をし、チャンスを作り出すことによって利益を得ることである」 -- Dr. Yogesh
Malhotra,
Malhotra, Inc. Technology
2002年1月、東京にて Jerry Smith
58
2002年1月、東京にて Jerry Smith
59