# CATSWoTS: Context Aware Trustworthy Social Web of Things System
## 3 Context Aware QoS Trust Management
### Trust Management
#### 3.2.1 Context Manager  
In CATSWoTS, two context managers at the local level and at the central level are designed. Conceptually, both are doing the same work and are deployed at two different levels. The difference between the two context managers is that the central context manager performs the phases of context acquisition and context modeling. In addition to this, the central context manager also maintains the history of services that were consumed in the past. The context managers consider four categories of the conceptual and the primary category of the operational perspective of the context as described in [5]. [PERSON] et al. identified various categories of context including (i) who; (ii) what; (iii) where; and (iv) when types of context in state of the art [5]. In CATSWoTS, the mentioned types are also considered, the details of which are shown in Figure 2.  
Each thing is identified by URI (Uniform Resource Identifier), which covers the aspect of \"Who\". For \"What\", the service type and the capability (which varies from one service type to the other) are considered as stated in [3]. Location of the things and the location of service seeker, in the form of longitude and latitude, are considered for the \"Where\". The time at which service is required manifests the \"When\". The aging time can also be used to reflect it. The first step of context acquisition is completed manually i.e., the service provider itself enters the detail of context information on the centralized server. The details include the registration of the service provider, types of services it provides, URI of each service and activity it performs. Then, the attributes like capability, location and time are also entered in the context manager. For context modeling, markup scheme modeling (e.g., JSON) is used as described in [5]. JSON is preferred overXML because the parsing process of XML takes time. JSON is more readable and can be easily mapped to domain objects. An example of SP service modeling for a smart waste management service provider based on IoT is shown in Figure 3. In this model, all of the information related to W4 is described. For context reasoning, a simple rule-based approach is used as it is the most popular approach in state of the art. The rules are defined based on various parameters. The context of SS is also taken in this pattern which helps in identifying the relevant SP. The example is shown in Figure 4 for an SS who is in search of a trustworthy waste management service provider. Figure 4: Modeling at service seeker end. Figure 3: Service modeling at service provider end. Figure 2: Categories of the context in CATSWoTS. The matching and identification of the services based on the context of the SS is described in Algorithm 1. The SS gives the parameters of \(\delta\) which is a service category, \(\alpha\) depicting service name, \(\Omega\) manifests capability which may have many variables. As shown in Figure 3, the capability of the smart bin is 2 kg garbage per house per day. The energy/battery level of the sensors embedded in this smart bin might be another capability. Then, the location of a service is identified in the form of longitude \(\lambda\) and latitude \(\phi\). The importance of the distance between the location of SP and the location at which a service is required cannot be ignored. Therefore, the Haversine formula for distance calculation is considered in the CATSWoTS. The mentioned formula calculates the distance by taking the values in longitude and latitude and measures the distance in kilometers or miles. The \"when\" of the context can be covered in different aspects like the aging of the device and the time at which a service is required. In this example, the service timing is significant as the waste management company provides service in the morning, afternoon and in the evening. After getting the input parameters, the local context manager searches its local database for the existence of any service id resembling the context of required service.