※この記事は全文機械翻訳されています。

フォルダーで命名規則を有効にする場合、プロジェクトチームは特定の内部追跡ワークフローに適合するように動的ブロックをカスタマイズすることがよくあります。

以下は、異なるチームがカスタムフィールドとドキュメント識別子トグルを利用して、整理されたワークスペースを維持する方法の実践的な例です。

この記事では次のトピックについて説明します：

命名規則の採用は、通常、プロジェクト所有者からの指示か、プロジェクトメンバー間でファイルの概要をより明確にしたいという希望によって駆動されます。

構造化された命名規則により、チームメンバーはドキュメント名の特定のコンポーネントをより効果的に検索できます。

ワークフローを開始する人に関係なく、プロジェクトメンバーはプロジェクト管理者に連絡して命名規則を構成および有効化する必要があります。

これらの設定を変更するには管理者アクセスが必要です。

実装の範囲は、通常、それを要求する人によって異なります：

命名規則がプロジェクト所有者によって要求されている場合、プロジェクト全体で頻繁に実装されます。

これらのシナリオでは、厳密な規則要件に合わないドキュメントに対応するために、別の指定フォルダーが確立されることがよくあります。

ローカライズされたワークフローを改善するために個人または特定のサブグループによって規則が要求されている場合、通常はそれらの特定の作業フォルダーでのみ有効になり、プロジェクトチームの残りの部分は規則なしで操作を続けます。

バージョンシーケンスは、連続したファイル更新を追跡するために使用されます。

プロジェクト要件に応じて、チームは展開可能な可変長トラック、厳密なダッシュパッド付きプレースホルダー、または単純な数値インジケーターから選択します。

このセクションでは次のトピックについて説明します：

2.1.1 チーム

Liam(BIMマネージャー)およびSophia(構造エンジニア)。

2.1.2 ワークフロー

Sophiaは定期的に構造モデルファイルをプラットフォームにアップロードします。

Liamは、すべての受信モデルにv1、v2、v3などの標準バージョンシーケンスで明示的にラベル付けすることを要求しています。

2.1.3 動作と考慮事項

このセットアップは最初は単純ですが、プロジェクトが進むにつれて、バージョントラックは2桁または3桁に拡張できます(v10またはv123など)。

この成長に対応するために、無限(可変)長またはより大きな固定長のいずれかのテキストフィールドが確立されます。

このアプローチの重要な視覚的考慮事項は、ブロックがファイル名の中央に配置されている場合、シーケンスに2番目または3番目の文字を追加すると、すべての後続の命名ブロックが文字スロットによって視覚的にシフトされることです。

これらのシフトするバージョンタグが各アップロード中に完全に個別のドキュメントコンテナーを作成するのを防ぐには、ドキュメント識別子を無効にする必要があります。

2.1.4 構成

2.1.5 結果

SophiaがStructural_Model_v1.ifcとStructural_Model_v10.ifcという名前のファイルをアップロードすると、プラットフォームは変更されたバージョン文字列を認識します。

ファイルはStructural_Modelという名前の単一の静的なドキュメントコンテナーの下に順序付けられたリビジョンとしてきちんとスタックされます。

2.2.1 チーム

Sarah(リードアーキテクト)およびTom(BIMコーディネーター)。

2.2.2 ワークフロー

Sarahは、初期リリースがダブルダッシュ(--)で始まり、その後に変更が発生するときに英文字追跡(-a、-b)が続く進行状況に従って建築図面を発行します。

彼女はフォルダーレイアウトを管理するTomと協力しています。

2.2.3 動作と考慮事項

標準バージョンシーケンスとは異なり、このダッシュパッド付きセットアップはブロック長を正確に同じに保ちます。

新しいバージョン文字が導入されると、均一な間隔を維持するためにプレースホルダーダッシュが犠牲になります。

この戦略の主な課題は、事前定義された長さ内のすべてのプレースホルダーダッシュが使い果たされると、規則が破たんすることです。

したがって、このアプローチは、ドキュメントの最大リビジョン制限を明確に理解する場合にのみお勧めします。

2.2.4 構成:

2.3.1 チーム

David(構造製図者)およびChloe(リード構造エンジニア)。

2.3.2 ワークフロー

Davidは構造詳細図を頻繁に更新し、01、02、03などの順序付きインジケーターを使用してローカルコンピューター上で数値でマークします。

Chloeはこれらの詳細をレビューし、プラットフォームがDavidが誤ったテキスト文字ではなく数字を入力していることを確認することに依存しています。

2.3.3 動作と考慮事項

整数に焦点を当てたルールブロックをフォルダー構造に追加して、エントリを検証します。

数値エントリのみが使用されることを保証しますが、厳密なステップバイステップの順序付けられたカウントを強制するのではなく、システムはすべての有効な整数を受け入れることに注意してください。

2.3.4 構成

2.3.5 結果

DavidがSteel_Detail_01.pdfをアップロードすると、整数フィールドはブロックに数値データが含まれていることを確認し、アップロードを許可します。

