1. ホーム
  2. のらマネージャーのブログ
  3. 2003年7月のアーカイブ

2003年7月のアーカイブ

Taxonomies and Hierarchies

2003年7月 4日 14:14

categoricalなフィールドの値は階層で組織化する(organized)ことができます。非常に身近な例は製品グループ、および市、郡、県、国のような地理的な階層です。階層も分類あるいは分類グラフとして知られています。

PMMLの中の階層の表\現は親/子供関係に基づきます。平板状(tabular)のフォーマットはこれらの関係にデータを供給するために使用されます。

分類は、1つ以上の親/子供テーブルのシーケンスから構\築されます。実価は外部テーブルに格納することができます。そのようなテーブルは、テーブル用の1種のURLをインプリメントするTableLocatorによって、参照されます。平板状のデータはさらにPMMLドキュメントそれ自身の一部でありえます。その場合では、要素InlineTableTableLocatorの代わりに使用されます。以下に、私たちはこれらのテーブル参照の例を示しましょう。しかしながら、内容の実際の定義はPMMLの範囲の外にあります。XMLの中のデータ・ベース・テーブルの表\現に対処する他の標準は、今後利用可能\になる予\定です。PMMLの中の現在の定義は、もっと今後、改良されるフレームワークであるように意図されます。


<!ELEMENT Taxonomy ( ChildParent+ ) >
<!ATTLIST Taxonomy
	name 			CDATA 		#REQUIRED
>

<!ENTITY % TABLE "( TableLocator | InlineTable ) " >


<!ELEMENT ChildParent ( %TABLE; ) >
<!ATTLIST ChildParent
	childField 		CDATA 		#REQUIRED
	parentField 		CDATA 		#REQUIRED
	parentLevelField 	CDATA 		#IMPLIED
	isRecursive 		(no | yes) 	"no"
>

<!ELEMENT TableLocator (Extension*) >
<!ELEMENT InlineTable (Extension*) >

属性記述(Attribute Description)

childField:レコード毎に子値(child value)を含んでいるフィールド名を定義します。

parentField:レコード毎に親値(parent value)を含んでいるフィールド名を定義します。

parentLevelField:親のレベル数を含んでいるフィールド名を定義します。最低のレベルの子は通常レベル0メンバーと呼ばれます。すなわち、親のレベル数は1でスタートします。レベルが子供/親データそれ自身から導出されうるので、parentLevelFieldはオプションです。

isRecursive:再帰的(recursive)なテーブルは1つのテーブルに完全な分類を定義することができます。すなわち、親フィールドでの値も子フィールドの中で使用することができます。

TableLocatorは、アプリケーションがあるテーブルを見つけるのを助けるすべての記述を含んでいるでしょう。PMML 2.0はまだ内容を定義しません。PMMLユーザは自分の拡張を使用しなければなりません。同じことはInlineTableなことに当てはまります。


:

ZIP code、Cityおよびstatesを持った階層を以下のように定義してみましょう。


<Taxonomy name="ZIP-City-State">

<ChildParent childColumn="ZIP code" parentColumn="City">
	<TableLocator x-dbname="myDB" x-tableName="ZIP_City" />
</ChildParent>

<ChildParent childColumn="cities" parentColumn="states">
	<TableLocator x-dbname="myDB" x-tableName="Cities_States" />
</ChildParent>

<ChildParent childColumn="State" parentColumn="Country">
	<TableLocator x-dbname="myDB" x-tableName="AllStates" />
</ChildParent>

</Taxonomy>

実際のデータは、ロケータによって与えられるような名前を備えたテーブルに存在するだろう。

ZIP_City | ZIP code    | City
===================================
         | CA 95126    | San Jose
         | CA 95020    | Gilroy
         | CA 90806    | Long Beach
         | IL 60463    | Oak Lawn
         | MA 02149    | Everett


Cities_States | cities     | states
===================================
              | San Jose   | CA
              | Gilroy     | CA
              | Long Beach | CA
              | Oak Lawn   | IL
              | Everett    | MA


