1. ホーム
  2. のらマネージャーのブログ
  3. General Structure of a PMML Document

General Structure of a PMML Document

2003年7月 2日 13:42

PMMLは、マイニングモデルを表\わすためにXMLを使用します。モデルの構\造は、PMML DTDと呼ばれるDTDによって記述されます。単一、もしくは複数のマイニングモデルはPMMLドキュメントに含まれます。PMMLドキュメントはタイプPMMLの素要素を持つXMLドキュメントです。PMMLドキュメントの一般的な構\造は以下の通りです。

<?xml version="1.0"?>
<!DOCTYPE PMML
PUBLIC "PMML 2.0"
"http://www.dmg.org/v2-0/pmml_v2_0.dtd">
<PMML version="2.0">
...
</PMML>
PMMLドキュメントにはDOCTYPE宣言が存在しなくてもかまいません。もし、存在した場合、PMMLドキュメントは外部パラメーターに依存してはなりません。それは、その<?xml?>ステートメント中のデフォルトの属性が standalone="yes" であると仮定しているからです。
PMMLドキュメントはPMML DTDに関して妥当であるはずなので、ドキュメントは外部エンティティをロードするだろう妥当性検証パーザを要求する必要はない。 妥当なXMLドキュメントであることに加えて、妥当なPMMLドキュメントは、PMML詳細中の様々な場所に記述される多くのさらに規則に従わなければならない。さらに妥当なPMMLドキュメント、開発者および利用者のための適合規則を参照してください。

PMMLドキュメントの素要素はタイプPMMLを持っていなければならない。

<!ENTITY % A-PMML-MODEL \'(TreeModel |
NeuralNetwork |
ClusteringModel |
RegressionModel |
GeneralRegressionModel |
NaiveBayesModels |
AssociationModel |
SequenceModel )\' >
<!ELEMENT PMML ( Header,
MiningBuildTask?,
DataDictionary,
TransformationDictionary?,
(%A-PMML-MODEL;)*,
Extension* )>
<!ATTLIST PMML
version	 CDATA	 #REQUIRED
>
<!ELEMENT MiningBuildTask (Extension*) >

一つのPMMLドキュメントは二つ以上のモデルを含むことができます。もし、アプリケーションシステムが名前によってモデルを選択する手法を提供し、かつ、PMML利用者がモデル名を特定したならば、そのモデルが使用されます。そうでなければ、はじめに記述されたモデルが使用されます。

PMML 2.0に準じたシステムは、名前によるモデル選択を提供することを要請しません。

PMMLドキュメント中のマイニングモデルのリストが空であることもありえるでしょう。 そのドキュメントでは、ある実際のモデルが計算される前に、初期のメタデータを用いることになるでしょう。いかなるモデルをも含んでいないPMMLドキュメントは、PMML利用者にとって役に立ちません。

PMMLバージョン2.0の、属性バージョン値は2.0です。

要素MiningBuildTaskは、モデルインスタンスを生み出したトレーニング実行のコンフィグレーションを記述する任意のXML値を持つことが出来る。この情報は、PMML利用者には直接、必要ではありません。しかし、多くの場面で、それがメンテナンスやモデルの視覚化には有用です。MiningBuildTaskの特定の内容構\造はPMML 2.0によっては、定義されません。しかし、この要素を使う事で、例えば、SQLまたはJavaといった他のマイニング基準によって定義されるようなタスクの仕様を組み込むことが可能\となるでしょう。

DataDictionary、およびともに取りうるTransformationDictionaryの中のフィールドは、一意の名前によって識別されます。これらのフィールドを、モデル中の他の要素は名前によって参照することができます。単一のPMMLドキュメント中にある複数のモデルは、TransformationDictionaryの中の同じフィールドを共有することができます。さらに、そのモデルが、その「自分から」派生したフィールドを定義することも出来ます。様々なモデルは、モデルの定義の中でDerivedField(派生したフィールド)要素を直接使用します。例えば、DerivedFieldはニューラル・ネットワークの入力層においてインラインで現れます。

ニューラル・ネットあるいは logistic regression のようなあるタイプのPMMLモデルは異なる目的のために使用することができます。ある手法(インスタンス:ニューラルネットワークやlogistic regression)は、量的な値の予\測を含意する一方で、分類という目的でも使われることがあります。したがって、PMMLは4つの異なるマイニング機能\を定義します。それぞれのモデルは、マイニング機能\を特定する属性「functionName」を持っています。

