Update Naming-convention.md

update sso prefix with ss4o

Signed-off-by: YANGDB <yang.db.dev@gmail.com>

docs/schema/observability/Naming-convention.md

@@ -39,28 +39,28 @@ A data stream is internally composed of multiple backing indices. Search request
 
 Index pattern will follow the next naming structure `{type}`-`{dataset}`-`{namespace}`
 
-- **type**	- indicated	the observability high level types "logs", "metrics", "traces" (prefixed by the `sso_` schema convention )
+- **type**	- indicated	the observability high level types "logs", "metrics", "traces" (prefixed by the `ss4o_` schema convention )
 - **dataset**	- The field can contain anything that classify the source of the data - such as `nginx.access` (If none specified "**default** " will be used).
 - **namespace**	- A user defined namespace. Mainly useful to allow grouping of data such as production grade, geography classification
 
-3) The ***sso_{type}-{dataset}-{namespace}*** Pattern address the capability of differentiation of similar information structure to different indices accordingly to customer strategy.
+3) The ***ss4o_{type}-{dataset}-{namespace}*** Pattern address the capability of differentiation of similar information structure to different indices accordingly to customer strategy.
 
 This strategy will be defined by the two degrees of naming freedom: `dataset` and `namespace`
 
 For example a customer may want to route the nginx logs from two geographical areas into two different indices:
-- `sso_logs-nginx-us`
-- `sso_logs-nginx-eu`
+- `ss4o_logs-nginx-us`
+- `ss4o_logs-nginx-eu`
 
-This type of distinction also allows for creation of crosscutting queries by setting the next **index query pattern** `sso_logs-nginx-*` or by using a geographic based crosscutting query `sso_logs-*-eu`.
+This type of distinction also allows for creation of crosscutting queries by setting the next **index query pattern** `ss4o_logs-nginx-*` or by using a geographic based crosscutting query `ss4o_logs-*-eu`.
 
 
 ## Data index routing
 The [ingestion component](https://github.com/opensearch-project/data-prepper) which is responsible for ingesting the Observability signals should route the data into the relevant indices.
-The `sso_{type}-{dataset}-{namespace}` combination dictates the target index, `{type}` is prefixed with the `sso_` prefix into one of the supported type:
+The `ss4o_{type}-{dataset}-{namespace}` combination dictates the target index, `{type}` is prefixed with the `ss4o_` prefix into one of the supported type:
 
-- Traces - `sso_traces`
-- Metrics - `sso_metrics`
-- Logs - `sso_logs`
+- Traces - `ss4o_traces`
+- Metrics - `ss4o_metrics`
+- Logs - `ss4o_logs`
 
 For example if within the ingested log contains the following section:
 ```json
@@ -75,7 +75,7 @@ For example if within the ingested log contains the following section:
   }
 }
 ```
-This indicates that the target index for this observability signal should be `sso_traces`-`mysql`-`prod` index that follows uses the traces schema mapping.
+This indicates that the target index for this observability signal should be `ss4o_traces`-`mysql`-`prod` index that follows uses the traces schema mapping.
 
 If the `data_stream` information if not present inside the signal, the default index should be used.
 
@@ -115,4 +115,4 @@ Important to mention here that this new suggestion would not change or prevent e
 
 **Do you have any additional context?**
  - [data-streams](https://opensearch.org/docs/latest/opensearch/data-streams/)
- - [data-prepper](https://github.com/opensearch-project/data-prepper)
+ - [data-prepper](https://github.com/opensearch-project/data-prepper)