AllStates | State | Country
===========================
          | CA    | USA
          | IL    | USA
          | MA    | USA

3つの異なるテーブルに子/親データを格納する必要がないことに注意してください。さらに、私たちは、statesのためのカラムを含めるためにテーブルZIP_Cityを拡張することができました。これは「City, State ZIP」を持つ典型的なアドレス・フォーマット(typical address format)に近いものになるでしょう。

階層は、2つのテーブルで以下のように表\わされうる:レベル0アイテムの1つのテーブル、それらの親、上位の要素/カテゴリーレベルの他のテーブル、それらの親用テーブル。後者のテーブルは、親カラムの値が子カラムにも現れるという意味で、再帰的でしょう。付加的な属性「isRecursive」は、ルートレベルまでの親/子供関係を定義するテーブルにフラグを立てることを意図しています。再帰的なテーブルがそのとき要素分類(Taxonomy)の内容に現われるなら、それはシーケンスの最後のテーブルでなければなりません。


TableLocatorInlineTable

要素TableLocatorInlineTableは、他の標準化グループがこれらの問題を手がけているので、まだ完全には定義されません。PMML 2.0のためのこれらの要素の予\備(preliminary)定義は次の例のようにすることが出来るでしょう。


<Taxonomy name="ZIP-City-State">

<ChildParent childColumn="ZIP code" parentColumn="City">
	<TableLocator x-dbname="myDB" x-tableName="ZIP_City" />
</ChildParent>

<ChildParent childColumn="member" parentColumn="group" isRecursive="yes" >
	<InlineTable><Extension extender="MySystem">
		<row member="San Jose" group="CA"/>
		<row member="Gilroy" group="CA"/>
		<row member="Long Beach" group="CA"/>
		<row member="Oak Lawn" group="IL"/>
		<row member="Everett" group="MA"/>
		<row member="CA" group="USA"/>
		<row member="IL" group="USA"/>
		<row member="MA" group="USA"/>
	</Extension></InlineTable>
</ChildParent>

</Taxonomy>

PMML Conformance

2003年7月 4日 14:01

PMMLドキュメント妥当性

PMMLは分析的なモデルのtrainedな実例を示すXMLドキュメントのための標準です。モデルの次のクラスが名づけられています:

・Association Rules(連想規則)
・Decision Trees(決定木)
・Center-Based & Distribution-Based クラスタリング
・Regression(回帰)
・General Regression(一般的回帰)
・Neural Networks(ニューラル・ネットワーク)
・Naive Bayes(ナイーブベイズ)
・Sequences(シーケンス)