<ENTITY % MINING-FUNCTION \'(associationRules |
sequences |
classification |
regression |
clustering )\' >

すべてのPMMLモデルについて、トップレベルモデル要素の構\造は、以下のようなXModelのテンプレートに類似している。

<!ELEMENT XModel (	Extension*,	MiningSchema,
ModelStats?, ..., Extension* ) >
<!ATTLIST XModel
modelName 	CDATA 			#IMPLIED
functionName 	%MINING-FUNCTION; 	#REQUIRED
algorithmName 	CDATA 			#IMPLIED
>
<!ELEMENT MiningSchema 	(MiningField+) >
<!ELEMENT ModelStats 	(UnivariateStats+) >

マイニングフィールドの空ではないリストは、mining schemaを定義します。univariate統計は、マイニングフィールド(あるいは、その部分集合)のグローバル統計を含んでいます。他のモデルの特定要素はXModelの内容中のModelStatsの後に現われます。PMML 2.0によって定義されたモデルのリストは、上記のエンティティA-PMML-MODELを参照しなさい。

modelName :modelNameの中の値はモデルを、PMMLファイルの文脈中の一意な名前で特定します。この属性は必須ではありません。PMMLファイルのモデルを読むユーザは、それらを区別するためのモデルの命名を自由に管理することができます。

functionNamealgorithmNameは、マイニングモデルの種類について記述します。例えば、それがクラスタリングや分類といった意図で用いられるかどうか、というような場面などです。アルゴリズム名は、そうしたモデルを生み出す特定のアルゴリズムに対して自由に表\記できます。この属性はたんなる情報でしかありません。

PMMLにおける名づけの規約(命名規則):ElementNamesは大文字小文字交じりで、一文字目は大文字。attributeNamesは、一文字目が小文字。enumConstantsも、一文字目が小文字。。ENTITY-NAMESはすべて大文字です。文字\'-\'は数学的表\記との混乱を回避するために、あまり使用しない。

拡張メカニズム

PMML DTDはモデルの内容を拡張するためのメカニズムを含んでいます。拡張要素は、多くの要素タイプの内容定義に含まれています。これらの拡張要素は、拡張の性質において、考えうる自由度を許す"ANY"という内容のモデルを持っています。拡張メカニズムのあるものを使うと、特定のツールのためのディスプレイ情報を関連させることも可能\になるでしょう。

<!ELEMENT Extension ANY>
<!ATTLIST Extension
extender 	CDATA 		#IMPLIED
name 		CDATA 		#IMPLIED
value 		CDATA 		#IMPLIED
>

拡張データはタイプExtensionの要素(集合)の範囲内に含まれていなければならない。しかしながら、属性名は拡張の種類を指定するために使用することができます。例えば、統計指標の特別な集合を格納するための拡張を<Extension extender="foo.com" name="StatsMomentum">...</Extension>のように書くことができるでしょう。HTMLタグを知っているなら、属性名とメタタグの内容との類似に気づくでしょう。

XML1.0のドキュメントは、拡張されたDTDを変更することなく、与えられた要素に対して属性宣言を加えることが出来ます。XMLパーザは警告を与えるかもしれませんが、追加属性を使用するドキュメントは正しいものです。すなわち、標準のPMML DTDが要素TreeNodeを含んでいる場合、ドキュメントはTreeNodeに追加の属性を宣言することができます。PMMLはこのルールに適合しますが、属性名は拡張を明らかにするために、接頭辞「x-」を持たなければならなりません。同じ規約が、拡張要素に含まれうるベンダー指定の要素タイプに対しても用いられます。そのタグ名は「X-」から始まっていなければなりません。

この規約は、さらに標準のPMMLに対して将来的にありうるの拡張との矛盾を回避することを助けもします。ドキュメントがローカルのnamespacesを使用する場合、namespaceの名前は「PMML」あるいは「DMG」、あるいは小文字を交えたこれらの名前の任意の変形で始まってはなりません。それらはPMMLでの将来の使用のために残しておかれます。

拡張PMMLドキュメントは以下のようになります。

<?xml version="1.0" >
<!DOCTYPE PMML
PUBLIC "http://www.dmg.org/v2-0/pmml_v2_0.dtd"
[	<!ELEMENT X-MyNodeExtension ( ...... ) > .....
<!ATTLIST TreeNode 	x-myAttr CDATA >
]>
...
<XXModel
<TreeNode x-myAttr="xxx" >
<Extension>
<X-MyNodeExtension>...</X-MyNodeExtension>
</Extension>
</TreeNode>
</XXModel>

