1. ホーム
  2. のらマネージャーのブログ
  3. PMML日本語化

PMML日本語化

Data Dictionary

2003年7月 2日 13:47

データ・ディクショナリーは、マイニングモデルに使用されるフィールドについての定義を含んでいます。それは型と値の範囲を指定します。これらの定義は、特定のモデルの訓練やスコアリングに使用されるような特定のデータ集合に依存しないと仮定されます。

データ・ディクショナリーは複数のモデルによって共有されることが可能\です。統計や他の情報は一つのモデルの中に格納されています。統計およびマイニングフィールドに関しては、さらにDTDを参照してください。


<!ENTITY 		% FIELD-NAME 		"CDATA" >

<!ELEMENT DataDictionary (Extension*, DataField+, Taxonomy* ) >
<!ATTLIST DataDictionary
	numberOfFields 	%INT-NUMBER; 		#IMPLIED
>

<!ELEMENT DataField ( Extension*, (Interval*| Value*) ) >
<!ATTLIST DataField
	name 		%FIELD-NAME;		#REQUIRED
	displayName 	CDATA 			#IMPLIED
	optype 		(categorical|ordinal|continuous) 	#REQUIRED
	taxonomy 	CDATA 			#IMPLIED
	isCyclic 	( 0 | 1 ) 	"0"
>

値numberOfFieldsはDataDictionaryの内容によって定義されるフィールドの数です。この数は一貫性チェックのために加えることができます。データ・フィールド名はデータ・ディクショナリーにおいて一意でなければなりません。displayNameはそのフィールドを参照するためにアプリケーションによって使用されるであろう文字列です。XMLドキュメント内では、名前の値だけが重要です。displayNameが与えられない場合、名前はデフォルト値です。

そのフィールドは、値に対して定義される演算に依存して異なるタイプに分けられます。これは属性optypeによって定義されます。Categoricalフィールドは演算子「=」を持っています。順序フィールドはそれに加えて「<」持っています。また、連続フィールドはさらに演算子を持っています。Cyclicフィールドは、最大の値および最小の値で閉じていることを考慮される距離の測度を持っています。

オプションの属性「taxonomy」は、値の分類を参照します。値は分類の名前です。それは、値の階層について記述します。属性はcategoricalフィールドにのみ適用可能\です。


DataFieldの内容は、妥当でありうる値の集合を定義します。

マイニングモデルは、値の3つの特性を区別します:

Missing value(欠損値):例えば、データ・ベースのカラムがnull値を含んでいる場合、入力値は見当たりません。欠損値として解釈される値を明示的に定義することは可能\です。

Invalid value(無効値):入力値は欠損しているわけではありません。しかし、ある妥当な値の範囲には属しません。有効値の範囲は各々のフィールドに対して定義することができます。

Valid value(有効):欠損値でも無効値でもない値。


intervalに対する次の要素定義は、データ・ディクショナリー内のフィールドに対する型と値の範囲を定義するために使われます。有効値の範囲は、集合自体の指定により、あるいは補集合の指定により定義することができます。

categoricalな入力値中の末尾のブランクは意味を持ちません。PMMLの中のcategoricalな値は末尾にブランクは持てません。接頭のブランクは意味を持ちます。

モデルのインタープリターがどのように現実に無効値や欠損値を表\わすかという事をPMMLは定義しないことに注意してください。これはアプリケーション環境に依存します。

連続フィールドは、有効値の範囲を定義する多くても2つのintervalを持つ程度でしょう。intervalが存在するなら、intervalの外にあるどんなデータも無効であると考えられます。いかなるintervalも存在しないなら、(個別のmissing値を除いた)実数全体の軸は有効な値で作られています。intervalは非連続フィールドのために許可されません。

有効な値のシーケンスがintervalの範囲の代わりに指定される連続フィールドは存在します。たとえば、これは、グレードの表\現に値1、2、3、4、5、6の固定集合を持つ格付システムの中で、使用することができます。これらの数より他の値は無効の入力と見なされます。その演算タイプは、値の合計と中間値の計算を許可しています。

