We’ve migrated our documentation to a new site, which means some URLs have changed.
Audience

Excelワークブックによる辞書作成

はじめに

辞書はシーセンスのプラットフォームで様々なカスタマイズを実装するために使用されます。例えば効率よく文字列を検索をする場合や他の文字列とのマッピングといったもので使用します。どのように検索の処理を動作させるのかというのは辞書を使用するアプリケーションによって様々であるため、多くの種類の文字列検索方法をサポートしております。

お客様にデータ管理を行い易くし、オフライン環境でも容易に辞書の変更ができるように、シーセンスでは、多くのお客様が使用している、Excelのワークシートによる辞書を提供しております。アップロードされたExcelのワークブックはパースされ、適切に処理が行われ自動的に目的に合わせた内部表記に変換します。

このページでは、シーセンスのプラットフォームに辞書を適用するには、Excelのワークブックをどのようにフォーマットすべきかを記載しております。

辞書を使って、検索のテストをする場合、 /processing/linguistics/execute APIを使用します。使用する場合、辞書をアップロードし、適用後は、シーセンスサーバが辞書を適切に処理するまでしばらく待つ必要があります。


Excelワークブック以外に、JSONオブジェクトを辞書として使用することもできます。JSONオブジェクトはプログラムによる処理や、第三者ソリューションなどでの統合に便利です。

コンセプト

 Excelワークブックと辞書を使用する際、いくつかの基本コンセプトがあります。

  • シーセンスプラットフォームのそれぞれの辞書は dictionary ID が割り当てられます。辞書を使ったサービスを使用する場合、辞書IDを設定する必要があります。このIDを用いて様々なサービスで、シーセンス上の辞書とクライアントの辞書をそれぞれ容易に変更、共有することができます。

  • Excel のワークブックは複数のワークシートを含むことができます。それぞれのワークシートに個別の辞書が設定されていても、それら全てのワークシートを含むワークブック1つの複合辞書とみなします。
    そのため、 dictionary ID は1つのワークブックに対して1つです。複数のワークシートを含むワークブックは検索時には全てのワークシートが参照対象となります。そのため、検索は全てのワークシートで並列に行われ結果は全てのワークシートの結合となります。

  • ワークシートは property ワークシート または data ワークシート のいずれかです。
    data ワークシートは、実際の辞書のエントリが含まれます。property ワークシートは、data ワークシートがどのように処理、検索されるかを、定義したメタデータです。

  • property ワークシートと data ワークシートは名前で紐付けします。property ワークシートは global property ワークシート としても名前で決めることができます。この場合、global property ワークシートは property シートが割り当てられていない全ての data ワークシートに対してメタデータを適用します。

  • data ワークシートは実際の辞書のエントリを含みます。1つのエントリは1行に記載します。各行は キー と 0個以上  で構成されます。キー が実際のエントリ(検索で入力される文字列など)となり、値は、キー に紐づいたメタデータとなります

ワークブックの構成

Excelのワークブックは下記のフォーマットを遵守してください。

  • ワークシート名は必ず @@から開始する必要があります。例: @@foo-stuffなど

  • ワークシート名は必ず以下の名前パターンにマッチする必要があります:
    ^@@\\p{L}(\\p{L}|\\d)*(-(\\p{L}|\\d)+)*$

  • ワークシート名は30文字以下である必要があります。

  • ワークシート名の終わりに -properties が含まれている場合、プロパティワークシートとみなします。含まれていない場合、データシートとみなします。ワークシート名からシートとプロパティのリンクが行われます。例: @@foo-stuff-properties のプロパティシートは @@foo-stuff データシートに適用します。

  • オプションのワークシートである @@global-properties は globalのプロパティシートとなります。

