# SOLIOT--Decentralized Data Control and Interactions for IoT
## 6 Mapping and Interaction Model
### Functional Characteristics  
At the core of all IoT specifications is the necessity to establish interoperability between the uncountable different systems and devices which are currently in place. While new protocols and interaction patterns are introduced on a regular basis, the core challenge of each new approach is certainly to reach a critical distribution. SOLID relies on the most successful and widespread interaction pattern currently known, the Web. The already proven and well-known techniques, like its server-client architecture or the connection of related information resources through hypermedia links, constitutes a powerful foundation for any integration challenge. SOLIOT therefore takes advantage of the SOLID interoperability (F1) approach, as a broad range of Web-compatible applications already exists and users, developers and administrators are familiar with its characteristics (cf. Table 1). The targeted use case of SOLID is an on-hop interaction between a defined Web client as the data consumer and the SOLID server acting as the origin server. The Pod is hosted in a Cloud environment, where the Cloud server complies to the SOLID specification but can be located anywhere in the Web. The users are either the data sovereign controlling the Pod, or consuming applications authorized by \begin{table}
\begin{tabular}{l l l} \hline \hline  & **SOLID** & **SOLID** \\ \hline Interoperability (F1) & LDP, RDF, SPARQL & Read/write RDF for IoT \\ Shared data: & SOLID Pod & Thing Description as the Digital Twin \\ \hline resource Interactions (F2) & LDP specification, & CoAP CRUD operations, \\  & Web Socket Updates, SPARQL & MQTT Updates \\ \hline Manage Notifications (F3) & Linked Data Notifications & MQTT Updates \\ \hline Invoke Operations (F4) & - & - \\ \hline Identification (F5) & WebID & Identity and/or Security Token \\ \hline Authorization (F6) & HTTP/1.1 Authentication & – \\ \hline Access Policies (F7) & Web Access Control (WAC) & WAC through ACL files \\ \hline Usage Control (F8) & – & – \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Mapping of Functional Requirements. the data sovereign. As SOLID models the social data of the data sovereign, the Pod can be regarded as the Digital Twin of the data sovereign. In an IoT setting, this overlap of roles is not possible anymore. The referent of the Digital Twin is usually not a natural person but a physical object. Still, a (legal) entity must exist which has the authority over the target asset. An additional difference is that in the basic SOLID setting, all components communicating in the network have sufficient resources, in terms of computing power, local storage, memory or provided energy. One can certainly assume that a service hosting SOLID Pods, like a typical state of the Art Cloud service, can scale and allocate additional resources as needed. At the same time, the user agent, usually a modern Web browser executed on a regular PC or laptop, is not challenged by the computational or network requirements of SOLID (F1.4). In an IoT setting however, constraint devices, battery-powered sensors, network disruptions etc. are common challenges. Usually a constant Internet connection cannot be maintained, neither the sending of complex data structures like full-flavored RDF or linked-data graphs. Consequently, SOLIOT-supporting devices cannot be assumed to be at the same network layer as a SOLID server (F1.2). Edge or Fog Gateways can serve as suitable bridges between such restricted devices and the rich expressions of SOLIOT. Such gateways serve as lifting and lowering points (F1.3) between the proprietary device communications. They however usually lack the rich expressions of the SOLIOT representation and can therefore not directly be integrated with higher-level applications (F1.1).