マルチパラダイムプログラミング言語を設計します。パート4-モデリング言語の基本的な構成

宣言的なスタイルとオブジェクト指向の機能的なスタイルを組み合わせたマルチパラダイムプログラミング言語の作成についての話を続けます。これは、半構造化データを操作し、異なるソースからのデータを統合するときに便利です。最後に、既存のマルチパラダイムテクノロジーと知識表現の言語の紹介とレビューの後、ドメインモデルの記述を担当するハイブリッド言語のその部分の記述に到達しました。私はそれをモデリングコンポーネントと名付けました。



モデリングコンポーネントは、オントロジーの形式でドメインモデルを宣言的に記述することを目的としています。これは、データインスタンス（ファクト）のネットワークと、関係を通じて相互接続された抽象的な概念です。これは、フレームロジック（知識表現へのオブジェクト指向アプローチと1次ロジックのハイブリッド）に基づいています。その主な要素は、一連の属性を使用してモデル化されたオブジェクトを記述する概念です。概念は他の概念または事実に基づいて構築され、最初の概念は親、派生、子と呼ばれます..。関係は、子と親の概念の属性の値をバインドするか、それらの可能な値を制限します。概念の定義に関係を含めて、可能であれば、それに関するすべての情報が1か所にまとめられるようにすることにしました。概念定義の構文スタイルはSQLに似ています。属性、親概念、およびそれらの間の関係は、異なるセクションに分割する必要があります。



この投稿では、概念を定義する主な方法を紹介したいと思います。



まず、親の概念を変換することによって構築される概念。

第二に、オブジェクト指向のスタイルは継承を意味します。つまり、親の概念の属性と関係を継承し、それらを拡張または縮小することによって概念を作成できるメカニズムが必要です。



第三に、メカニズムは、子と親の概念に分割することなく、ピアの概念間の関係を定義するのに役立つと思います。

次に、モデリングコンポーネントの主なタイプについて詳しく説明します。

事実から始めましょう

ファクトは、ドメインに関する特定の知識の説明を、名前付きのキーと値のペアのセットの形式で表します。

fact < > {
	< > : < >
	...	
}

例えば：

fact  product {
	name: “Cabernet Sauvignon”,
	type: “red wine”,
	country: “Chile”
}

ファクト名は一意ではない場合があります。たとえば、名前、タイプ、原産国が異なる製品が多数存在する場合があります。それらの名前とそれらの属性の名前と値が一致する場合、事実は同一であると見なされます。



モデリングコンポーネントのファクトとPrologのファクトの間に類似性を引き出すことができます。構文のみが異なります。Prologでは、ファクト引数はその位置によって識別され、モデリングコンポーネントのファクトの属性は名前によって識別されます。

コンセプト

概念は、抽象的なエンティティを説明する構造であり、他の概念や事実に基づいています。概念の定義には、名前、属性のリスト、および子の概念が含まれます。また、その（子概念）属性と親概念の属性の間の依存関係を記述する論理式により、子概念の属性の値を推測できます。

concept < > < > (
		< > = <>,
		...	
) 
from 
	<  > <  > (
		< > = <> 
	   	...
	 ),
            …
where < >

収益とコストに基づいて利益を 定義する例：

concept profit p (
	value = r.value – c.value,
	date
) from revenue r, cost c
where p.date = r.date = c.date

概念の定義はSQLクエリと形式が似ていますが、テーブル名の代わりに親概念の名前を指定する必要があり、返される列の代わりに子概念の属性を指定する必要があります。さらに、コンセプトには、他のコンセプトの定義やモデルクエリで参照できる名前があります。親の概念は、概念自体または事実のいずれかです。where句の関係式は、論理演算子、等式条件、算術演算子、関数呼び出しなどを含むことができるブール式です。それらの引数は、変数、定数、および親と子の両方の概念の属性への参照にすることができます。属性参照の形式は次のとおりです。

< >.< >

フレームロジックと比較して、概念の定義では、その構造（属性）は他の概念との関係（親概念および関係の表現）と組み合わされます。私の見解では、これにより、概念に関するすべての情報が1つの場所に収集されるため、コードをより理解しやすくすることができます。また、概念の実装の詳細がその定義内に隠されているという意味で、カプセル化の原則にも準拠しています。比較のために、フレームロジックの言語での小さな例が以前の出版物にあります。



