Fig 2 presents the LAURA domain reference model. The proposed model was inspired by previous initiatives in IoT domain, such as IoT-A (Bauer et al., 2013), Butler and FI-WARE (Butler Consortium, 2013), IoT-lite (Bermudez-Edo et al., 2017), and SSN (Compton et al., 2012). The model offers stakeholders a lean and useful artifact that promotes a common ground of understanding of the abstract concepts, properties, attributes, relationships and semantics, necessary to develop their own version of LAURA applied final IoT solution, according to the requirements and specificities of the company domain problem.


The model is divided into two parts or visions that complements each other. The blue highlighted elements represent the concepts addressed in the ‘Physical’ and ‘Core’ layers of LAURA architecture and the green highlighted elements represent the concepts addressed in the ‘Fog’, ‘Situation/Rule’ and ‘Application/Business Process’ layers.

The blue highlighted elements can represent the virtual view (as a virtual sensor) of things, devices, entities and other ==related virtual artifacts==. The main focus is to represent the ==general concepts== used in the ‘Core’ layer, but all these ==elements== must be used while modeling/coding the solution in the physical layer. The lower level ==concerns== related to hardware aspects, such as the type of device, sensor, tag or actuator, are not addressed by the domain model, because as the LAURA architecture proposes the use of the VM-based device sensors, lower level issues are abstracted from the application running on the device. As discussed previously in section 2.1, the bytecode (node code that effectively reads and sends the raw sensor data) uses high-level language that abstracts hardware features. Thus, these general concepts must be used in the programming of the bytecode, however, the treatment standardization and delivery, done in the ‘Core’ layer, use the general concepts represented by blue highlighted elements.

The ‘Sensing Device’ entity is the virtual representation of a device, with sensors, that has a single identification ‘key’, defined as key and a ‘descriptor’ that helps the stakeholder to characterize its purpose or utility, e.g., ‘Living-room controller’, ‘Claire's mobile phone’, ‘Store Beacon’. The ‘Sensing Device’ can add one or more ‘Observed Properties’ that can be any property, quality or attribute that a ‘Sensing Device’ is able to observe or collect, for example, a temperature observation, humidity and location.

==An== ‘Observation’ can be defined as a set of values or physical world magnitudes identified for a certain property at a specific time. An observation of geolocation, for example, has, at least, two pairs of ’Keyvalue’, latitude and longitude, respectively. Frequently, the magnitudes captured by ´Observations´ are transmitted periodically in temporally ordered series (streams of data) with their respective ==‘ObservableProperties’==. ==An 'ObservableProperty' represents a topic that can be measured over time with shared conditions like source/sensor origin, measuarement unit, accuracy. Examples 'ObservableProperty' are the temperature of a specific place or area, the location of an certain individual, etc. 'ObservableProperties' and its stream of 'Observation's can be available or “exposed” by means of ‘endpoints’ via a API.==

It is possible to associate characteristics or metadata, according to the necessity or preference of the stakeholder, in any instances of the blue highlighted entities. The ‘metadata’ has a ‘name’, ‘value’ and ‘kind’. The semantic or utility of the metadata instances will depend on its own version of LAURA applied final IoT solution. Following this, some examples of ‘metadata’ values will be presented that can be used in a specific solution: ‘name’="devicemodel", ‘value’="MTM-CM5000-MSP", ‘kind’="String"). In order to identify the magnitude unit of an ‘ObservedProperty’, it is possible to use the following values; ‘name’="unit", ‘value’="Celsius", ‘kind’="String" and to define the precision of an Observation, it is possible to use: ‘name’="precision", ‘value’="0.3", ‘kind’="Double"). Next, the green highlighted elements related to the concepts addressed in the ‘Fog’, ‘Situation/Rule’ and ‘Application/Business Process’ layers will be present.

==An== 'Entity' is a virtual representation of a real-world individual, ==it is composed by== properties and contexts ('Context') ==which== are of the stakeholder’s interest. ==An== 'Entity' must have a ‘key’ for a unique identification. In addition, it has a descriptor for human-friendly characterization, and a kind, to designate its type, class or scheme. The tuple (50303, "Sergio", "Person") is an example of 'Entity', with its values referring to attributes ‘key’, ‘descriptor’ and ‘kind’, respectively. ==An== 'Entity' may present a set of 'Attributes', values that belong to an individual or thing that remains unchangeable during the existence of its owner in the application or scenario. A valid example of an 'Attribute' associated with 'Entity' previously suggested would be (label = "birthday", value = "1987-03-16", type = "datetime").

==A== 'Context' makes up the state-of-affairs of ==an== 'Entity', characteristics of an individual that are submitted to changes in the environment that it is inserted. The green highlighted elements are based on (Dockhorn Costa, 2007) and use a similar classification when distinguishing 'Context' in 'Intrinsic' and 'Relational'. ==An== 'IntrinsicContext' represents properties that relate only to your bearer, e.g., "temperature", "location", "mood". ==A== 'RelationalContext' constitutes states shared between one or more 'Entity'. Good examples are "friendship", "proximity", "containment", "ownership", and so on. In both classifications ‘Context’ must have a key and kind, e.g., (key = "temp50303", kind = "Temperature"), (key = "prox50303-45231", kind = "Proximity"), and in such 'Relational Context' it must be given a specific role or part within the relation to entities, like in an "ownership" context, one is expected to be labeled as the owner and the other one labeled as the owned. ==A== 'RelationalPart' class helps in qualifying those participations.

Besides its intrinsic or relational characteristics, every 'Context' ==has a relation with a 'ContextValue' which represents its current state==, quite similar to an 'Observation' in the 'Core' layer, in the sense that it's a temporal construct, a point-in-time event, and may present a composite of key-value pairs, a set of 'Entries', as it can be seen in Fig 2.

The link between the 'Core' and 'Application/Business' layers is made by exposing contexts and observing properties of the 'Core' layer. This can be seen in the connection between 'ContexSubscription' and ‘ObservableProperty’. The proposed model allows an association of a certain 'Context' to the consumption of streams of 'Observation', produced directly by 'ObservableProperty'. Once the 'Context' is defined, it is possible to associate the 'ContextSubscription', whose purpose is to maintain a subscription through an endpoint that refers to the URL or URI in which a particular 'ObservableProperty' was exposed. The technical characteristics related to how this link, subscription or observation should be performed are not part of the scope of this reference model. Furthermore, in the 'ContexSubscription', the stakeholder must be able to define a window rule in order to establish a time window to be used by the consumed part in order to interpret and send the 'Observation' group of interest. For example, it is possible that the consuming part needs to perform some pre-processing, such as an aggregation operation over a value of the last N 'Observation' (length window) or even 'Observation' occurred in the last 10 minutes (time window). The applications of these operations are defined by means of a 'Formula'.