付加的な属性や要素タイプを内的なDTDで定義できる参照DTD(http://www.dmg.org/v2-0/pmml_v2_0.dtdで見出される)と比してXMLドキュメントが妥当であり、かつ、http://www.dmg.org/v2-0/で見出されるモデルの詳細において表\記される制限にしたがっているのであれば、そのXMLドキュメントは妥当なPMML 2.0である。モデルの詳細は、DTDの内では含意されない様々な制限を定義します。例は次のとおりです:

「%FIELD-NAMEの値;データ・ディクショナリー中の、あるいはtransformation dictionary中のフィールドを参照しなければならない。」

あるいは

「DataFieldに高々2つのinterval要素が存在するだけなければならない」

PMML適合

PMMLは、様々なツールによって生み出された分析的なモデルのアプリケーション移植、共有および再利用を可能\にすることを意図しています。適合は、それゆえ、製造者および利用者の両方の観点から指定されるべきである。アプリケーションは、それらが利用することができる分析的なモデルの種類を指定する方法を必要とする。そして、モデリングツールは、それらが生み出す分析的なモデルの種類を指定する方法を必要とする。PMMLドキュメントはtrainedな分析的なモデルを指定するモデリング・ツールによって生成されるもので、そのモデルを展開させるためにアプリケーションが利用するものです。製造者適合規則(conformance rules)を満たすことは、モデル定義ドキュメントが文法的に正しいことを保障し、実際に、モデルの詳細で定義される意味論的基準と整合しているモデル実例を定義することを保証します。利用者適合規則を満たすことは、そのようなモデルが妥当な方法で適用されるだろうということを保証します。

製造者適合(Producer Conformance)

あるツール、もしくはアプリケーションが、モデルの少なくとも一つのタイプのPMMLドキュメントを生成するなら、それは製造者適合をしている。製造者適合ステートメントは、このやり方でサポートされるモデルのどれかのタイプを含んでいなければならない。製造者適合は、データマイニング ツール/アプリケーション ベンダーとユーザーとアプリケーションが供給する種類のモデルを定義するPMMLドキュメントがインテグレート可能\で利用可能\であると主張するアプリケーション供給者の間の「契約」である。

利用者適合(Consumer Conformance)

アプリケーションが、モデルの少なくとも一つのタイプの妥当なPMMLドキュメントを受け入れるならば、それは利用者適合をしている。利用者適合ステートメントは、どのタイプのモデルが受け入れられるかを指し示していなければならない。アプリケーション適合はアプリケーション供給者とユーザー、それらのタイプのモデルを定義するPMMLドキュメントがインテグレート可能\で利用可能\であると主張するデーマイニング ツール/アプリケーション ベンダーの間の「契約」である。アプリケーションが多項式回帰モデル(Polynomial-Regression-model)タイプに対して利用者適合であるなら、異なる製造者によって生み出されたこのタイプのモデルを定義する妥当なPMMLドキュメントが、そのアプリケーションにおいて交換可能\であるだろう。

核および非核特徴(Core and Non-Core Features)

モデルの与えられたクラスに対して、対応するDTDおよび詳細が、すべての適合手続きと利用者がサポートしなければならない核となる特徴を識別し、オプションとしてサポートされるであろう非核な特徴を識別します。

Statistics

2003年7月 4日 13:58

統計に対するこのDTDのサブセット化は、1変数統計を表\わすために基礎的なフレームワークを提供します。それは、ModelStatsとして特定のモデルに対して、DTDによって使用されます。


<!ELEMENT ModelStats ( Extension*, UnivariateStats+ ) >

モデルに対する統計は、単一のフィールドに対する統計の集まり(collection)からなります。

一変数統計


<!ENTITY % AGGREGATE "(Counts?, NumericInfo?)" >

<!ELEMENT UnivariateStats ( Extension*, (%AGGREGATE;)?, 
			DiscrStats?, ContStats? ) >
<!ATTLIST UnivariateStats 
	field 		%FIELD-NAME; 		#IMPLIED 
>

UnivariateStats要素は、一つのマイニングフィールドについての統計情報を含んでいます。ModelStatsの中のUnivariateStats要素はフィールド名を持たなければなりません。他の場合、属性「field」が見当たらないかもしれません。離散的な統計と連続的な統計が、数値のフィールドに対して同時に可能\です。数値のフィールドがあまりにも多くの離散値を持っている場合、この事は重要かもしれません。統計は最も頻度の高い値(the most frequent values)およびさらに完全なヒストグラム分配(complete histogram distribution)を含むことができます。

順序フィールドの統計はDiscrStatsに含まれています。


<!ELEMENT Counts EMPTY>
<!ATTLIST Counts
	totalFreq 	%NUMBER; 	#REQUIRED
	missingFreq 	%NUMBER; 	#IMPLIED
	invalidFreq 	%NUMBER; 	#IMPLIED
>

要素Countsは、欠損か、無効か、有効であるのそれらの状態に関しての値の頻度のためのカウンターを実行します。

totalFreqはレコードをすべて数えます。すべてのマイニングフィールドの統計に対するものと同じである。missingFreqは、値が欠損しているレコードを数えます。invalidFreqは有効ではなかった値のレコードを数えます。全頻度(total frequency)は、欠損値と無効値を含んでいます。


<!ELEMENT NumericInfo (Quantile*) >
<!ATTLIST NumericInfo
	minimum 		%NUMBER; 	#IMPLIED
	maximum 		%NUMBER; 	#IMPLIED
	mean 			%NUMBER; 	#IMPLIED
	standardDeviation 	%NUMBER; 	#IMPLIED
	median 			%NUMBER; 	#IMPLIED
	interQuartileRange 	%NUMBER; 	#IMPLIED
>

値のために、中間(mean)最小(minimum)最大(maximum)および標準偏差(standardDeviation)は普通に定義されます。中央値(median)は50%の四分位点として計算されます。interQuartileRangeは(75%quantile-25%quantile)として、計算されます。


<!ELEMENT Quantile EMPTY>
<!ATTLIST Quantile
	quantileLimit 	%PERCENTAGE-NUMBER; 	#REQUIRED
	quantileValue 	%NUMBER; 		#REQUIRED
>

quantileLimitは0と100の間のパーセンテージの数です。quantileValueはフィールド値のドメインに対応する値です。


<!ELEMENT DiscrStats ( Extension*, (%STRING-ARRAY;)?, (%INT-ARRAY;)? ) >
<!ATTLIST DiscrStats
	modalValue 		CDATA 		#IMPLIED
>

modalValueは最も頻度の高い離散値(most frequent discrete value)です。INT-ARRAYは、すべての頻度数(frequency numbers)のコンパクトな表\現を含んでいます。もし、文字列値の配列があるなら、INT-ARRAYの中の頻度数はそれそれの文字列値に対応します。そうでなければ、頻度数は、DataDictionaryの中で与えられるような(有効な)値のリストに対応します。統計がDerivedFieldを参照するなら、DerivedFieldが有効な値のリストを指定する手段を持たないので、値はすべてSTRING-ARRAYにリストされます。DiscrStatsが文字列値の配列を含んでおり、対応するDataFieldが、有効な値のリストを定義するなら、両方の集合は同じである。


<!ELEMENT ContStats ( Extension*, Interval*,
			(%INT-ARRAY;)?, 
			(%NUM-ARRAY;)?, (%NUM-ARRAY;)? )>
<!ATTLIST ContStats
	totalValuesSum 		%NUMBER; 	#IMPLIED
	totalSquaresSum 	%NUMBER; 	#IMPLIED
>

3つのARRAYは頻度、値の合計、および各々のintervalに対して2乗された値の合計を含んでいます。

注:intervalはDataDictionaryのためのDTDで定義されます。

例えば、分割(Partition)は、レコードの部分集合の統計を含んでいます。たとえば、クラスタ中の集団(population)を記述することができます。


<!ELEMENT Partition (PartitionFieldStats+) >
<!ATTLIST Partition
	name 		CDATA 		#REQUIRED
	size 		%NUMBER; 	#IMPLIED
>

名前(name)は分割(partition)を識別します。サイズ(size)はレコードの数です、PartitionFieldStatsの中のAGGREGATEはすべては、total - frequency = sizeを持っていなければなりません。


<!ELEMENT PartitionFieldStats ( (%AGGREGATE;), (%NUM-ARRAY;)* ) >
<!ATTLIST PartitionFieldStats
	field 		%FIELD-NAME; 		#REQUIRED
>

fieldは、バックグラウンド統計用のMiningField(の名前)を参照する。NUM-ARRAYのシーケンスはContStatsに対するのと同じ物です。categoricalなフィールド対しては、頻度数を含むただ一つの配列が存在します。数値のフィールドに対しては、第2および第3の配列が、値の和および2乗和をそれぞれ含んでいます。各配列中の値の数は、フィールドのUnivariateStatsの中のカテゴリーの数、もしくはintervalの数と一致しなければなりません。

TransformationDictionary & DerivedValue

2003年7月 3日 13:55

様々な場面で、マイニングモデルは、ユーザーのデータを特定のモデルの中で扱い易い値へと写像するための、単純な関数を使います。例えば、ニューラル・ネットは、内部的には、通常0から1までの範囲にある数を取り扱います。数値の入力データは範囲[0..1]に写像されます、また、categorical なフィールドは一連の0/1のindicatorsに写像されます。同様に、Naive Bayesモデルは、categoricalな値へと入力データすべてを内部的に写像します。

PMMLは、様々な種類の単純なデータの変換を定義します:

Normalization(正規化):値を数へと写像する。その入力値は連続値も離散値も取り得る。

Discretization(離散化):連続値を離散値に写像する。

Value mapping(値写像):離散値を離散値に写像する。

Aggregation(集合?):値を要約したり集めたりする。例えば、平均の計算。

対応するXML要素は、様々な写像に共通の要素を与えるsurroundingなマークアップDerivedFieldの内容として現われます。さらに、それらは、いくつかの場面では、ニューラル・ネットかNaive Bayesモデルのような特定のモデルの定義の中に現われることがあります。変換されたフィールドは、統計やモデルがこれらのフィールドを参照できるように名前を持っています、

PMMLの中のtransformationsは、マイニングのためのデータを集めて準備するために必要な予\備処理をする関数の全集合をカバーしません。あまりにも多くの予\備処理の表\記が存在します。その代わりに、PMMLtransformationsは、マイニングシステムによって自動的に作成される表\現を持ちます。典型的な例はニューラル・ネット中の入力値の正規化です。同様に、離散化は、偏りのあるデータを変換するために四分位範囲を計算するマイニングシステムシステムによって構\成されうる。


<!ELEMENT TransformationDictionary ( Extension*, DerivedField* ) >

<!ENTITY % EXPRESSION "( Constant | FieldRef | 
			NormContinuous | NormDiscrete | 
			Discretize | 
			MapValues | 
			Aggregate)" >