関係の表現は結合形式（論理演算「AND」で接続された表現で構成されます）を持ち、子概念のすべての属性の値を決定するのに十分な等式条件を含める必要があります。さらに、親の概念の意味を制限したり、それらを相互に接続したりする条件を含めることができます。すべての親概念がwhere句で関連しているわけではない場合、推論エンジンは結果としてそれらの値のすべての可能な組み合わせを返します（SQLのFULL JOIN操作と同様）。



便宜上、属性が等しいための条件のいくつかは、子と親の概念の属性セクションに配置できます。たとえば、利益の定義では、属性の条件値は属性セクションに移動され、日付属性の場合はwhereセクションに残されます。fromセクションに転送することもできます：

concept profit p (
	value = r.value – c.value,
	date = r.date
) from revenue r, cost c (date = r.date)

この構文上の砂糖を使用すると、属性間の依存関係をより明確にし、他の条件と区別することができます。



コンセプトはPrologのルールに従いますが、セマンティクスが少し異なります。Prologは、論理的に関連するステートメントとそれらに対する質問の作成に焦点を当てています。概念は、主に入力データを構造化し、そこから情報を抽出することを目的としています。概念属性は、プロローグ用語の引数に対応します。ただし、Prologで引数という用語が変数を使用してバインドされている場合、この場合、属性には名前で直接アクセスできます。



親の概念のリストと関係の条件は別々のセクションに分かれているため、推論はPrologの推論とは少し異なります。そのアルゴリズムを一般的に説明します。親の概念は、fromセクションで指定された順序で出力されます。次の概念の解決策の検索は、SLD解決の場合と同じ方法で、前の概念の部分的な解決策ごとに実行されます。ただし、部分解ごとに、where句の関係式の有効性がチェックされます。..。この式は結合形式であるため、各部分式は個別にテストされます。部分式がfalseの場合、この部分的な解決策は拒否され、検索は次の解決策に進みます。一部の部分式引数がまだ定義されていない（値に関連付けられていない）場合、その検証は延期されます。部分式が等式演算子であり、その引数の1つだけが定義されている場合、推論システムはその値を見つけて、残りの引数と関連付けようとします。これは、自由引数が属性または変数である場合に可能です。



エンティティ表示するときにたとえば、利益の概念を、実体の収入のコンセプトとは、それに応じて、その属性の値が最初に発見されます。次に、等式p.date = r.date = c.datewhereセクションでは、日付属性やその他の概念を値に関連付けることができます。論理検索がコストの概念に到達すると、その日付属性の値はすでにわかっており、検索ツリーのこのブランチの入力引数になります。次の出版物の1つで、推論アルゴリズムについて詳しく説明する予定です。



Prologとの違いは、Prologルールではすべてが述語であり、他のルールや、同等性、比較などの組み込み述語を呼び出すことです。また、チェックの順序を明示的に指定する必要があります。たとえば、最初の2つのルールを実行し、次に変数の同等性を指定する必要があります。

profit(value,date) :- revenue(rValue, date), cost(cValue, date), value = rValue – cValue

この順番で実行されます。モデリングコンポーネントは、where句の条件のすべての計算が決定論的である、つまり、次の検索ブランチに再帰的に飛び込む必要がないことを前提としています。それらの計算はそれらの引数のみに依存するため、引数が値にバインドされているため、任意の順序で計算できます。



推論の結果として、子の概念のすべての属性を値に関連付ける必要があります。また、関係の式は真である必要があり、未定義の部分式が含まれていてはなりません。子育ての概念の導出が成功する必要はないことは注目に値します。ネガティブ操作などで、元のデータからの親概念の導出の失敗を確認する必要がある場合があります。fromセクションの親概念の順序によって、決定ツリーがトラバースされる順序が決まります。これにより、検索スペースをより強力に制限する概念から始めて、ソリューションの検索を最適化することができます。



論理的推論のタスクは、子の概念の属性の可能なすべての置換を見つけて、それらのそれぞれをオブジェクトとして表すことです。そのようなオブジェクトは、それらの概念名、名前、および属性値が一致する場合、同一であると見なされます。



