Automated API traversal
Armed with a thesaurus and an almanac of system functionality we can write robots that program themselves
In Restful HATEOAS design, web applications provide endpoints that provides a list of web resources related to the current request that can also be introspected in the API.
A restaurant resource has links or URLs to a booking resource because you can book a restaurant.
A system should publish an endpoint that is an almanac of system functionality, that is, every endpoint it has, a thesaurus of keywords used to access that endpoint and a thesaurus of operations that it supports.
A system should also publish a series of workflows that it expects people to use.
This way we can write a fuzzy logic for a system based on a rough description of what to do - based on the thesaurus and almanac of a system.
"Export all my tweets to file"
All has an thesaurus entry for "list", "listAll", "getAll".
So the service knows it has to loop over this collection and save all fields to a file.
しかし、これはAPIがすでに機能する方法であり、その年鑑は「ドキュメント」と呼ばれ、すでに多くの場合、機械で読み取り可能です（[コアプロトコル]（https://thecoreprotocols.org）および[open api]（https：// www .openapis.org）？）。
まあ、それらには制限があり、オブジェクトタイプに関連付けられた語彙を返さず、Mime-TypesまたはContent-Typesは十分な情報を提供しません。それらのAPIがJSON-LD応答を返す場合、または単に応答をメタフォーマットの[polycontext metasymbol]（https://0oo.li/method/863/metaformat）で装飾するだけで、概念で定義されたスキーマにバインドするのに十分である可能性があります。ポリコンテキストメタシンボルを介してリンクされ、APIをトラバースしてすべてに関するデータを取得しながら、誰もがすべてについて推論することができます。
ソフトウェアタイプがオントロジー（言語）とのリンクが不十分な、十分に文書化されていないソフトウェアが多数存在するため、人間の作業を必要とし、この希望的観測を実現するためにすでに機能している（エキスパートシステムと呼ばれる）既存のソリューションの束） タイプ。
誰もが何かを知りたいと思っただけで多数のデータベースにクエリを自動生成できるようにその言語接続を作成するには、人間の例からそれをマッピングするためのAIシステムのトレーニングが必要になります。いくつかのレイヤーがあります：
-人間の言語の一部である同義語
-コンセプトID（ウィキデータにあります）
-クラス名（OOPソフトウェアで見つけることができます）
-テーブル名（データベースで見つけることができます）
これらすべては、単一の優れた[ポリコンテキストメタシンボル]（https://0oo.li/method/863/metaformat）を定義することで、美しくリンクできます（人類のポリコンテキストメタシンボルを考え出して進化させる必要があると思いますRFCを介してプロトコルを進化させるのと同様の方法であり、最終的には、すべてのプロトコルおよびすべての情報システムで、このように、本当に超越的に推論できるという望ましい特性を持つことができます。
But this is how APIs work already, that almanac is called "documentation" and it is already often machine-readable (read the core protocols and open api?).
Well, they have a limitation, they do not return vocabularies associated with their object types, and Mime-Types or Content-Types are not sufficiently informative. They could, if those APIs returned JSON-LD respones, or simply decorating their responses with metaformat's polycontext metasymbol would be enough to bind them to schemas defined in concepts also linked via polycontext metasymbol, and everyone could reason about everything while retrieving data about everything, traversing APIs.
A bunch of existing solutions that require human work, and already work (they are called expert systems) for this wishful thinking to get realized, because there exists a lot of not very well documented software, where software types are poorly linked with ontological (linguistic) types.
To create that linguistic connect so that everyone could auto-generate queries in numerous databases just by thinking that one would want to know something, will require the training of an AI system to map it from human examples. There are a couple of layers:
All of that, can be beautifully linked up by defining a single good polycontext metasymbol (I think we should come up with and evolve the polycontext metasymbol for humanity, in a similar way that we evolve protocols, through RFCs), and that would allow to eventually have that desired property of being able to reason this way, really transcendentally, in all protocols and with all information systems.
私は本当に賢いreteアルゴリズムを使用するDroolsのようなエキスパートシステムに精通しています。そして私はOpenAPIについて知っています
ただし、明示的にコーディングする必要があります。
I'm familiar with expert systems such as Drools which uses the rete algorithm which is really clever. And I know about OpenAPI
But they still have to be explicitly coded.
//ただし、明示的にコーディングする必要があります。
しかし、あなたが提案するもの（シソーラスとシステム機能の年鑑）も明示的にコーディングする必要がありますね。
「システムは、システム機能のアルマナックであるエンドポイントを公開する必要があります。つまり、システムが持つすべてのエンドポイント、そのエンドポイントにアクセスするために使用されるキーワードのシソーラスと、サポートする操作のシソーラスです。」
機能を公開するには、これらのシステムをコーディングする必要があるため、機能を備えているすべてのシステムを変更して、公開できるようにする必要があります。あなたのアプローチは、それらのシステムを変更して「シソーラスと年鑑」に自分自身の説明を公開するための明示的なコーディングの必要性をどのように回避しますか？
// But they still have to be explicitly coded.
But what you propose (the thesaurus and an almanac of system functionality) would also have to be explicitly coded, wouldn't it?
You say: "A system should publish an endpoint that is an almanac of system functionality, that is, every endpoint it has, a thesaurus of keywords used to access that endpoint and a thesaurus of operations that it supports."
You need to code those systems to publish their functionality, so you'd have to modify every system that has functionality, to be able to publish it. How would your approach avoid this need for explicit coding to modify those systems to publish descriptions of themselves to the "thesaurus and an almanac"?
REST API用のnnnのバージョンがあるはずだと思います。 ファイルシステムとしてのRESTAPI、次に
nnnutilを拡張して.jsonを処理しますファイルはそれを行います。しかし、FUSEのパフォーマンスはそれほど高くないことがわかりました。また、Linus Torvaldsは、FUSEファイルシステムはおもちゃにすぎないと有名に言っています...I think, there should be a version of nnn for REST APIs. The REST API as a filesystem, and then extending the
nnnutil to handle.jsonfiles would do it. However, I found that FUSE is not very performant, and Linus Torvalds famously says FUSE filesystems are nothing more than toys...