正規化ルールの操作

正規化ルールの作成

1. MDエディタページ（［リソース > 目録 > メタデータエディタを開く］）で、［ルール］領域を開きます。
2. MARC  または Dublin Core レコードの場合、[新規] > [正規化] を選択して正規化ルールを作成します。  [正規化ルールのプロパティ (新しいルール)] というタイトルのダイアログ ボックスが表示されます。
   
   正規化ルールのプロパティダイアログボックス
3. 正規化ルールファイルの［名前］ と［説明］を入力します。
   ルール名に「ルール」という単語を使用する場合は、大文字にしないでください。大文字にするとルールは機能しません。
   
   ルール名にバックスラッシュ (\\) を使用しないでください!そうすると、 このルールは フィルター セット機能には使用できません。
4. MARC レコードの正規化ルールを作成するには、[Drool]を選択します。DC（Dublin Core）レコードの 正規化ルールを作成するには、［XSL］を選択します。
5. アクセスオプションを、［プライベート］または［共有］から選択します。［プライベート］を選択した場合、自分だけがルールを操作でき、ルールを正規化プロセスに含めることはできません。［共有］を選択すると、ルールは目録者間で共有されます。この場合、複数のユーザーが同時にルールを表示できます。 2人以上のユーザーが編集のためにルールを開いている場合、変更を保存しようとすると警告メッセージが表示されます。（変更を保存するか、他のユーザーが変更を行って保存できるようにするかを選択できます。）
6. ［保存］を選択します。 MD エディタの編集ペインが表示されます。
   既存のルール構文を含めるか（[編集] > [ルールの追加] > {type of rule}）、ルールを定義できます（詳細については、「正規化ルールの構文」を参照）。
7. [保存]を選択します。ルールは、［正規化ルール］タブのルールファイルのリストに追加されます。

1. [リソース] > [目録] > [メタデータ エディタを開く] メニューから [ルール] タブを選択して、MD エディタ ページの [正規化] フォルダ を展開します。
2. コピーするには、コミュニティフォルダを開きます。コピーしたいルールを右クリックして重複を選択します。 
   重複ルールダイアログが開きます。名前と説明を指定し、プライベート（自分だけが利用可能）として、または共有ルール（組織内のすべてのユーザーが利用可能）として保存するかどうかを指定します。 
   ルールを CZに投稿したAlmaユーザーの名前と連絡先メールアドレスがダイアログに表示されます。質問がある場合は、このユーザーに連絡できます。 
3. 自分でCZに投稿するには、ルールを右クリックして[CZに投稿する]を選択します。 
   ルールの共有ダイアログが開きます。記述名 と説明を入力し、保存を選択してCZにルールを保存します 。

1. [MD エディタ] ページ ([リソース] > [目録] > [メタデータ エディターを開く]) で[ルール] タブを選択し、 [正規化] フォルダーを展開して、保存されているルールを表示します。
2. 使用するルールを選択し、次のオプションのいずれかから選択します。
   • ［編集］ - ルール構文が含まれるテキストボックスを開き、この構文を変更できるようにします（詳細については、正規化ルールの構文を参照してください）。
   • ［削除］ - はいを選択して、ルールファイルの削除を確認します。
   • ［重複］ - 選択したルールファイルを複製し、元のファイルに影響を与えずに新しいルールとして変更して保存できるようにします。
   • ［プロパティ］ - 正規化ルールのプロパティダイアログボックスを開き、ルールファイルのプロパティを変更できます。
3. ルールの名前を変更するには、 ルールを複製し、その重複に目的の名前を付けてから、古いルールを削除します。 

• ［変更の適用］を選択して変更をレコードに保存するか、さらに編集を行いたい場合は［正規化ルールに戻る］ を選択します。 
• 正規化ルールに最終的な変更を加えたら、[保存して外部レコードを使用してテストする] を選択し、正規化ルールの最終バージョンを保存します。詳細については、 外部データソースの正規化ルールのテストを参照してください。

 Dublin Coreレコードの正規化ルール

メタデータエディタには、Dublin Coreに関連する次のタイプのルールがあります。

• XSL表示ルール
• XSL 正規化ルール

Dublin Core正規化ルールは、通常の正規化ルール形式での記述はできず、 XSL形式でのみの記述が可能です。つまり、 メタデータエディタで直接XSLを作成するか（上記で説明）、 メモ帳  （または任意の外部アプリケーション）で作成し 、それをメタデータエディターにコピーすることができます。 

メタデータエディタのコミュニティゾーンでは、 XSL正規化ルールの以下の例を表示できます。

• EXL – dc:language値「en」を「English」に変更
• EXL – Dublin Coreレコードの文字列を置き換える一般的なルール
• EXL_Add_field_accessRights

1. 選択した外部アプリケーションでXSLを記述します。
2. [メタデータ エディタ] > [ルール] セクションを開きます。 
3.  メタデータエディター でXSLをコピーして貼り付け、ルールを保存します。

Primo VEの正規化ルールプロセス構成

Almaの正規化ルールに加えて、Primo VEの正規化ルールと Esploroの正規化ルールを作成できます。これらのルールを作成するには、 [新規]をクリックして、 次を選択します。

