Refactor manual documentation for BEAR.Sunday's ROA

This commit enhances the description of BEAR.Sunday's Resource-Oriented Architecture (ROA) in both the English and Japanese versions of the tech manuals. It clarifies the comparison between traditional MVC and ROA, details on injecting views into resources, and explanations on resource constraints and dependencies. It also simplifies the language for reader-friendly comprehension.

manuals/1.0/en/15.tech.md

@@ -44,16 +44,16 @@ By using BEAR.Sunday's ROA, scalable and loosely coupled applications that align
 
 ### Differences from MVC
 
-BEAR.Sunday's ROA takes a different approach compared to the traditional MVC architecture. MVC structures an application with three components: Model, View, and Controller. In practice, however, the Controller freely manipulates the Model and View at runtime, literally controlling everything.
+The ROA of BEAR.Sunday takes a different approach from the traditional MVC architecture. While MVC organizes an application into three components: model, view, and controller, in reality, the controller freely manipulates the model and view at runtime, literally controlling everything.
 
-In contrast, with BEAR.Sunday, the View is injected into the Resource object, and the Resource is unaware of the View, just as the View is unaware of the Resource. The Resource object does not manipulate the injected View and does not even know what kind of View has been injected. Only when the Resource object is evaluated as a string does the injected View render the Resource's state into a string representation. In this way, the Resource and View are loosely coupled, and their responsibilities are clearly separated.
+In contrast, in BEAR.Sunday, a view is injected into a resource object, and the resource is ignorant of the view, and vice versa. The resource object does not perform any operations on the injected view and is unaware of which view is injected. The resource's methods are only concerned with the resource state, while the injected resource view renders the resource state to a string representation when the resource object is evaluated as a string. In this way, the resource and view are loosely coupled, with clear separation of concerns.
 
-Furthermore, unlike the unconstrained relationship between Controller and Model, Resources have constraints on including other Resources, which can be done declaratively. The Resource also depends on different Resources, forming a tree structure similar to DI dependencies. Other differences include:
+Unlike the unrestricted relationship between the controller and model in MVC, there is a constraint in BEAR.Sunday where resources can contain other resources, declared using URIs. These resources can depend on other resources, forming a tree-like structure, similar to DI dependencies. Some other differences include:
 
-* BEAR.Sunday Resources provide possible operations (affordances) by declaring relationships. Clients can dynamically manipulate Resources using this as a clue. It is self-descriptive.
-  HAL (Hypertext Application Language) is adopted for links, standardizing the links between Resources.
-* Unlike MVC Models, Resources can be directly called from various clients, including the console.
-* There is no need to build HTML sites and API sites separately; the same Resources can be used to build both HTML sites and API sites simultaneously.
+- BEAR.Sunday resources provide affordances, or possible operations, by declaring relations. Clients can dynamically manipulate resources using these hints, making them self-descriptive. 
+- HAL (Hypertext Application Language) is used for links to standardize the representation of links between resources.
+- Unlike MVC models, they can be directly called from a diverse range of clients, including the console.
+- There is no need to build HTML and API sites separately; the same resources can be used to build both simultaneously.
 
 
 ## Dependency Injection (DI)

manuals/1.0/ja/15.tech.md

@@ -14,6 +14,10 @@ permalink: /manuals/1.0/ja/tech.html
 
 BEAR.SundayのROA は、RESTful な API を Web アプリケーションの内部構造で実現するためのアーキテクチャであり、BEAR.Sundayの設計原則の中核を成すものです。これはハイパーメディア フレームワークであり、オブジェクト as a サービスでもあります。Web と同様に、すべてのデータや機能をリソースとして扱い、GET/POST/PUT/DELETE などの規定されたインターフェイスで操作します。またリソースとリソースは相互に接続されています。リソースが他のリソースへのハイパーリンクを提供することでリソースは情報や機能を提供するだけでなく、アフォーダンスも提供することができます。
 
+### URI
+
+URI（Uniform Resource Identifier）は、Webの成功の鍵となる要素であり、BEAR.SundayのROAの中核でもあります。アプリケーションが扱うすべてのリソースにURIを割り当てることで、リソースを識別し、アクセスしやすくなります。 URIは、リソースの識別子として機能するだけでなく、リソース間の関係を表現するためにも使用されます。これにより、リソースの操作、再利用、組み合わせが容易になります。
+
 ### ユニフォームインターフェース
 
 リソースへのアクセスはHTTPのメソッド（GET, POST, PUT, DELETE）を用いて行われます。これらのメソッドはリソースに対して実行できる操作を規定しており、リソースの種類に関わらず共通のインターフェースを提供します。
@@ -46,9 +50,9 @@ BEAR.SundayのROAを用いることで、Webの設計原則に沿ったスケー
 
 BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。MVCはモデル、ビュー、コントローラーの3つのコンポーネントによってアプリケーションを構成しますが、実際はコントローラーがモデルやビューを自由にランタイムで操作し、あくまでコントローラーが文字通り全てをコントロールしています。
 
-これに対して、BEAR.Sundayではリソースオブジェクトにビューがインジェクトされ、リソースはビューに対して無知であると同時に、ビューもまたリソースに対して無知です。リソースオブジェクトはインジェクトされたビューに対して操作を行いませんし、そもそもどのようなビューがインジェクトされたのかも知りません。リソースオブジェクトが文字列評価された時に初めて、インジェクトされたビューがリソースの状態を文字列表現にレンダリングします。このように、リソースとビューは疎結合であり、それぞれの責務が明確に分離されています。
+これに対して、BEAR.Sundayではリソースオブジェクトにビューがインジェクトされ、リソースはビューに対して無知であると同時に、ビューもまたリソースに対して無知です。リソースオブジェクトはインジェクトされたビューに対して操作を行いませんし、そもそもどのようなビューがインジェクトされたのかも知りません。リソースのメソッドはリソース状態にのみ関心を持つ一方、インジェクトされたリソースビューはリソースオブジェクトが文字列評価された時に初めて、リソースの状態を文字列表現にレンダリングします。このように、リソースとビューは疎結合であり、それぞれの責務が明確に分離されています。
 
-また、コントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことに制約があり、宣言的に行うことができます。そのリソースはまた違うリソースに依存し、まるでDIの依存性のようにツリー構造を形成します。その他以下のような違いがあります。
+また、コントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことにURIを用いた制約があり、宣言的に行うことができます。そのリソースはまた違うリソースに依存し、まるでDIの依存性のようにツリー構造を形成します。その他以下のような違いがあります。
 
 * BEAR.Sundayのリソースはリレーションを宣言することで、可能な操作（アフォーダンス）を提供します。クライアントはこれを手がかりにリソースを動的に操作できます。自己記述的です。 リンクにはHAL（Hypertext Application Language）を採用し、リソース間のリンクを標準化します。
 * MVCのモデルと違って、コンソールを含む多様なクライアントから直接コールすることができます。