<!ELEMENT DerivedField (Extension*, %EXPRESSION; )>
<!ATTLIST DerivedField
	name 		%FIELD-NAME; 	#IMPLIED
	displayName 	CDATA 		#IMPLIED
>

DataDictionaryの中のDataFieldに加えTransformationDictionaryの中のDerivedFieldは、一意な名前を持っていなければなりません。

定数値および他のフィールドへの参照は、多数の議論(arguments)を行っている表\現の中で使用することができます。フィールドの参照は、正規化されないフィールドに対する中心座標を定義するために、クラスタリングモデルで使用されます。DerivedFieldがTransformationDictionaryに含まれている場合、名前属性が要求されます。モデル中にinlineに含まれるDerivedFieldsに対して、名前はオプションとなります。


<!ELEMENT Constant ( Value ) >

<!ELEMENT FieldRef >
<!ATTLIST FieldRef
	field 		%FIELD-NAME; 		#REQUIRED
>

正規化 (Normalization)

正規化のための要素は入力値を、特定の値(たいていは数値幅[0 .. 1]の)へと写像するための基礎的なフレームワークを与えます。正規化はニューラル・ネットの中で使用されます。同様の事例は回帰(regression)モデルの中でも使用されます。


<!ENTITY % NORM-INPUT "( NormContinuous | NormDiscrete )" >

