| Oracle® Fusion Middleware Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-01 |
|
 前 |
 次 |
ホーム > アプリケーション管理者ガイド > Content Categorizerの管理
| Oracle® Fusion Middleware Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-01 |
|
前 |
次 |
ホーム > アプリケーション管理者ガイド > Content Categorizerの管理
この項の内容は次のとおりです。
Content Categorizer (CC)はオプションのコンポーネントで、コンテンツ・サーバーとともに自動的にインストールされます。有効にすると、Content Categorizer では、コンテンツ・サーバーにチェックインする新しいドキュメントのメタデータ値と、コンテンツ・サーバーにメタデータ値がすでに存在するかどうかに関係なく、既存のドキュメントのメタデータ値が推奨されます。これらのメタデータ値は、システム管理者が指定した検索ルールに従って決定されます。
このコンポーネントとともに含まれるバッチ・ユーティリティでは、大量のファイルを検索したり、適切なメタデータ・フィールド値を含むバッチ・ローダー制御ファイルを作成できます。バッチ・ユーティリティは、既存のコンテンツ(すでにコンテンツ・サーバー・リポジトリにチェックイン済)を再分類するために使用できます。
Content Categorizerでは、コンテンツ・サーバーにチェックインする新しいドキュメントのメタデータ値と、コンテンツ・サーバーにメタデータ値がすでに存在するかどうかに関係なく、既存のドキュメントのメタデータ値が推奨されます。これらのメタデータ値は、システム管理者が指定した検索ルールに従って決定されます。
この項の内容は次のとおりです。
Content Categorizerでは、定義されているルールのタイプに基づいて検索ルールを実行します。
パターン照合ルールと抽象ルール: Content Categorizerは、コンテンツ・ドキュメントの「ランドマーク」を検索します。ランドマークは、特定のテキストにすることも、ソース・ドキュメントの構造プロパティ(スタイル、フォント、フォーマットなど)に基づいて使用することもできます。
オプション・リスト・ルール: Content Categorizerはキーワードを検索し、そのキーワードの累積スコアによって、オプション・リストの中のどのオプションを選択するかを決定します。ランドマークまたは特定のXMLタグは検索しません。
カテゴリ化エンジン・ルール: Content Categorizerはサードパーティのカテゴライザ・エンジンと分類を起動し、コンテンツ・アイテムを分類します。
Filetypeルール: Content Categorizerはドキュメント・ファイル・タイプ(ファイル名拡張子)を検索します。
検索ルールのオーバーライド
通常、「コンテンツ・チェックイン・フォーム」にユーザーが値を入力すると、そのフィールドに対するContent Categorizerによる検索ルールの適用が防止されます。これは、「タイプ」フィールドなど、デフォルト値があるオプション・リスト・フィールドの場合も同様です。
|
重要: コントリビュータには、検索ルールによって入力するフィールドは空白のままにするように指示することが重要です。 |
現在のバージョンのコンテンツ・サーバーは、デフォルト値として空の値をカスタムのオプション・リスト・フィールドに自動的に挿入します。この場合、最初の値(デフォルトでは空の値)はユーザーによる入力値とみなさないため、オプション・リスト検索ルールが適用されます。オプション・リスト検索ルールでカスタムのオプション・リスト・フィールドの最初の値をオーバーライドしない場合は、構成マネージャ・アプレットでそのオプション・リストのデフォルト値を指定する必要があります。
Content Categorizerがデフォルト値を無視して検索ルールを「タイプ」フィールドに適用するように、コンテンツ・サーバー構成ファイルを編集できます。「「タイプ」フィールドへのルールの適用」を参照してください。
Content Categorizerで構造プロパティを認識するためには、コンテンツをXML (eXtensible Markup Language)に変換する必要があります。変換メソッドは、ユーザー定義のランタイム構成設定です。変数名はsccXMLConversionで、可能な値には「Flexiondoc」、「SearchML」および「なし」があります。「なし」の値は、既存のXMLのファイルで使用されます。
Content CategorizerとともにインストールされたCC_Sampleディレクトリには、Wellington_WordStyle.docという名前のサンプル・ソース・ファイルが含まれており、このファイルではドキュメント・プロパティとスタイルが豊富に使用されています。このディレクトリには、ソース・ドキュメントを使用可能な各XML Converterで変換して生成したXMLを示すサンプルのXMLファイル(Wellington_WordStyle_flexion.xmlとWellington_WordStyle_searchml.xml)も含まれています。
|
重要: 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に変換します。第2段階では、スタイルシートを使用してXMLをさらに調整し、Content CategorizerでXMLを検索できるようにします。XML要素ではネイティブ・ドキュメントのプロパティとテキスト・セグメントが分離され、対応するドキュメント・プロパティ、段落スタイルまたは文字スタイルに基づいて名前が付けられます。
OutsideInテクノロジは、カスタムXSLTスタイルシート(searchml_to_scc.xsl)と組み合せて使用し、2段階の処理でXMLを生成します。第1段階では、ネイティブ・ドキュメントをSearchML形式のXMLに変換します。第2段階では、スタイルシートを使用してXMLをさらに調整し、Content CategorizerでXMLを検索できるようにします。XML要素ではネイティブ・ドキュメントのプロパティとテキスト・セグメントが分離され、対応するドキュメント・プロパティまたは段落スタイルに基づいて名前が付けられます。SearchMLでは、文字スタイルはサポートされません。
Content Categorizerを実行するには、次の設定が必要です。
Content Categorizerで次のいずれかのXML変換メソッドを定義します。
sccXMLConversion=Flexiondoc
sccXMLConversion=SearchML
「XML変換メソッドの設定」を参照してください。
Content Categorizer管理アプレットで検索ルールを定義します。「検索ルールの定義」を参照してください。
オプション: Content Categorizer管理アプレットで、各メタデータ・フィールドのデフォルト値など、フィールドのプロパティを定義します。詳細は、「フィールドのプロパティの定義(オプション)」を参照してください。
|
重要: CATEGORY検索ルールを使用するには、メタデータ・フィールドに対してCATEGORYルールを定義する前に、カテゴライザ・エンジンをインストール、設定および登録する必要があります。 |
Content Categorizerは、対話型モードまたはバッチ・モードで操作できます。すべてのモードでソース・ドキュメントをXML中間フォームに変換する必要があります。ただし、各モードのプロセス・フローは大きく異なります。
対話型モードでは、Content Categorizerは、コンテンツ・サーバーの「コンテンツ・チェックイン・フォーム」および「情報更新フォーム」と統合されます。ユーザーは、フォーム上の「分類」ボタンをクリックし、単一のコンテンツ・アイテムに対してContent Categorizerを実行します。Content Categorizerによって返される値は推奨値であるため、コントリビュータは返される値を編集したり、置換できます。
バッチ・モードは、コンテンツ・サーバー・リポジトリにすでに存在する大量のドキュメントを再分類する場合に使用します。システム管理者は、スタンドアロンのバッチ・カテゴライザ・ユーティリティを使用してContent Categorizerを実行し、コンテンツ・メタデータのライブ・アップデートを実行するか、バッチ・カテゴライザからの出力ファイルをバッチ・ローダーへの入力として使用します。
この項の内容は次のとおりです。
コントリビュータが「コンテンツ・チェックイン・フォーム」または「情報更新フォーム」を表示し、プライマリ・ファイル(「コンテンツ・チェックイン・フォーム」のみ)を選択して「分類」ボタンをクリックします。
「コンテンツ・チェックイン・フォーム」によって、そのプライマリ・ファイルがコンテンツ・サーバーのホストにコピーされ、Content Categorizerサービスがコールされます。
Content Categorizerはソース・コンテンツを検索します。
コンテンツがXML形式ですでに存在する場合、変換は発生せず、プロセスはステップ6に進みます。
コンテンツがXML形式で存在しない場合は、特定の変換メソッドを使用して変換されます。
コンテンツは、Flexiondoc形式のXMLに変換されます。
XMLは、flexiondoc_to_scc.xslを使用して、Content Categorizerで使用できるXMLに変換されます。
コンテンツは、SearchML形式のXMLに変換されます。
XMLは、searchml_to_scc.xslを使用して、Content Categorizerで使用できるXMLに変換されます。
Content Categorizerは検索ルールをXMLに適用し、特定のメタデータ・フィールドの推奨値を取得します。
Content Categorizerは、推奨メタデータ値を「コンテンツ・チェックイン・フォーム」または情報更新フォームに挿入し、そのフォームをコントリビュータに返します。
コントリビュータは、推奨値が入力されたドキュメントのチェックインや送信、メタデータ値の変更、またはチェックインや更新の取消しを実行できます。
オプションのAddCCToNewCheckinコンポーネントがインストールされていて有効な場合は、「コンテンツ・チェックイン・フォーム」の「チェックイン」をクリックすると、前述のステップ2から6が実行されてチェックイン・プロセスが自動的に完了します(dDocTitleのプロパティが「コンテンツのオーバーライド」に設定されている場合)。dDocTitleのプロパティが「コンテンツのオーバーライド」に設定されていない場合は、必須フィールドを入力するように要求するアラートが表示されます。フィールドのプロパティは、CC管理アプレットを使用して設定します。詳細は、「フィールドのプロパティの定義(オプション)」を参照してください。
バッチ・カテゴライザ・アプリケーションを実行します。このアプリケーションは、Windowsでも起動でき、「スタート」→「プログラム」→「コンテンツ・サーバー」→「<instance_name」→「バッチ・カテゴライザ」の順にクリックします。UNIXシステムでのアプリケーションの実行の詳細は、『Oracle Fusion Middleware Content Serverシステム管理者ガイド』を参照してください。
「バッチ・カテゴライザ」画面が表示されます。
「バッチ・カテゴライザ」画面で、フィルタとリリース日の情報を定義し、分類するコンテンツのリストを表示します。「バッチ・カテゴライザ」画面のオプション(後続の手順で説明)を使用すると、分類する正確なコンテンツをさらに定義できます。
「分類」をクリックします。
「既存の分類」画面が表示されます。
「ライブ・アップデート」または「バッチ・ローダー」を選択します。
「ライブ・アップデート」オプションは、リポジトリのデータを即座にアップデートする場合に使用します。
「バッチ・ローダー」オプションは、Content Categorizerプロセスの出力である制御ファイルを作成する場合に使用します。ファイルには、各ソース・ドキュメントのエントリと、Content Categorizerで定義した検索ルールに基づいた各メタデータ・フィールドの値が含まれます。
|
ヒント: このファイルは、編集/フィルタリングしてからバッチ・ローダーに送信することも、バッチ・ローダーに直接送信することもできます(次の手順を参照)。 |
Content Categorizerプロセスの完了後にバッチ・ローダー・ユーティリティを自動的に実行するには、「バッチ・ローダーの実行」チェック・ボックスを選択します。
ログ・ファイルの場所とファイル名を入力します。ログ・ファイルには、Content Categorizerプロセスに関するエラー情報が格納されます。
「すべての分類」または「選択済の分類」を選択します。
「すべての分類」オプションは、コンテンツ・リストに表示されているすべてのコンテンツ・アイテムを分類する場合に使用します。
「選択済の分類」オプションは、表示されているコンテンツ・リストで選択した(ハイライトした)コンテンツ・アイテムのみを分類する場合に使用します。
「最新のリビジョン」または「全リビジョン」の分類を選択します。
「最新のリビジョン」オプションは、コンテンツ・リストに表示されている最新のリビジョンのコンテンツ・アイテムのみを分類する場合に使用します。
「全リビジョン」オプションは、コンテンツ・リストに表示されているコンテンツ・アイテムのすべてのリビジョンを分類する場合に使用します。
バッチ・カテゴライザにエラーが発生したときに、カテゴリ化プロセスを続行するか中止するかを選択します。
「OK」をクリックします。進行状況バーには、バッチ・プロセスのステップ間移動の進行状況が表示されます。
Content Categorizerはソース・コンテンツを検索します。
コンテンツがXML形式ですでに存在する場合、変換は発生せず、プロセスはステップdに進みます。
コンテンツがXML形式で存在しない場合は、XML変換メソッドとして選択したFlexiondocまたはSearchMLを使用してXMLへの変換が実行されます。
Content Categorizerは検索ルールをXMLに適用し、特定のメタデータ・フィールドの値を取得します。
「ライブ・アップデート」が指定されている場合は、データベース・レコードが即座に更新されます。「バッチ・ローダー」が指定されている場合は、出力制御ファイルが作成され、バッチ・ローダー・ユーティリティが実行されます(処理後に実行するようにオプションが指定されている場合)。
バッチ・プロセスの完了後、エラー・ログを確認します。バッチ・カテゴライザで発生したエラーはコンソールに表示され、バッチ・カテゴライザのログにも記録されます(指定した場合)。バッチ・ローダーで発生したエラーはコンソールに表示され、コンテンツ・サーバーのシステム・ログにも記録されます。
オプションのAddCCToArchiveCheckinコンポーネントがインストールされていて有効な場合、バッチ・ローダー・ユーティリティを使用してコンテンツ・サーバーにロードしたすべてのコンテンツは、事前定義されたルール・セットに基づいて自動的に分類されます。ルール・セットの定義の詳細は、次を参照してください。
Content Categorizerを使用するには、その前に、必要なソフトウェアをインストールして構成する必要があります。
この項の内容は次のとおりです。
対話型モードまたはバッチ・モードで操作する場合、Content Categorizerを使用してネイティブ・ドキュメントをXMLに変換するメソッドは、ランタイム構成パラメータとして設定します。
Content CategorizerでXML変換メソッドを設定する手順は、次のとおりです。
コンテンツ・サーバーにシステム管理者としてログインします。
「管理」リンクをクリックします。
「Content Categorizerの管理」リンク(instance_nameの管理者ページの下)をクリックします。
Content Categorizer管理アプレット・ページが表示されます。
「構成」タブで、「sccXMLConversion」プロパティを選択し、「編集」をクリックするか、プロパティをダブルクリックします。
「プロパティの構成」画面が表示されます。
ドロップダウン・リストから、必要なXML変換メソッドを選択します。
「OK」をクリックします。
「適用」をクリックして変更内容を保存するか、「OK」をクリックして変更内容を保存し、CC管理アプレット→フィールドのプロパティの定義の順に閉じます。
フィールドに対するルールが成功すると、(「バッチ・ローダー」操作または「ライブ・アップデート」操作で)検出された値が使用されます。ただし、「オーバーライド」値の設定方法によっては、検出された値は既存の値をオーバーライドしません(「オーバーライド」を無効に設定した場合)。
フィールドに対するすべてのルールが失敗すると、値はフィールドに割り当てられません。これは、フィールドのデフォルト値が定義されている場合、または「デフォルトの使用」が有効に設定されている場合を除き、適用されます。
|
重要: コンテンツ・サーバーのバッチ・ローダー・ユーティリティは、必須フィールドに値がない場合、挿入アクションに失敗します。 |
システムでメタデータ・フィールドのフィールド・プロパティを定義する手順は、次のとおりです。
Content Categorizer管理アプレットを開きます。
「フィールドのプロパティ」タブをクリックします。
編集するメタデータ・フィールドを選択し、「編集」をクリックするか、フィールドをダブルクリックします。
「フィールドのプロパティ」画面が表示されます。
フィールドのデフォルト値を入力します。
オプション・リスト・フィールドのデフォルト値は、そのフィールドで使用可能な値のいずれかと一致する必要があります。
カテゴリ化プロセスから返された値でフィールドの既存の値をオーバーライドする場合は、「オーバーライド」チェック・ボックスを選択します。
カテゴリ化プロセスの実行時にすべてのルールが失敗した(または定義されていない)場合に、フィールドのデフォルト値を使用する場合は、「デフォルトの使用」チェック・ボックスを選択します。
「OK」をクリックします。
編集するフィールドごとに手順3から7を繰り返します。
「設定の保存」をクリックして変更内容を保存します。
MaxQueryRows変数は、コンテンツ・サーバーの構成変数で、バッチ・ロード・プロセスに含めることができる最大ドキュメント数を指定する場合に使用します。このため、ユーザーがBatchCategorizerに表示するドキュメント数に影響を与えます。
この構成変数のデフォルト設定は200ですが、必要に応じて増減できます。値を増加すると、大規模リストのドキュメントをロードするためにレスポンス時間が遅くなります。MaxQueryRowsを1000から2000の範囲で設定した場合の影響は大きくありませんが、100,000の領域に設定すると、パフォーマンス・レベルが許容されない可能性があります。
この変数の形式は次のとおりです。
MaxQueryRows=2000
この項の内容は次のとおりです。
検索ルールは、Content Categorizerがメタデータ値を決定し、「コンテンツ・チェックイン・フォーム」、「情報更新フォーム」(対話型モードの場合)またはバッチ・ファイル(バッチ・モードの場合)に返す方法を定義します。
すべての検索ルールは次の内容によって定義されます。
ルール・タイプは、Content CategorizerがXMLドキュメントを検索するために使用するメソッドを決定します。
キーは、Content Categorizerがドキュメントで検索するXML要素、句、キーワードを定義したり、Content Categorizerがドキュメントを分類するために使用するカテゴリ化エンジン/分類を定義します。
件数は、検索条件を絞り込むために使用します。
キーと件数の詳細は、各検索ルール・タイプのヘルプ・トピックを参照してください。
この項の内容は次のとおりです。
メタデータ値は、次のメソッドを使用して導出できます。
パターン照合検索ルールは、特定のテキストまたは特定のXML要素を検索し、関連する値を返します。
抽象検索ルールは、XML要素を検索し、その要素から説明文または段落を返します。
オプション・リスト検索ルールは、ソース・ドキュメント内のキーワードを検索し、検出した各キーワードにスコアを適用して、最も高いキーワード・スコアのオプション・リスト値を返します。
カテゴリ化エンジン検索ルールは、サードパーティのカテゴリ化エンジンと定義済の分類を使用して適切なメタデータ値を決定します。
Filetype検索ルールは、プライマリ・ファイルのファイル名拡張子を調査し、そのファイル名拡張子に関連付けられている用語を返します。
検索ルールは、カスタム・メタデータ・フィールドに適用できます。
検索ルールは、標準メタデータ・フィールドの「タイトル」、「コメント」および「タイプ」に適用できます。他の標準のメタデータ・フィールド(「作成者」、「セキュリティ・グループ」、「アカウント」など)に対しては、検索ルールを定義できません。
1つのメタデータ・フィールドに対して複数の検索ルールを定義できます。(ただし、単一のメタデータ・フィールドに対して、異なる分類を参照する複数のCATEGORYルールはサポートされていません。)
検索ルールで推奨値が検出されなかった場合は次のルールが実行されるように、検索ルールが複数ある場合は指定した順序で実行されます。詳細指定から曖昧指定の順序でリストを配置する必要があります。
複数の検索ルール・タイプを1つのメタデータ・フィールド内に混在できます。たとえば、同じメタデータ・フィールドに対してオプション・リスト・ルール、パターン照合ルールおよび抽象ルールを定義できます。
指定した検索ルールを満たさないメタデータ・フィールドは、空白のままになります。
パターン照合検索ルールは、特定のテキストまたは特定のXML要素を検索し、関連する値を返します。たとえば、「インボイス#」メタデータ・フィールドには、ソース・ドキュメントの「インボイス:」ラベルまたは「インボイス番号:」ラベルの後の値を入力したり、XMLドキュメントの<Invoice>タグ内の値を入力できます。
この項の内容は次のとおりです。
パターン照合ルールには、タグ検索とテキスト検索の2つの一般的なタイプがあります。
タグ検索は、キーと正確に一致するXML要素を検索します。そのような要素が検出されると、要素に含まれるテキストが結果として返されます。
テキスト検索は、キーと一致するテキストを検索します。そのようなテキストが検出されると、キーの近く、またはキーの次のテキストが結果として返されます。
タグ検索では、大/小文字が区別されます。テキスト検索では、大/小文字は区別されません。
サブタイプ
パターン照合検索ルールの2つの一般的なタイプには、それぞれ複数のサブタイプがあります。次の「例」の項では、これらのサブタイプについて説明します。
タグ検索
TAG_TEXT
TAG_ALLTEXT
テキスト検索
TEXT_REMAINDER
TEXT_ALLREMAINDER
TEXT_FULL
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つの要素からそれぞれ最初の文が返されます。
次の例は、抽象検索ルールの使用を示しています。
この例では、<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.
この例では、最初の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.
OPTION_LISTという名前のオプション・リスト検索ルールは、ソース・ドキュメント内のキーワードを検索し、検出した各キーワードにスコアを適用して、最もキーワード・スコアが高いオプション・リスト値を返します。たとえば、ドキュメントに利益、有価証券報告書または請求書というキーワードが検出された場合、「部門」フィールドの推奨値は会計ですが、キーワードがトレランス、組立品または在庫の場合は、推奨値として製造を返します。
オプション・リスト検索ルールは通常、構成マネージャでオプション・リストが定義されているメタデータ・フィールドに適用されます。カスタム・メタデータ・フィールドのオプション・リスト作成の詳細は、コンテンツ・サーバーのオンライン・ヘルプを参照してください。
(Content Categorizerで「カテゴリ」と呼ばれる)オプション・リストの名前と値は、構成マネージャで指定したとおりにContent Categorizerに表示されます。CC管理アプレットが開いている状態でカスタムのオプション・リスト・フィールドを作成または変更した場合は、変更内容を確認するためにアプレットを閉じて再度開く必要があります。
現在のバージョンのコンテンツ・サーバーは、デフォルト値として空の値をカスタムのオプション・リスト・フィールドに自動的に挿入します。この場合、最初の値(デフォルトでは空の値)はユーザーによる入力値とみなさないため、オプション・リスト検索ルールが適用されます。オプション・リスト検索ルールでカスタムのオプション・リスト・フィールドの最初の値をオーバーライドしない場合は、構成マネージャ・アプレットでそのオプション・リストのデフォルト値を指定する必要があります。
この項の内容は次のとおりです。
オプション・リスト検索ルールのタイプは1つで、キーで定義したキーワードと正確に一致するキーワード(1つの単語または句)を検索します。
キーワードには、1つの単語(dogなど)または語句(black dogなど)を使用できます。
キーワードは、次の定義済の一連の演算子を使用して、検索をさらに絞り込むことができます。
$$AND$$
$$OR$$
$$AND_NOT$$
$$NEAR$$
キーワードはオプション・リストの各カテゴリ(値)に事前に割り当てられていて、各キーワードには重みが割り当てられています。「オプション・リストのキーワードの定義」を参照してください。
ドキュメントで検出された各キーワードの出現回数に重みが乗算され、キーワード・スコアが生成されます。
カテゴリごとのキーワード・スコアがまとめて加算され、カテゴリ・スコアが生成されます。
スコアの最も高いカテゴリが、推奨値として返されます。
カテゴリが同点の場合は、オプション・リストで最初に出現するカテゴリが推奨値として返されます。
重みの「常に」と「なし」を使用すると、スコアと件数しきい値をオーバーライドできます。
重みの「常に」が指定されたキーワードが出現した場合は、スコアに関係なく、そのカテゴリが推奨値として返されます。
重みの「なし」が指定されたキーワードが出現した場合、スコアに関係なく、そのカテゴリは推奨値として返されません。
2つのカテゴリに重みの「常に」が割り当てられているキーワードがあり、両方のキーワードがドキュメントに出現した場合は、ドキュメントで検出された最初のキーワードが優先されます。
|
重要: オプション・リスト検索では、大/小文字が区別されるため、正確に一致する必要があります。たとえば、「Invoice」というキーワードのすべてのインスタンスを取得する場合は、Invoice、Invoices、invoiceおよびinvoicesを定義する必要があります。 |
オプション・リスト検索ルールのキーは、CC管理アプレットの「オプション・リスト」タブに表示されるオプション・リストの名前です。
オプション・リスト検索ルールの件数では、ルールが結果を返す最小しきい値スコアを設定します。たとえば、件数を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
キー: xMainCharacter
件数: 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
CATEGORYという名前のカテゴリ化エンジン検索ルールでは、サードパーティのカテゴライザ・エンジンと定義済の分類を使用して、特定の分類内のカテゴリ(News/Technology/Computersなど)を表す値を決定して返します。
この項の内容は次のとおりです。
カテゴリ化エンジン検索ルールのタイプは1つで、カテゴライザ・エンジンおよびキーで指定した分類を使用してフィールドの値を返します。
カテゴリ化エンジン検索ルールのキーは、カテゴライザ・エンジンの名前の後に分類の名前を付けたものです。たとえば、EngineName/TaxonomyNameです。
「キー」フィールドにエンジン名を指定しない場合、Content Categorizerでは、カテゴライザ・エンジン・リストに表示される最初のエンジンにデフォルト設定されます。したがって、唯一のエンジンを定義した場合は、「キー」フィールドに分類名のみを入力する必要があります。
カテゴリ化エンジン検索ルールの件数では、返される結果に関する最小信頼度しきい値を設定します。
カテゴリ化エンジンによって、特定の問合せに対する1つのカテゴリ(または一連のカテゴリ)が返されるときに、各カテゴリをパーセントで表す信頼度も返されます。CATEGORYルールでは、最大信頼度カテゴリが常に受け入れられますが、その信頼度がルールに指定した件数の値を下回る場合は、ルールが失敗します。たとえば、件数を50に設定した場合に、返された最大信頼度カテゴリが45であると、ルールは失敗します。
デフォルトの件数の1を使用すると、カテゴライザ・エンジンが返す最大信頼度カテゴリが常に受け入れられます。
「件数」値の実際の範囲は、使用するカテゴライザ・エンジンによって異なります。
FILETYPEという名前のFiletype検索ルールは、ドキュメントのファイル名拡張子を調査し、用語(通常はファイル名拡張子に関連付けられているファイル・タイプの説明)を返します。
この項の内容は次のとおりです。
Filetype検索ルールのタイプは1つで、プライマリ(ネイティブ)・ファイルのファイル名拡張子を使用してフィールドの値を返します。
メタデータ・フィールドに対してFiletype検索ルールを定義すると、そのコンテンツ・アイテムのファイル名拡張子がコンテンツ・サーバーのDocFormatsWizard表のすべての値と照合されます。この表は、IntradocDir/shared/config/resources/ディレクトリのdoc_config.htmファイルにあります。
一致が検出されると、「説明」列の関連値が抽出されて変換されます。結果の文字列は、そのフィールドの推奨メタデータ値として返されます。
プライマリ・ファイルのパスに拡張子がない場合、または拡張子がDocFormatsWizard表の拡張子の値と一致しない場合、ルールは失敗し、そのメタデータ・フィールド用のリストの次のルールが実行されます。
FILETYPE検索ルールのキーは、メタデータ値の決定時に使用されません。「キー」フィールドは、空白のままにします。
FILETYPE検索ルールの件数は、メタデータ値の決定時に使用されません。「件数」フィールドは、空白のままにします。
「キー」フィールドまたは「件数」フィールドが空白でない状態でFILETYPEルールを作成すると、これらのフィールドがルールでサポートされないことを示す警告メッセージが表示されます。
コンテンツ・サーバーの起動時に、Content Categorizerは、ファイルの名前と長さを含む、現在のメタデータ・フィールド構成のスナップショットを作成します。メタデータ・フィールドの構成を変更した場合は、コンテンツ・サーバーを再起動してからContent Categorizer管理アプレットを実行し、検索ルールを追加または変更する必要があります。
メタデータ・フィールドの検索ルールを定義する手順は、次のとおりです。
コンテンツ・サーバーにシステム管理者としてログインします。
「管理」リンクをクリックします。
「Content Categorizerの管理」リンク(instance_nameの管理者ページの下)をクリックします。
Content Categorizer管理アプレット・ページが表示されます。
「ルール・セット」タブをクリックします。
「ルールセット」ドロップダウン・リストをクリックして必要なルールセットを選択するか、「追加」をクリックして新しいルールセットを追加します。
「フィールド」選択リストからメタデータ・フィールドを選択します。
「追加」をクリックします。
「フィールドのルールの追加」/「フィールドのルールの編集」画面が表示されます。
「ルール」選択リストからルール・タイプを選択します。
「キー」フィールドに検索ルール・キーを入力します。OPTION_LIST検索ルールの場合は、オプション・リストのキーワードを「オプション・リスト」タブで定義する必要があります。「オプション・リストのキーワードの定義」を参照してください。
「件数」フィールドに件数を入力します。
「OK」をクリックします。
必要に応じて、各メタデータ・フィールドに検索ルールを追加します。
ルールを削除するには、「ルール・リスト」でルールを選択し、「削除」をクリックします。
ルールを編集するには、「ルール・リスト」でルールを選択し、「編集」をクリックします。
ルールの順序を調整するには、「ルール・リスト」でルールを選択し、「上に移動」または「下に移動」をクリックします。ルールはリストされている順序で適用されます。最初のルールが成功すると、他のルールは適用されません。最初のルールが失敗すると、次のルールが適用され、以下同様に続きます。
|
重要: CATEGORYルールを追加、編集または削除した場合は、変更内容を適用して、このルールを作成、再作成、または「問合せツリー」タブでこのルールに対する孤立した問合せツリーがないかを確認するように求めるダイアログが表示されます。 |
「適用」をクリックして変更内容を保存するか、「OK」をクリックして変更内容を保存し、CC管理アプレット画面を閉じます。
オプション・リストのキーワードと重みを定義する手順は、次のとおりです。
コンテンツ・サーバーにシステム管理者としてログインします。
「管理」リンクをクリックします。
「Content Categorizerの管理」リンク(instance_nameの管理者ページの下)をクリックします。
Content Categorizer管理アプレット・ページが表示されます。
「オプション・リスト」タブをクリックします。
「オプション・リスト」選択リストからオプション・リストを選択します。
|
注意: オプション・リスト・メタデータ・フィールドを構成マネージャから削除すると、そのフィールドは「ルール・セット」タブから削除されますが、「オプション・リスト」タブの「オプション・リスト」選択リストには引き続き表示されます。廃止したオプション・リストを選択しないように注意してください。 |
「カテゴリ」選択リストから値を選択します。
「キーワード」フィールドにキーワードまたは語句を入力します。オプション・リスト検索では、大/小文字が区別されるため、正確に一致する必要があります。
キーワードには、1つの単語または語句を使用できます。
キーワードには、ブール型の式を含めることができ、有効な一連のバイナリ演算子は$$AND$$、$$OR$$、$$AND_NOT$$、$$NEAR$$です。
キーワードの重みを選択します。
常に: キーワードが見つかった場合、スコアに関係なく、選択したカテゴリが推奨値として返されます。
重み: この数値をキーワードの出現回数に掛けた値が、カテゴリのスコアとなります。スコアの最も高いカテゴリが、オプション・リスト・フィールドの推奨値として返されます。
なし: キーワードが見つかった場合、スコアに関係なく、選択したカテゴリが推奨値として返されません。
「追加」をクリックします。
選択したオプション・リストの各カテゴリにキーワードを入力します。
キーワードを削除するには、「キーワード」リストでキーワードを選択し、「削除」をクリックします。
キーワードを編集するには、「キーワード」リストでキーワードを選択して「編集」をクリックし、キーワードまたは重み(あるいはその両方)を編集して「更新」をクリックします。
「適用」をクリックして変更内容を保存するか、「OK」をクリックして変更内容を保存し、CC管理アプレット画面を閉じます。
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で大量の異なるソース・ドキュメント形式をサポートできます。
変換ステップでは、XSLT (eXtensible Stylesheet Language Transformations)を使用して、最初のXML出力を、ユーザーが定義した検索ルールに基づいてContent Categorizerで容易に検索および分析できるXMLに変換します。
変換プロセスの概要は、カテゴリ化プロセスに興味があるユーザーにとって有用であり、独自のXSLTスタイルシートを定義して特定のドキュメント処理ニーズに対応する必要のあるユーザーの開始点としても役立ちます。
OutsideIn XML Exportフィルタを使用した変換
OutsideIn XML Export製品のランタイム・バージョンはコンテンツ・サーバーと統合してインストールされ、チェックインされたコンテンツを分類のためにフィルタ処理します。このExportフィルタは、CategorizerのXSLTスタイルシートを使用した変換のために、コンテンツをXMLに変換します。この変換が必要なのは、Export XMLスキーマ、FlexiondocおよびSearchMLがContent Categorizerルールで容易に検索できない形式であるためです。
Content Categorizerには2つのスタイルシートが付属しており、OutsideIn XML Exportフィルタが提供する最初の変換形式に基づいて適用されます。スタイルシートは、次のディレクトリにあります。
/<cs_root>/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属性で区別します。
ドキュメント・プロパティとテキスト・スタイルの例
たとえば、IntradocDir/custom/ContentCategorizer/CC_Sample/ディレクトリにあるWellington_WordStyle.docの例を使用すると、ファイルの作成者プロパティの「Duke of Wellington」は、SearchML XML出力で次のようにタグ付けされます。
<doc_property type="author">Duke of Wellington</doc_property>
日付を示すアイテムの最初の段落は、次のようにタグ付けされます。
<p>Date: August 24, 1812</p>
スタイル属性が定義されていないことに注意してください。
変換されたXMLファイルへのsearchml_to_scc.xslスタイルシートの適用によって、XMLのすべての<doc_property>タグが検索され、接尾辞としてtype属性が使用されるため、変換された出力タグがContent Categorizerルールでキーとして使用されます。
たとえば、searchml_to_scc.xslスタイルシートで次のコードがタグ付けされるとします。
<doc_property type="author">Duke of Wellington</doc_property>
出力は次のとおりです。
<scc_author>Duke of Wellington</scc_author>:
<xsl:template match="sml:doc_property[@type]">
<xsl:variable name="typeValue">
xsl:value-of select="@type"/>
</xsl:variable>
<xsl:element name="scc_{translate($typeValue, $translateFrom, $translateTo)}">
<xsl:value-of select="."/>
</xsl:element>
</xsl:template>
同様に、searchml_to_scc.xslスタイルシートによって、XMLファイルのすべての<p>タグが検索され、接尾辞としてs属性が使用されるため、変換された出力タグがContent Categorizerルールでキーとして使用されます。スタイル属性が定義されていない場合、変換で<p>タグは無視されます。
OutsideIn XML Exportフィルタは、コンテンツをFlexiondoc XML形式に変換するときに、タイトル、件名、作成者など、コンテンツ・アイテムのプロパティを識別し、それらをSearchMLと同様に<doc_property>要素としてタグ付けします。ただし、各プロパティはtype属性ではなく、name属性で区別します。
この項の内容は次のとおりです。
たとえば、IntradocDir/custom/ContentCategorizer/CC_Sample/ディレクトリにあるWellington_WordStyle.docの例を使用すると、ファイルの作成者プロパティの「Duke of Wellington」は、Flexiondoc XML出力で次のようにタグ付けされます。
<doc_property name="author">Duke of Wellington</doc_property>
変換されたXMLファイルへのflexiondoc_to_scc.xslスタイルシートの適用によって、XMLのすべての<doc_property>タグが検索され、接尾辞としてname属性が使用されるため、変換された出力タグがContent Categorizerルールでキーとして使用されます。
たとえば、flexiondoc_to_scc.xslスタイルシートで次のコードがタグ付けされるとします。
<doc_property name="author">Duke of Wellington</doc_property>
出力は次のとおりです。
<scc_author>Duke of Wellington</scc_author>:
<xsl:template match="fld:doc_property">
<xsl:variable name="propName">
<xsl:choose>
<xsl:when test="@name">
<xsl:value-of select="@name" />
</xsl:when>
<xsl:when test="@user_defined_name">
<xsl:value-of select="@user_defined_name" />
</xsl:when>
<xsl:otherwise>NAMELESS_DOC_PROPERTY_WITH_ID_<xsl:value-of select="@id" /></xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:element name="scc_{translate($propName, $translateFrom, $translateTo)}">
<xsl:value-of select="." />
</xsl:element>
</xsl:template>
FlexiondocがSearchMLと異なる点は、スタイルの識別方法です。段落スタイルは<tx.p>タグでタグ付けされ、文字スタイルは<tx.r>タグでタグ付けされますが、それぞれは、name属性に加えて、一意のスタイルのidに基づいて属性が指定されています。
すべてのスタイルは、Flexiondoc XMLファイルの<style_tables>要素の子要素で定義され、id属性が指定されていますが、この属性はスタイルを参照するときにコールされ、テンプレート・ファイルを使用してスタイル・キーとname属性が定義されます。
たとえば、Wellington_WordStyle.docのFlexiondoc XML出力の例では、文字スタイルが親要素の<style_tables>の子の<tx.char_style_table>で定義されています。id属性に注意してください。
<tx.char_style_table>
<tx.char_style id="ID16d" auto_kern_above="0.1111in" auto_kerning="false" back_brush="ID168" font="ID16f" kerning="0in" text_brush="ID16e" text_effect="normal" text_hidden="false" text_position="normal" text_protected="false" text_strikethrough="none" underline="ID170"/>
<tx.char_style id="ID178" back_brush="ID176" font="ID177" text_brush="ID176"/><tx.char_style id="ID187" font="ID186"/><tx.char_style id="ID1d6" font="ID1d5"/>
<tx.char_style id="ID1e5" font="ID1e4"/>
<tx.char_style id="ID1e8" name="Default Paragraph Font" predefined="default"/>
<tx.char_style id="ID1ec" font="ID1eb"/>
</tx.char_style_table>
flexiondoc_to_scc.xslスタイルシートが適用されると、出力のXMLファイルのすべての<tx.char_style>文字スタイルが検索されます。スタイルのid属性を使用し、各<tx.char_style>タグのidに基づいて一意の<xsl:key>要素とname属性が定義されます。
<xsl:key name="charStyleKey" match="fld:tx.char_style" use="@id" />
<xsl:template match="fld:tx.r[@style]">
<xsl:variable name="charStyleName">
<xsl:value-of select="key('charStyleKey', @style)/@name" />
</xsl:variable>
<xsl:choose>
<xsl:when test="string-length($charStyleName) > 0">
<xsl:element name="scc_{translate($charStyleName, $translateFrom, $translateTo)}">
<xsl:apply-templates />
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="." />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
同様に、スタイルシートが適用されると、出力のXMLファイルのすべての<tx.para_style>段落スタイルが検索されます。スタイルのid属性を使用し、各<tx.para_style>タグのidに基づいて一意の<xsl:key>要素とname属性が定義されます。
<xsl:key name="paraStyleKey" match="fld:tx.para_style" use="@id" />
<xsl:template match="fld:tx.p[@style]">
<xsl:variable name="styleValue">
<xsl:value-of select="@style" />
</xsl:variable>
<xsl:variable name="paraStyleName">
<xsl:value-of select="key('paraStyleKey', $styleValue)/@name" />
</xsl:variable>
<xsl:choose>
<xsl:when test="string-length($paraStyleName) > 0">
<xsl:element name="scc_{translate($paraStyleName, $translateFrom, $translateTo)}">
<xsl:apply-templates />
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:element name="p" >
<xsl:value-of select="." />
</xsl:element>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
例の詳細は、次の場所にあるサンプル・ファイルを参照してください。
IntradocDir/data/components/ContentCategorizer/CC_Sample
XSLTスタイルシートの詳細は、次の場所を参照してください。
IntradocDir/data/components/ContentCategorizer/stylesheets
前述のディレクトリにあるスタイルシートは、Content Categorizerで使用されます。検討する場合は、コピーを作成してください。
