From 9ea3c33ca7d05d7e0c4d2a85c7cd244b8fb645c7 Mon Sep 17 00:00:00 2001
From: Ingo Friese <ingo.friese@telekom.de>
Date: Thu, 27 Jun 2024 13:37:41 +0000
Subject: [PATCH] 6 and 6.1

---
 TS-0041-oneM2M-SensorThings_interworking.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/TS-0041-oneM2M-SensorThings_interworking.md b/TS-0041-oneM2M-SensorThings_interworking.md
index 0a657ae..efedea6 100644
--- a/TS-0041-oneM2M-SensorThings_interworking.md
+++ b/TS-0041-oneM2M-SensorThings_interworking.md
@@ -192,7 +192,9 @@ The basic interworking enables applications that are connected to an oneM2M-base
 ## 6.1 OGC/STA-to-oneM2M Data Model Mapping
 
 According to oneM2M TS-0033 <a href="#_ref_2">[2]</a> a representation of a non-oneM2M Proximal IoT function/device in a oneM2M-specified resource instance is to be synchronized with the entity that it represents.
+
 This means that the OGC/STA data model is represented in the hosting CSE. The data in the OGC/STA server are organized as Sensing Entities <a href="#_ref_1">[1]</a> (see Figure 5-2: STA Sensing Entities data model).
+
 The oneM2M structure for data models is a tree-structure where data are organized in containers or trees of containers. 
 The OGC/STA data model is a relational one, as used in databases, and not hierarchical. Thus, it creates a challenge for full interworking of all data captured in the OGC/STA data model. In this technical specification, only a limited set of data is mapped between OGC/STA and oneM2M.
 
-- 
GitLab