同じ名前で、異なる属性のセットを含む異なる実装で、いくつかの概念を作成することは許容できると考えられています。これらは、同じ概念の異なるバージョン、1つの名前で便利に組み合わせることができる関連概念、異なるソースからの同一の概念などです。論理的な結論として、概念の既存の定義がすべて考慮され、それらの検索結果が組み合わされます。同じ名前のいくつかの概念は、用語のリストが分離形式（用語はOR化されている）を持つPrologのルールに類似しています。

概念の継承

概念間の最も一般的な関係の1つは、属種などの階層関係です。彼らの特徴は、子と親の概念の構造が非常に似ているということです。したがって、構文レベルでの継承メカニズムのサポートは非​​常に重要です。継承メカニズムがないと、プログラムは反復的なコードでいっぱいになります。概念のネットワークを構築するときは、それらの属性と関係の両方を再利用すると便利です。属性のリストはそれらのいくつかを拡張、短縮、または再定義するのは簡単ですが、関係の変更を伴う状況はより複雑です。これらは結合形式の論理式であるため、サブ式を簡単に追加できます。ただし、削除または変更すると、構文が大幅に複雑になる可能性があります。これの利点はそれほど明白ではありませんしたがって、このタスクは将来のために延期します。



次の構造を使用して、継承に基づいて概念を宣言できます。

concept < > < > is 
	<  > <  > ( 
		< > = <>, 
		...
	 ),
	...
with < > = <>, ...
without <  >, ...
where < >

is セクションには、継承された概念のリストが含まれています。それらの名前は、このセクションで直接指定できます。あるいは、親の概念の完全なリストを指定するから、セクション、およびである-継承されますのみそれらのの別名：

concept < > < > is 
	<  >,
	…
from 
	<  > <  > ( 
		< > = <> 
		   ...
	 ),
            …
with < > = <>, ...
without <  >, ...
where < >

セクションでは、あなたが継承された概念の属性のリストを展開またはそれらのいくつか、上書きすることができずにセクションを短縮します- 。 継承に基づく概念の推論アルゴリズムは、上記の概念の推論アルゴリズムと同じです。唯一の違いは、属性のリストが親の概念の属性のリストに基づいて自動的に生成され、関係の表現が子と親の概念の属性の同等性の操作で補足されることです。







継承メカニズムを使用するいくつかの例を考えてみましょう。継承を使用すると、既存の概念に基づいて概念を作成し、親だけに意味があり、子の概念には意味がない属性を取り除くことができます。たとえば、ソースデータがテーブルの形式で表示される場合、特定の列のセルに独自の名前を付けることができます（列番号で属性を削除します）。

concept revenue is tableCell without columnNum where columnNum = 2

いくつかの関連する概念を1つの一般化された形式に変換することも可能です。一部の属性を一般的な形式に変換し、不足している属性を追加するには、withセクションが必要です。たとえば、ソースデータはさまざまなバージョンのドキュメントであり、そのフィールドのリストは時間の経過とともに変化します。

concept resume is resumeV1 with skills = 'N/A'
concept resume is resumeV2 r with skills = r.coreSkills

「再開」の概念の最初のバージョンにはスキルを持つ属性がなく、2番目のバージョンには別の名前が付いていたとしましょう。



多くの場合、属性のリストを拡張する必要があります。一般的なタスクは、属性の形式の変更、既存の属性または外部データに機能的に依存する属性の追加などです。例えば：

concept price is basicPrice with valueUSD = valueEUR * getCurrentRate('USD', 'EUR')

構造を変更せずに、複数の概念を1つの名前で簡単に組み合わせることができます。たとえば、それらが同じ属であることを示すには、次のようにします。

concept webPageElement is webPageLink
concept webPageElement is webPageInput

または、エンティティの一部を除外して、コンセプトのサブセットを作成します。

concept exceptionalPerformer is employee where performanceEvaluationScore > 0.95

子コンセプトがすべての親コンセプトの属性を継承する複数の継承も可能です。同一の属性名がある場合は、リストの左側にある親の概念が優先されます。セクションで目的の属性を明示的にオーバーライドすることにより、この競合を手動で解決することもできますwith。たとえば、この種の継承は、1つの「フラット」構造にいくつかの関連する概念を収集する必要がある場合に便利です。

concept employeeInfo is employee e, department d where e.departmentId = d.id 