<!ELEMENT NormContinuous ( Extension*, LinearNorm* ) >
<!ATTLIST NormContinuous
	field 		%FIELD-NAME; 		#REQUIRED
>

NormContinuous: piecewise linear interpolation(部分化線形補間)よって入力フィールドを正規化する方法を定義します。

field:データ・ディクショナリー中のフィールドを参照しなければなりません。LinearNormが欠損なら、入力フィールドは正規化されません。


<!ELEMENT LinearNorm EMPTY >
<!ATTLIST LinearNorm
	orig 		%NUMBER; 	#REQUIRED
	norm 		%NUMBER; 	#REQUIRED
>

LinearNorm*: stepwise linear interpolation(飛び石線形補間)関数に対する点の列を定義する。列は少なくとも2つの要素を含んでいなければならない。処理を単純化するために、列は、origの値を昇順にする(acending)ことによって、ソ\ートされなければなりません。NormContinous内に、要素LinearNormを元々の値を昇順にすることにより厳密にソ\ートしなければなりません。a1<a3<a2を満たす点(a3、b3)が存在しないような2点(a1,b1)、および(a2,b2)を与えると、正規化された値は以下のようになる。

b1+ ( x-a1)/(a2-a1)*(b2-b1) ただし a1 <= x <= a2.

