## 5 Group Communication Using Unicasts
### Validation Process
This profile contains information related to the resource itself, as described in [25]. In this example, this includes the options that are supported, the supported methods (only GET) and the content format \"application/json\" (50). In addition, the profile is extended with an entity specific part, providing more information about the entity itself. The resulting profile of the entity looks as follows:  
Figure 8: Entity validation process flow. Res: 2.05 Content (application/json)  {  \"profile\":[  {  \"path\":\"1\",  \"op\":[3,4,7,11,12],  \"cf\":[50],  \"m\":[1]  }  ],  \"entity\":[  {  \"er\":\"coap://[sen5]/tmp,coap://[sen8]/tmp\",  \"eo\":[\"1 st\", \"avg\", \"min\", \"max\"]  }  ]  ]  
This simple example illustrates how an entity profile is constructed; either based on information from individual resource profiles or based on information retrieved via other means such as resources attributes derived from /.well-known/core. Much more information than shown here can be included and, by using a flexible representation format, the profile concept can be easily extended with new information. The entity specific part of the profile currently supports the following fields:  
* _Entity Resources (er)_: a list of the individual resources out of which the entity is composed. * _Entity Message Type (emt)_: specifies the message type to be used for communication between EM and members. Possible values are _con_ (confirmable) and _non_ (non-confirmable). The default is _con_. * _Entity Number of Replies (emt)_: specifies the number of replies that should be received from the members before sending a reply to the client. This makes it possible not to wait for all members to reply. The default behavior is to wait until all replies have been received or have timed out. * _Entity Operation (eo)_: The operations that can be performed on the results obtained from the members. The operation is used to combine replies received from all the members (or the number of replies specified by enr) into one reply to the client. If at the time of querying the entity the client does not specify which operation to use, the first operation listed in this field will be used. Currently the following Entity Operations are supported:
* _List (lst)_: A list of replies received from the members, without any arithmetic processing. This is the default behavior if no entity operation was specified. * _Average (avg)_: The average value. * _Minimum (min)_: The minimum value. * _Maximum (max)_: The maximum value. * _Delay between Requests (delay)_: specifies the delay that should be injected between the requests sent from the EM to the members. The default is 0 and thus the EM will send the requests as fast as it can. These entity profile fields can be provided by the client upon creation time. If no values are provided, the EM will use default values for the newly created entity. To construct the entity profile,the EM uses its internal knowledge to offer additional features that are not provided by the individual members. For example, the EM can interpret certain member payloads, convert between content formats and return the entity result in particular content format. Currently we support conversion between plain-text, JSON and RDFN3 content formats for numerical sensor values. The list of conversion functions can be extended easily.