共通データ環境Catenda HUBの重要な部分はドキュメントエリアです。この記事では、このエリアをどのように構成し、より良い構成のために個々の機能を使用できるかを説明します。ドキュメントエリアの構成には3つのアプローチがあります。
1.文書やファイルを整理して格納する古典的なフォルダ構造
2.文書やファイルの整理、ファイルの検索を可能にするメタデータの使用。
3.フォルダ構造とメタデータの組み合わせ
ヒントこれら2つの方法の組み合わせは、しばしば理にかなっており、多くの利点を提供します。
以下は、これら2種類のメリットとデメリットの比較です：
クラシックなフォルダ構造
メリット
|
短所
|
構造化されたデザイン
|
フォルダ構造を作成・管理する必要がある
|
文書検索の補助
|
ドキュメントは個別のフォルダに保存する必要があり、トピックをまたいで整理することはできない
|
フォルダ経由でアクセス設定を作成できる
|
|
メタデータに基づく文書構造
利点
|
デメリット
|
自由な構造
|
高度な規律と確固たるガイドラインが必要
|
文書の保存と検索は動的
|
文書に仕様に沿った名前を付け、メタデータを提供する必要がある
|
両者の組み合わせ
利点
|
デメリット
|
フォルダー構造に基づく構造化された組織と、その他の可能なメタデータを組み合わせた動的なアプローチ
|
どちらも事前に十分な調整が必要
|
フォルダ構造と名前＋メタデータによって、ドキュメントの割り当てと検索が非常に簡単にできる。
|
|
フォルダ構造の例
フォルダ構造は、非常にさまざまに設定することができます。一方では、プロジェクトの要件と関連するプロジェクトチームに依存し、他方では、使用する計画キーに依存します。
例 - フェーズごとに構造を分ける
サービスフェーズに基づいてフォルダ構造が設定されます。これにより、どの管理フェーズのどの文書がどのフォルダに保存されるかが明確に分けられる。しかし、すべてのサービスフェーズに適用される文書はどうなるのでしょうか？様々なサービスフェーズのフォルダに文書が整理されていれば、例えばプランキーにこの情報はもう必要ないと思うかもしれません。しかし、プランが印刷されたり、建設現場にデジタル送信されたりする場合はどうなるのだろうか。ここでも、正確なドキュメントを識別するためにプラン名を使用する必要があります。最良のシナリオでは、フォルダ構造とプランキーは、プロジェクトの全過程を通じて関係者全員のために機能するユニットを形成する。
文書のメタデータ
文書やファイルに対するいわゆるメタデータの使用は、近年ますます普及しています。いくつかの文書メタデータはCatenda HUBによって直接生成され、文書に保存されます。例えば、アップロード日、ドキュメントの作成者、ファイルサイズが直接表示されます。
自動的に表示されるメタデータに加えて、Catenda HUBは独自のメタデータを作成することもできます。ユーザー定義の属性やラベルを使って。
例
ドキュメントがプランキー2-ARC-AN-02-00-2階平面図.pdfでアップロードされた場合、命名規則がドキュメントに関するいくつかの情報を自動的に読み出すために使用されます。これは、命名規則を認識することにより、バックグラウンドで自動的に行われます。
2 = 予備計画
ARC = 建築
AN = 眺望
02 = 2階上層階
...
ヒント:この情報に加えて、ドキュメントのステータスを追加できます。提出前、承認、アーカイブ、却下
この文書が建築申請やDGNB認証にとって重要かどうかなどの情報を追加したい場合は、前述のラベルやユーザー定義フィールドのオプションを使用して追加できます。