欠損している入力値は、欠損した出力へと写像される。 入力値が範囲[a1..an]内に存在しない場合、それはoutlierとして扱われ、outlierを扱う特定の手法は、callerによって与えられなければならない。例えば、outlierは 欠損値へと写像することも、あるいは最小値もしくは最大値としてそれを写像することができるかもしれません。


<!ELEMENT NormDiscrete ( Extension* ) >
<!ATTLIST NormDiscrete
	field 		%FIELD-NAME; 			#REQUIRED
	method 		( indicator | thermometer ) 	#FIXED "indicator"
	value 		CDATA 				#REQUIRED
>

indicator methodで、要素(f,v)は、入力フィールドfの値がvならユニットは値1.0をもち、fの値がvではないならそのユニットは値0を持つという事を定義する。

ある入力フィールドを参照するNormDiscrete事例(instances)の集合は、単一の入力フィールドを正規化したフィールドの集合へと写像するfan-out関数を定義します。欠損している入力値は欠損した出力へと写像されます。

PMML 2.0は、1つの種類の離散値の正規化だけをサポートします。将来のバージョンは、thermometer encodingのような他の技術をサポートすることになるだろう。thermometer encodingは順序値に対し使用することができます。入力フィールドfの値がvより大きいか等しい場合、出力は1.0で、そうでなければ、それは0.0です。

離散化(Discretization)

数の入力フィールドの離散化はintervalから文字列への写像です。


<!ELEMENT Discretize (DiscretizeBin+) >
<!ATTLIST Discretize
	field 		%FIELD-NAME; 		#REQUIRED
>

<!ELEMENT DiscretizeBin (Interval) >
<!ATTLIST DiscretizeBin 
	binValue 	CDATA 			#REQUIRED
> 

2つのintervalは同じcategoricalな値へと写像されるが、個々の数の入力値の写像は一意でなければならない。つまり、intervalは離れていなければならないということだ。intervalは、入力値の全範囲をカバーするべきです。intervalがカバーしないある値が見出されたなら、それは、欠損値へと写像される。入力が欠損値であれば、結果も欠損値です。

以下のように定義すると:


<Discretize field="Profit">
	<DiscretizeBin binValue="negative">
		<Interval closure="openOpen" rightMargin="0" />
		<!-- left margin is -infinity by default -->
	</DiscretizeBin>
	<DiscretizeBin binValue="positive">
		<Interval closure="closedOpen" leftMargin="0" />
		<!-- right margin is +infinity by default -->
	</DiscretizeBin>
</Discretize>

入力としてフィールド「Profit」として、0未満の値を「negative」へと写像し、それ以外の値を「positive」へと写像する。

SQLでは、この定義が以下のCASE表\現に相当します。

CASE When "Profit" <0 THEN \'negative\' WHEN "Profit">=0 Then \'positive\' End

写像値(Map values)

任意の離散値は、値の対をリストすることによって、異なる任意の可能\な離散値へと写像されうる。このリストはテーブルによってインプリメントされます、したがって、それは、XMLマークアップのシーケンスによって、あるいは外部テーブルへの言及によって、inlineに与えらえれることができます。テーブルがquite largeになることができるので、同じ技術は階層に対して使われます。


<!ELEMENT MapValues (FieldColumnPair+, %TABLE; ) >
<!ATTLIST MapValues
	outputColumn 	CDATA 		#REQUIRED
	defaultValue 	CDATA 		#IMPLIED
>