各ワークシートのフォーマットは以下のルールとなります。

  • ワークシートは特殊ヘッダの行は設定しない。もしあった場合も辞書のデータとして取り扱います。 

  • 空白の行は無視します。

  • 行で、空白のセルは無視します。

  • もし、セルの値が 「//」から始まる場合、その行以降にあるセルは全て無視します。例: 「//」 はコメント文の最初で使用します

  • 空白ではない、各行のセルは1つの辞書エントリとして変換します。

  • 空白ではない行の最初のセルが辞書の キー として使用されます。

  • 空白ではない行の2つ目以降のセルが キー との紐付けの 値 になります。

  • ワークシートでは、同じキーを複数回使用しないでください。同じキーが適用されていないか、プロパティワークシートの紐付けやデータシートの標準化を行なった後にチェックします。

Property ワークシート

 プロパティワークシートはデータワークシートのメタデータを定義します。
例えば、データワークシートのエントリがどのように標準化すべきかやマッチすべきかなど。
プロパティワークシートの値は Keyと値のペアとなります。

Basic properties

以下は、一般的に使用するプロパティです。

  • tokenizer-context
    必須項目です。ワークシートの言語を定義します。通常 ISO 639-1 コード に基づき表記します。
    これを設定することで、トークン化やその他の言語処理をその言語に準じて行うことができます。

  • mode
    検索文字列に対して、辞書の キー がどのようにマッチするかを定義します。
    異なる検索モードは異なる基準と動作特性があります。現在、下記 mode をサポートしております。

    • complete
      入力文字に対して完全一致するかどうか。例: food processor で検索すると food processor のエントリのみマッチします。

    • prefix
      入力文字に対して前方一致でマッチするかどうか。例: foo で検索した場合、 food processor がマッチします。

    • overlap
      入力文字と辞書から共通項目の文字がマッチするかどうか。例: snazziest food processor で検索した場合、 food processor がマッチし、angeles は消去します。

    • didyoumean
      入力文字を辞書でスペルチェックするかどうか。例: sppelling mistae で検索した場合、spelling mistake にマッチします。

    • phrase
      入力文字が1つ以上辞書に入っているかどうか。通常は、慣用句として検索します。例: spears で検索した場合、britney spears toxic にマッチします。

    • ranked
      辞書のマッチングをするためには、"十分な"量の入力文字列が必要です。自然な適合性に沿ってN-of-M マッチングでインデックスとランクでマッチングを行います。1-of-M は OR 検索と同じで、M-of-M は AND 検索と同じです。

    • ngram
      rankedモードと同様ですが、処理が条件単位ではなく、文字単位となります。

    • head
      overlapと同様ですが、最初の文字列がマッチするかどうかを検索します。ただ、辞書のエントリーの最後の文字列処理が考慮されます。

    • tail
      overlapと同様ですが、最後の文字列がマッチするかどうかを検索します。ただ、辞書のエントリーの最初の文字列処理が考慮されます。

    • keystroke
      日本語で、prefixモード動作となりますが、キーボード入力時点で文字列を推測します。詳細はこちらをご確認してください。

  • key-normalization-flags
    どのように辞書の key を標準化するかを定義します。標準化のフラグはマッチングに影響します。
    例:ワークシートに Food Processor を含んでいる場合、food processor として標準化するかどうかなど。
    大文字小文字の区別をするかどうかといった定義を行います。標準化フラグはビットマスクとして定義されているため、複数の値の合計がフラグとなります。
    現在サポートしているフラグは下記です。

    • 0
      何も設定しません。例: reSUMé は reSUMé として標準化します。

    • 4
      大文字小文字の標準化。例: somETHing は something として標準化します。

    • 8
      アクセントの標準化。例: André Previn は Andre Previn として標準化します。

    • 64
      URLデコード化。例: foo+%42ar は foo Bar として標準化します。

    • 128
      URL標準化。例: http://foo.com/bar#blah は foo.com/bar として標準化します。

    • 256
      ヒンズー語とインド語の標準化用です。

    • 512
      スカンジナビアの言語の標準化用です。

    • 1024
      アラビア語の標準化用です。

    • 2048
      トルコ語とアゼルバイジャン語の標準化用です。

    • 4096
      日本語用の標準化用です。カタカナからひらがな変換をするかなど。

  • value-normalization-flags
    辞書の 値 をどのように標準化するかを定義します。設定値は、key-normalization-flagと同様ですが、辞書の 値 に対して紐付けられた文字列のリストに対して metaデータが適用されます。

  • swap-fields
    どのように辞書の結果をクライアントに返すか定義します。
    もし値が true に設定されている場合、値/キー の組み合わせではなく、キー/値 の組み合わせで返します。これは標準化やカテゴリー化でよく使用されます。
    例:german shepherd で検索した場合、german shepherd で返さず、犬としてマッチしたデータを返すなど。
    このオプションを使用する場合、何かしらの値を返すことを想定しています。そのため、全てのエントリは最低2つ以上のセルの値が設定されていることを想定しています。また、キー と 値 は同じ値を設定しないようにしてください。このフィールドが設定されている辞書に対する /processing/dictionary/search の使用はサポートされていません。