概念の構造を変更せずに継承すると、オブジェクトのIDの検証が複雑になります。例として、exceptionalPerformerの定義を考えてみましょう。親（employee）と子（exceptionPerformer）の概念に関するクエリは、同じ従業員エンティティを返します。それを表すオブジェクトは、意味が同じになります。それらは、クエリが行われたコンセプトに応じて、異なるコンセプト名に対して共通のデータソース、同じリストおよび属性値を持ちます。したがって、オブジェクト等式操作では、この機能を考慮に入れる必要があります。概念名は、構造を変更せずに一致するか、一時的な継承関係によってリンクされている場合、等しいと見なされます。



継承は、class-subclass、private-common、set-subsetなどの概念間の関係を明示的に表現するための便利なメカニズムです。また、概念定義内の重複コードを取り除き、コードをより理解しやすくします。継承メカニズムは、属性の追加/削除、1つの名前での複数の概念の組み合わせ、およびフィルタリング条件の追加に基づいています。特別なセマンティクスは組み込まれていません。誰もが好きなように認識して適用できます。たとえば、resume、price、webPageElementの概念を持つ例のように、特定の階層から一般的な階層を構築します。または、逆に、収益とexceptionPerformerの概念を持つ例のように、一般的なものから具体的なものへ..。これにより、データソースの詳細に柔軟に適応できます。

関係を説明するための概念

コードを理解し、モデリングコンポーネントとOOPモデルの統合を容易にするために、子の概念と親の関係をその定義に組み込む必要があることが決定されました。したがって、これらの関係は、親の概念から子の概念を取得する方法を定義します。ドメインモデルがレイヤーに組み込まれていて、新しいレイヤーがそれぞれ前のレイヤーに基づいている場合、これは正当化されます。ただし、場合によっては、概念間の関係を個別に宣言する必要があり、いずれかの概念の定義に含めないでください。これは、一般的な用語で定義し、さまざまな概念、たとえば親子関係に適用したい普遍的な関係にすることができます。または、2つの概念を接続する関係を両方の概念の定義に含める必要があります。これにより、最初の概念の本質と2番目の概念の既知の属性の両方を見つけることができ、その逆も可能です。次に、コードの重複を避けるために、リレーションを個別に設定すると便利です。



関係の定義では、関係に含まれる概念をリストし、それらを相互に接続する論理式を設定する必要があります。

relation < > 
between <  > <  > (
	< > = <>,
 	 ...	
),
...
where < >

たとえば、ネストされた長方形を記述する関係は、次のように定義できます。

relation insideSquareRelation between square inner, square outer 
where inner.xLeft > outer.xLeft and inner.xRight < outer.xRight 
and inner.yBottom > outer.yBottom and inner.yUp < outer.yUp

実際、このような関係は一般的な概念であり、その属性はネストされた概念の本質です。

concept insideSquare (
	inner = i
	outer = o												
) from square i, square o
where i.xLeft > o.xLeft and i.xRight < o.xRight 
and i.yBottom > o.yBottom and i.yUp < o.yUp

この関係は、他の親概念とともに概念定義で使用できます。関係に含まれる概念は、外部からアクセス可能であり、その属性の役割を果たします。属性名は、ネストされたコンセプトエイリアスと一致します。次の例では、HTMLフォームにHTMLページのフォーム内にあるHTML要素が含まれていることを示しています。

oncept htmlFormElement is e 
from htmlForm f, insideSquareRelation(inner = e, outer = f), htmlElement e

解決策を検索するとき、htmlFormコンセプトのすべての値が最初に検索され、次にそれらはリレーションinsideSquareの外側のネストされたコンセプトに関連付けられ、その内部属性の値が検索されます。最後に、htmlElementの概念に関連する内部値がフィルタリングされます。 リレーションには機能的なセマンティクスを指定することもできます。これをブール型の関数として使用して、ネストされた概念の特定のエンティティに対してリレーションが満たされているかどうかを確認できます。

oncept htmlFormElement is e 
from htmlElement e, htmlForm f
where  insideSquareRelation(e, f)