<!ELEMENT FieldColumnPair () >
<!ATTLIST FieldColumnPair
	field 		%FIELD-NAME; 	#REQUIRED
	column 		CDATA 		#REQUIRED
> 

それぞれの文字列値は1つの値へと写像される事が出来ます。しかし、マッチングに使用されたテーブル・エントリーが一意でない場合、それはエラーになります。値写像は部分的かもしれません。つまり、入力値が写像テーブルの中で値と一致しないばあい、結果は欠損値です。もし、defaultValueがそのとき与えられているなら、テーブルの中に一致するエントリーをもたない入力価はデフォルト値に写像されます。入力が欠損値である場合、同じことになります。

以下のように定義すると:


<MapValues outputColumn="longForm">
	<FieldColumnPair field="gender" column="shortForm"/>
	<InlineTable><Extension>
		<row><shortForm>m</shortForm><longForm>male</longForm>
		</row>
		<row><shortForm>f</shortForm><longForm>female</longForm>
		</row>
	</Extension></InlineTable>
</MapValues>

フィールド「gender」から対応する完全な語句へと短縮的な写像をします。すなわち、「m」は「male」に、「f」は「female」に写像されます。

SQLでは、この定義が以下のCASE表\現に相当します。

CASE "gender" When \'m\' Then \'male\' When \'f\' Then \'female\' End

属性「defaultValue」は、Else SomeDefaultを加えることで含意されるでしょう。

集合(Aggregations)

Association rulesおよびシーケンスは、アイテムの集合を参照します。入力レコードの集合上のaggregationによって、これらの集合は定義されうる。 そのレコードはフィールドのうちの1つによって一まとめにされます。また、このグループ化したフィールドの値は、aggregationに対するレコードの集合を分割します。これは、「GROUP BY」節を使ったSQLの従来のaggregationに対応します。


<!ELEMENT Aggregate ( ) >
<!ATTLIST Aggregate
	field 		%FIELD-NAME; 		#REQUIRED
	function 	"count | sum | average |
			min | max| multiset " 	#REQUIRED
	groupField 	%FIELD-NAME; 		#IMPLIED
	sqlWhere 	CDATA 			#IMPLIED
>

以下のように定義すると:


<Aggregate field="item" function="multiset" groupField="transaction"/>

アイテム値の集合を構\築。各トランザクションに対して、つまり、フィールド「transaction」での各々の値について、アイテムの一つの集合が存在する。

適合

PMML利用者は、transformation dictionariesをサポートすることは要求されません。しかしながら、ニューラル・ネット・モデルおよびクラスタリングモデルは、タイプNormContinuousおよびタイプNormDiscreteの正規化要素を含んでいるだろう。Bayesモデルは、タイプDiscretizeの離散化要素を含んでいるだろう。もし、それらが、それぞれNeuralNetwork、ClusteringModel、あるいは、NaiveBayesModelの中に含まれているなら、利用者がそれらをサポートしなければならない。

Data flow

2003年7月 3日 13:53

PMMLは決定木分類、ニューラル・ネット、回帰などの様々な特定のマイニングモデルを定義します。等しく重要なことは、入力データそれ自身を記述し、モデル自身の評価以前に入力データに対して適応されうる一般的なtransformationを記述するために、すべてのモデルに共通の定義も存在するということである。 以下のリストは、データ定義、および対応するデータ・フローを含むデータtransformationを構\成要素として記述しています。

データ・ディクショナリーはデータを「あるがまま(as is)」として記述した生の入力データです。DataDictionaryはオリジナルのデータを参照し、どのようにマイニングモデルがデータを解釈するか(たとえば、categoricalとして、あるいは数量的なものとして)ということや、どのように有効値の幅が制限されるであろうかという事を定義します。