Advanced properties

mode の値によっては、下記のいくつかの項目が必要になります。関連する mode の値と一緒に使用してください。

  • count
    いくつかのアプリケーションや、mode の値では、マッチした数をフィルタすることで 1 か 0 かを制約することが望ましい場合があります。これは "十分な" マッチがあるか、もしくは戻り値を抑制することを可能にします。
    例: カテゴリー化するアプリケーションの正確さを向上させるために使用するなど。
    どのような要素が"十分な"マッチがあるか、制御できるかなど、行数や一意な値の数で制約を与えることができます。
    例: 項目が3つ以上あると戻り値が必要だが、2つ以下の場合、一意とみなすなど

  • unique-count
    countと同様です。countは行のカウントに制約がありますが、この値は一意な値の制約を追加します。

  • count-field
    上の count の閾値をどのように解釈し、count フィルタに影響するかを定義します。
    例: 実行結果を全てとみなすのか、group-byの制約を下記に示す値の解釈に従って適用するかなど
    現在、サポートしているのは下記の値です。

    • none
      グルーピングしません。例: count は実行結果の特定のフィールドで翻訳されません。

    • value
      実行結果にマッチした値に対して、 group-byに制約を与えます。swap-fieldの設定も確認してください。

    • extra
      実行結果にマッチしたメタデータに対して、group-byに制約を与えます。swap-fieldの設定も確認してください。

  • expand-paths
    この値が false で、辞書の値がタクソノミのパスである場合("/"で分割されている場合)、ユーザやアプリケーションが全てのプリフィックスを含めるためにパスを展開する必要があります。
    例: Cxense Analyticsget で正しいロールアップカウントを訂正する場合など。
    これを設定することで、ユーザはより制御ができますが、ワークシートはより複雑なものになる場合があります。 この値が true の場合、ユーザは特定/詳細 パスをリストするのみで、全てのパスのプリフィックスは自動的に生成します。

  • annotate-paths
    この値が true で、辞書の 値 がタクソノミのパスである場合("/"で分割されている場合)、@@で始まるワークシート以外はタクソノミのトップカテゴリとして挿入されます。

  • group-prefix
    ユーザが カスタマープリフィックス でこの値を設定している場合、ワークブックはユーザーの関心事項についてのタクソノミとみなします。ユーザの関心事項の詳細はこちらを参照してください。

  • lemmatize
    デフォルトでは false です。もし true である場合、マッチングは言語学に基づいて標準化しされ、検索されます。
    例: ノルウェー語の røde biler が検索文字の rød bil にマッチします。現在、英語、ウルドゥー語はサポートしていません。
    キーが、言語学に基づいて標準化されるため、この値が true である場合、key-normalization-flags を定義してはいけません。

Very advanced properties

