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

2003年7月のアーカイブ

Mining Schema

2003年7月 3日 13:51

各々のモデルは、そのモデルの中で使用されるようなフィールドをリストする、1つのマイニングスキーマを含んでいます。これはデータ・ディクショナリーで定義されるようなフィールドの部分集合です。マイニングスキーマがあるモデルを特定する情報を含んでいる一方、データ・ディクショナリーはモデルによって変わらないデータ定義を含んでいます。マイニングスキーマの主な目的はモデルを適用するためにユーザが与えなければならないフィールドをリストすることです。


<!ENTITY % FIELD-USAGE-TYPE "(active |
				predicted |
				supplementary)" >

<!ENTITY % OUTLIER-TREATMENT-METHOD "( asIs |
					asMissingValues |
					asExtremeValues ) " >

<!ENTITY % MISSING-VALUE-TREATMENT-METHOD "(asIs | asMean |
						asMode | asMedian |
						asValue) " >

<!ELEMENT MiningField (Extension*)>
<!ATTLIST MiningField
	name 			%FIELD-NAME; 			#REQUIRED
	usageType 		%FIELD-USAGE-TYPE; 		"active"
	outliers 		%OUTLIER-TREATMENT-METHOD;	"asIs"
	lowValue 		%NUMBER; 			#IMPLIED
	highValue 		%NUMBER; 			#IMPLIED
	missingValueReplacement	CDATA 				#IMPLIED 
	missingValueTreatment 	%MISSING-VALUE-TREATMENT-METHOD; #IMPLIED 

<!ELEMENT MiningSchema (MiningField+) >

usageType

active:入力として使用されるフィールド(独立したフィールド)。

predicted:その値がモデルによって予\測されるフィールド。

supplementary: 付加的で記述的な情報を保持するフィールド。

Supplementaryフィールドはモデルを適用するためには要求されません。しかしながら、それらは説明の目的のための付加情報として与えられます。モデルが構\築される前に、あるフィールドが、予\備処理のtransformationを詳細に調べる時に、付加的なSupplementaryフィールドは典型的には、オリジナルのフィールド値に対する統計についての記述のために使用されます。

outliers

asIs:フィールド値をそのものとして扱う。

asMissingValues:outlier値を欠損値と同じように扱う。

asExtremeValues:outlier値は、MiningFieldに定義された特定の高い値もしくは低い値に変更されます。

name:フィールドのsymbolic name。データ・ディクショナリー中のフィールドを参照しなければなりません。

highValuelowValue: %outlierTreatmentMethodと共に使用されます;このフィールドでのoutliersをもつレコードに対する値としての「asExtremeValues」。 x < lowValue ならば x=lowValue。

missingValueReplacement:この属性がそのとき指定される場合、欠損している入力値は与えられた値と自動的に置き換えられます。すなわち、モデルそれ自身は、あたかも与えられた値が初めの入力で含まれていたかのように働きます。例えば、MiningFieldが置き換えた値を指定するなら、TreeModelの中の代理演算子(surrogate operator)は適用されません。

missingValueTreatment:PMML利用者にとって、このフィールドは「情報だけのため」のものです。利用者はmissingValueReplacementだけを見ます。値が存在する場合、それは欠損値に置き換えます。missingValueTreatment属性は、missingValueReplacementがどのように導かれ、利用者に何も作業要求を課さないという事を指し示すだけである。

欠損値の詳細はPMMLの中に数箇所現れます。

1.欠損値の外部表\現は、PMMLによって直接的には定義されません。PMML利用者のシステムは、データ・ベース中のnull値として、あるいはファイル中のブランクの文字列、等々として、それらを含意しているでしょう。

2.PMMLデータ・ディクショナリーは、欠損値を示す値のオプションのリストを考慮に入れます。例えば、データソ\ースは文字列「-」もしくは「NA」を使用することもあるでしょう。もし、そのような値が入力データ中に現れたなら、PMML利用者は欠損値としてそれを扱わなければなりません。

3.モデル内のPMMLマイニングスキーマは選択的(optional)に置き換えられた値を定義するかもしれません。入力値が欠損しているなら、PMML利用者はそれを指定された値に置き換えなければなりません。

4.PMMLモデルの各々のタイプに対して、欠損値をスコア結果の計算の中で扱う特定の手法が存在します。

適合

outlier処理「asIs」(すなわち、MiningFieldの中の属性outlierのデフォルト価)は、非常に重要である。他のオプションはさほど重要ではない。

地域情報化必敗の陣、地域商店街EC

2003年7月 2日 23:30

最近良い事例の話ばかりなので、たまには、「ど勘違い」してる悪い例の話もしてみようかなと思ったりもします。こういう場合実名トークしちゃうと、訴えられたりして怖いので匿名で行くことにします。(私は臆病者ですんで-笑)
北海道のT市では、市と大学が一丸となってある地域情報化プロジェクトが動いているんです。それはどういうものかというと、「商店街によるオンラインショップ(バーチャルモール)&決済としての地域通貨」。なんかすごそうだけど、そのままやったら普通に失敗すること請け合い。
なぜって?それをすこしづつ解説しましょう。

1.特産品ECと商店街ECは根本的に違う

商店街が「観光客専用」みたいなところは、「商店街=特産品販売所」なので、バシバシとオンラインショップしましょう。こういう場合は本質的に「特産品EC=商店街EC」なので、普通のネットビジネスのノウハウで、普通に成功できることでしょう(それはそれで大変なんだけど)。でも、それって地域情報化とは関係ないですよね。
一般に地域の商店街には、特産品はそれほど売っていない。それは当然。商店街は、あくまで商活動を通じて地域住民の物的ニーズやサービスニーズを満たすもの。人間活動の衣食住において地域差はそれ程ない。商店街に求められるものは、商圏住民が直接その場に行って、商圏住民の衣食住を満たすことだけ。それであれば、オンラインショップに、いくら決済があっても、取りおきサービスがあっても、配送サービスがあっても、それ程嬉しくはない。むしろ営業時間の延長とかの方が重要ということになる。