値範囲が与えられ、厳密に2つの有効値だけを含んでいるcategoricalフィールドとして2値(binary)フィールドがモデル化されることに注意してください。2値フィールドに対する特定のoptype値は存在しません

順序と連続フィールドはcyclicかもしれません。これらは、類似性や値の距離がcyclicな特性に依存するクラスタリングモデルに使用されます。cyclic順序フィールドに対する「値」要素の列が、一つのcycleの最初と最後の値を定義します。cyclicな連続フィールドのための値範囲は、interval、もしくは「値」要素の列によって定義することが出来ます。フィールドが一つのintervalを持っている場合、確実に一つ存在しなければなりません。このintervalは、cycleの最初と最後の値のデフォルト値を定義します。そうでなければ、これらは「値」要素によって与えられた最小値と最大値です。

順序フィールドに対しての順序付けは、カテゴリー要素の列によって指定されます。 順序付けが、その要素で指定されないなら、表\記タイプ(文字列、日付、数など)上のデフォルトの順序も、マイニングモデル中のフィールド値の順序を定義します。モデルのあるクラス用のアプリケーションアルゴリズムが順序フィールドの任意の特定の扱いを要請しないならば、それらはcategoricalフィールドとして解釈することができます。


<!ELEMENT Value (Extension*) >

<!ATTLIST Value
	value 		CDATA 			#REQUIRED
	displayValue 	CDATA 			#IMPLIED
	property 	(valid | invalid | missing ) "valid"
>

categoricalもしくは順序フィールドが、プロパティの値が妥当かもしくは未指定である値要素を、少なくとも一つ含んでいるのならば、値要素の集合は有効な値の集合を完全に定義します。そうでなければ、どんな値もデフォルトによって有効です。

要素Intervalは 数(numeric)の値の範囲を定義します。


<!ELEMENT Interval EMPTY>

<!ATTLIST Interval
	closure 	(openClosed|openOpen|
			 closedOpen|closedClosed) 	#REQUIRED
	leftMargin 	%NUMBER; 			#IMPLIED
	rightMargin 	%NUMBER; 			#IMPLIED
>

属性leftMarginおよびrightMarginはオプションです。しかし、少なくとも1つの値が定義される。マージンが見当たらないならば、それぞれ正もしくは負の無限が仮定されます。

適合

順序フィールドの、およびcyclicな値範囲のサポートは、PMMLのコアな必要条件ではありません。欠損値や無効値、値範囲の詳細なサポートもPMMLのコアの範疇ではありません。「DataField」の内容を参照。

Header Information

2003年7月 2日 13:44


<!ELEMENT Header(Application?,Annotation*,Timestamp?)>
<!ATTLIST Header
	copyright 	CDATA 			#REQUIRED
	description 	CDATA 			#IMPLIED
>
<!ELEMENT Application (EMPTY)>
<!ATTLIST Application
	name 		CDATA 			#REQUIRED
	version 	CDATA 			#IMPLIED
