| Oracle® Oracle Fusion Middleware Oracle WebCenter Contentのマネージング 11g リリース1(11.1.1) B72426-01 |
|
 前 |
 次 |
| Oracle® Oracle Fusion Middleware Oracle WebCenter Contentのマネージング 11g リリース1(11.1.1) B72426-01 |
|
前 |
次 |
Content Categorizerおよびリンク・マネージャはオプションのコンポーネントで、Oracle WebCenter Content Serverとともに自動的にインストールされます。Content Categorizerを有効にすると、コンテンツ・サーバーにチェックインされた新しいドキュメントや、メタデータ値が設定されている(または設定されていない)既存のドキュメントに対して推奨メタデータ値が示されます。有効な場合は、リンク・マネージャは索引付けしたコンテンツ・アイテムのURLリンクを、データベース表(ManagedLinks)への格納のために抽出する前に、評価、フィルタ処理および解析します。
Content Categorizerで構造プロパティを認識するには、コンテンツをXML変換(eXtensible Markup Language)する必要があります。変換メソッドは、sccXMLConversion構成変数で定義します。Content Categorizerは検索ルールを使用して、コンテンツの推奨メタデータ値を示します。
このコンポーネントとともに含まれるバッチ・カテゴライザでは、大量のファイルを検索したり、適切なメタデータ・フィールド値を含むバッチ・ローダー制御ファイルを作成できます。バッチ・カテゴライザは、リポジトリにチェックイン済のコンテンツを再分類するためにも使用できます。
|
重要: Flexiondocスキーマを使用して変換したPDFコンテンツをXSLT変換を使用して後処理する場合は、問題が発生します。Flexiondocスキーマを使用すると、1つの単語が個別のXML要素に割り当てられ、最終的なXMLが使用できなくなります。PDFコンテンツを分類する場合は、SearchMLを使用する必要があります。 |
いずれのXML Converterを指定する場合でも、XML中間ファイルはContent Categorizerによってのみ使用されるため、使用後は破棄され、ドキュメントは元のソース形式でコンテンツ・サーバーにチェックインされます。唯一の例外はXML形式であるコンテンツで、これは変換処理の対象にはなりません。
各コンバータで、OutsideIn XML ExportテクノロジがカスタムXSLTスタイルシート(flexiondoc_to_scc.xsl)と組み合せて使用され、2段階の処理でXMLを生成します。第1段階では、ネイティブ・ドキュメントをFlexiondoc形式のXMLまたはSearchML形式のXMLのいずれかに変換します。
第2段階では、スタイルシートを使用してXMLをさらに調整し、Content CategorizerでXMLを検索できるようにします。XML要素ではネイティブ・ドキュメントのプロパティとテキスト・セグメントが分離され、対応するドキュメント・プロパティ、段落スタイルまたは文字スタイルに基づいて名前が付けられます(文字スタイルはSearchMLではサポートされていないことに注意してください)。
OutsideIn XML Exportでサポートされるファイル・フォーマットのリストは、第40章「入力ファイル・フォーマット」を参照してください。
Content Categorizerは、定義されているルールのタイプに基づいて検索ルールを実行します。
パターン照合ルールと抽象ルール: Content Categorizerは、コンテンツ・ドキュメントの「ランドマーク」を検索します。ランドマークは、特定のテキストにすることも、ソース・ドキュメントの構造プロパティ(スタイル、フォント、フォーマットなど)に基づいて使用することもできます。
オプション・リスト・ルール: Content Categorizerはキーワードを検索し、そのキーワードの累積スコアによって、リストの中のどのオプションを選択するかを決定します。ランドマークまたは特定のXMLタグは検索しません。
カテゴリ化エンジン・ルール: Content Categorizerはサードパーティのカテゴライザ・エンジンと分類を起動し、コンテンツ・アイテムを分類します。
Filetypeルール: Content Categorizerはドキュメント・ファイル・タイプ(ファイル名拡張子)を検索します。
通常、「コンテンツ・チェックイン・フォーム」にユーザーが値を入力すると、そのフィールドに対するContent Categorizerによる検索ルールの適用が防止されます。これは、「タイプ」フィールドなど、デフォルト値があるリスト・フィールドの場合も同様です。
|
重要: コントリビュータに、検索ルールによって入力するフィールドは空白のままにするよう指示することが重要です。 |
検索ルールの詳細は、第9.1.5項を参照してください。
Content Categorizerを実行するには、次のタスクを完了する必要があります。
XML変換メソッドを定義します。詳細は、第9.1.4.1項を参照してください。
検索ルールを定義します。詳細は、第9.1.5.6項を参照してください。
(オプション)メタデータ・フィールドのデフォルト値などのフィールドのプロパティを定義します。詳細は、第9.1.4.2項を参照してください。
|
重要: CATEGORY検索ルールを使用するには、カテゴライザ・エンジンをインストール、設定および登録してから、メタデータ・フィールドに対してCATEGORYルールを定義します。 |
Content Categorizerは、対話型モードまたはバッチ・モードで操作できます。すべてのモードでソース・ドキュメントをXML中間フォームに変換する必要があります。ただし、各モードのプロセス・フローは大きく異なります。
バッチ・モードは、リポジトリ内の大量のドキュメントを再分類する場合に使用します。システム管理者は、スタンドアロンのユーティリティを使用してContent Categorizerを実行し、コンテンツ・メタデータのライブ・アップデートを実行するか、バッチ・カテゴライザからの出力ファイルをバッチ・ローダーへの入力として使用します。このプロセスで実行する手順の詳細は、第9.1.3.1.1項を参照してください。
対話型モードでは、Content Categorizerは、「コンテンツ・チェックイン・フォーム」および「情報更新フォーム」と統合されます。ユーザーは、フォーム上の「分類」をクリックし、単一のコンテンツ・アイテムに対してContent Categorizerを実行します。Content Categorizerによって返される値は推奨値であるため、コントリビュータは返される値を編集したり、置換できます。このプロセスで実行する手順の詳細は、第9.1.3.1.2項を参照してください。
MaxQueryRows構成変数を使用して、単一のバッチ・ロード・プロセスに含めることができる最大ドキュメント数を指定します。これは同様に、バッチ・カテゴライザで表示されるドキュメント数にも影響します。この構成変数のデフォルト設定は200ですが、必要に応じて増減できます。変数の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
バッチ・モード・プロセスでは、システム管理者が次の手順を実行します。
バッチ・カテゴライザ・アプリケーションを実行します。UNIXシステム上でのアプリケーションの実行の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
必要に応じて、「バッチ・カテゴライザ」ページで、フィルタとリリース日の情報を定義し、分類するコンテンツのリストを表示します。「分類」をクリックします。
「既存の分類」ページで、「ライブ・アップデート」または「バッチ・ローダー」を選択します。
「ライブ・アップデート」オプションは、リポジトリのデータを即座に更新します。
「バッチ・ローダー」オプションは、Content Categorizerプロセスの出力である制御ファイルを作成する場合に使用します。ファイルには、各ソース・ドキュメントのエントリと、Content Categorizerで定義した検索ルールに基づいた各メタデータ・フィールドの値が含まれます。このファイルは、バッチ・ローダーに送信する前に編集できます。
Content Categorizerプロセスの完了後にバッチ・ローダー・ユーティリティを自動的に実行するには、「バッチ・ローダーの実行」チェック・ボックスを選択します。
Content Categorizerプロセスのエラー情報が含まれるログ・ファイルの場所およびファイル名を入力します。
すべてのコンテンツ・アイテムが処理されるように「すべての分類」を選択するか、または、コンテンツ・リスト内のハイライトされたアイテムのみが使用されるように「選択済の分類」を選択します。
アイテムの最新リビジョンのみを処理する「最新のリビジョン」の分類を選択するか、または「全リビジョン」の分類を選択します。
バッチ・カテゴライザにエラーが発生したときに、カテゴリ化プロセスを続行するか中止するかを選択します。
「OK」をクリックします。進行状況バーには、バッチ・プロセスのステップ間移動の進行状況が表示されます。
Content Categorizerはソース・コンテンツを検索します。
コンテンツがXML形式の場合、変換は発生せず、プロセスは手順dに進みます。
コンテンツがXML形式ではない場合、XML変換メソッドとして選択したFlexiondocまたはSearchMLを使用してXMLへの変換が実行されます。
Content Categorizerは検索ルールをXMLに適用し、特定のメタデータ・フィールドの値を取得します。
「ライブ・アップデート」が指定されている場合は、データベース・レコードが即座に更新されます。「バッチ・ローダー」が指定されている場合は、出力制御ファイルが作成され、バッチ・ローダー・ユーティリティが実行されます(処理後に実行するようにオプションが指定されている場合)。
バッチ・プロセスの完了後、エラー・ログを確認します。バッチ・カテゴライザで発生したエラーはコンソールに表示され、バッチ・カテゴライザのログにも記録されます(指定した場合)。バッチ・ローダーで発生したエラーはコンソールに表示され、システム・ログにも記録されます。
オプションのAddCCToArchiveCheckinコンポーネントがインストールされていて有効な場合、バッチローダー・ユーティリティを使用してロードされたすべてのコンテンツが、事前定義されたルール・セットに基づいて自動的に分類されます。ルール・セットの定義の詳細は、第9.1.5.6項を参照してください。
チェックイン・プロセスで次の手順が実行されます。
コントリビュータが「コンテンツ・チェックイン・フォーム」または「情報更新フォーム」を開き、プライマリ・ファイルを選択して(「コンテンツ・チェックイン・フォーム」のみ)、「分類」をクリックします。
「コンテンツ・チェックイン・フォーム」によって、そのプライマリ・ファイルがホストにコピーされ、Content Categorizerサービスがコールされます。
Content Categorizerはソース・コンテンツを検索します。
コンテンツがXML形式の場合、変換は発生せず、プロセスは手順6に進みます。
コンテンツがXML形式ではない場合、指定した変換メソッドが使用されます。
Content Categorizerは検索ルールをXMLに適用し、特定のメタデータ・フィールドの推奨値を取得します。
Content Categorizerは、推奨メタデータ値を「コンテンツ・チェックイン・フォーム」または情報更新フォームに挿入し、そのフォームをコントリビュータに返します。
コントリビュータは、推奨値を使用したドキュメントのチェックインや送信、メタデータ値の改訂、またはチェックインや更新の取消しを実行できます。
オプションのAddCCToNewCheckinコンポーネントがインストールされていて有効な場合は、「コンテンツ・チェックイン・フォーム」の「チェックイン」をクリックすると、手順2から6が実行されてチェックイン・プロセスが完了します(dDocTitleのプロパティが「コンテンツのオーバーライド」に設定されている場合)。
dDocTitleのプロパティが「コンテンツのオーバーライド」に設定されていない場合は、必須フィールドを入力するように要求するアラートが表示されます。フィールドのプロパティは、CC管理アプレットを使用して設定します。詳細は、第9.1.4.2項を参照してください。
Content Categorizerを使用する前に、必要なソフトウェアをインストールおよび構成します。この項では次のタスクについて説明します。
Content CategorizerでXML変換メソッドを設定する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Categorizerの管理」を選択します。
「Content Categorizerの管理」ページで、「構成」をクリックします。
「構成」タブで、「sccXMLConversion」プロパティを選択し、「編集」をクリックするか、プロパティをダブルクリックします。
「プロパティの構成」ページのリストから、XML変換方法として「Flexiondoc」または「SearchML」を選択します。
「OK」をクリックします。
「適用」をクリックして変更を保存します。
フィールドに対するルールが成功すると、(「バッチ・ローダー」操作または「ライブ・アップデート」操作で)検出された値が使用されます。ただし、「オーバーライド」値の設定方法によっては、検出された値は既存の値をオーバーライドしません(「オーバーライド」をfalseに設定した場合)。
フィールドに対するすべてのルールが失敗した場合、フィールドにデフォルト値が定義されており、「デフォルトの使用」がtrueに設定されていないかぎり、フィールドに値は割り当てられません。
メタデータ・フィールドに対するフィールド・プロパティを定義する手順は次のとおりです。
「メイン」メニューから「管理」→「Content Categorizerの管理」を選択します。
「Content Categorizerの管理」ページで、「フィールドのプロパティ」タブをクリックします。
編集するメタデータ・フィールドを選択し、「編集」をクリックするか、フィールドをダブルクリックします。
「フィールドのプロパティ」ページで、フィールドに対するデフォルト値を入力します。
リスト・フィールドのデフォルト値は、そのフィールドで使用可能な値と一致する必要があります。
カテゴリ化プロセスから返された値でフィールドの既存の値をオーバーライドする場合は、「オーバーライド」チェック・ボックスを選択します。
カテゴリ化プロセスの実行時にすべてのルールが失敗した(または定義されていない)場合に、フィールドのデフォルト値を使用するには、「デフォルトの使用」チェック・ボックスを選択します。
「OK」をクリックします。
編集するフィールドごとにこれらの手順を繰り返します。
「設定の保存」をクリックして変更内容を保存します。
検索ルールは、Content Categorizerがメタデータ値を決定し、「コンテンツ・チェックイン・フォーム」、「情報更新フォーム」(対話型モードの場合)またはバッチ・ファイル(バッチ・モードの場合)に返す方法を定義します。
この項では、検索ルールに関する次の項目について説明します。
すべての検索ルールは次の内容によって定義されます。
ルール・タイプは、Content CategorizerがXMLドキュメントを検索するために使用するメソッドを決定します。
キーは、Content Categorizerがドキュメントで検索するXML要素、句、キーワードを定義したり、Content Categorizerがドキュメントを分類するために使用するカテゴリ化エンジン/分類を定義します。
件数は、検索条件を絞り込むために使用します。
検索ルールを作成する際には、次のガイドラインを考慮してください。
任意のカスタム・メタデータ・フィールドに検索ルールを適用できます。
標準メタデータ・フィールドの「タイトル」、「コメント」および「タイプ」には、検索ルールを適用できます。他の標準メタデータ・フィールド(「作成者」、「セキュリティ・グループ」、「アカウント」など)に対しては、検索ルールを定義できません。
1つのメタデータ・フィールドに対して複数の検索ルールを定義できます。(ただし、単一のメタデータ・フィールドに対して、異なる分類を参照する複数のCATEGORYルールの定義はサポートされていません。)
検索ルールで推奨値が検出されなかった場合は次のルールが実行されるように、検索ルールが複数ある場合は指定した順序で実行されます。詳細指定から曖昧指定の順序でリストを配置します。
1つのメタデータ・フィールド内に、複数の検索ルール・タイプが混在できます。たとえば、同じメタデータ・フィールドに対してオプション・リスト・ルール、パターン照合ルールおよび抽象ルールを定義できます。
指定した検索ルールを満たさないメタデータ・フィールドは、空白のままになります。
パターン照合検索ルールは、特定のテキストまたは特定のXML要素を検索し、関連する値を返します。たとえば、「インボイス#」メタデータ・フィールドに、ソース・ドキュメントの「インボイス:」ラベルまたは「インボイス番号:」ラベルの後の値を含めたり、XMLドキュメントの<Invoice>タグ内の値を含めることができます。
パターン照合ルールには、タグ検索とテキスト検索の2つの一般的なタイプがあります。各タイプには、複数のサブタイプがあります。
タグ検索は、キーと一致するXML要素のフル・ネームを検索します。そのような要素が検出されると、要素に含まれるテキストが結果として返されます。タグ検索では、大/小文字が区別されます。サブタイプには次のものがあります。
TAG_TEXT
TAG_ALLTEXT
テキスト検索は、キーと一致するテキストを検索します。そのようなテキストが検出されると、キーの近く、またはキーの次のテキストが結果として返されます。テキスト検索では、大/小文字は区別されません。サブタイプには次のものがあります。
TEXT_REMAINDER
TEXT_FULL
TEXT_ALLREMAINDER
TEXT_ALLFULL
TEXT_NEXT
TEXT_ALLNEXT
パターン照合検索ルールのキーは、XML要素(タグ検索の場合)またはテキスト句(テキスト検索の場合)です。
パターン照合検索ルールの件数は、ルールが結果を返す前に一致する必要があるタグまたはテキスト句の数を定義します。たとえば、件数を4にすると、キーの4番目の出現を探します。ドキュメントで見つかったキーの出現が3つのみであると、検索ルールは失敗します。デフォルトの件数は1で、この場合はキーの最初の出現が返されます。
次の例は、パターン照合検索ルールの使用を示しています。
例: TAG_TEXT
このルールは、キーと一致するXML要素(大/小文字の区別も含む)のフル・ネームを検索します。そのような要素が検出されると、その要素に属するすべてのテキストが連結され、結果として返されます。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TAG_TEXT
キー: TAG_A
戻り値: Title: The Big Wolf
例: TAG_ALLTEXT
このルールは、キーと一致するXML要素(大/小文字の区別も含む)のフル・ネームを検索します。そのような要素が検出されると、その要素に属するすべてのテキストと、その要素のすべての子に属するすべてのテキストが連結され、結果として返されます。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TAG_ALLTEXT
キー: TAG_A
戻り値: Title: The Big Bad Wolf
例: TEXT_REMAINDER
このルールは、キーと一致するテキスト(大/小文字の区別を除く)を検索します。そのようなテキストが検出されると、同じXML要素に属するキーの次のテキストが結果として返されます。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TEXT_REMAINDER
キー: Title:
戻り値: The Big Wolf
例: TEXT_ALLREMAINDER
このルールは、キーと一致するテキスト(大/小文字の区別を除く)を検索します。そのようなテキストが検出されると、同じXML要素に属するキーの次のテキストと、その要素のすべての子に属するキーの次のテキストが結果として返されます。
コンテンツ: TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TEXT_ALLREMAINDER
キー: Title:
戻り値: The Big Bad Wolf
例: TEXT_FULL
このルールは、キーと一致するテキスト(大/小文字の区別を除く)を検索します。そのようなテキストが検出されると、同じXML要素に属するテキスト(キーのテキストも含む)が結果として返されます。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TEXT_FULL
キー: Title:
戻り値: Title: The Big Wolf
例: TEXT_ALLFULL
このルールは、キーと一致するテキスト(大/小文字の区別を除く)を検索します。そのようなテキストが検出されると、同じXML要素に属するテキスト(キーのテキストとその要素の子に属するテキストも含む)が結果として返されます。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TEXT_ALLFULL
キー: Title:
戻り値: Title: The Big Bad Wolf
例: TEXT_NEXT
このルールは、キーと一致するテキスト(大/小文字の区別を除く)を検索します。そのようなテキストが検出されると、空要素以外のXML要素に属するテキストが結果として戻されます。空要素と非印刷文字で構成される要素は、戻り値として選択されません。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TEXT_NEXT
キー: Title:
戻り値: Subtitle: A Play
例: TEXT_ALLNEXT
このルールは、キーと一致するテキスト(大/小文字の区別を除く)を検索します。そのようなテキストが検出されると、次の空要素以外のXML要素に属するテキストと、その要素のすべての子に属するテキストが結果として返されます。空要素と非印刷文字で構成される要素は、戻り値として選択されません。
コンテンツ: <TAG_A>Title: The Big <TAG_B>Bad</TAG_B> Wolf</TAG_A>
<TAG_C>Subtitle: A <TAG_D>Morality</TAG_D> Play</TAG_C>
ルール: TEXT_ALLNEXT
キー: Title:
戻り値: Subtitle: A Morality Play
抽象検索は、XML要素を検索し、その要素から説明文または段落を返します。たとえば、「サマリー」メタデータ・フィールドには、次の文の戻り値を入力できます: "Germany is a large country in size, culture, and worldwide economics.One of Germany's largest industries includes the manufacturing of world class automobiles like BMW, Mercedes, and Audi."
抽象ルール・タイプは、コンテンツ・アイテムに即座に識別可能な、または明示的にタグ付けされたテキストのブロックがない場合に役立ちます。通常、これらのルールは、ドキュメントに関するサマリーやトピック情報を提示するために使用されます。
抽象検索ルールには、「最初の段落」と「最初の文」の2つのタイプがあります。
「最初の段落」は、キーと一致するXML要素のフル・ネームを検索します。段落全体の中でサイズ基準(件数で指定)を満たしている最初の要素が結果として返されます。
「最初の文」は、キーと一致するXML要素のフル・ネームを検索します。そのような要素が検出されると、その要素の最初の文が結果として返されます。
抽象検索ルールのキーはXML要素です。
件数は、「最初の段落」検索ルールと「最初の文」検索ルールとで解釈が異なります。
「最初の段落」検索ルールの場合、件数はパーセントで測定されるサイズのしきい値です。
キーと一致するすべての段落についてドキュメントを検索します。
キーと一致する各段落の平均サイズ(文字数に基づく)を計算します。
平均サイズに件数率(0 = 0%、100 = 100%)を掛けます。
結果の数値よりも大きい値の最初の段落を検索します。
たとえば、件数を75に設定し、平均段落サイズが100文字とすると、キーに一致し、かつ75文字より大きい最初の段落が返されます。
件数をデフォルトの1に設定すると、キーに一致する最初の段落が返される可能性が高くなります。
「最初の文」検索ルールの場合、件数は最初の文を返す要素の数です。
たとえば、件数を3に設定した場合、キーに一致する最初の3つの要素からそれぞれ最初の文が返されます。
次の例は、抽象検索ルールの使用を示しています。
例: FIRST_PARAGRAPH
この例では、<Text>要素の段落サイズの平均の1/2を超える最初の<Text>要素が返されます。<Title>要素は、キーの値と一致しないため、検索および長さの平均を計算する際に無視されます。
コンテンツ: <Title>Poem</Title>
<Text>Mary had</Text>
<Text>a little Lamb</Text>
<Text>The fleece was white as snow</Text>
<Text>And everywhere that Mary went the lamb was sure to go</Text>
ルール: FIRST_PARAGRAPH
キー: Text
件数: 50
戻り値: The fleece was white as snow.
例: FIRST_SENTENCE
この例では、最初の2つの<Text>要素の最初の文が返されます。<Title>要素は、キーの値と一致しないため、検索から除外されることに注意してください。
コンテンツ: x<Title>Barefoot in the Park</Title>
<Text>See Dick run.See Jane run.See Dick and Jane.</Text>
<Text>See Spot run.See Puff chase Spot.</Text>
<Text>See Dick chase Spot and Puff.</Text>
ルール: FIRST_SENTENCE
キー: Text
件数: 2
戻り値: See Dick run.See Spot run.
オプション・リスト検索ルールは、ソース・ドキュメント内のキーワードを検索し、検出した各キーワードにスコアを適用して、最も高いキーワード・スコアを持つ値を返します。
たとえば、ドキュメントに利益、有価証券報告書または請求書というキーワードが検出された場合、「部門」フィールドの推奨値は会計ですが、キーワードがトレランス、組立品または在庫の場合は、推奨値として製造を返します。
オプション・リスト検索ルールは通常、構成マネージャでリストが定義されているメタデータ・フィールドに適用されます。
(Content Categorizerで「カテゴリ」と呼ばれる)オプション・リストの名前と値は、構成マネージャで指定したとおりにContent Categorizerに表示されます。CC管理アプレットが開いているときにカスタム・リスト・フィールドが作成または変更された場合は、アプレットを閉じてから再度開いて、変更を確認します。
現在のバージョンのコンテンツ・サーバーは、デフォルト値として空の値をカスタム・リスト・フィールドに自動的に挿入します。この場合、最初の値(デフォルトでは空の値)はユーザーによる入力値とみなさないため、オプション・リスト検索ルールが適用されます。オプション・リスト検索ルールでカスタム・リスト・フィールドの最初の値をオーバーライドしないようにするには、構成マネージャ・アプレットでそのリストのデフォルト値を指定します。
オプション・リスト検索ルールのタイプは1つで、キーで定義したキーワードと一致するキーワード(1つの単語または句)を検索します。
キーワードには、1つの単語(dogなど)または語句(black dogなど)を使用できます。
キーワードでは、次の一連の定義済演算子を使用して、検索をさらに絞り込むことができます。
$$AND$$
$$OR$$
$$AND_NOT$$
$$NEAR$$
キーワードはリストの各カテゴリ(値)に事前に割り当てられていて、各キーワードには重みが割り当てられています。
ドキュメントで検出された各キーワードの出現回数に重みが乗算され、キーワード・スコアが生成されます。
カテゴリごとのキーワード・スコアが加算され、カテゴリ・スコアが生成されます。
スコアの最も高いカテゴリが、推奨値として返されます。
カテゴリが同点の場合は、先にリストに出現するカテゴリが推奨値として返されます。
重みの「常に」と「なし」を使用すると、スコアと件数しきい値がオーバーライドされます。
重みの「常に」が指定されたキーワードが出現した場合は、スコアに関係なく、そのカテゴリが推奨値として返されます。
重みの「なし」が指定されたキーワードが出現した場合、スコアに関係なく、そのカテゴリは推奨値として返されません。
2つのカテゴリに重みの「常に」が割り当てられているキーワードがあり、両方のキーワードがドキュメントに出現している場合は、ドキュメントで先に検出されたキーワードが優先されます。
|
重要: オプション・リスト検索では、大/小文字が区別されるため、正確に一致する必要があります。たとえば、「Invoice」というキーワードのすべてのインスタンスを取得する場合は、Invoice、Invoices、invoiceおよびinvoicesを定義する必要があります。 |
オプション・リスト検索ルールのキーは、「管理アプレット」の「オプション・リスト」タブに表示されるオプション・リストの名前です。
オプション・リスト検索ルールの件数では、ルールが結果を返す最小しきい値スコアを設定します。たとえば、件数を50に設定した場合に、最大蓄積キーワード・スコアが45であると、検索ルールは失敗します。
次の例は、オプション・リスト検索ルールの使用を示しています。
例1: オプション・リスト
たとえば、DickとSpotのスコアが30 (3回出現x 10)で、JaneとPuffのスコアが20 (2回出現x 10)とします。Dickは、リストでSpotよりも前にあるため、推奨値として返されます。
コンテンツ: <Title>Barefoot in the Park</Title>
<Text>See Dick run.See Jane run.See Dick and Jane.</Text>
<Text>See Spot run.See Puff chase Spot.</Text>
<Text>See Dick chase Spot and Puff.</Text>
ルール: OPTION_LIST
キー: MainCharacterList
件数: 10
オプション・リスト・カテゴリ、キーワードおよび重み: Dick: Dick=10、boy=5、Richard=2
Jane: Jane=10、girl=5、Janie=2
Spot: Spot=10、dog=5
Puff: Puff=10、cat=5
戻り値: Dick
例2: オプション・リスト
この例では、Spotが他のカテゴリよりも高いスコアの60 (3回出現x 20)であるため、推奨値として返されます。
コンテンツ: <Title>Barefoot in the Park</Title>
<Text>See Dick run.See Jane run.See Dick and Jane.</Text>
<Text>See Spot run.See Puff chase Spot.</Text>
<Text>See Dick chase Spot and Puff.</Text>
ルール: OPTION_LIST
キー: MainCharacterList
件数: 10
オプション・リスト・カテゴリ、キーワードおよび重み: Dick: Dick=10、boy=5、Richard=2
Jane: Jane=10、girl=5、Janie=2
Spot: Spot=20、dog=10
Puff: Puff=10、cat=5
戻り値: Spot
例3: オプション・リスト
この例では、件数しきい値の50を超えるスコアがないため、ルールは失敗します。
コンテンツ: <Title>Barefoot in the Park</Title>
<Text>See Dick run.See Jane run.See Dick and Jane.</Text>
<Text>See Spot run.See Puff chase Spot.</Text>
<Text>See Dick chase Spot and Puff.</Text>
ルール: OPTION_LIST
キー: MainCharacterList
件数: 50
オプション・リスト・カテゴリ、キーワードおよび重み: Dick: Dick=10、boy=5、Richard=2
Jane: Jane=10、girl=5、Janie=2
Spot: Spot=10、dog=5
Puff: Puff=10、cat=5
戻り値: 失敗
例4: オプション・リスト
この例では、キーワードの「Puff」に重みの「常に」が指定されているため、Puffが推奨値として返されます。
コンテンツ: <Title>Barefoot in the Park</Title>
<Text>See Dick run.See Jane run.See Dick and Jane.</Text>
<Text>See Spot run.See Puff chase Spot.</Text>
<Text>See Dick chase Spot and Puff.</Text>
ルール: OPTION_LIST
キー: MainCharacterList
件数: 10
オプション・リスト・カテゴリ、キーワードおよび重み: Dick: Dick=10、boy=5、Richard=2
Jane: Jane=10、girl=5、Janie=2
Spot: Spot=10、dog=5
Puff: Puff=常に、cat=5
戻り値: Puff
カテゴリ化エンジン検索ルールでは、サードパーティのカテゴライザ・エンジンと定義済の分類を使用して、特定の分類内のカテゴリ(News/Technology/Computersなど)を表す値を決定して返します。
カテゴリ化エンジン検索ルールのタイプは1つで、キーで指定したカテゴライザ・エンジンおよび分類を使用してフィールドの値を返します。
カテゴリ化エンジン検索ルールのキーは、カテゴライザ・エンジンの名前の後に分類の名前を付けたものです。たとえば、EngineName/TaxonomyNameです。「キー」フィールドにエンジン名を定義した場合、Content Categorizerでは、カテゴライザ・エンジン・リストに表示される最初のエンジンにデフォルト設定されます。1つのエンジンのみが定義されている場合は、単に「キー」フィールドに分類名を入力します。
カテゴリ化エンジン検索ルールの件数では、返される結果に関する最小信頼度しきい値を設定します。
カテゴリ化エンジンによって、特定の問合せに対する1つのカテゴリ(または一連のカテゴリ)が返されるときに、各カテゴリをパーセントで表す信頼度も返されます。CATEGORYルールでは、最大信頼度カテゴリが常に受け入れられますが、その信頼度がルールに指定した件数の値を下回る場合は、ルールが失敗します。たとえば、件数を50に設定した場合に、返された最大信頼度カテゴリが45であると、ルールは失敗します。
デフォルトの件数の1を使用すると、カテゴライザ・エンジンが返す最大信頼度カテゴリが常に受け入れられます。「件数」値の実際の範囲は、使用するカテゴライザ・エンジンによって異なります。
Filetype検索ルールはドキュメントのファイル名拡張子を調べ、用語(通常はファイル名拡張子に関連付けられているファイル・タイプの説明)を返します。
Filetype検索ルールのタイプは1つで、プライマリ(ネイティブ)・ファイルのファイル名拡張子を使用してフィールドの値を返します。
メタデータ・フィールドに対してFiletype検索ルールを定義すると、コンテンツ・アイテムのファイル名拡張子がDocFormatsWizard表のすべての値と照合されます。この表は、IntradocDir/shared/config/resources/ディレクトリのdoc_config.htmファイルにあります。
一致が検出されると、「説明」列の関連値が抽出されて変換されます。結果の文字列は、そのフィールドの推奨メタデータ値として返されます。プライマリ・ファイルのパスに拡張子がない場合、または拡張子がDocFormatsWizard表の拡張子の値と一致しない場合、ルールは失敗し、そのメタデータ・フィールド用のリストの次のルールが実行されます。
FILETYPE検索ルールのキーは、メタデータ値の決定時に使用されません。「キー」フィールドは空白にしておきます。
FILETYPE検索ルールの件数は、メタデータ値の決定時に使用されません。「件数」フィールドは空白にしておきます。
「キー」フィールドまたは「件数」フィールドが空白でない状態でFILETYPEルールを作成すると、これらのフィールドがルールでサポートされないことを示す警告メッセージが表示されます。
次の例は、Filetype検索ルールの使用を示しています。
例1: Filetype検索
プライマリ・ファイル: policies.doc
ルール: FILETYPE
キー: 空白
件数: 空白
戻り値: Microsoft Wordドキュメント
例2: Filetype検索
プライマリ・ファイル: procedures.wpd
ルール: FILETYPE
キー: 空白
件数: 空白
戻り値: Corel WordPerfectドキュメント
起動時に、Content Categorizerは、フィールドの名前と長さを含む、現在のメタデータ・フィールド構成のスナップショットを作成します。メタデータ・フィールドの構成を変更した場合は、コンテンツ・サーバーを再起動してから、Content Categorizerの管理アプレットを実行して、検索ルールを追加または変更します。
|
重要: Content Categorizerでファイル・タイプ(.doc、.txt、.xmlなど)を調べるには、そのタイプの空でないルールセットが必要です。特定のファイル・タイプのルールがない場合、Content Categorizerは例外をスローします。この例外を回避する最も簡単な方法は、デフォルトのルールセットに少なくとも1つのルールを追加することです。デフォルトのルールセットは、カスタム・ルールセットが割り当てられていないすべてのファイル・タイプに使用されます。 |
メタデータ・フィールドの検索ルールを定義する手順は、次のとおりです。
「管理」→「Content Categorizerの管理」を選択します。
「Content Categorizerの管理」ページで、「ルール・セット」タブをクリックします。
「ルールセット」ペインで、リストからルールセットを選択するか、「追加」をクリックし、新しいルールセットを追加して名前を付けます。ルールセットには、特定のドキュメントまたは特定のドキュメント・タイプに適用される複数のルールが含まれます。指定されたドキュメントまたはドキュメント・タイプに対して特定のルールセットが定義されていない場合は、デフォルトのルールセットが使用されます。
「フィールド」リストからメタデータ・フィールドを選択します。
「追加」をクリックします。
「field_nameのルールの追加」/「field_nameのルールの編集」ページで、「ルール」リストからルール・タイプを選択します。
「キー」フィールドに検索ルール・キーを入力します。
CATEGORYを使用する場合は、カテゴリ化エンジン名(カテゴライザ・エンジンのリストに複数のアイテムがある場合)、スラッシュ(/)、分類名の順に入力します。たとえば、EngineName/TaxonomyNameです。
OPTION_LIST検索ルールの場合は、リストのキーワードを「オプション・リスト」タブで定義する必要があります。
「件数」フィールドに件数を入力します。TAGタイプおよびTEXTタイプの場合、これは、ルールが結果を返す前に一致する必要があるタグまたはテキスト句の数です。たとえば、件数を4にすると、キーの4番目の出現を探します。
ドキュメントで見つかったキーの出現が3つのみであると、検索ルールは失敗します。デフォルトの件数は1で、キーの最初の出現が返されます。
FIRST_PARAGRAPHの場合、これはパーセントで測定されるサイズのしきい値です。件数率に平均段落サイズを掛けた値よりも大きいキーに一致する最初の段落が返されます。たとえば、件数を75に設定し、平均段落サイズが100文字とすると、キーに一致し、かつ75文字より大きい最初の段落が返されます。件数をデフォルトの1に設定すると、キーに一致する最初の段落が返される可能性が高くなります。
FIRST_SENTENCEの場合、これは最初の文を返す要素の数です。たとえば、件数を3に設定した場合、キーに一致する最初の3つの要素からそれぞれ最初の文が返されます。
CATEGORYの場合、これはルールが結果を返す最小信頼度しきい値です。たとえば、件数を50に設定した場合に、最大信頼度カテゴリが信頼度45であると、検索ルールは失敗します。
終了したら、「OK」をクリックします。
必要に応じて、各メタデータ・フィールドに検索ルールを追加します。
ルールを削除するには、「ルール・リスト」でルールを選択し、「削除」をクリックします。
ルールを編集するには、「ルール・リスト」でルールを選択し、「編集」をクリックします。
ルールの順序を調整するには、「ルール・リスト」でルールを選択し、「上に移動」または「下に移動」をクリックします。ルールはリストされている順序で適用されます。最初のルールが成功すると、他のルールは適用されません。最初のルールが失敗すると、次のルールが適用され、以下同様に続きます。
|
重要: CATEGORYルールを追加、編集または削除した場合は、変更内容を適用して、このルールを作成または再作成するか、「問合せツリー」タブでこのルールに対する孤立した問合せツリーがないかを確認するように求めるダイアログが表示されます。 |
「適用」をクリックして変更を保存するか、または「OK」をクリックして変更を保存し、「Content Categorizerの管理」ページを閉じます。
リストのキーワードと重みを定義する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Categorizerの管理」を選択します。
「Content Categorizerの管理」ページで、「オプション・リスト」タブをクリックします。
「オプション・リスト」からリストを選択します。このリストには「タイプ」($DocType)リスト以外に、構成マネージャでリストが定義されているすべてのカスタム・メタデータ・フィールドのリストも含まれます。
|
注意: リスト・メタデータ・フィールドを構成マネージャから削除すると、そのフィールドは「ルール・セット」タブから削除されますが、「オプション・リスト」タブの「オプション・リスト」リストには引き続き表示されます。廃止したリストを選択しないように注意してください。 |
「カテゴリ」リストから値を選択します。そのリスト用に事前に定義されている値のみ表示されます。
「キーワード」フィールドにキーワードまたは語句を入力します。オプション・リスト検索では、大/小文字が区別されるため、正確に一致する必要があります。
キーワードには、1つの単語または語句を使用できます。
キーワードには、ブール型の式を含めることができ、有効なバイナリ演算子は$$AND$$、$$OR$$、$$AND_NOT$$、$$NEAR$$です。
キーワードの重みを選択します。
常に: キーワードが見つかった場合、スコアに関係なく、選択したカテゴリが推奨値として返されます。
重み: この数値をキーワードの出現回数に乗算した値が、カテゴリのスコアとなります。スコアの最も高いカテゴリが、リスト・フィールドの推奨値として返されます。
なし: キーワードが見つかった場合、スコアに関係なく、選択したカテゴリは推奨値として返されません。
「追加」をクリックします。
選択したリストの各カテゴリにキーワードを入力します。
キーワードを削除するには、「キーワード」リストでキーワードを選択し、「削除」をクリックします。
キーワードを編集するには、「キーワード」リストでキーワードを選択して「編集」をクリックし、キーワード、重みまたはその両方を編集して「更新」をクリックします。
「適用」をクリックして変更内容を保存するか、「OK」をクリックして変更内容を保存し、ページを閉じます。
Content Categorizerが「タイプ」のデフォルト値を無視して、検索ルールを「タイプ」フィールドに適用するように、構成ファイルを構成できます。
この手順を適用できるのは、「タイプ」(dDocType)フィールドのみです。他の標準のリスト・フィールド(「セキュリティ・グループ」、「作成者」および「アカウント」)には、検索ルールを適用できません。
検索ルールを「タイプ」フィールドに適用する手順は、次のとおりです。
ワードパッドなどのテキスト・エディタで、IntradocDir/config/ディレクトリにあるconfig.cfgファイルを開きます。
次の行をファイルに追加します。
ForceDocTypeChoice=true
ファイルを保存して閉じます。
コンテンツ・サーバーを停止して再起動します。
次に、doc_config.htmページのサンプルを示します。
<@table DocFormatsWizard@>
| dFormat | 拡張子 | dConversion | dDescription |
|---|---|---|---|
|
application/ corel-wordperfect、application/wordperfect |
wpd |
WordPerfect |
apWordPerfectDesc |
|
application/ vnd.framemaker |
fm |
FrameMaker |
apFramemakerDesc |
|
application/ vnd.framebook |
bk、book |
FrameMaker |
apFrameMakerDesc |
|
application/vnd.mif |
mif |
FrameMaker |
apFrameMakerInterchangeDesc |
|
application/lotus-1-2-3 |
123、wk3、wk4 |
123 |
apLotus123Desc |
|
application/lotus-freelance |
prz |
Freelance |
apLotusFreelanceDesc |
|
application/lotus-wordpro |
lwp |
WordPro |
apLotusWordProDesc |
|
application/msword、application/ms-word |
doc、dot |
Word |
apMicrosoftWordDesc |
|
application/vnd.ms-excel、application/ms-excel |
xls |
Excel |
apMicrosoftExcelDesc |
|
application/ vnd.ms-powerpoint、application/ms-powerpoint |
ppt |
PowerPoint |
apMicrosoftPowerPointDesc |
|
application/vnd.ms-project、application/ms-project |
mpp |
MSProject |
apMicrosoftProjectDesc |
|
application/ms-publisher |
pub |
MSPub |
apMicrosoftPublisherDesc |
|
application/write |
wri |
Word |
apMicrosoftWriteDesc |
|
application/rtf |
rtf |
Word |
apRtfDesc |
|
application/vnd.visio |
vsd |
Visio |
apVisioDesc |
|
application/vnd.illustrator |
ai |
Illustrator |
apIllustratorDesc |
|
application/vnd.photoshop |
psd |
PhotoShop |
apPhotoshopDesc |
|
application/vnd.pagemaker |
p65 |
PageMaker |
apPageMakerDesc |
|
image/gif |
drw、igx、flo、abc、igt |
iGrafx |
apiGrafxDesc |
|
text/postscript |
ps |
Distiller |
apDistillerDesc |
|
application/hangul |
hwp |
Hangul97 |
apHangul97Desc |
|
application/ichitaro |
jtd、jtt |
Ichitaro |
apIchitaroDesc |
|
image/graphic |
gif、jpeg、jpg、png、bmp、tiff、tif |
ImageThumbnail |
apThumbnailsDesc |
|
image/application |
txt、eml、msg |
NativeThumbnail |
apNativeThumbnailsDesc |
<@end@> <@table PdfConversions@>
| dFormat | 拡張子 | dConversion | dDescription |
|---|---|---|---|
|
application/pdf |
|
PDFOptimization |
apPdfOptimization |
|
application/pdf |
|
ImageThumbnail |
apPdfThumbnailsDesc |
<@end@>
コンテンツ・サーバーでは、2ステップのプロセスを使用してコンテンツを分類します。最初のステップでコンテンツをXML形式に変換し、2番目のステップでXMLファイルをContent Categorizerで使用できる別のXMLファイルに変換します。このプロセスは透過的で、元のコンテンツは変更されず、変換された両方のXMLファイルは使用後に破棄されます。
この項の内容は次のとおりです。
変換ステップでは、OutsideIn XML Exportフィルタを使用し、変換するコンテンツのタイプと、使用するプラットフォームで使用可能な形式かどうかに基づいて、SearchMLまたはFlexiondoc XML形式でXMLを出力します。この変換プロセスを使用すると、Categorizerで大量の異なるソース・ドキュメント形式をサポートできます。
変換ステップでは、eXtensible Style Sheet Language Transformations(XSLT)を使用して、最初のXML出力を、ユーザーが定義した検索ルールに基づいてContent Categorizerで容易に検索および分析できるXMLに変換します。
変換プロセスの概要は、カテゴリ化プロセスに興味があるユーザーにとって有用であり、独自のXSLTスタイルシートを定義して特定のドキュメント処理ニーズに対応する必要のあるユーザーの開始点としても役立ちます。
OutsideIn XML Exportフィルタを使用した変換
OutsideIn XML Export製品のランタイム・バージョンはコンテンツ・サーバーと統合してインストールされ、チェックインされたコンテンツを分類のためにフィルタ処理します。Exportフィルタは、CategorizerのXSLTスタイルシートを使用した変換で使用できるように、コンテンツをXMLに変換します。この変換が必要なのは、Export XMLスキーマ、FlexiondocおよびSearchMLがContent Categorizerルールで容易に検索できない形式であるためです。
OutsideIn XML Exportでサポートされるファイル・フォーマットのリストは、第40章「入力ファイル・フォーマット」を参照してください。
Content Categorizerには2つのスタイルシートが付属しており、OutsideIn XML Exportフィルタによって提供される最初の変換形式に基づいて適用されます。スタイルシートは次のディレクトリにあります。
/IntradocDir/data/contentcategorizer/stylesheets/
SearchMLでコンテンツ・アイテムを出力する場合は、searchml_to_scc.xslが適用されます。Flexiondocでコンテンツ・アイテムを出力する場合は、flexiondoc_to_scc.xslが適用されます。SearchMLとFlexiondocは、ソース・コンテンツで検出されたスタイル指定を再生成しますが、Content Categorizerルールでは検出できないスタイル指定をそれぞれ異なる方法で再生成します。適切なスタイルシートを使用すると、各形式で必要なスタイル情報を認識し、その情報を基にして、最終出力タグをContent Categorizerで使用可能なXMLドキュメントに変換できます。
SearchMLとFlexiondocの類似性は、コンテンツで使用されている内部スタイルまたはメタデータの程度によって異なります。Microsoft Wordなどの名前付きスタイルを使用したコンテンツを処理した場合、結果出力は類似します。PDFやテキストなどの形式のコンテンツを処理する場合、結果はより包括的なタグ付けになります。
|
重要: Flexiondoc形式で出力されたPDFコンテンツの後処理にXSLT変換を使用すると、問題が発生します。Flexiondocを使用すると、1つの単語が個別のXML要素に割り当てられ、最終的なXMLがほとんどのCategorizer検索ルールに対して不適合となります。PDFコンテンツを分類する場合は、SearchMLを使用することをお薦めします。 |
OutsideIn XML Exportフィルタは、コンテンツをSearchML XML形式に変換するときに、タイトル、件名、作成者など、コンテンツ・アイテムのプロパティを識別し、それらを<doc_property>要素としてタグ付けします。各プロパティはtype属性で区別します。ドキュメント・テキストも識別し、<p>要素としてタグ付けします。テキスト内のスタイルはs属性で区別します。
OutsideIn XML Exportフィルタは、コンテンツをFlexiondoc XML形式に変換するときに、タイトル、件名、作成者など、コンテンツ・アイテムのプロパティを識別し、それらをSearchMLと同様に<doc_property>要素としてタグ付けします。ただし、各プロパティはtype属性ではなく、name属性で区別します。
FlexiondocがSearchMLと異なる点は、スタイルの識別方法です。段落スタイルは<tx.p>タグでタグ付けされ、文字スタイルは<tx.r>タグでタグ付けされますが、それぞれは、name属性に加えて、一意のスタイルのidに基づいて属性が指定されています。
すべてのスタイルは、Flexiondoc XMLファイルの<style_tables>要素の子要素で定義され、id属性が指定されていますが、この属性はスタイルを参照するときにコールされ、テンプレート・ファイルを使用してスタイル・キーとname属性が定義されます。
リンク・マネージャはコンテンツ・サーバーにバンドルされたオプションのコンポーネントで、コンテンツ・サーバーとともに自動的にインストールされます。有効な場合は、リンク・マネージャは索引付けしたコンテンツ・アイテムのURLリンクを、データベース表(ManagedLinks)への格納のために抽出する前に、評価、フィルタ処理および解析します。抽出したURLリンクがManagedLinks表に移入されると、リンク・マネージャ・コンポーネントはこの表を参照し、リンク検索結果、コンテンツ情報ページ用のリンク参照リストおよびリンク情報ページ用のリソース情報を生成します。
リンク・マネージャ・コンポーネントを使用すると、ユーザーは次のことを実行できます。
特定の検索条件を使用したリンク・リストの表示
特定のリンクに関する詳細情報の表示
リンクを再評価して検証するための再計算とリフレッシュ
特定のコンテンツ・アイテム内にある他のコンテンツへのリンクの表示
特定のコンテンツ・アイテムに戻るリンクの表示
検索結果、リンク参照リストおよびリンク情報ページは、コンテンツの追加、変更またはリビジョン削除による影響を受けるコンテンツ・アイテムの判別に役立ちます。たとえば、コンテンツ・アイテムを削除する前に、含まれているURL参照が重要でないことを確認できます。コンテンツ・アイテムがどのように使用されているかを監視するためにも使用できます。
リンク・マネージャ・コンポーネントによるURLリンクの抽出は索引作成サイクル中に実行されるため、抽出されるのはリリースされたコンテンツ・アイテムのURLリンクのみです。複数のリビジョンがあるコンテンツ・アイテムの場合、データベース表にエントリがあるのは、最新のリリース済リビジョンのみです。コンテンツ・アイテムがすでにチェックインされた後でリンク・マネージャ・コンポーネントをインストールする場合は、すべてのリンクがManagedLinks表に確実に含まれるように、再構築を実行する必要があります。
リンク・マネージャによる作業はすべて索引作成サイクル時に実行されるため、コンテンツ・アイテムの索引作成およびコレクションの再構築に必要な時間が増加します。
必要な時間は、関連するコンテンツ・アイテムのタイプとサイズによって決まります。つまり、ファイルが変換される場合は、テキストベース(HTML)のファイルより時間がかかります。
再構築サイクル中にリンク・マネージャを無効にする方法については、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスで、LkDisableOnRebuildおよびLkReExtractOnRebuild変数を参照してください。
このセクションのトピックは次のとおりです:
|
注意: リンク・マネージャ・コンポーネントでは、ファイルの変換にHtmlExport 8を使用します。リンク・マネージャ・コンポーネントには、リンク抽出テンプレート・ファイルが含まれています。HtmlExport 8には、このテンプレートが必要です。このファイルは編集しないでください。 |
リンク・マネージャは、抽出エンジンとパターン・エンジンで構成されています。抽出エンジンには変換エンジン(HtmlExport)が含まれています。変換エンジンは、抽出エンジンではテキストベースのファイル・フォーマット(HTML)にネイティブに解析できないファイルを変換するために使用されます。
リンク・マネージャでは、ファイル・フォーマットにhcs、htm、image、text、xml、jspおよびaspのいずれかの文字列が含まれているファイルの変換にHtmlExportを使用しません。これらのテキストベースのファイルは、リンク・マネージャによって処理され、変換の必要はありません。
索引作成サイクル中に、リンク・マネージャ・コンポーネントは、URLリンクを検出するために、チェックインしたコンテンツ・アイテムを次のように検索します。
抽出エンジンが、変換エンジンを使用してファイルを変換します(必要な場合)。
抽出エンジンは、次に、パターン・エンジンを使用して、リンク・マネージャ・パターン表に定義されているリンク評価ルールにアクセスします。
評価ルールは、コンテンツ・アイテム内の承認済URLリンクをソート、フィルタ処理、評価および解析する方法を抽出エンジンに指示します。
承認済URLリンクがManagedLinks表に挿入されるかまたは更新されます。
|
重要: 正常に実行するには、HtmlExportに仮想または物理ビデオ・インタフェース・アダプタ(VIA)のいずれかが必要です。ほとんどのWindows環境には、フレーム・バッファへのHtmlExportアクセスを提供するグラフィック機能が備えられています。しかし、UNIXシステムには、グラフィック・カードがない場合があり、HtmlExportで使用するためのX-Windowsサーバーが稼働していません。グラフィック・カードのないシステムの場合は、仮想フレーム・バッファ(VFB)をインストールして使用できます。 |
リンクを抽出する前に、様々なファイル・フォーマット(Wordなど)を変換エンジン(HtmlExport)で変換する必要があります。リンク・マネージャではテキストベースのファイル(HTML)内のリンクを変換なしで抽出できるため、リンク・マネージャでは、ファイル・フォーマットにhcs、htm、image、text、xml、jspおよびaspのいずれかの文字列が含まれているファイルの変換にHtmlExportを使用しません。
また、リンク・マネージャでは、これらのファイル・フォーマットのすべてのバリエーションも処理されます。たとえば、hcs文字列は、動的サーバー・ページ文字列のhcst、hcspおよびhcsfと一致します。image文字列は、image/gif、image/jpeg、image/rgb、image/tiffなどの類似するすべてのバリアントに一致します。他のタイプのファイルが変換されないようにするには、LkDisallowConversionFormats構成変数を使用します。詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
リンク・マネージャでは、次のファイル・フォーマットでリンクが認識されます。
テキストベースのフォーマット(txt、html、xml、jsp、asp、csv、hcst、hcsfおよびhcsp)
電子メール(msgおよびeml)
Microsoft Word
Microsoft Excel
OpenOffice Writer
OpenOffice Calc
新しいリンクと既存のリンクはすべて、索引作成サイクル中に管理されます。コンテンツ・アイテムがチェックインされると、これらのコンテンツ・アイテム内の承認済リンクは管理されたリンク表に追加されるか、更新されます。既存のリンクは、コンテンツ・アイテムのチェックインまたは削除による変更に対して評価されます。リンクが追加または監視されると、そのリンクには有効または無効のマークが付けられます。
システム内のあるコンテンツ・アイテムがシステム内の別のコンテンツ・アイテムを参照している場合、結果のリンクには有効のマークが付けられます。既存のリンクが削除されたコンテンツ・アイテムを参照している場合、そのリンクは再評価され、ステータスが有効から無効に変わります。ステータスは、管理されたリンク表のdLkState列にY(有効)またはN(無効)として記録され、ユーザーに対しては、リンク情報ページの「状態」列に、「有効」または「無効」として表示されます。
IntradocDir/config/config.cfgファイルで次のリンク・マネージャ構成変数を指定できます。
AllowForceDelete
HasSiteStudio
LkRefreshBatchSize
LkRefreshErrorsAllowed
LkRefreshErrorPercent
LkRefreshErrorTHreshold
LkDisableOnRebuild
LkDisallowConversonFormats
LkReExtractOnRebuild
LkIsSecureSearch
これらの構成変数の使用の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
リンク・マネージャ・コンポーネントでは、リソース表に定義されたリンク・パターンを参照する抽出エンジンを使用します。これらのリンク・パターンは、様々なリンクのソート方法、フィルタ処理で除外するリンク、受け入れるリンク、および詳細情報を取得するためにリンクを解析する方法を抽出エンジンに指示するルールです。
DomainHome/ucm/LinkManager/resources/linkmanager_resource.htmリソース表をカスタマイズするために、新しいルールを追加するか、または既存のデフォルト・ルールを編集できます。標準コンポーネント・アーキテクチャを使用して、この表をカスタマイズします。表には、次の列があります。
| 列名 | 説明 |
|---|---|
|
lkpName |
パターンの名前であり、この表の主キーです。主にエラー処理で使用され、指定したルールのオーバーライドを他のコンポーネントで直接ターゲット指定できるようにします。 |
|
lkpDescription |
パターンの目的の説明です。 |
|
lkpType |
URLの初期スクリーニングです。
抽出エンジンは2ステップのエンジンです。prefixおよびcontainsのタイプはURLのパス部分で使用されるのに対して、serviceのタイプは、URLの問合せ文字列部分で使用されます。 |
|
lkpParameters |
タイプで使用されるパターンまたはパラメータのカンマ区切りのリスト。パラメータはIdocスクリプト対応であり、Idocスクリプトに対して最初に評価されます。エンジンでは、パラメータからパターンを抽出するために次のルールが使用されます。
その後のルールでは、パラメータを |
|
lkpAccept |
パターンが一致した場合に、URLが承認されるかどうかを決定します。
|
|
lkpContinue |
パターン処理エンジンがURLの解析を続行するかどうかを決定します。trueの場合、処理は続行します。falseの場合、処理は停止します。 |
|
lkpLinkType |
このリンク用に決定したURLタイプを指定します。 |
|
lkpAction |
LinkHandlerクラスで定義された関数であり、URL.をさらに解析指標化するために使用されるLinkImplementorクラスのメソッドを参照します。 LinkImplementorは、エイリアス化されたクラス、または拡張されたクラスの場合があります。 |
|
lkpOrder |
パターンが評価される順序。 |
|
lkpEnabled |
このルールを評価するかどうかを決定します。これは、パターンがロードされる起動時に計算され、評価されます。 |
標準コンポーネント・アーキテクチャを使用して、新しいルールを追加するか、または既存のデフォルト・ルールを編集できます。
リンク・マネージャでは、次の2つのデータベース表をメンテナンスします。
管理されたリンク表: パターン・エンジンでリンクの処理に成功し、リンクが承認可能と判断されると、そのリンクは管理されたリンク表に格納されます。表内の各リンクには一意のクラスID(dLkClassId)が割り当てられ、表内の各行には一意のGUID(dLkGUID)があります。1つのリンクが複数のリソースで定義され、各リソースが単独でリンクを破棄できる場合、そのリンクは、表内の複数の行で構成されている可能性があります。
たとえば、Site Studioでは、1つのリンクがノードとコンテンツ・アイテムの両方で定義される可能性があります。ノードが見つからない場合、そのリンクは破棄されます。コンテンツ・アイテムが見つからない場合、そのリンクは破棄されます。この場合、相互に依存しない2つのリソースがあり、それぞれがリンクを破棄できます。したがって、各リソースはManagedLinks表で別々に管理されます。
問合せ実行パフォーマンスを改善するために、標準索引が管理されたリンク表のdDocName列とdLkResource列に追加されています。システム管理者は、様々なシステム環境で、特定のデータベース・チューニング要件に合わせてこれらの索引を調整する必要があります。
リンク参照カウント表: コンテンツ・アイテムが、それぞれManagedLinks表で参照されている回数にマップされます。この表内のコンテンツ・アイテムは、コンテンツ・サーバーで現在管理されているコンテンツ・アイテムではない可能性があります。この表にコンテンツ・アイテムのエントリがある場合は、ManagedLinks表内のリンクが、パターン・エンジンによって解析されたときに、コンテンツ・アイテムをdocリソースとして参照したことのみを示しています。
コンテンツ・アイテムがチェックインされ、リンクでそのコンテンツ・アイテムが参照される場合、そのリンクには有効のマークが付けられます。削除したコンテンツ・アイテムがリンクで参照される場合、そのリンクには無効のマークが付けられます。dLkState列には、リンクのステータスがY(有効)またはN(無効)として示されることに注意してください。
リンク・マネージャ・コンポーネントには、パターン・エンジンの部品用に、いくつかの非常に特殊な動作をカスタマイズできるフィルタが用意されています。一般的に、パターン・エンジンのルールは、変更されることがよくあります。特定の状況では、リンク・マネージャによって、標準の動作を拡張するためのフィルタが明示的に作成および使用されます。
extractLinksフィルタ: 抽出エンジンで承認済URLリンクが解析されるとき、抽出プロセス中に使用されます。リンクが抽出されると、リンク・マネージャによって特定のHTMLタグが検索されます。ただし、他のHTMLタグにも関連リンクが含まれていることがあります。この場合は、このフィルタを使用して、これらの追加リンクを抽出できます。
タグは、キーHtmlTagとともに、キャッシュされたオブジェクトとしてフィルタに渡されます。値(つまりリンク)は、キーHtmlValueとともに解析に戻されます。フィルタによって追加情報が抽出された場合、渡されたバインダは、パターン・エンジンに渡される前にフラッシュされることに注意してください。service.setCachedObjectおよびservice.getCachedOjectメソッドで、それぞれ追加情報を渡し、取得する必要があります。
デフォルトでは、<a>、<link>、<iframe>、<img>、<script>および<frame>のHTMLタグが検索されます。
linkParseServiceフィルタ: IdcServiceパラメータを使用するリンクがパターン・エンジンで評価されるとき、抽出プロセス中に使用されます。評価後、リンク・バインダとサービスがlinkParseServiceフィルタに提供されます。
サービスには、解析済のURLと情報マップのバインダが含まれています。特定のパラメータを調整して、解析済URLバインダの値をカスタマイズするか、または、(parseServiceメソッドに対して、URLバインダから抽出するパラメータや、データをリソース・タイプにマップする方法を指示する)情報マップをカスタマイズします。
sortAndDecodeLinksフィルタ: リフレッシュ・オプションからのみ使用できます。これは、ユーザーがリンクをリフレッシュしているときにのみコールされます。サービスには、ManagedLinks表に格納されているリンクのソート済リストを含むLinkSetMapが含まれています。リフレッシュでは、Site Studioのリンク、およびdocリソースを参照するすべてのリンクの存在が検証されます。標準の検証を拡張するコンポーネントを作成することもできます。
|
重要: Site Studioを使用する場合は、 |
Site Studioとともに機能するように構成されると、リンク・マネージャでは、Site Studioで識別されたリンクの解析を直接リクエストすることによって、Site Studioからリンクが取得されます。かわりに、Site Studioからリンクの操作やコンポーネントに関する情報が提供されます。特に、Site Studioからは、ノード/セクション、コンテンツ・アイテムが使用されるかどうか、コンテンツ・アイテムの状態、リンクのタイプ(フレンドリ、ページまたはノード)、およびリンクが有効かどうかに関する情報が提供されます。
Site Studioでは、スタンドアロン・アプリケーションの起動時に、プロジェクト情報がロードされません。したがって、スタンドアロン・アプリケーションによって再構築または索引更新サイクルが開始および完了された場合、Site Studioリンクは正しく評価されません。
ユーザーがSite Studio Designerを使用してリンクを変更すると、リンク・マネージャによってフィルタ・イベントが確認されます。ノードが削除された場合は、リンク・マネージャによって、削除されたノードを使用するすべてのリンクに無効のマークが付けられ、これにより、ノードIDを直接参照するリンクが管理されます。さらに、Site Studioから提供される情報によって、リンク・マネージャではリンクの状態を正確に判断できます。
フレンドリURL(つまり、ノードIDまたはdDocNameを参照しないリンク)は、管理および検証がより困難です。ノードのプロパティが変わると、リンク・マネージャによって、このノードを使用するすべてのフレンドリ・リンク(相対と絶対の両方)に無効および破棄のマークが付けられます。リンク・マネージャでは、リンクの変更された部分、その修正の方法、または実際に破棄されているかどうかを判断するために、親のチェーンを再トレースできません。
Site Studioでは、2つのタイプの管理されたリンクが使用されます。
完全に管理されたリンク: SS_GET_PAGE IdcServiceを使用するすべてのリンク、または次のものを含むノードへのリンクがあります。
javascript:nodelink(ノード、サイト)
javascript:nodelink(ノード)
ssNODELINK/サイト/ノード
ssNODELINK/ノード
および、次のものを含むページへのリンク:
ssLINK/ドキュメント
ssLINK/ノード/ドキュメント
ssLINK/サイト/ノード/ドキュメント
ssLink(ドキュメント)
ssLink(ドキュメント、ノード)
ssLink(ドキュメント、ノード、サイト)
javascript:link(ドキュメント)
javascript:link(ドキュメント、ノード、サイト)
暫定的に管理されたリンク:次のSite Studioリンクは、Site Studioノードの変更に至るまで管理されます。リンクの状態を判断するには、「管理されたリンクの管理」ページからリフレッシュ・オプションを使用します。リンクの大部分がこの形式で、ノードが大幅に変化した場合は、リンクをリフレッシュまたは再計算してください。
絶対(または完全URL): http://site/node/doc.htm
ノードへのフレンドリ・リンク
<!--$ssServerRelativeSiteRoot-->dir/dir/index.htm
[!--$ssServerRelativeSiteRoot--]dir/dir/index.htm
<%=ssServerRelativeSiteRoot%>dir/dir/index.htm
ページへのフレンドリ・リンク
<!--$ssServerRelativeSiteRoot-->dir/dir/doc.htm
[!--$ssServerRelativeSiteRoot--]dir/dir/doc.htm
<%=ssServerRelativeSiteRoot%>dir/dir/doc.htm
この項の内容は次のとおりです。
「管理されたリンクの管理」ページで使用可能なリフレッシュ・アクティビティ以外に、管理されたリンク表とリンク参照カウント表の更新に、次の代替方法も使用できます。
リポジトリ・マネージャを使用して、コレクションの再構築を実行します。このプロセスでは、検索索引全体が再構築され、再構築が正常に完了すると古い索引コレクションが新しい索引コレクションに置き換えられます。
リポジトリ・マネージャがスタンドアロン・アプリケーションとして開かれている場合、この代替リフレッシュ方法を使用できるのは、HasSiteStudio構成変数が無効化されているときのみです。Site Studioから情報がリクエストされ、リポジトリ・マネージャがスタンドアロン・モードである場合、Site Studioは完全に初期化されず、正確な情報が返されません。この問題は、リポジトリ・マネージャ・アプレットが使用されている場合には発生しません。
コンテンツがシステム内にある間にカスタム・フィールドが追加された場合は、構成マネージャの「検索索引の再構築」を使用して、検索索引を再構築します。
ManagedLinks表のリンクを再評価する手順は、次のとおりです。
「メイン」メニューから「管理」→「管理されたリンクの管理」を選択します。
「管理されたリンクの管理」ページで、次のいずれかのオプションを使用してリンクを管理します。
リンクの再計算: 「リンクの再計算」オプションの横にある「実行」をクリックします。このリフレッシュ・アクティビティは、ManagedLinks表の各リンクを取得して、パターン・エンジンに再送信します。リンクは、パターン・ルールに従って評価され、表内で更新されます。リンクは、有効または無効になったパターンに応じて、別のタイプのリンクとして再分類される場合があります。このオプションは、パターン・ルールが変更された場合に使用します。
リンクのリフレッシュ: 「リンクのリフレッシュ」オプションの横にある「実行」をクリックします。このアクティビティでは、ManagedLinks表の各リンクをチェックして、リンクが有効かどうかを判断します。Site Studioのリンクは、リンクで使用されるノードとコンテンツ・アイテムを判断するために、リンクがSite Studioデコード・メソッドに送信されます。リンクが有効かどうか、確かにSite Studioリンクかどうかも判断されます。
このオプションは、Site Studioのノード/セクションのプロパティに多くの変更が加えられた後に使用します。リンク・マネージャでは、Site Studioのフレンドリ・リンクに対する変更を完全には追跡できません。リンクをリフレッシュするか、強制的に検証を実行することによって、リンク・マネージャでは、破棄されているリンクおよび有効なリンクをより正確に判断できます。
参照カウントのリフレッシュ: 「リフレッシュ」オプションの横にある「実行」をクリックします。このアクティビティは、LinkReferenceCount表をフラッシュして、ManagedLinks表にコンテンツ・アイテム参照を問い合せます。表の再計算と表のリフレッシュのアクティビティは両方とも、LinkReferenceCount表をメンテナンスしようとします。ただし、この表は同期がとれていない場合があるため、このオプションを静止したシステムで使用すると、表が再構築されます。
リフレッシュ・アクティビティの取消し: アクティビティの中止オプションの横にある「実行」をクリックします。一度にアクティブにできるリフレッシュ・アクティビティは1つのみです。
「ステータス」領域には、処理されたリンクの数、および発生したエラーの数が表示されます。
一度にアクティブにできるリフレッシュ・アクティビティは1つのみです。別のリフレッシュ・アクティビティを試行するには、リフレッシュ・アクティビティが完了し、「準備完了」ステータスが表示されるまで待機します。