前の場合とは異なり、ここでは関係は関数として扱われ、推論の順序に影響します。関数の評価は、すべての引数が値に関連付けられるまで延期されます。すなわち、まず概念の値の組み合わせでのHtmlElementとhtmlForm見出されるついで、および関係に対応しないものinsideSquareRelation除外されるであろう。次の出版物の1つで、論理的および機能的なプログラミングパラダイムの統合についてさらに詳しく説明する予定です。

それでは、小さな例を見てみましょう。

事実の定義と基本的なタイプの概念は、最初の出版物からの債務者による例を実装するのに十分です。顧客に関する情報（顧客ID、名前、電子メール）と請求書（アカウントID、顧客ID、日付、支払額、支払額）を格納する2つのCSVファイルがあるとします。



また、これらのファイルの内容を読み取り、それらを一連のファクトに変換する特定の手順があります。

fact cell {
	table: “TableClients”,
	value: 1,
	rowNum: 1,
	columnNum: 1
};
fact cell {
	table: “TableClients”,
	value: “John”,
	rowNum: 1,
	columnNum: 2
};
fact cell {
	table: “TableClients”,
	value: “john@somewhere.net”,
	rowNum: 1,
	columnNum: 3
};
…
fact cell {
	table: “TableBills”,
	value: 1,
	rowNum: 1,
	columnNum: 1
};
fact cell {
	table: “TableBills”,
	value: 1,
	rowNum: 1,
	columnNum: 2
};
fact cell {
	table: “TableBills”,
	value: 2020-01-01,
	rowNum: 1,
	columnNum: 3
};
fact cell {
	table: “TableBills”,
	value: 100,
	rowNum: 1,
	columnNum: 4
};
fact cell {
	table: “TableBills”,
	value: 50,
	rowNum: 1,
	columnNum: 5
};

まず、テーブルセルに意味のある名前を付けましょう。

concept clientId is cell where table = “TableClients” and columnNum = 1;
concept clientName is cell where table = “TableClients” and columnNum = 2;
concept clientEmail is cell where table = “TableClients” and columnNum = 3;
concept billId is cell where table = “TableBills” and columnNum = 1;
concept billClientId is cell where table = “TableBills” and columnNum = 2;
concept billDate is cell where table = “TableBills” and columnNum = 3;
concept billAmountToPay is cell where table = “TableBills” and columnNum = 4;
concept billAmountPaid is cell where table = “TableBills” and columnNum = 5;

これで、1つの行のセルを1つのオブジェクトに結合できます。

concept client (
	id = id.value,
	name = name.value,
	email = email.value
) from clientId id, clientName name, clientEmail email
where id.rowNum = name.rowNum = email.rowNum;

concept bill (
	id = id.value,
	clientId = clientId.value,
	date = date.value,
	amountToPay = toPay.value,
	amountPaid = paid.value
) from billId id, billClientId clientId, billDate date, billAmountToPay  toPay,  billAmountPaid  paid
where id.rowNum = clientId.rowNum = date.rowNum = toPay.rowNum = paid.rowNum;

「未払いの請求書」と「債務者」の概念を紹介しましょう。

concept unpaidBill is bill where amountToPay >  amountPaid;
concept debtor is client c where exist(unpaidBill {clientId: c.id});

どちらの定義も継承を使用します。unpaidBillという概念は、請求書、債務者、つまりクライアントの概念のサブセットです。債務者の定義には、unpaidBillコンセプトのサブクエリが含まれています。ネストされたクエリのメカニズムについては、次のいずれかの出版物で詳しく検討します。



「フラット」概念の例として、「顧客債務」の概念も定義しましょう。ここでは、「顧客」と「アカウント」の概念のいくつかのフィールドを組み合わせます。

concept clientDebt (
	clientName = c.name,
	billDate = b.date,
	debt = b. amountToPay – b.amountPaid
) from unpaidBill b, client c(id = b.client); 

コンセプトクライアントと請求書の属性間の依存関係はfromセクションに移動され、子コンセプトclientDebtの依存関係はその属性のセクションに移動されます。必要に応じて、それらをすべてwhereセクションに配置できます。結果は同じになります。しかし、私の観点からは、現在のバージョンはより簡潔であり、これらの依存関係の目的、つまり概念間の関係を定義することをより強調しています。



次に、少なくとも3つの未払いの請求書が連続している悪意のある不履行者の概念を定義してみましょう。これを行うには、1人の顧客の請求書を日付で注文できる関係が必要です。一般的な定義は次のようになります。