MiningSchemaは、PMMLモデルのユーザへのインターフェースを定義します。それは、マイニングモデルの中で計算の入力として使用されるすべてのフィールドをリストします。マイニングモデルは、その内部で、入力値に依存して導出された新たな値を、要求するかも知れません。しかし、それらの導出された値はMiningSchemaの部分ではない。 導出された値は、transformationブロックで定義されます。MiningSchemaは、さらにどの値がoutliersと関係するか、どの重み付けがあるフィールドに適応されるか(たとえばクラスタリングの場面で)という事も定義します。いくつかのモデルは「supplementary」フィールドを持っているでしょう。

・モデルのユーザが正規化をすることは要求されないので、MiningSchemaの中で指定される入力フィールドは、導出された(derived)フィールドではなくデータ・ディクショナリー中のフィールドを参照します。

transformationsの様々なタイプは、たとえば数の範囲[0..1]への正規化や、連続フィールドの離散化のように定義されます。それらのtransformationは元々の値を内部値へと、ネットワークモデルの入力ニューロンのようにマイニングモデルで要求される形で、変換します。

・PMMLモデルがtransformationsを含んでいる場合、ユーザは、これらの正規化を要求されません。MiningSchemaは、正規化されていないオリジナルの値を参照する入力フィールドをリストします。ユーザはモデルへの入力としてこれらのフィールドを提示します。

・PMMLの中のtransformationsは、マイニングの技術によって生み出された表\現(expressions)をカバーするように意図されます。完全なマイニングプロジェクトは、通常、手動で定義しなければならない多くの他の予\備処理ステップを必要とします。PMML 2.0は、これらすべての予\備処理に対しては完全な言語を与えません。これらのデータ準備ステップは、値をPMML利用者に与える前に実行されなければなりません。

・もし、PMMLドキュメントが複数のモデルを含んでいるなら、正規化の定義を共有することでドキュメントのスペースを節約することが出来ます。それは共通のデータ・ディクショナリーを持つという考え方と同じようなものです。忘れては行けないのは、正規化はモデル間で異なることもある。つまり、異なったモデルは、導出されたフィールドの異なる集合を参照する事もあるということです。

・正規化によって定義され、導出された値は別のtransformationのために入力することができます。例えば、ニューラル・ネット・モデルは指数変換された入力フィールド「income」で定義された線形の正規化を持つこともあります。

・決定木分類あるいはニューラル・ネットのようなモデルの特定の定義は、MiningSchemaにリストされたフィールド、あるいはMiningSchemaフィールド(transitive closureを含めた)から計算されうる、導出されたフィールドを参照するでしょう。

・統計および特定のモデルは、MiningSchemaの中のフィールドを参照することができますし、変換されたフィールドも参照できます。欠損値に対して定義され、置き換えられた値がある場合、欠損値が置き換えられる前に、統計はその値を参照します。

モデルの出力は、常に特定の種類のモデルに依存します、例えば、それは決定木中のleaveノードによって、あるいはニューラル・ネット中の出力ニューロンによって定義されます。予\測されたクラスや確率のような最終結果は、モデルの出力から計算されます。もし、ニューラル・ネットが数値を予\測することに対して使われるならば、ネットワークの出力値は通常、値の元々のドメインへ逆正規化(denormalization)する必要があります。幸運にも、この逆正規化は、同じ種類のtransformationタイプを使用することができます。PMML利用者システムは自動的に逆の写像を計算するでしょう。

tranformation dictionaryのフィールドがマイニングスキーマ中のフィールドからの入力に依存することに注意してください。PMMLモデルの静的構\造は動的なデータ・フローとは異なることができます。マイニングスキーマはモデルの一部です。しかし、tranformation dictionaryはモデルの外で共有される要素です。モデルのマイニングスキーマ中のすべてのフィールドもグローバルなデータ・ディクショナリーの中で表\わされるという素晴らしい性質を持ちます。すなわち、tranformation dictionary中の導出されたフィールドを解析するのに、特定の採鉱図表\中の情報は必要ではありません。導出されたフィールド内の入力は、常にデータ・ディクショナリー中の、あるいはtranformation dictionaryそれ自体の中のフィールドを参照します。

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

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

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