>
<!ELEMENT Annotation (#PCDATA)>
<!ELEMENT Timestamp (#PCDATA)>

Header:ヘッダー情報の始まりを示すトップのレベル・タグ。

copyright:この属性は、このモデルの著作権に関する情報を含んでいます。

description:この属性は、モデルに関しての非特異的な記述を含んでいます。さらなるアプリケーションでこのモデルを使うために必要な情報を含むべきではあるが、そのアプリケーションにおける、要素、注釈、データディクショナリなどをより詳しく定義するための情報を含む必要はない。この属性は、単なる人間の判読可能\な情報を含んでいるべきです。

Application:この要素は、モデルを生成したソ\フトウェア・アプリケーションについて記述します。PMMLモデルは移植可能\な形で生成されるべきですが、メカニズムが異なれば、同じデータ集合から異なるモデルを作成するかもしれません。それは、それらのモデルを生成したアプリケーションのユーザーにとっては関心のあることです。

name:モデルを生成したアプリケーションの名前。

version:このモデルを生成したアプリケーションのバージョン。

Annotation:ドキュメント修正履歴はここに埋め込まれます。各注釈は自由なテキストです、そして、ヘッダー要素中のdescription属性のように、人間が読む場合にのみ意味をなします。例えば、ユーザは自分の発言を格納することができます。

<Annotation x-author="John Doe">This is a churn model for 1999 customers who ... </Annotation>

Timestamp:この要素はモデル生成タイムスタンプを許可します。

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"> 

PMML日本語化ページ更新履歴

2003年7月 2日 13:40

2003.7.2 サイト開設
2003.7.3 舟橋翻訳分UP、General Structure、Header、Data Dictionary
2003.7.4 舟橋翻訳分UP、Mining Schema、Data flow、Transformation Dictionary & Derived Value
2003.7.5 舟橋翻訳分UP、 Statistics、PMML Conformance、Taxonomies and Hierarchies、Trees、 Regression
2003.7.6 舟橋翻訳分UP、General Regression、Cluster Models、Association Rules、Neural Network、Naive Bayes Models、Sequence Rules
これで一応通しの翻訳作業は終了。 後は修正や、未定の訳語の修正。
2003.7.7 PMML対応製品の一覧をアップ。にわか調査なので、おそらく不十\分。
2003.11.16 言語交流研究所 小松氏 指摘修正UP、General Structure、Header
2003.11.18 言語交流研究所 小松氏 指摘修正UP、Data Dictionary、Mining Schema、Data flow、Transformation Dictionary & Derived Value、 Statistics、PMML Conformance
2003.11.19 言語交流研究所 小松氏 指摘修正UP、Trees、Neural Network
  業務に使うので、ツリーとニューラルネットを優先的に修正
2003.11.21 言語交流研究所 小松氏 指摘修正UP、Regression、General Regression、Cluster Models
2003.11.28 言語交流研究所 小松氏 指摘修正UP、Association Rules、Naive Bayes Models、Sequence Rules
小松氏指摘分の通しの修正は完了。他の方の修正指摘を募集中。 2011.12.29 株式会社アイリンク運営BLOG内に移設。

PMML日本語化

2003年7月 2日 13:26

はじめに

PMMLはDataMiningGroup(DMG:http://www.dmg.org/)が策定している、データマイニングのためのXMLです。どうもWeb上に、日本語のPMMLの仕様書が見当たらないので、仕事上の必要性もあって、翻訳をやろうと思いたちました。
そこでDMGへメールしたところ、是非やりなさいというお返事を頂けたので、翻訳を開始しました。
つたない英語力で作成しているので、今一つおかしな文章ですが、皆様の叱咤激励で、より良いPMMLの日本語仕様書に仕上げるように努力しますので、ご協力のほどよろしくお願いします。

翻訳に関しての、ご意見等は funahasi@funahasi.com へお願いします。


PMMLバージョン2.0

予測(Predictive)モデル・マークアップ言語(PMML)は、アプリケーションにおける統計とデータ・マイニングモデルを定義し、かつPMMLに準じたアプリケーション間のモデルを共有する方法を提供するXMLの―基づいた言語です。

PMMLは、アプリケーション固有の問題や非互換性が、アプリケーション間のモデルの交換において、もはや障壁とならないような、ベンダーに依存しないモデルを定義する方法をアプリケーションに提供します。 それによって、ユーザはあるベンダーのアプリケーションの範疇においてモデルを開発し、さらに、他のベンダーのアプリケーションを用いてモデルを視覚化、分析、評価などを行うことという事が可能となる。以前は、こうしたやり方を取ることは非常に困難でした。しかし、PMMLを用いて、それに準じたアプリケーション間のモデルの交換は、簡単に行えるようになりました。 PMMLはXMLに基づいた標準ですので、詳細はXMLドキュメントタイプ定義(DTD)の形をしています。

PMML 2.0 Specification
PMML 2.0 のXML、DTD
PMML対応製品
PMML日本語化ページ更新履歴

PMML日本語化ページエントリー一覧

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

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

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