3.3 提案されている商品記述の実例
3.3.7 ＭＭＦ（Multi-Schema Metadata Format）
３．１「商品属性の論理構造」で述べた商品属性の論理構造が持つべき要件を備えた研 究事例として日本の(株)ディジタル・ビジョン・ラボラトリーズが提案している Multi‑
Schema Metadata Format がある。このフォーマットはＤＶＬが実験運用しているインター ネット商品検索サービス「グルメファインダー(http://cm.dvl.co.jp/)」で利用されている。
ここではＭＭＦの説明を試みるが、さらに詳しくは６．１資料編ＭＭＦ仕様書も参考にされ たい。
このフォーマットは、商品の特徴をＨＴＭＬファイルのヘッダ部に meta タグを用いて埋 め込んでおり、スキーマの異なるメタデータを扱うために必要なスキーマ定義やスキーマオ ントロジーを別のファイルとして用意し互いをＵＲＬで結ぶ構造となっている。
Multi‑Schema Metadata Format の構造を以下の図に示す。
Multi‑Schema Metadata Format では、価格＝５０００円、生産地＝新潟などの商品属性 情報を①のメタデータインスタンスの層で保持し、この層はＨＴＭＬファイル内に記述され
る。②のスキーマ定義の層では日本酒用スキーマは価格・生産地・日本酒度などの属性を持 つと言うことが宣言される。③のスキーマオントロジーの層では、異なるスキーマの属性の 間の概念関係（同一の物であるのか、片方を含む物なのか）が宣言される。④の標準属性辞 書の層では一般的に使われる属性の辞書が表現される。
Multi‑Schema Metadata Format では、これらの層に位置するデータはそれぞれ別個のネ ットワーク上の存在（ファイル、データベース中のデータ）として扱われ、互いはＵＲＬ指 定によって結ばれている。
３．１で述べた４つのレイヤー、商品属性情報本体、スキーマ定義情報、スキーマ意味 情報、標準概念辞書はそれぞれ、Multi‑Schema Metadata Format のメタデータインスタン ス、スキーマ定義、スキーマオントロジー、標準属性辞書に対応すると考えられる。
以下でそれぞれのレイヤーについて述べる。
3.3.7.1 メタデータインスタンス
メタデータインスタンス部はメタデータの実体が記述される部分で、商品カタログペー ジに埋め込むことができる。
メタデータインスタンスは図２のようにＨＴＭＬのヘッダ部に meta タグを付けて記述す る。インターネット上の資源のメタデータの表現形式はいくつか提案されており、ＩＡＦＡ
スキーマ定義 日本酒：価格、生産地、日本酒度…
スキーマオントロジー 日本酒.生産地⊇水産物.生産県…
標準属性辞書 販売価格、生産国、生産地方
価格＝5000円、生産地＝新潟 メタデータインスタンス
1 2 3 4
URLでリンク URLでリンク URLでリンク
図 1 Multi-Schema Metadata Format の構成
Ｔｅｍｐｌａｔｅ, ＵＲＣ, ＳＯＩＦなどがある。最近では、ＯＣＬＣが主催する一連のワ ークショップで Digital Library への応用を主眼とした Dublin Core、The Warwick Framework が提案された。このうち、The Warwick Template はスキーマを複数扱うことも視野に入れ て設計されている。このため、ＭＭＦのメタデータインスタンスの表現形式は The Warwick Template に基づいている。ＭＭＦで新たに拡張したのは以下の二つである。
1. delimiter‑line の導入 2. Aspect とSystem の導入
一つの商品カタログページに複数の商品が紹介されている時、それぞれの商品のメタデ ータは delimiter‑line で分けられる。Aspect と System は Dublin Core における Qualifier の一種である。図２の例では、「製造会社」という属性は「会社名」「電話番号」という二 つの Aspect を持っている。また、System は、値の通貨単位や RFC1738 のような特定の単位 系や記述規則を表すもので、例の「価格」という属性の値「５５００」には「JPY」（日本 円）という System が指定されている。
3.3.7.2 スキーマ定義
<meta name="---" content="begin">
<link rel=SCHEMA.CN href=http://www.dvl.co.jp/schema/
cn.scm>
<meta name="CN.商品名称" content="()Formula 1">
<meta name="CN. 商 品 購 買 "
content="(System=RFC1738)
http://www.dvl.co.jp/purchase/aaa.htm">
<meta name="CN. 商 品 サ ン プ ル "
content="(System=RFC1738)
http://www.dvl.co.jp/sample/aaa.htm">
<meta name="CN.製造会社"
content="(Aspect=会社名)（株）DVL">
<meta name="CN.製造会社"
content="(Aspect=電話番号)XX-XXXX-XXXX">
<meta name="CN. 商 品 価 格 "
content="(System=JPY)55000">
<meta name="---" content="separate">
<link rel=SCHEMA.CN href=http://www.dvl.co.jp/schema/
cn.scm>
<meta name="CN.商品名称" content="()Rage Racer">
<meta name="CN. 商 品 購 買 "
content="(System=RFC1738)
http://www.dvl.co.jp/purchase/bbb.htm">
<meta name="CN.製造会社"
content="(Aspect=会社名)（株）DVL">
<meta name="CN. 商 品 価 格 "
content="(System=JPY)55000">
<meta name="---" content="end">
図 2 メタデータインスタンスの表記例
スキーマ定義ではメタデータに使われる属性とその Aspect のセットをスキーマとして定 義する。メタデータインスタンスにおいてある属性の値の取りうる System が制限されると きは、スキーマ定義にその制限を書くことができる。スキーマ定義は、ＳＯＩＦ(the Summary Object Interchange Format)に従って記述される。スキーマ定義の例を図３に示す。
スキーマ定義を作成するスキーマ設計者はメタデータ作成者とは異なる人物であると考 えられる。例えば、業界の専門家やモールがスキーマを設計し、メタデータの作成者はそれ らから適切なスキーマを選択してメタデータを作成することが考えられる。このため、スキ ーマ定義はメタデータインスタンスとは独立して記述することとした。
3.3.7.3 スキーマオントロジー
スキーマオントロジーでは、メタデータや検索式のスキーマ間の相互変換を可能にする ために、スキーマの属性と他のスキーマの属性との包含関係を階層的に表現している。
例として二つのオンラインビデオショップを考える。最初の店 A はスキーマ A を用いて 商品である映画のメタデータを作成している。もう一つの店 B はスキーマ B を用いている。
スキーマ A では、「出演者」という属性を持ち、映画に出演する役者の名前のリストを値と して持つ。一方、スキーマ B は「出演者」よりも細かい属性「主演女優」を持っている。「Ms.
Maedchen Amick」が出演するビデオを探そうとするとき、「A.出演者 == Maedchen Amick」
という検索式を用いると店 A から探すことができる。しかしこの式は店 B では使えない。逆
@SCHEMADEFINITION { http://cm.dvl.co.jp/sch/def.scm Schema-ontology{x}: http://cm.dvl.co.jp/ont/default.sot Number-of-Entries{x}:
Attribute-1{x}: 商品名称
Description-1{x}: 商品の名称を記入
Attribute-2{x}: 商品購買
Description-2{x}: 商品を購入できるWWWのURL
System-2{x}: RFC1738
Attribute-3{x}: 商品価格
Description-3{x}: 商品を購入できる価格
System-3{x}: JPY
System-3{x}: USD
Attribute-4{x}: 製造会社
Description-4{x}: 商品を製造した会社の情報
Number-of-aspects-4{2}: 2
Aspect-5{x}: 会社名
Parent-attribute-5:{x} 製造会社
Description-5{x}: 製造会社の正式名称
Aspect-6{x}: 電話番号
Parent-attribute-6:{x} 製造会社
Description-6{x}: 製造会社の電話番号を記入
}
図 3 スキーマ定義の例
に、「B.主演女優 == Maedchen Amick」という検索式は店 B で使えるが、店 A では使えない。
異なるスキーマ間で検索を行うためには、検索式を他のスキーマに変換することが必要 である。店 B の商品をスキーマ A による検索式「A.出演者 == Maedchen Amick」で検索する 場合は、検索式を「B.主演女優 == Maedchen Amick」に置き換える必要がある。逆に、店 A の商品を検索式「B. 主演女優 == Maedchen Amick」で探す場合は、検索式を「A.出演者 ==
Maedchen Amick」に拡大解釈して検索することが必要な場合もある。この変換のための、「A.
出演者」と「B.主演女優」の二つの属性の間の包含関係をスキーマオントロジーに記述する。
スキーマオントロジーで定義づけられる関係は次の二つである。
l 同等関係：二つの属性が同じ関係を意味している場合。「商品名称」と「商品名」
など。「商品名称 ＝ 商品名」と書く。
l 包含関係：属性 A が示す関係が属性 B の示す関係の特殊な物である場合。「出 演者」と「主演女優」など。「出演者 ⊇ 主演女優」と書く。
以上のように、スキーマオントロジーは二つ以上のスキーマの属性の間の関係を記述す るものである。具体例を図４に示す。
検索式の変換には「言い換え」と「拡大解釈」の二つがある。言い換えとは同等の属性 もしくは指定された属性よりも広い意味の属性に変換することであり、拡大解釈とは検索式 で指定された属性の内容が含まれるかもしれない狭い意味の属性に変換することである。先 ほどの例では、「A.出演者 ⊇ B.主演女優」という関係があった。「B.主演女優 : Maedchen Amick」というメタデータを持つ映画は、「A.出演者 == Maedchen Amick」という検索式に 合致する。つまり、「属性 1 ⊇ 属性 2」の関係が成り立つとき、「属性 1 == 値」という 検索式は「属性 2 == 値」という検索式に変換できる。これは「属性 1＝属性 2」の場合も 同等である。この変換を「言い換え」と呼ぶ。
一方、「A.出演者：Maedchen Amick」というメタデータを持つ映画は、Miss Amick が主 演か助演か不明なため確実ではないが、検索式「B.主演女優 == Maedchen Amick」にあては まる可能性がある。そこで、可能性がある検索結果として、この映画を挙げるのが「拡大解 釈」である。すなわち、検索する「属性１ ⊆ 属性２」の関係の時に、検索式「属性１ == 値」
を検索式「属性２ ＝ 値」に変換することを「拡大解釈」と呼ぶ。「拡大解釈」は、検索サ ービスにおいて、ユーザの指定された検索式に合致する商品が少ない場合に拡大解釈して商 品を探すなどの用途が考えられる。
3.3.7.4 標準属性辞書
スキーマの数が少ない場合は、スキーマ間の関係は m 対 n で設定することができる。し かし、スキーマは各店が他店との差別化のために拡張したり独自に定義したりして、スキー マの数が多くなると、m 対 n の設定は実質的に不可能になる。これを解決するためには、標 準的な属性を集めた標準属性辞書が必要となる。スキーマを新規に作るときには標準属性辞 書との関係を記述すれことで他のスキーマとの互換性を実現する。