relation billsOrder between bill next, bill prev
where next.date > prev.date and next.clientId = prev.clientId and not exist(
    bill inBetween 
    where  next.clientId = inBetween.clientId 
    and  next.date > inBetween.date  > prev.date
);

2つの請求書が同じ顧客に属し、一方の日付がもう一方の日付よりも大きく、それらの間に他の請求書がない場合、2つの請求書が連続して表示されます。この段階では、そのような定義の計算の複雑さにこだわるつもりはありません。ただし、たとえば、すべての請求書が1か月の間隔で発行されることがわかっている場合は、大幅に簡略化できます。

relation billsOrder between bill next, bill prev
where next.date = prev.date + 1 month and next.clientId = prev.clientId;

3つの未払いの請求書のシーケンスは次のようになります。

concept unpaidBillsSequence (clientId = b1.clientId, bill1 = b1, bill2 = b2, bill3 = b3) 
from 
    unpaidBill b1, 
    billsOrder next1 (next = b1, prev = b2)
    unpaidBill b2
    billsOrder next2 (next = b2, prev = b3)
    unpaidBill b3;

この概念では、最初にすべての未払いの請求書が検索され、次にnext1リレーションを使用してそれぞれの次の請求書が検索されます。概念b2を使用すると、この請求書が未払いであることを確認できます。同じ原則で、next2とb3を使用すると、3番目の未払いの請求書が連続して見つかります。この概念と顧客の概念との接続をさらに容易にするために、顧客IDが属性のリストに個別に追加されました。

concept hardCoreDefaulter is client c where exist(unpaidBillsSequence{clientId: c.id});

債務者の例は、ドメインモデルを宣言的なスタイルで完全に記述する方法を示しています。OOPまたは機能スタイルでのこの例の実装と比較すると、結果のコードは非常に簡潔で理解しやすく、自然な言語で問題を説明するのに近いものです。

簡単な結論。

そこで、ハイブリッド言語モデリングコンポーネントの3つの主要な概念を提案しました。

• 他の概念の変換に基づいて作成された概念。
• 他の概念の構造と関係を継承する概念。
• 他の概念間の関係を定義する概念。

これらの3つのタイプの概念には異なる形式と目的がありますが、解決策を見つける内部ロジックは同じであり、属性のリストを形成する方法のみが異なります。



概念の定義は、形式と実行の内部ロジックの両方でSQLクエリに似ています。したがって、提案された言語が開発者にとって理解可能であり、エントリのしきい値が比較的低いことを願っています。また、他の概念の定義での概念の使用、継承、派生関係、再帰的定義などの追加機能により、SQLを超えて、コードの構造化と再利用が容易になります。



RDFやOWLとは異なり、モデリングコンポーネントは概念と関係を区別しません。すべてが概念です。フレームロジックの言語とは対照的に、概念の構造を説明するフレーム、およびそれらの間の接続を定義するルールは、一緒に組み合わされます。 Prologなどの従来の論理プログラミング言語とは対照的に、モデルの主な要素は、フラットな構造を持つルールではなく、オブジェクト指向の構造を持つ概念です。この言語設計は、大規模なオントロジーや一連のルールを作成するのにそれほど便利ではないかもしれませんが、半構造化データを操作したり、異種のデータソースを統合したりする場合にははるかに優れています。モデリングコンポーネントの概念は、OOPモデルのクラスに近いため、アプリケーションコードにモデルの宣言的な説明を含めるタスクが容易になります。



モデリングコンポーネントの説明はまだ完了していません。次の記事では、ブール変数、否定、高次ロジックの要素など、コンピューターロジックの世界からの問題について説明する予定です。その後、特定の関数を使用してエンティティを生成する概念、集計、および概念のネストされた定義。



英語の科学的なスタイルの全文は、papers.ssrn.com / sol3 / papers.cfm？abstract_id = 3555711で入手できます。



以前の出版物へのリンク：



マルチパラダイムプログラミング言語の設計。パート1-それは何のためですか？

マルチパラダイムプログラミング言語を設計します。パート2-PL / SQL、LINQ、GraphQLでのモデル構築の比較

マルチパラダイムプログラミング言語を設計します。パート3-知識表現言語の概要