• 正規化 （検出）  – このオプションは、 Primo VEがシステムで定義されている場合にのみ表示されます。Primo VEに ロードされ、 Almaで管理されていない 書誌レコードのDCまたはXML正規化ルールを作成する場合は、このオプションを選択します。 これらのルールの構文については、「DCおよびXML形式の正規化ルールの構文」を参照してください。

• 正規化（リサーチ）  – このオプションは、 Esploroがシステムで定義されている場合にのみ表示されます。詳細については、 「アセット正規化ルールの管理」 （Esploro）を参照してください。

正規化ルールの構文

• \b
• \t
• \n
• \f
• \r
• \"
• \'
• \\

• \\\を \\ に置換
• \.を . に置換
• \を ¥¥ に置換
• ¥(を ( に置換
• \)を ) に置換
• \\\|を \\| に置換

ワイルドカードと特殊文字

サブフィールド区切り文字（$$）は、ルール名を含め、ルール内のどこにも表示することはできません。

行の先頭にあるハッシュ文字（#）は、行の残りがコメントであることを示し、ルールの処理時には無視されます。

アスタリスク（*）は、長さゼロの文字列を含む任意の文字列と一致させるために使用されます。たとえば、"<tag>.<*>.<value>"は、値<value>を持つタグ<tag>内のすべてのサブフィールドに適用されます。*は「貪欲」機能であるため、文字列内のできるだけ多くの文字に一致しようとします。例：文字列が「a b c b d b e」の場合、「b*b」というパターンは「b c b」だけでなく、「b c b d b」も一致します。

空のインジケータ（フィールドまたはサブフィールドは除く）は、ハイフン（-）で示されます。たとえば、"<tag> {-,<ind2>}"は、MARCタグが<tag>で、最初のインジケーターが定義されておらず、2番目のインジケーターが<ind2>であるすべてのフィールドを返します。

サブフィールドのテキストに最後の文字としてピリオドが含まれる場合、4つのバックスラッシュ記号を使用してピリオドに一致させます。例：

ルール「$a (unconditional)の'1 v.'を'Leaves'に置換」
when
(TRUE)
then
replaceContents "300.a.1 v\\\\." with "Leaves"
end

二重引用符は条件（のみ）で使用できます。条件の一部として二重引用符を使用するには、二重引用符（"）ではなく、単一引用符を使用してルール内のテキストを囲みます（'）。この方法を使用すれば、二重バックスラッシュ（\\）に続くテキスト内で二重引用符を使用できます。

rule "populate 008 7-10 2016"
when
(exists '245.{*, }.c.\"')
then
replaceControlContents "008.{7,4}" with "2016"
end

ヘブライ語の日付は、条件（のみ）で使用できます。（ヘブライ語は右から左に読み取るため、次の例の二重バックスラッシュは実際には二重引用符の前にあります。）

rule "populate 008 7-10 2016"
when
((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
then
replaceControlContents "008.{7,4}" with "2016"
end

• ワイルドカードは、条件または値の最初の文字として使用することはできません。
• リテラルバックスラッシュ（\）使用するには、別のバックスラッシュ\\ でエスケープします。
• ピリオドが文字列の最後の文字である場合、4つのバックスラッシュ (\\\\)を使用してエスケープします。ピリオドの直後に別の文字が続く場合、4つのバックスラッシュは必要ありません(次の例のようにaddField "907.a.F.L.T\\\\.")。ただし、一貫性のある望ましい結果を確保するには、正規化ルールで常に4つのバックスラッシュを使用することをお勧めします。次の例を参照してください。
• 上記のように、二重引用符が単一引用符を使用してエスケープする条件（でのみ）使用される場合や、単一引用符を使用してエスケープする条件で単一引用符を使用する場合、二重引用符または引用符をダブルバックスラッシュでさらにエスケープする必要があります。
• パイプ記号が条件の一部である場合は、4つのバックスラッシュを使用してエスケープします。例： removeField "866" if (exists "866.8.0\\\\|99")。これは、条件でパイプ記号を使用する場合にのみ必要です。

例：replaceContentsを使用した正規化ルールでのピリオドの使用

ピリオドを含むレコードの例：

245 00 $$a Feminist literary theory.: $$b a reader / $$c edited by Mary Eagleton.

246 0# $$a F.L.T.

上記のサンプルレコードの正規化ルール

ルール「245および246サブフィールドaのピリオドを削除（およびピリオドを何とも置き換えない）ピリオドの前に4つのバックスラッシュを入れる」
when
(TRUE)
then
replaceContents "245.a.\\\\." with ""
replaceContents "246.a.\\\\." with ""
end

前後の例については、下の図を参照してください。

前後の例

例：addFieldを使用した正規化ルールでのピリオドの使用

以下は、ピリオドを追加する必要のあるレコードの例です。

906 $$a Architecture.

907 $$a F.L.T.

以下は、常にスラッシュを含めるというベストプラクティスを使用した上記のサンプルレコードの正規化ルールです：

ルール「フィールド906に文字Architectureとその末尾にピリオドを追加、およびフィールド907にF.L.T.も追加」
salience 100
when
TRUE
then
addField "906.a.Architecture\\\\."
addField "907.a.F\\\\.L\\\\.T\\\\."
end

レコードの前後の例については、次の図を参照してください。

前後の例