Davidが誤りを犯し、そのブロックに文字を含むファイルをアップロードしようとした場合、システムはファイルを拒否します。

Chloeは、プラットフォームが有効な任意の整数を受け入れ、Davidが厳密な年代順のシーケンスでカウントアップすることを強制しない場合、ファイル情報パネルで清潔な数値タイムラインを保証することを知ってファイルを監視できます。

3.1 チーム

Elena(HVACエンジニア)およびMarcus(プロジェクトマネージャー)。

3.2 ワークフロー:

Elenaは、図面のライフサイクルステータスを示すために単一文字の短縮形コードを追加するローカル命名システムを利用しています:進行中の作業の場合はW、ドラフトの場合はD、公開の場合はP。

プロジェクトマネージャーのMarcusは、彼女のエンジニアリングシートの正確なステータスを一目で知る必要がありますが、短縮形ではなく完全な記述語を好みます。

3.3 動作と考慮事項

ドロップダウン構成をフォルダーに適用して、ローカル短縮形コードとプラットフォームメタデータ表示タイトルの間のギャップを埋めます。

3.4 構成:

3.5 結果

ElenaがHVAC_Layout_W.pdfをアップロードすると、システムはコードWに一致し、メタデータ表示を自動的に進行中の作業として入力します。

Marcusが右側の情報メニューを展開してファイルをレビューすると、コアドキュメント名はHVAC_Layoutのままでクリーンで静的なままですが、リビジョン情報セクションは明示的に「進行中の作業」を表示します。

このセクションでは次のトピックについて説明します：

4.1 チーム - 4.2 ワークフロー - 4.3 リビジョン…日付(標準順序) - ソート用の日付(年月日順)

Oliver(ドキュメント管理者)およびEmma(サイトマネージャー)。

Oliverは日次サイトレポートを処理し、各レポートが生成されたときを正確に追跡する必要があります。

サイトマネージャーのEmmaはドキュメントテーブルに頻繁にアクセスし、ファイルが高度に整理されることを要求しています。

命名規則内でネイティブ日付ブロックが使用されていないため、OliverとEmmaは日付文字列を入力するために数値カスタムフィールドを使用しています。

ファイルの動作を希望する方法に応じて、2つの異なる構成バリエーションを調べます。

このバリエーションでは、日付は新しいファイルアップロード時に変更され、日次ログの新しいリビジョンを表します。

Oliverは日付に2桁を使用します(01–31)、月に2桁(01–12)、2桁の年(26、27)または4桁の年(2026、2027)。

命名規則はそのブロック全体で単一の主要な区切り文字のみを許可するため、隔離された日付形式を管理するには、2つの異なる構成パスから選択する必要があります：

4.3.1 3つの個別の整数ブロック

4.3.2 内部区切り文字を持つ単一テキストブロック

このバリエーションでは、Emmaは日付がドキュメント名に表示されたままにしたいため、各日の個別のファイルが存在します。

さらに、Emmaは、ドキュメントテーブルがファイルを完全な年代順に自動的にソートすることを要求しています。

プラットフォーム内のリストは、Unicode値に従ってアルファベット順にソートされます。

日付が日月年として書かれている場合、リストは最初に日番号でソートし、異なる月の「01」日のすべてのファイルをグループ化します。

これを防ぐために、Oliverは最初に年を配置し、その後に月を、その後に日を配置します。

このプレフィックスを管理する場合、文字スペースを節約することと、即座に読みやすさを確保することの間にバランスがあり、これは2つの実装オプションにつながります：

4.4.1 2桁の年プレフィックス(YYMMDD)

このオプションは、ソート文字列を単一ブロックに短縮して追加の区切り文字を削除し、年を2つの整数に削減します(例:26、27、28)。

これにより、文字スペースが節約され、長いドキュメント名がユーザーインターフェースの行の終わりで切り取られたり切り捨てられたりするリスクが減少します。

ただし、このオプションは即座に読みやすさを犠牲にしています。

260126のような日付文字列は、どの数字が年を表し、どの数字が日を表しているのかがすぐには明確ではないため、誤解を招く可能性があります。

パターンは複数のファイルを表示した後にのみ認識できるようになり、日または年の値が31を超えるとのみ区別が明確になります。

4.4.2 4桁の年プレフィックス(YYYYMMDD)

このオプションは、名前の先頭に4桁の年(例:2026、2027、2028)を使用します。

この構成により、明確性と即座に読みやすさが大幅に向上し、すべてのチームメンバーに対して年代順のシーケンスが明らかになります。

ただし、ファイル名の先頭で文字スペースが多く消費され、長いドキュメント名の最後の情報がインターフェースで切り取られたり切り捨てられたりする可能性が高まります。

4.4.3 構成

4.4.4 結果

Oliverが260115_Report.pdfと260201_Report.pdfのようなファイルをアップロードすると、ドキュメント識別子がアクティブであるため、個別のドキュメントが作成されます。

年月が最初に来て、一貫した2桁のパッディングを使用するため、ドキュメントテーブルは自動的にファイルを完璧な年代順に並べ替えます。