まず、あなたが指摘した 1 つのポイントを取り上げたいと思います。
Jena やその他の非 DotNet プロジェクトとは異なり、オントロジーをサポートしていません。
これは正確にはどういう意味ですか？
API のオントロジー API部分を試した場合、よりオントロジー/リソース中心の API がないことについて話しているのですか?
それとも、OWL オントロジーおよび/または推論サポートの欠如について話しているのでしょうか? その場合、はい、現時点では何もサポートされていません/非常に限定されたサポートがあり、現時点ではこれらの機能に取り組むための帯域幅がありません
他のオープン ソース プロジェクトと同様に、dotNetRDF は開発者とユーザーの自由時間の入力と貢献に依存しています。あなたにとって本当に重要な機能が不足している場合は、メーリング リストでお知らせください。ディスカッションを開始してください。
必要な機能を追加するのが比較的簡単である場合 (または、既に存在し、十分に文書化されていない場合) は、問題が解決されたことをすぐに見つけることができます。または、実際に誰も来て、まだそれを求めていないため、その機能がまだ存在していない可能性があります!
.Net の人々は、どんな助けも本当に感謝しています。
すべての新機能は、開発者のニーズまたはユーザーからの機能要求によって推進されます。dotNetRDF はオープン ソース プロジェクトであるため、不足している機能を自分で提供したり、(私のような) 開発者と協力して必要な機能を利用できるようにすることをいつでも検討できます。
第二に、あなたの質問に実際に答えようとします
dotNetRDF と Jena の両方の開発者として、私は個人的に Jena.Net の概念が嫌いです。移植されたコードの実行に関連して、ある程度のパフォーマンス ヒットが発生する可能性があるという事実に加えて、Jena は非常に非 .Net であるという事実があります。命名規則、設計パターン (どこでも静的ファクトリ!)、複雑なカスタム イテレータ インフラストラクチャ、一貫性のないパッケージ名など、さまざまな方法で設計します。これの一部は簡単に修正できIEnumerable<T>ますが、特殊なイテレータが使用されているすべての場所で置換するなど、他の部分はそれほど修正できません。私が 3.5 年前に dotNetRDF を開始したのには理由があります。それは、醜いポートではなく、適切な .Net ネイティブ API が必要だったからです。
dotNetRDF で確認したい Jena の特定の機能がある場合は、Jena コードベースをガイドとして使用して、それらの機能のネイティブ .Net 実装を作成することにもっと興味があります。前に述べたように、あなた/他の人は dotNetRDF への貢献としてこれに取り組むことに興味があるかもしれません
多くが放棄されている/未熟であると考えられている.Net用のツールが他にもいくつかあります。