2.オンラインショッピングの本質って

オンラインショップで勝ち組になる要件は結構シンプル。「オンリーワンショップ」か「ワンストップショッピング」。オンリーワンなら、どうにかこうにか生きていけるし、ワンストップなら誰よりも大量のアイテムを揃え、どこよりも安く売り、欲するものをリコメンドし続ければ勝てる。
商店街は個々の店舗を連合させることで、本質的に日常的な地域のワンストップショッピングを目指している。ある種オンリーワンショップである特産品と根底から違う部分だ。ネット上では、ワンストップ型の大型オンラインショッピングは上位数社しか生き残りが不可能であることはすでに常識になっている。また、品揃え数と売価勝負という部分も大きく、小資本ではとても立ち行かない。この辺は、リアルの世界の大型スーパーと商店街の争いと同じである。現時点で、ワンストップ型のオンラインショップであれば国内では楽天、Yahoo!ショップ、GAZOOなど大資本によるし烈な争いが繰り広げられ弱小自治体が入る余地などないのが現状だ。言い換えるなら、T市商店街が6兆円という巨大なキャッシュフローを持つトヨタに挑戦状を突き付けるようなもの(まぁ、どっちも同じTだけど)。普通に考えたらかなりのドンキホーテだ。

3.仮に成功しても・・・

仮にこのような商店街ECが成功したとしよう。それはそれで不気味な光景が待っている。地域の人間も大多数が商店街オンラインで商品を購入してしまうので、商店街そのものに行く必要はなくなってしまう。
で、商店街はどうなっちゃうかというと、大量の商品を入れてあるだけの倉庫。配送センター。これって商店街を軸にした地域情報化なのかな?地域活性化なのかな?
まさに空洞化した商店街。商店街「オンラインショッピング」と考えれば、こうなっちゃっても成功なんだろうけど、商店街という一つの地域の活性化という視点でみれば、もはや商店街じゃない。
こんな、勝ち目がないばかりか、勝っても首をかしげる状態が待っているオンラインショッピングを地域情報化のためにやってどうするんだろうか。

4.地域通貨は外貨じゃない

おまけに、地域通貨をこの手の決済に絡めてどうするんだろうか?オンラインショッピングが成功したとして、T市の人口なんて高が知れるんだから、お客の大半はT市の外にいるということになる。
となると-個人的に、地域通貨に懐疑的という事もあるけど-外から入ってくるお金に「うちの地域の通貨をつかえ」というのは、どうかと思う。
例えばAmazon.comで洋書を買うと、「ドルという名の欧米地域の通貨に変換されて損をするのでめんどくさい」という気分になってしまう。だから、洋書を買う時には、Amazon.co.jpで買う。が、実際にはカード決済は便利なもので、円ドルを変換して、売買してくれるのでまだいい。
地域外の人のために、これと同等の仕掛でも用意するんだろうか?
そのコストを差っぴいても良い!というほどのお金持ちじゃないと思うぞ。T市も、日本国も。

と、見ても分かるように、このような商店街ECは論理的に成功しようもないし、成功しても何とも判断しがたい状態しか迎えない試みである。まさに愚の骨頂だ。それでも、「やらないよりやったほうがマシだ」という議論もあるだろうが、もっというと、これを道民なり国民の税金というものでやろうというんだから、かなり良い根性だ。やったほうがマシというなら、T市の自前の財源で勝手にやってくれといいたい。

商店街でやるなら

でも、地域の活性化につながるような、商店街のIT化というのが不可能かというと、そうでもないと思う。というか、そういうまっとうな取り組みのほうが全国には多いと思う。

地域情報ポータルの視点を取りいれるのが一つ。いわば、○○商店街という名の一つの地域として捉えるのだ。エリア内での人の動きを活性化させ、商店街にお金を落とす機会を増やすのである。東京の「ささはたドットコム」はその好例である。しかし、これは東京の商店街ならではという側面は否めない。地域情報ポータルの運営コストを考えると「0563.net」の例では、商圏人口に10万人が必要だそうだ。これはひとつの商店街だけでは無理な商圏人口といえる。

もう一つの手段として、ホットスポットというのも注目されている。商店街という直線エリアの特性を生かして、簡単な無線ターミナルで商店街全体を繋ぐというプランが各地で動き出している。非常にローコストで出来、組織的には既存の振興組合やNPO法人という形でインフラの永続的な維持もしやすい。ITによる商店街での来客の滞留を生み出す手法であると同時に、地域内のインフラ構築を通じた振興組合等の人的交流の再活性化という側面も持ち、地域活性化に寄与することも考えられる。とはいえ、IT人口の少ない田舎だとこれでもつらかったりする。

後は携帯メールを活用した形での商店街への来客誘因は非常にポピュラーな手段だ。一定の効果も見られている。ただ、これらに関しては数多くのASP等のローコストのサービスがあり、むしろこれはそういう民間企業のサービスを活用すべき。柔軟に地域の中と外のサービスや組織を組み合わせて、最適のソリューションを探すのも重要だ。

いずれにせよ、いくら商店街のIT化だからといって、商店街=沢山の商店の集まり→沢山のショップの集まり=バーチャルモールというだけでは、短絡的にもほどがあるでしょう。
地域情報化は簡単そうで難しいものです。■

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

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

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

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