| Oracle® WebCenter Content Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-02 |
|
 前 |
 次 |
Content Categorizerは、Oracle WebCenter Content Serverとともに自動的にインストールされるオプション・コンポーネントです。Content Categorizerを有効にすると、Oracle WebCenter Content Serverにチェックインされた新しいドキュメントや、メタデータ値が設定されている(または設定されていない)既存のドキュメントに対して推奨メタデータ値が示されます。これらのメタデータ値は、システム管理者が指定した検索ルールに従って決定されます。
このコンポーネントとともに含まれるバッチ・カテゴライザでは、大量のファイルを検索したり、適切なメタデータ・フィールド値を含むバッチ・ローダー制御ファイルを作成できます。バッチ・カテゴライザは、リポジトリにチェックイン済のコンテンツを再分類するためにも使用できます。
この章の内容は、次のとおりです。
Content Categorizerで構造プロパティを認識するには、コンテンツをXML変換(eXtensible Markup Language)する必要があります。変換メソッドは、sccXMLConversion構成変数で定義します。Content Categorizerは検索ルールを使用して、コンテンツの推奨メタデータ値を示します。
この項の内容は次のとおりです。
|
重要: Flexiondocスキーマを使用して変換したPDFコンテンツをXSLT変換を使用して後処理する場合は、問題が発生します。Flexiondocスキーマを使用すると、1つの単語が個別のXML要素に割り当てられ、最終的なXMLが使用できなくなります。PDFコンテンツを分類する場合は、SearchMLを使用する必要があります。 |
いずれのXML Converterを指定する場合でも、XML中間ファイルはContent Categorizerによってのみ使用されるため、使用後は破棄され、ドキュメントは元のソース形式でOracle WebCenter Content Serverにチェックインされます。唯一の例外はXML形式であるコンテンツで、これは変換処理の対象にはなりません。
各コンバータで、OutsideIn XML ExportテクノロジがカスタムXSLTスタイルシート(flexiondoc_to_scc.xsl)と組み合せて使用され、2段階の処理でXMLを生成します。第1段階では、ネイティブ・ドキュメントをFlexiondoc形式のXMLまたはSearchML形式のXMLのいずれかに変換します。
第2段階では、スタイルシートを使用してXMLをさらに調整し、Content CategorizerでXMLを検索できるようにします。XML要素ではネイティブ・ドキュメントのプロパティとテキスト・セグメントが分離され、対応するドキュメント・プロパティ、段落スタイルまたは文字スタイルに基づいて名前が付けられます(文字スタイルはSearchMLではサポートされていないことに注意してください)。
Content Categorizerは、定義されているルールのタイプに基づいて検索ルールを実行します。
パターン照合ルールと抽象ルール: Content Categorizerは、コンテンツ・ドキュメントの「ランドマーク」を検索します。ランドマークは、特定のテキストにすることも、ソース・ドキュメントの構造プロパティ(スタイル、フォント、フォーマットなど)に基づいて使用することもできます。
オプション・リスト・ルール: Content Categorizerはキーワードを検索し、そのキーワードの累積スコアによって、リストの中のどのオプションを選択するかを決定します。ランドマークまたは特定のXMLタグは検索しません。
カテゴリ化エンジン・ルール: Content Categorizerはサードパーティのカテゴライザ・エンジンと分類を起動し、コンテンツ・アイテムを分類します。
Filetypeルール: Content Categorizerはドキュメント・ファイル・タイプ(ファイル名拡張子)を検索します。
通常、「コンテンツ・チェックイン・フォーム」にユーザーが値を入力すると、そのフィールドに対するContent Categorizerによる検索ルールの適用が防止されます。これは、「タイプ」フィールドなど、デフォルト値があるリスト・フィールドの場合も同様です。
|
重要: コントリビュータに、検索ルールによって入力するフィールドは空白のままにするよう指示することが重要です。 |
検索ルールの詳細は、第9.3項「検索ルール」を参照してください。
Content Categorizerを実行するには、次のタスクを完了する必要があります。
XML変換メソッドを定義します。詳細は、第9.2.1項「XML変換メソッドの設定」を参照してください。
検索ルールを定義します。詳細は、第9.3.3項「検索ルールの定義」を参照してください。
(オプション)メタデータ・フィールドのデフォルト値などのフィールドのプロパティを定義します。詳細は、第9.2.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 WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
バッチ・モード・プロセスでは、システム管理者が次の手順を実行します。
バッチ・カテゴライザ・アプリケーションを実行します。UNIXシステムでのアプリケーションの実行の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。
「バッチ・カテゴライザ」画面が開きます。
必要に応じて、フィルタとリリース日の情報を定義し、分類するコンテンツのリストを表示します。「分類」をクリックします。
「既存の分類」画面が開きます。
「ライブ・アップデート」または「バッチ・ローダー」を選択します。
「ライブ・アップデート」オプションは、リポジトリのデータを即座に更新します。
「バッチ・ローダー」オプションは、Content Categorizerプロセスの出力である制御ファイルを作成する場合に使用します。ファイルには、各ソース・ドキュメントのエントリと、Content Categorizerで定義した検索ルールに基づいた各メタデータ・フィールドの値が含まれます。このファイルは、バッチ・ローダーに送信する前に編集できます。
Content Categorizerプロセスの完了後にバッチ・ローダー・ユーティリティを自動的に実行するには、「バッチ・ローダーの実行」チェック・ボックスを選択します。
Content Categorizerプロセスのエラー情報が含まれるログ・ファイルの場所およびファイル名を入力します。
すべてのコンテンツ・アイテムが処理されるように「すべての分類」を選択するか、または、コンテンツ・リスト内のハイライトされたアイテムのみが使用されるように「選択済の分類」を選択します。
アイテムの最新リビジョンのみを処理する「最新のリビジョン」の分類を選択するか、または「全リビジョン」の分類を選択します。
バッチ・カテゴライザにエラーが発生したときに、カテゴリ化プロセスを続行するか中止するかを選択します。
「OK」をクリックします。進行状況バーには、バッチ・プロセスのステップ間移動の進行状況が表示されます。
Content Categorizerはソース・コンテンツを検索します。
コンテンツがXML形式の場合、変換は発生せず、プロセスは手順dに進みます。
コンテンツがXML形式ではない場合、XML変換メソッドとして選択したFlexiondocまたはSearchMLを使用してXMLへの変換が実行されます。
Content Categorizerは検索ルールをXMLに適用し、特定のメタデータ・フィールドの値を取得します。
「ライブ・アップデート」が指定されている場合は、データベース・レコードが即座に更新されます。「バッチ・ローダー」が指定されている場合は、出力制御ファイルが作成され、バッチ・ローダー・ユーティリティが実行されます(処理後に実行するようにオプションが指定されている場合)。
バッチ・プロセスの完了後、エラー・ログを確認します。バッチ・カテゴライザで発生したエラーはコンソールに表示され、バッチ・カテゴライザのログにも記録されます(指定した場合)。バッチ・ローダーで発生したエラーはコンソールに表示され、システム・ログにも記録されます。
オプションのAddCCToArchiveCheckinコンポーネントがインストールされていて有効な場合、バッチローダー・ユーティリティを使用してロードされたすべてのコンテンツが、事前定義されたルール・セットに基づいて自動的に分類されます。ルール・セットの定義の詳細は、第9.3.3項「検索ルールの定義」を参照してください。
コントリビュータが「コンテンツ・チェックイン・フォーム」または「情報更新フォーム」を開き、プライマリ・ファイルを選択して(「コンテンツ・チェックイン・フォーム」のみ)、「分類」をクリックします。
「コンテンツ・チェックイン・フォーム」によって、そのプライマリ・ファイルがホストにコピーされ、Content Categorizerサービスがコールされます。
Content Categorizerはソース・コンテンツを検索します。
コンテンツがXML形式の場合、変換は発生せず、プロセスは手順6に進みます。
コンテンツがXML形式ではない場合、指定した変換メソッドが使用されます。
Content Categorizerは検索ルールをXMLに適用し、特定のメタデータ・フィールドの推奨値を取得します。
Content Categorizerは、推奨メタデータ値を「コンテンツ・チェックイン・フォーム」または情報更新フォームに挿入し、そのフォームをコントリビュータに返します。
コントリビュータは、推奨値を使用したドキュメントのチェックインや送信、メタデータ値の改訂、またはチェックインや更新の取消しを実行できます。
オプションのAddCCToNewCheckinコンポーネントがインストールされていて有効な場合は、「コンテンツ・チェックイン・フォーム」の「チェックイン」をクリックすると、手順2から6が実行されてチェックイン・プロセスが完了します(dDocTitleのプロパティが「コンテンツのオーバーライド」に設定されている場合)。
dDocTitleのプロパティが「コンテンツのオーバーライド」に設定されていない場合は、必須フィールドを入力するように要求するアラートが表示されます。フィールドのプロパティは、CC管理アプレットを使用して設定します。詳細は、第9.2.2項「フィールドのプロパティの定義(オプション)」を参照してください。
Content Categorizerを使用する前に、必要なソフトウェアをインストールおよび構成します。この項では次のタスクについて説明します。
Content CategorizerでXML変換メソッドを設定するには、次の手順に従います。
「メイン」メニューから「管理」→「Content Categorizerの管理」を選択します。
「構成」をクリックします。
「構成」タブが開きます。
「sccXMLConversion」プロパティを選択して「編集」をクリックするか、プロパティをダブルクリックします。
「プロパティの構成」画面が開きます。
リストから、XML変換メソッドとして「Flexiondoc」または「SearchML」を選択します。
「OK」をクリックします。
「適用」をクリックして変更を保存します。
フィールドに対するルールが成功すると、(「バッチ・ローダー」操作または「ライブ・アップデート」操作で)検出された値が使用されます。ただし、「オーバーライド」値の設定方法によっては、検出された値は既存の値をオーバーライドしません(「オーバーライド」をfalseに設定した場合)。
フィールドに対するすべてのルールが失敗した場合、フィールドにデフォルト値が定義されており、「デフォルトの使用」がtrueに設定されていないかぎり、フィールドに値は割り当てられません。
メタデータ・フィールドのフィールドのプロパティを定義するには、次の手順に従います。
「メイン」メニューから「管理」→「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管理アプレットが開いているときにカスタム・リスト・フィールドが作成または変更された場合は、アプレットを閉じてから再度開いて、変更を確認します。
現在のバージョンのOracle WebCenter Content Serverは、デフォルト値として空の値をカスタム・リスト・フィールドに自動的に挿入します。この場合、最初の値(デフォルトでは空の値)はユーザーによる入力値とみなさないため、オプション・リスト検索ルールが適用されます。オプション・リスト検索ルールでカスタム・リスト・フィールドの最初の値をオーバーライドしないようにするには、構成マネージャ・アプレットでそのリストのデフォルト値を指定します。
オプション・リスト検索ルールのタイプは1つで、キーで定義したキーワードと一致するキーワード(1つの単語または句)を検索します。
キーワードには、1つの単語(dogなど)または語句(black dogなど)を使用できます。
キーワードでは、次の一連の定義済演算子を使用して、検索をさらに絞り込むことができます。
$$AND$$
$$OR$$
$$AND_NOT$$
$$NEAR$$
キーワードはリストの各カテゴリ(値)に事前に割り当てられていて、各キーワードには重みが割り当てられています。詳細は、第9.3.3.2項「オプション・リストのキーワードの定義」を参照してください。
ドキュメントで検出された各キーワードの出現回数に重みが乗算され、キーワード・スコアが生成されます。
カテゴリごとのキーワード・スコアが加算され、カテゴリ・スコアが生成されます。
スコアの最も高いカテゴリが、推奨値として返されます。
カテゴリが同点の場合は、先にリストに出現するカテゴリが推奨値として返されます。
重みの「常に」と「なし」を使用すると、スコアと件数しきい値がオーバーライドされます。
重みの「常に」が指定されたキーワードが出現した場合は、スコアに関係なく、そのカテゴリが推奨値として返されます。
重みの「なし」が指定されたキーワードが出現した場合、スコアに関係なく、そのカテゴリは推奨値として返されません。
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
キー: MainCharacter
件数: 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
キー: MainCharacter
件数: 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
キー: MainCharacter
件数: 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
キー: MainCharacter
件数: 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は、フィールドの名前と長さを含む、現在のメタデータ・フィールド構成のスナップショットを作成します。メタデータ・フィールドの構成を変更した場合は、Oracle WebCenter Content Serverを再起動してから、Content Categorizerの管理アプレットを実行して、検索ルールを追加または変更します。
|
重要: Content Categorizerでファイル・タイプ(.doc、.txt、.xmlなど)を調べるには、そのタイプの空でないルールセットが必要です。特定のファイル・タイプのルールがない場合、Content Categorizerは例外をスローします。この例外を回避する最も簡単な方法は、デフォルトのルールセットに少なくとも1つのルールを追加することです。デフォルトのルールセットは、カスタム・ルールセットが割り当てられていないすべてのファイル・タイプに使用されます。 |
この項の内容は次のとおりです。
メタデータ・フィールドの検索ルールを定義するには、次の手順に従います。
「メイン」メニューから「管理」→「Content Categorizerの管理」を選択します。
「ルール・セット」タブをクリックします。
「ルールセット」ペインで、リストからルールセットを選択するか、「追加」をクリックして新しいルールセットを追加します。ルールセットには、特定のドキュメントまたは特定のドキュメント・タイプに適用される複数のルールが含まれます。指定されたドキュメントまたはドキュメント・タイプに対して特定のルールセットが定義されていない場合は、デフォルトのルールセットが使用されます。
ルールセットを追加する場合は、ダイアログ画面が開き、そこでルールセットの名前を入力できます。
「フィールド」リストからメタデータ・フィールドを選択します。
「追加」をクリックします。
「ルール」リストからルール・タイプを選択します。
「キー」フィールドに検索ルール・キーを入力します。タイプおよびサブタイプの詳細は、第9.3.2項「検索ルール・タイプ」を参照してください。
CATEGORYを使用する場合は、カテゴリ化エンジン名(カテゴライザ・エンジンのリストに複数のアイテムがある場合)、スラッシュ(/)、分類名の順に入力します。たとえば、EngineName/TaxonomyNameです。
OPTION_LIST検索ルールの場合は、リストのキーワードを「オプション・リスト」タブで定義する必要があります。詳細は、第9.3.3.2項「オプション・リストのキーワードの定義」を参照してください。
「件数」フィールドに件数を入力します。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の管理」を選択します。
「オプション・リスト」タブをクリックします。
「オプション・リスト」からリストを選択します。このリストには「タイプ」($DocType)リスト以外に、構成マネージャでリストが定義されているすべてのカスタム・メタデータ・フィールドのリストも含まれます。
|
注意: リスト・メタデータ・フィールドを構成マネージャから削除すると、そのフィールドは「ルール・セット」タブから削除されますが、「オプション・リスト」タブの「オプション・リスト」リストには引き続き表示されます。廃止したリストを選択しないように注意してください。 |
「カテゴリ」リストから値を選択します。そのリスト用に事前に定義されている値のみ表示されます。
「キーワード」フィールドにキーワードまたは語句を入力します。オプション・リスト検索では、大/小文字が区別されるため、正確に一致する必要があります。
キーワードには、1つの単語または語句を使用できます。
キーワードには、ブール型の式を含めることができ、有効なバイナリ演算子は$$AND$$、$$OR$$、$$AND_NOT$$、$$NEAR$$です。
キーワードの重みを選択します。
常に: キーワードが見つかった場合、スコアに関係なく、選択したカテゴリが推奨値として返されます。
重み: この数値をキーワードの出現回数に乗算した値が、カテゴリのスコアとなります。スコアの最も高いカテゴリが、リスト・フィールドの推奨値として返されます。
なし: キーワードが見つかった場合、スコアに関係なく、選択したカテゴリは推奨値として返されません。
「追加」をクリックします。
選択したリストの各カテゴリにキーワードを入力します。
キーワードを削除するには、「キーワード」リストでキーワードを選択し、「削除」をクリックします。
キーワードを編集するには、「キーワード」リストでキーワードを選択して「編集」をクリックし、キーワード、重みまたはその両方を編集して「更新」をクリックします。
「適用」をクリックして変更内容を保存するか、「OK」をクリックして変更内容を保存し、画面を閉じます。
Content Categorizerが「タイプ」のデフォルト値を無視して、検索ルールを「タイプ」フィールドに適用するように、構成ファイルを構成できます。
この手順を適用できるのは、「タイプ」(dDocType)フィールドのみです。他の標準のリスト・フィールド(「セキュリティ・グループ」、「作成者」および「アカウント」)には、検索ルールを適用できません。
検索ルールを「タイプ」フィールドに適用する手順は、次のとおりです。
ワードパッドなどのテキスト・エディタで、IntradocDir/config/ディレクトリにあるconfig.cfgファイルを開きます。
次の行をファイルに追加します。
ForceDocTypeChoice=true
ファイルを保存し、閉じます。
Oracle WebCenter Content Serverを停止して再起動します。
次に、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@>
Oracle WebCenter Content Serverでは、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製品のランタイム・バージョンはOracle WebCenter Content Serverと統合してインストールされており、チェックインされたコンテンツを分類できるようにフィルタ処理します。Exportフィルタは、CategorizerのXSLTスタイルシートを使用した変換で使用できるように、コンテンツをXMLに変換します。この変換が必要なのは、Export XMLスキーマ、FlexiondocおよびSearchMLがContent Categorizerルールで容易に検索できない形式であるためです。
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属性が定義されます。