基本的なデータ・タイプおよびエンティティ:

定義

<!ENTITY % NUMBER "CDATA" >

量的な値を、他のデータから区別するために一般に使用されます。数には整数、分数および指数を含むでしょう。NUMBERに加えて、2、3のより限定的な定義があります:

<!ENTITY % INT-NUMBER "CDATA">

INT-NUMBERは整数でなければなりません。分数あるいは指数ではあってはなりません。

<!ENTITY % REAL-NUMBER "CDATA">

REAL-NUMBERは、C/C++タイプ「float」「long」「double」をカバーする任意の数が可能\です。科学的記数法(eg 1.23e4)は許されています。

<!ENTITY % PROB-NUMBER "CDATA">

PROB-NUMBERは、一般に確率を記述する0.0と1.0の間のREAL-NUMBERです。

<!ENTITY % PERCENTAGE-NUMBER "CDATA">

PERCENTAGE-NUMBERは0.0と100.0の間のREAL-NUMBERです。

それらのエンティティはXMLパーザがデータタイプをチェックすることを強化しない。しかし、それらは、まだ、妥当なPMMLドキュメントに対する必要条件を定義します。

多くの要素は、入力フィールドに対する参照を含んでいます。PMMLは、フィールド名を表\わすためにはIDREFを使用しません。フィールド名が必ずしも妥当なXML identifiersでないのからです。その代わりに、定義を与えられます。

<!ENTITY % FIELD-NAME "CDATA">

そうすると、入力フィールドに対する参照はDTDの文法から明らかです。一つのモデルが2種類の入力フィールドを参照できることに注意してください。1つはMiningSchemaの中のMiningFieldのセットです。もう一つはTransformationDictionaryの中のDerivedFieldのセットです。

PMMLは、REAL-NUMBERの値の表\現で小数点として「.」を使用します。

値のコンパクト配列

マイニングモデルの事例は、しばしば多数の値をもつ集合を含んでいます。タイプ配列はかなりコンパクトな方法で、多くの数および文字列を含む container structure として定義されます。

<!ELEMENT Array (#PCDATA) >
<!ATTLIST Array
n 		%INT-NUMBER; 			#IMPLIED
type 		( int | real | string ) 	#IMPLIED
>

「配列」の内容は値のブランクの分離されたシーケンスです、複数のブランクは1つのブランクと同じ程度です。属性「n」は、シーケンスの要素の数を決定します。nが与えられたなら、内容の中で値の数と一致しなければならない。さもなくばPMMLドキュメントは無効です。属性「type」は、配列中の値のデータ・タイプを示します。配列が使用される場合、多くの場合では、配列が使われる文脈から、データ・タイプが含意されているので、この属性はオプションです。 文字列値はダブルクォート"で囲まれるかもしれません。それ("そのもの)は値の一部であると考えられません。文字列値が、「"」を含んでいるなら、バックスラッシュ文字¥で、回避しなければなりません。それはC/C++の中で使用されるのと同じ回避するメカニズムです。

例:

<Array n="3" type="int"> 1 22 3
</Array>
<Array n="3" type="string">
ab 	"a b" 	"with \\"quotes\\" "
</Array>

第2の配列は3つの文字列を含んでいます。「ab」、「a b」、「with "quotes" 」

そのとき長さ属性nに対する値がある場合、内容中のエントリー数はこの値と一致しなければなりません。そうでなければ、PMMLドキュメントは妥当ではありません。 数の異なるタイプのエンティティに対するものと同様に、特定の内容のタイプを持つべき配列に対するエンティティを定義する。 私たちが定義する異なるタイプの数のための実体に似ている、特定の内容タイプを持っているべき配列用の実体。再び、これらのエンティティは単一のXMLマークアップにちょうど写像します。

<!ENTITY % NUM-ARRAY "Array">

NUM-ARRAYは数の配列です。

The following entities define arrays which contain integers, reals, or strings. 次のエンティティは、整数、実数あるいは文字列を含んでいる配列を定義します。

<!ENTITY % INT-ARRAY "Array">
<!ENTITY % REAL-ARRAY "Array">
<!ENTITY % STRING-ARRAY "Array">

トラックバック(0)

コメントする

アイリンクへのお問い合わせ

お問い合わせメールフォームはこちら

2016年12月移転 北海道旭川市神楽1条7丁目4−8 お問合わせはメール・SNSアカウントで mail
  • twitter
  • facebook
  • google
  • noimage
  • noimage
  • noimage