SeCoMan
A Semantic-Aware Policy Framework for Developing Privacy-Preserving and Context-Aware Smart Applications
The ontologies we describe below emerge as a representation of the information that is managed within the SeCoMan (Semantic web-based Context Management) framework. SeCoMan allows developing context-aware smart applications preserving the users' privacy and using a Semantic oriented Internet of Thing (IoT) vision. Smart applications will be able to gather the information generated by the IoT by using a set of queries predefined in the framework, which are categorized into six groups:

  • Operational queries, providing context-aware information;
  • Location queries, providing the indoor location of the elements (objects and people);
  • Range queries, supplying the elements contained in a specific place;
  • Closeness queries, supplying the elements close to the requester;
  • Navigation queries, giving the path to arrive to a place or an element; and
  • Authorization queries, providing specific information about the users' permission to stay in one place.
The space and context information is shaped in a structured way by using a collection of ontologies, which will be described in subsequent points.

As users' privacy is an important issue that is often overlooked by the framework architectures proposed for the IoT, SeCoMan supports semantic rules to define policies. These policies will allow users to share their location to the right users, at the right granularity, at the right place, and at the right time. By using location policies, users can manage their privacy independently of the applications: hiding their locations to other persons; masking their locations with fictitious positions; establishing the granularity at which they want to be located; and defining the level of closeness accepted to be located. In addition, SeCoMan also manages authorization policies to control who can access (or stay in) a given space.
As we have noted above, SeCoMan defines a collection of ontologies to shape the space and context information. This collection is composed of an ontology called Location that models the indoor location, common for all contexts, and a set of ontologies for the smart applications that provide specific services in different contexts. The Location ontology is shown on the left hand side of the next figure. This ontology models the space and provides a set of primitives with which to describe regions of the space and relationships among them.
The Location ontology is categorized into three different but related topics: element, authorization, and space. The top level class in the element topic is Element, which represents any entity that forms part of the environment. Elements can have several Roles and Privileges that can be used to provide personalized information. Note that Privilege is the most important class in the authorization topic. Privileges are used to allow Elements to perform certain actions, such as staying in a specific position. The Element class has two predefined subclasses, System and Person, which are defined to be disjoint.

A Person defines the accuracy of granularity and closeness at which he/she want to release his/her locations by using the Accuracy, Granularity and Closeness classes. Finally, and in order to support location generalization, the Location ontology uses a hierarchical model for location. Space is the top level class in this model, having five predefined subclasses, namely (from low to high accuracy): Building, Floor, Area, Section, and Position. Position establishes the Geographical or Absolute Position of an element, where several Positions form a Section which has two predefined subclasses, Corridor and Room. One or more Sections form an Area; several Areas form a Floor; and one or more Floors form a Building.

The Location ontology entities are related each other by properties. A portion of these properties are used to establish new relationships through policies. For example, authorization policies use the hasAuthzAccess property to link Persons and Spaces depending on the Person's privileges; location policies generate the hasCloaking and hasHiding properties between two Persons to mask and hide their location, respectively; and the hasRequesterGranularity and hasRequesterCloseness properties are established by the location policies to link Persons each other with a specific Granularity and Closeness.

The complete definition of both ontologies in OWL format can be downloaded below.
As a proof of concept and to show the ease of adding new ontologies to SeCoMan, we implemented a smart application called eCoMarket. It offers smart services to customers of a supermarket according to their location. eCoMarket defines an ontology called Supermarket that shapes the supermarket context. This ontology is depicted on the right hand side of the previous figure.

The top level class in the Supermarket ontology is Product, representing an article of the supermarket. This class inherits from Element of the Location ontology, so that this relation is the connection between both ontologies. As can be observed, a new ontology only has to inherit from the Element class of the Location ontology, or from one of its subclasses, in order to create a link between the two ontologies. In the supermarket context, it is worth noting that Products can have Discounts, and some of them can belong to a ShoppingCart through a ShoppingList which contains one or more ProductItems.

For clarity's sake, the next figure shows a graphic representation of a basic example about a given instance of the supermarket scenario, in order to clearly follow up all elements here introduced.
The next listings show a basic example defined in RDF syntax about the eCoMarket application.
In this example we have created entities of the classes defined in the Location and Supermarket ontologies. In this sense, related to the space information we have one Supermarket (line 1 in Listing 1) with one Floor (line 2), two Areas (lines 3 and 4), two Corridors (lines 5 and 6), and five Positions (lines from 7 to 11). At the supermarket, there are four persons: Peter, Natalie, Andy, and Margaret (lines from 12 to 15). They can use three different Roles (lines from 16 to 18), the OpenCashRegister privilege (line 19), the Granularity1 (line 20), the Closeness1 (line 21), and two different Accuracies (lines 22 and 23).

Related to the supermarket context, we have defined the Laptop and Tablet products (lines 1 and 2 in Listing 2), one ProductItem (line 3), one ShoppingList (line 4), and one ShoppingCart1 (line 5).

In order to show how the previous individuals are related each other we depict the Listing 2. Peter has the GoldCustomer and Hidden roles (lines 12 and 13 in Listing 2) and he is located at Position1 (line 14). This position belongs to the ComputersCorridor (line 6), which is in turn located at ElectronicsArea (line 4). Peter has a ShoppingCart1 (line 15), which contains a Laptop (lines from 16 to 18). On the other hand, Natalie is located at Position5 (line 22) and she has the OpenCashRegister privilege (line 21). Position5 belongs to the PaymentCorridor (line 11) that is located at PaymentArea (line 5). Andy has the AnonymChild role (line 23), and he is located at Position4 (line 24) belonging to PaymentCorridor (line 10). Finally, Margaret is located at Position2 (line 25) and she has Granularity of Area (lines 26 and 27) and Closeness of Floor (lines 28 and 29). Position2 belongs to ComputersCorridor (line 7). Furthermore, the supermarket has two products: Tablet, whose price is 400€ (line 31), it is located at Position3 (line 30) which belongs to ComputersCorridor and PaymentCorridor (lines 8 and 9); and Laptop whose price is 1000€ (line 19) and it is located at Position1 (line 20). Both the ElectronicsArea and PaymentArea are located at the GroundFloor (lines 3 and 2) of the Supermarket Building (line 1).

The complete definition of the Supermarket example in OWL format can be downloaded below.