• No results found

3.3 Interaction with Data Warehouse

3.3.3 Creation of new annotations

In Java, annotations are a form of metadata which provide data about a Java program that is not part of the program itself. Annotations can be used to provide the information for compile-time and deployment-time processing and runtime processing. [105] It is possible to create meta-annotations out of the existing ones in Java. [106] On consideration about the demands expalined above, a mechanism has been designed to instruct the Model Manager about where and how to persist a Java object by creating a set of new annotations for the use in this developed IoT platform.

The Java Classes to be persisted should follow the pattern of Plain Old Java Object (POJO), i.e. only have variables and the getters and setters for each variable. As these objects should be a reflection for the data persisted in the Data Warehouse, this convention is not going to result in sacrificing of expressiveness.

By adding annotations in one Java class, the class can be integrated with the platform and benefit the data persistence process of Model Manager without changing its class structure.

54 Background and preliminary work The instances of the Java class will be persisted to relational database or ontology triple store according to their annotations.

The new defined annotation set (Fig. 3.12) consists of three parts: general annotations, annotations for relational database and annotations for ontology. By the creation of this annotation set, the issues including data storage instruction, ontology concepts registration and most importantly, data consistency guarantee in Data Warehouse has been solved .

Data Storage instruction and configuration

Having a class to persist, the first problem to solve is which storage(s) to choose. For telling this, we have defined two class-level annotations, @OWLClass and @RDBClass.

• If a Java class needs to be persisted partly or fully in the ontology triple store, the annotation @OWLClass should be provided with the corresponding concept name, such as @OWLClass("bat:User"). The annotations @OWLDatatypeProperty and @OWLObjectProperty inside of a class will be ignored if the class does not have @OWLClass.

• If a Java class needs to be persisted partly or fully in the relational database, the annotation @RDBClass should be provided with the corresponding table name. A class with @RDBClass("user") will be persisted to the table named "user" in database. The annotation @RDBAttribute inside of a class will be ignored if the class does not have @RDBClass.

Concept Registration in the platform

For each class to persist to ontology, by providing the information in @OWLClass and @Namespaces, it is able to register a series information in the ontology structure of the

platform:

• @Namespaces provides a list of mapping between the prefixes and the corresponding

URL such as "bat:www.cedint.upm.es/bat.owl]". If the defined prefix is already

registered with another URL, an exception is thrown.

• @OWLClass("conceptName") provides the corresponding concept URL of the class in the ontology.

3.3 Interaction with Data Warehouse 55 Fig. 3.12 Annotation set created in the platform

56 Background and preliminary work

Data consistency between ontology and relational database

In the case that one class is stored in both ontology and database, an unique identifier is necessary for identifying the same object in both of these two storage. Fig. 3.13 illustrates how the same Java object is persisted into both storages.

Fig. 3.13 Ontology storage and relational database schema

• The annotation @Id is defined for achieving this objective. It is obligatory to put @Id for one and only one Primitive/Primitive Wrapper field of the class. The annotated field will be used as the primary key in the database and as the reference to generate individual URL in the ontology. During the persistence process, data consistency is guaranteed as the data come from the same object, as shown by theow (1).

• During the retrieval process, Model Manager retrieves the data of each fields according to the same id passed and unifies them in the same object. If the data of the same field

3.3 Interaction with Data Warehouse 57

is different in the two storages, an exception will be thrown. As shown by the arrow (2), if the value retrieved from the System for property bat:name and value retrieved from RDB for column Name are different, an exception will be thrown.

Storage of attributes of concepts and relations among them

In a Java class, one field could be of type Primitive/Primitive Wrapper or an object/collection of objects:

• If the field is of type Primitive/Primitive Wrapper, it will be stored in the ontology as an attribute of the concept if the annotation @OWLDatatypeProperty provided, while if @RDBAttribute is provided, the field will be stored as a column in the corresponding

table.

• If the field is an object or a collection of objects, if a @OWLObjectProperty() is provided, this relationship will be stored as an object property between the annotated field and the current class. While, in relational database, the cases could be more complicated. Considering the different cases of fields inside of a Java class, an option cascade() is provided for @RDBAttribute to indicate the manner used to store the data:

– CascadeType.TOSTRING, indicating that the field is converted as a String to be

stored in the corresponding column.

– CascadeType.MERGE, indicating that all the fields inside of this annotated field

will be retrieved and stored in the same table of the class.

– CascadeType.RECURSIVE, indicating that the annotated field will be stored in a

separate table with a foreign key consistent with the primary key of the current class.

Data Retrieve confidentiality and efficiency

Considering the efficiency and security of data retrieval, an option displayLevelis provided in both of the annotations. It indicates the level to which the field value is exposed:

• DisplayLevel.CONFIDENTIAL, for the confidential information such as a password or a secret key.

• DisplayLevel.PUBLIC, for the fields that should be shown or retrieved in all kinds of methods.

58 Background and preliminary work • DisplayLevel.SPECIFIC is the default option, which is used for those field that should

not be exposed when a list of objects are retrieved at the same time.

In Model Manager, those methods for retrieving data can define the displayLevel. The information will be exposed only if its displayLevel is higher than the level specified in the retrieve method, the sequence is PUBLIC >SPECIFIC >CONFIDENTIAL.