より高度なプロパティを下記にまとめます。これらは、 mode 用や辞書検索の設定で使用します。

  • candidates
    クライアントに返す最大マッチ数を制御します。mode のいくつかの値では無視される場合があります。

  • sort-candidates
    prefixとphraseのmodeで使用します。
    検索結果を返す前に、結果セットのソートをしたい場合があります。この値が true である場合、返される キーが数値である場合、降順でソートされます。

  • emit-exact-match
    近似によるマッチング mode を使用している場合に使用します。
    true に設定している場合、完全一致があれば、該当するもの表示します。
    例: 完全一致がある場合、近似によるマッチングは計算しません。

  • shingle-width
    文字列のマッチング検索の範囲を指定します。
    例: n-gramマッチングの n の定義をします。値が小さいと不要なマッチングを引き起こします。値が大きいと精度が落ちます。

  • recall-threshold
    M/Nの冗長検索で転置インデックスを使用する mode でN/Mの割合の閾値を設定します。(Mは検索クエリで使用された用語で、Nはマッチした用語)
    例: ランク付けされるべき辞書のキーで、検索で使用する用語の最小パーセンテージを定義します。
    N=Mの場合、AND構文となります。N=1の場合、OR構文となります

  • rank-threshold
    ランク検索で転置インデッックスを使用する mode でランクスコアの閾値を設定するのに使用します。
    例: この値より低いスコアにマッチするものは無視されます。

  • use-delimiters
    文字でのマッチングモード検索に依存致します。
    trueに設定している場合、特殊なデリミッターが辞書のエントリの開始と最後に適用されます。
    I設定することでパフォーマンスコストを改善します。

  • frequency-threshold
    didyoumean の mode で使用します。
    もし、頻度の重み付けがある場合、この値より小さい頻度の辞書のエントリは無視されます。
    設定されている場合、頻度データは、辞書の各キーに紐付けされていると想定されます(数値と想定しています。)
    キーが特定されていない場合、適切な頻度の閾値が動的に計算されます。

  • distance-exponent
    didyoumean の mode で使用します。
    最初に文字列で検索された検索対象文字は、文字間隔でランク付けの再計算が行われます。
    この値はどのくらい強調されるか、検索対象の文字間隔と頻度で制御します。
    キーが設定されていない場合、適切な距離の解釈が動的に計算されます。

  • distance-threshold
    didyoumean の mode で使用します。
    対象と辞書のエントリーの最大文字間隔を制御します。正確さを制御するために使用します。

  • identity-match
    一部のアプリケーションでは、オリジナルでインプットした用語を記事から検索し、更なる計算をする場合などで有用性があります。
    例: foo で検索すると通常、food processor がヒットしますが、この値が true に設定されている場合、foofood processor がヒットします。

  • leftmost-longest-match
    辞書のエントリが同じ用語を含んでいる場合や、重複している場合などいくつかの mode で全てをマッチすべきか、
    それとも、一番長い重複用語を含んでいるものを表示するか選択する必要がある場合に使用します。
    例: この値が true に設定されており、overlap mode で、辞書に "chicago"  "chicago symphony orchestra" が登録されている場合、
    検索で "chicago symphony orchestra" と入力した場合、"chicago symphony orchestra" がより長い用語となるため、"chicago" は無視されます。

  • allow-complete-match
    head と tailの modeで使用します。
    無視もしくは、表示するのに、完全一致が有効である場合に使用します。

  • emit-contextual-match
    didyoumean の mode で使用します。
    true に設定されている場合、周りの単語や文脈から検索単語を推測します。
    これを行うためには辞書にフレーズとパフォーマンスコストが含まれている必要があります。

  • start-marker
    didyoumean の mode で使用します。
    検索で変更された単語は、この値でマークアップされるため、GUIでは、何が変わったのか明確に表示することができます。
    例: 検索で "the rollig stones worldd tour"と検索した場合
    "the <changed>rolling</changed> stones <changed>world</changed> tour" で検索したものとして動作します。

  • end-marker
    didyoumean の mode で使用します。詳細は、start-markerを確認してください。

Data worksheets

data ワークシートは実際に検索する文字列の辞書データです。property ワークシートではないワークシートは全てデータシートです。

data ワークシートのエントリーは キー/値 の組み合わせです。キーは実際にマッチングに使用します。
値はキーに基づいた、メタデータです。詳細は、上部のワークブックの構成のフォーマットの行に対するルールを参照してください。

Examples

To appear.

Last updated: