Received 18 May 2016; accepted 26 July 2016; published 29 July 2016

1. Introduction

Standardizing the Ontology and Information Model (IM), which normalize the semantics of various objects such as sensor devices, has been in progress. (In the following, we will call “the Ontology and IM” as simply “IM”, as far as not specialized cases.) In accordance with the requirements of expanding Machine-To-Machine communication (M2M), it has been required to share the events and measured data yielded by various types of sensors among multiple machines and equipments. In particular, the more emergences of the scalable and integrated computational environments using Cloud computing there are, the more demands to make an overlay network by integrating the various and ad hoc sensor networks there will be. In order to respond to these demands, it is also required to share the context in regards to these events and measured data yielded by various sensors in a system with the same views and granularities without any dependency on particular matters of their manufacturers. Accordingly, Ontology and IM which normalize the semantics including sensor expressions and meta data, should be generalized as much as possible. Additionally, it is crucial to provide them as a service by storing these Ontology and IM in a common repository.

So far, there have been multiple efforts and initiatives for standardizing the Ontology and IM in regards to the sensors expression. One of the representative Ontologies is that by the W3C Semantic Sensor Network Incubator Group (W3CSSNIG), which describes sensors, observations and the events around sensors [1] - [3] . Whereas, another type of the Ontology and IM which gives us the categories and attributes of sensors by defining a sensor as a component of an artificial structure has traditionally existed [4] [5] . In general, various Ontology and IM are required based on multiple viewpoints and the seamless integration among them are ideally expected. Thus, there have been harmonizing activities such as Sensor Standards Harmonization by the National Institute of Standards and Technology (NIST) [6] . However, it has appeared a little ineffective on the viewpoint of the structures.

The issues to realize the seamless integration among the Ontology and IM have still remained even today when the Internet of Things (IoT) has got momentum. For example, Sensor Capability Information Model has been defined newly in [7] [8] . According to their explanation, a comprehensive standardized information infrastructure that enables sensors in their fields to observe more precisely and to facilitate cooperative observation effectively, are often shortened. In particular, the current existing approach has been insufficient in order to express the various aspects owned by sensor devices. Therefore, it looks integration oriented. In their approach, a new structure as a sensing system which includes multiple physical sensors is modeled, and several capabilities are specified to express that structure. In particular, [8] explain to us about the case of Earth observation sensors in detail. However, they are specific in the field of Geospatial Sensors and not generalized. The current insufficient maturity level of the defined Ontology and IM, together with the integration among them has negatively affected the progress of IoT [9] . That is why most of IoT applications have a certain tendency of being isolated application silos. [9] also point out the issues of Semantic Sensor Network (SSN). These are definitely insufficient accounts to actuation and other realms for IoT and its complexity. Accordingly, the new IoT-Lite Ontology has also been proposed [10] . This is more integration-oriented due to the adding of new entities such as “iot-lite:Object”, “iot-lite:Service”, rather than the existing entity of “ssn: Device”. However, it still seems to be unclear to serve expressing structures implementing the elemental physical sensors. A weakness in integration among them could potentially become an obstacle for implementing applications with severe requirements in their specifications. For instance, aggregation and calculation processes from raw data observed from various sensors are definitely required in the case of capturing the physical measured quantities of the structures such as behaviours’ parameters in robotics. The weakness in integration as one of its qualities could force us to deal with them in ad hoc approaches, and it is quite unproductive.

The remainder of this paper is organized as follows. In Section 2 we talk about the related works, especially with respect to the Ontology for sensor fields. In Section 3, we detail our comprehensive IM. In Section 4, we clarify our assumptions about how our IM will be deployed into the implemented architecture and under use cases. In Section 5, we mention the results of our multiple evaluations and clarify our insights. Firstly, we will outline several related works, then, mention the results of our evaluation and how they correspond to our IM. Secondly, we deal with the encountered issues in our actual implementation, in particular, a semantics gap between our IM and IEEE1888. Thirdly, we discuss the operational requirements, and finally we assess the potentiality to the standardization. Section 6 is our conclusion.

2. Related Works

It is required to identify our targeting position before the survey of related works. Firstly, in Section 2.1 we clarify the corresponding position of our IM in a space categorizing the views of modeling and interpreting the objects. In Section 2.2, we talk about the related works corresponding to “Sensors in sensing” category, then in Section 2.3, we talk about the related works corresponding to “Sensors as Physical Components” category. Finally, other studies will be explained in Section 2.4.

2.1. Position of Our IM in the Space Categorizing the Views of Modeling

When categorizing the existing Ontology and IMs on the viewpoints of modeling and interpretations of the sensors, there are at least three categorical aspects about sensors as depicted in Figure 2. The first is “Sensors in sensing” on the left side of Figure 2. The second is “Sensors as Physical Components” on the right side. The

last is “Sensors from other viewpoints”. The major instance of the first category is Semantic Sensor Network (SSN) by W3C Semantic Network Incubator Group (W3CSSNIG) and it covers the Ontological items about event, stimulus and observations around sensors [1] - [3] . The second one is based on the Product Ontology which has mainly been developed in the area of the Continuous Acquisition and Life-cycle Support (CALS). When the sensor is regarded as a component, this Ontology is available for identifying the category of a sensor and specifying its features on the identified category, [4] [5] . The both of them have been expanded on individual motivation and needs during the individual developing stages. Most of the previous efforts to define the existing Ontology and IMs might reflect from any thoughts of these two categorical aspects, and some cases could include both of them. In this sense, there could be a distribution about how close individual Ontology and IMs are plotted to each side.

Our IM could mainly be placed in the middle area including both aspects. In particular, the Partial IM explained in later Section 3.1 and 3.2 are reflected from the concepts of “Sensors as Physical Components” in Figure 2. On the other hand, Partial IM with regards to Raw Event Data from Sensors and Aggregated Data mentioned in later Section 3.3 corresponds to the concepts of “Sensors in sensing” in Figure 2.

2.2. Category of “Sensors in Sensing”

As stated previously, the typical major work in this category is SSN by W3CSSNIG [1] - [3] . Except the works by W3CSSNIG, multiple projects have tried to define similar frameworks. For example, the national project titled as “The George E. Brown Jr. Network for Earthquake Engineering Simulation (NEES)” had also disclosed their IM on the specification document [11] . [12] is the summary of their IM. In the NEES documents, they explicitly defined their requirements on sensors, such as the requirement to categorize sensors as types; furthermore they also defined the configuration model titled as “PrimaryEquipment” and “SecondaryEquipment”. They also touched on the standard for the exchange of product model data, ISO-10303 Industrial Systems and Integration-Product Data Representation and Exchange (STEP) which is introduced in the next section. However, their adoptions, especially the specifying the requirements around sensors seemed to be not rigid enough. In particular, their definition levels on the conceptual categories and attributes for sensors had remained at the following level; “sensorType” as a string is information sensed by the sensor, e.g. acceleration, pressure, displacement, strain and temperature, etc. The “outputQuantity” as a string is quantity that sensor puts out in response to the input, it can be voltage, current, charge, or human read. We have considered this level seems to be insufficient and vague for the category and attribute definitions, if aiming to establish the interoperability with using sensors. Therefore, they seemed not intent on having the exact definitions on sensors on IM, because of their rudimentary level of the definitions.

There are other works, in which the context of observation, and use cases were independently dealt with. We can find out an instance of them in [14] . In accordance with the more expansion in grasping spatial and temporal events by sensors, there have been more demands in e-science whereby the results and contexts of the observations should be more thorough. In order to describe the actual observations more closely, they should be tagged with location, time, ownership, instrument and measurement. The actual data management in scientific fields has generally been specialized on individual area without normalization across them and it was difficult to exchange the data beyond the borders between fields. In their work, a guidance of IM in related to query containing What, Where, Which, When and Who is provided in order to clarify the definition scenario more. Furthermore, it also provides the basic viewpoints for defining the Ontology in a wide sense. However, there are very few explanations about the relationship with SSN.

In general, our work should be regarded as a new instance of the Ontology integration in the sensor domain. Another instance which aims at a similar purpose is for example the work explained in [15] based on the modularity. This is the work to orient the integration between sensors and Semantic Web. And they provided the novel semantic definition focusing on the sensor networks domain, and methodology to contribute interoperability, in order to tackle the issues derived from inexistent standards to realize the interoperability including high level knowledge among systems. In this work, they proposed their modularity and extension and mentioned the following three domains; External, Main and Extended domains. Furthermore, they depicted the semantic network structure showing the multiple relationships which a sensor instance has. The Categories and Attributes in our sense are expressed as Features. However the capability of expression seems to remain at the general level and they are implemented in OWL.

2.3. Category of “Sensors as Physical Components”

In [5] , the essential structure of the Common Information Model (CIM) in RDF version of IEC61970-501 applied for smart grid is introduced as Figure 3. This is closely related to the previous PLIB. As shown in Figure 3, a class may have relationships to single or multiple properties, individual of which has the own data type. And classes related to a sensor must obey the above constraint. In [20] , the concrete instance specified by PLIB of sensors and the Product Ontology is introduced. In this work, they evaluated the actual efficiency by applying PLIB in the sensor field.

2.4. Other Categories

Besides the areas in previous sections, there are several related studies. In this section, some of them are intro-

duced. [21] is about dealing with the real time data generated by multiple sensor networks with definitions of spatial and temporal aspects, and this is oriented towards harmonizing with Geographic Information System (GIS). It includes their definition of IM containing sensors. Their IM does not contain the configuration aspect specified in PLIB and categories, although it involves the sensors’ aspects and agility. However, there are several points which we should refer to, such as harmonizing with GIS and defining a measurement consisting of relationships with multiple sensors.

[22] mention the aspect of process and architecture in integrating the multiple sensor networks. This is an explanation on the viewpoint of users of the Ontology, rather than the theory related to integrating the Ontologies. However, three instances of the Ontology are referred when translating a raw XML instance by the (Resource Description Framework) RDF Wrapper during processing these data gained through the observation with a dynamic aspect. In particular, in their RDF common model, Sensor class represented by several items such as identification, type, characteristic, temporal and spatial attributes, and Measurement class, are contained. Furthermore, the Observation and Measurement (O&M) standard is adopted. Therefore it has a close relationship with our work.

[23] propose the novel approach related to the advanced aggregation functionality, and touches on the architectures of data processing. In particular it mentions the characteristics of data and how to represent them. This suggests several important points. However, the following point as one of our motivations is still vague; how to make an interpretation from raw sensors’ data under the constraints from surrounding structures.

3. Proposed Information Model

Our IM mainly consists of the following four sub parts. The words contained in round brackets mean the schema name representing the corresponding part, and by using the prefix, the individual class assigned to which part is indicated. Furthermore, common classes across the four parts are tagged with the prefix “COM”.

1) Partial IM of Metadata in regards to Sensors and Measured Objects. (Metadata (Prefix: META))

2) Partial IM in regards to Configuration and Deployment of Sensors and Structural Measured Objects. (Configuration (Prefix: CON))

3) Partial IM in regards to Raw Event Data from Sensors and Aggregated Data. (Data (Prefix: DATA))

4) Partial IM in regards to Data Accessing. (Permission (Prefix: PER))

Besides the above four partial IMs, we define some partial IMs such as classes for managing control targets. However, these should be omitted here because of their minor roles. The adopted notation for the above partial IMs is the class chart of UML (Unified Modeling Language).

3.1. Partial IM of Metadata in Regards to Sensors and Measured Objects

Figure 4 shows class organization of this partial IM, and Table 1 gives us the definitions of individual classes.

This partial IM deals with set of categories with respect to sensors and measured Objects, and attributes to define the features of categories. Typical instances of the above category of a sensor are for example “Optical Sensor” and “Current Meter”. And typical instance of an attribute is for instance “Current” as the physical quantity for “Current Meter”. Class (META) Category which means the above category has conceptually the equivalent structure of that in ISO/IEC11179 [26] . We specialize this class into particular sub categories such as class (META) DeviceCategory and class (META) ProductCategory depending on the targeted type; a sensor or a measured Object. In order to specify and identify the features of individual category, a category has relationships to one or multiple instances of class (META) Attributes. In Figure 4, we express it in a term “Attribute” based on the concept of ISO/IEC11179. However, we have another term in the equivalent concept, “Property” in CIM (Common Information Model) of IEC61970. We also specialize this class (META) Attribute according to a sensor or a measured Object. As each of the features is related to a physical unit and measured conditions, class (META) Attribute has relationships with class (META) Unit and class (META) MeasuredCondition. Class (META) Attribute also has an aggregatable structure itself to be able to have a structural data type. Only class (META) ProductAttribute has a relationship with class (META) StatisticsType. This is because of our interpretation that an entity which carries out the aggregation process of the measured data yielded from sensors, is only the measured Object embedding the sensors, rather than the sensors themselves. In this sense, our interpretation in the practical operation is regarded independently from the context that a sensor has the own internal structure, although we explicitly define class (CON) SensorSystem in Figure 5. This is substantially independent from the semantics in SSN by W3CSSNIG, which will be mentioned later. It is quite usual that the categories and attributes receive some maintenance for long term since being released. Even after being maintained, it is still required to refer the previous state of data in regards to the categories and attributes. Therefore, we need to adopt a version management. Accordingly, we also need to identify the validity of a version such as “Obsoleted” or “Valid”. Class (COM) Status which means the condition of the instance is commonly referred to for this purpose by several classes in the figures.

3.2. Partial IM in Regards to Configuration and Deployment of Sensors and Structural Measured Objects

3.3. Partial IM in Regards to Raw Event Data from Sensors and Aggregated Data

Figure 6 shows class organization of this partial IM, and Table 3 gives us the definitions of individual classes. This partial IM primarily deals with the classes to express event data yielded by sensors and aggregated data. However, at the top layer of Figure 6 the relationships around class (CON) Sensor are also depicted for expressing another aspect. There are two subclasses for (CON) Sensor. The first is class (CON) GenericSensor. This is applied for generalized sensors of which an industrial standard organization such as International Organization for Standardization (ISO) specifies the standardized features. These features are usually specified in the published documents. In this case, an instance of class (META) DeviceCategory is referred as obeying the class organization in Figure 4. The second is class (CON) CustomizedSensor. This is applied for exceptional cases. Due to the rapid expansion of sensing technologies, there are potentially some special cases where a specialized sensor is developed without any standards. Accordingly, this class (CON) CustomizedSensor is prepared for these exceptional cases. In these cases, this class has the direct relationship with class (META) DeviceAttribute, because we must describe the features of sensors for whatever reasons, even though there is some ambiguity in specifying the category of the sensor.

Class (CON) Sensor has relationship with class (DATA) RawDataFromSensor, an instance of which is equivalent to the individual event yielded by a sensor. In this class, the items in regards to a physically measured quantity and the timestamp are included. Class (DATA) RawDataFromSensor can be aggregated within its

own structure, because the referred class (META) Attribute by this class also has an aggregatable structure to be able to have a structural data type as mentioned. Accordingly, subclass (DATA) SetOfRawDatafromSensor for aggregating instances of another subclass (DATA) ElementalRawDataFromSensor meaning the class for an elemental data is also defined. Class (CON) MeasuredObject has the indirect relationship with class (DATA) Extracted Fact Data for Object through class (DATA) ObservedObjectDataManagement that manages the aggregation and the context. The aggregation will generally be carried out on various viewpoints. Accordingly, this class (DATA) ObservedObjectDataManagement functions as the superior manager of set of instances of class (DATA) ExtractedFactDataForObject in order to maintain the various meta data of these viewpoints. Furthermore, class (DATA) ExtractedFactDataForObject has a relationship with class (META) ProductAttribute, because this class has the nature of aiming at features of the specified measured Object.

Figure 7 includes a graph of time series values of a physically measured quantity plotting by timestamps, both of which are recorded on the instances of class (DATA) RawDataFromSensor. In this case, the new instance of class (DATA) RawDataFromSensor arises within Δt as an average interval. On the other hand, there are also two graphs corresponding to other instances of class (DATA) ExtractedFactDataForObject in Figure 7. They are tagged by labels “series.1” and “series.2”. Class (DATA) ObservedObjectDataManagement corresponds to the class of managing the meta data in the aggregation such as these “series.1” and “series.2”. Regardless of number, the instance of this class can be generated depending on the aggregation conditions and context, such as how to manipulate the instances of class (DATA) RawDataFromSensor. The depicted cases in Figure 7 are assumed with only single sensor. However, the cases of multiple sensors regardless of categories can be also accepted. And class (DATA) ExtractedFactDataForObject has the relationship with class (META) ProductAttribute in Figure 6, because of referring to an instance of the MeasuredObject directly. Furthermore, in order to generate an instance of the class (DATA) ExtractedFactDataForObject by using multiple instances of class (DATA) RawDataFromSensor, there is another relationship as a constraint between them. Figure 8 depicts an example of models of the constraint. Class (CON) AttributeConstraintsForMeasuredObject is the class to manage the constraint conditions by specifying instance set of class (META) ProductAttribute, which individual instance of (CON) MeasuredObject has. An instance of the class (CON) AttributeConstraintsForMeasuredObject marshals instances of classes (CON) SpeficiedDeviceCategory and (CON) SpecifiedDeviceAttribute. These classes specify which instances of the class (META) DeviceAttribute under the class (META) DeviceCategory are related in the constraint. It is allowable to specify the complicated cases using multiple types of sensors as mentioned. However, the actual organization is influenced from the aspect of algorithms in aggregation process, and also relies on the individual requirement. Therefore, we have avoided putting the constraint into the class organization explicitly.

3.4. Outline of Partial IM in Regards to Data Accessing

This partial IM primarily deals with classes and relationships for the authentication and authorization for data access. We do not adopt the role based access control model (RBACM) in order to avoid increasing number of

classes, although it is general to apply the RBACM [27] . Detailed information with regard to this is omitted in this paper due to space constraints.

4. The Relationship between Information Model and Implemented Architecture

In this section, we clarify our assumptions about how our IM will be deployed under the configuration of the implemented architecture and use cases. As mentioned in [28] , the major stream of IM for the Smart Grid area is based on CIM as IEC61970. However, we have believed that there are potential requirements in regards to harmonization with the new architecture which has the overlay features, when considering how to take legacy and proprietary configuration into the new architecture. Our current implementation adopts IEEE1888 as specified in [29] with some modifications. Figure 9 depicts the network architecture specified in IEEE1888.

According to [29] , the outline of the architecture is specified as follows; “Gateway component has physical sensors and actuators. It generalizes the data model and the access method for those devices, encapsulating each physical (field-bus) data model and access method. Storage component archives the history of data sequences. The written values from other components should be permanently stored in the backend disks. It provides the archived values to the components that have requested them. Application component provides some particular works on sensor readings and actuator commands. It can have user interface to display the latest environmental state. It can also allow a user to input some schedules of actuator settings, and it can as well analyze some sensor data in real time and provide the result as a virtual device. Finally, Registry works as a broker of GW, storage, and APPs. The main role of registry is to bind those components appropriately and autonomously. It is separated from the data-plane.”

Figure 10 depicts the modified deployment chart in UML based on the elements in Figure 9 and shows how to deploy the classes and schemes of our IM which were defined as four partial IMs in Figures 4-6. According to the requirements of the implementation, APPs and Storages defined in Figure 9 should be specialized more as shown. The instances of any classes under the schema (DATA) such as “(DATA) RawDataFromSensor” are stored into the individual Storages. Whereas any other instances of any classes under other schemas besides (DATA) are deployed into the Registry (Repository). In particular, we assume that the Registry (Repository) should be implemented in singleton according to the characteristics of this functionality, in which the management of meta data should be centralized. However, the actual implementation of it, whether it would be implemented in singleton or decentralized approach with replicas, could depend on the requirements in regards to scalability. “(DATA) RawDataFromSensor” as event and measured data from sensors should be deployed in the spread distributed Storages because of the requirement of scalability. Accordingly, the cardinality constraint on them is specified as more than one. On the other hand, “(DATA) ObservedObjectDataManagement” and “(DATA) ExtractedFactDataForObject” which are related to aggregation, strongly depending on the meta data. Therefore, both of them should be nearly allocated to the Registry (Repository) with the close connecting, in order to avoid a needless latency caused by accessing these meta data under the distributed management.

5. Evaluations and Consideration

In this Section, we mention the results of our multiple evaluations and our consideration. In this paper, we do not touch on the evaluation from the viewpoint of aggregation for the specified structure, because the actual organization is influenced from the aspect of algorithms in aggregation process, and this seems to be beyond the scope of our paper. Therefore, the following four items are focused on. Firstly, we explain the relationship between our IM and the existing Ontology and IM, in particular, Semantic Sensor Network (SSN) by mentioning the correspondence to our schemas in Section 5.1. Secondly, we deal with the encountered issue in our actual implementation, in particular, a semantics gap between our IM and IEEE1888 in Section 5.2. This suggests to us that there is a certain requirement to put another class having a role for bridging and accommodating the structure and the granularity of the scope of observation. Through the implementation, we revealed that there is still insufficiency in our IM. Thirdly we mention in Section 5.3, issues in the practical operations. Finally, we evaluate the potentiality of standardization in Section 5.4.

5.1. Comparison to SSN

SSN by W3CSSNIG that corresponds to the “Sensors in sensing” in Figure 2, has been reported comprehensively in [1] . [3] is a partial survey on multiple projects relating to the standardizing effort. The report in [2] corresponds to a summary of the previous [1] . And [30] discusses on the efforts of the existing IM of sensors and Semantic Sensor Web. SSN ontology was defined as Web Ontology Language (Second Edition: OWL2), and gives us the semantics of sensors and Observation related to these sensors. There are four remarkable features as follows: the first is to define the pattern of “Stimulus-Sensor-Observation”, that means the relationship among the sensors and the events captured by these sensors. The detail is depicted in Figure 11 (the original figure is Figure 2 in [2] .) The second is to assume that multiple ontologies are combined. We can confirm the relationships among multiple Ontologies in SSW as depicted in Figure 12 (the original figure is Figure 2 in [30] .) The third is an indirect relationship with the items “Unit of Measurement”, “Hierarchies of Sensor Types” and “Features”. They are explicitly dealt with in the Product Ontology. And the last is to contain the following four perspectives: The first perspective is the sensor perspective which focuses on what senses, how it senses such as degree of precision, and what is sensed. The second is the system perspective which focuses on systems of sensors and deployments. The detail is depicted in Figure 13 (the original figure is Figure 4 in [2] .) In the scope of the deployments, the various lifecycle stages such as “Installation”, “Maintenance” and “Decommissioning” are also contained except “Location”. The third perspective is the observation perspective which focuses on observation data and related metadata and the fourth is a feature and property perspective. The former observation perspective is related to the context of a stimulus as an input shown as the pattern of “Stimulus-Sensor-Observation”. And it corresponds to judgement of an event. The later feature and property perspective focus on what senses a particular property or what observations have been made about a property.

Figure 14 depicts the correspondences between SSN and our defined IM. The major differences between them are as followed:

1) There are differences on the aims and use cases between them. Our IM is mapped on the different meta category from that of SSN, when we apply the meta category about modeling features such as “conceptual model level” and “implementation model level”. SSN tends to remain at the conceptual model level, and gives us the comprehensive semantics and contexts. Whereas, in our IM, some constraints for implementation such as those

in Figure 8 and several items pointed out in Sections 3.1, 3.2 are also included. Based on this, there are some risks to retain our IM at more narrow sense. This derives from our intention that aggregation from the raw data yielded by the sensors should be treated on the middleware layer which manages our IM, instead of the layer of user application programs.

2) Our IM will give a context in regards to the phenomenon and the role around that sensor from the point of views of the structure containing that specified sensor, rather than the simplified aggregation sets of the sensor seen in general.

3) In spite of the aspects that a sensor has as a product, SSN seems to have a lack in viewing sensors explicitly on these aspects. Otherwise, the meta data in our IM prioritizes to be as a part of “Product Ontology”, sensors and measured objects are explicitly categorized and having a set of attributes to express the physical quantity. SSN has a tied relationship with OGC (Open Geospatial Consortium), and are influenced from the remote sensing area. In other words, some dependency on the particular application areas might be allowed and accepted for SSN.

The following explanations are the results of individual comparison seen in Figure 14. In our schemas such as Common, Metadata, “Unit of Measurement”, “Hierarchies of Sensor Types” and “Features” which are not regarded as the primary roles in SSN, are treated explicitly. Therefore, it is difficult to identify the direct correspondence between our Common, Metadata schemas and perspectives in SSN. However, as the sensors and features are definitely referred to, we believe that there must be some indirect links. On the other hand, Sensor Perspective of SSN explicitly includes items in regards to “Accuracy” and “Resolution”, although our IM does not include the corresponding identifiable classes. Our IM does not deal with these items, because they can generally be defined as instances of class (META) Attribute. In the remote sensing applications which SSN might primarily target, the accuracy is one of critical factors. Thus, due to these differences in background, the above conceptual gaps might arise.

Our Configuration schema corresponds to the System Perspective of SSN, although that remains at an incomplete matching. For instance, the deployment in SSN contains not only location, but the aspects of lifecycle as well. Whereas, we recognize that it corresponds to updating the state of the structures expressed as the measured Objects. And that should be handled by updating the current version of instances of class (CON) MeasuredObject. Both are considered about temporal aspects, however it is not the complete correspondence.

As for both following Perspectives in SSN, Observation Perspective and Feature & property perspective, there are some ambiguities in their correspondences to our IM. The former is related to the interpretation and context in regards to stimulus as an input specified in the Stimulus-Sensor-Observation pattern, and corresponds to judgement norms for event data. This superficially corresponds to our sub schema containing class (DATA) ExtractedFactDataForObject. However, we can recognize some differences between interpreting the aggregation results produced from events and measured data yielded by sensors in SSN and those of our IM. Accordingly, they are not conceptually in the complete correspondence. Furthermore, in some cases, interpretation during the Observation might be totally independent from just aggregating events and measured data yielded by sensors. Thus, it is hard for both Perspectives to neglect the relationships to class (DATA) RawDataFromSensor completely. Correspondence to our Permission Schema is not explicitly treated in SSN, because of its nature with regard to practical implementation. Therefore, there are no obvious relationships from our Permission Schema in Figure 14.

5.2. Revealed Issues in Actual Implementation

The relationship is obviously simple when we make a correspondence between a sensor and a “Point” within interpretation of one-to-one. In this case, we can identify the “Point” by using the deployment information of the sensor. However, when we need to handle some complicated cases, such as sensors having the internal configuration due to their complication or sensors being expressed with multiple properties and attributes, it is required to adopt a conceptual model like CIM depicted in previous Figure 3. According to the nature of the “Point”, that should be specified by the combination consisting of the identification of the specified sensor and the specified attribute which the category of the mentioned sensor has. In this case, the sensor itself should be mapped to an instance of “PointSet”, and it is not conceptually equivalent to mapping to the “Point”. When specifying the attributes of the sensor due to the above background, only adopting IEEE1888 becomes insufficient for handling the complete information. Therefore, it is needed to implement a query processing to the Registry (Repository) in order to gain an attribute set of the specified sensor. And this procedure should be carried out as an unconventional preprocess of the protocol defined in IEEE1888. These treatments derive from the narrower scope of information defined in IEEE1888.

Furthermore, we also have concerns about the difficulty in specifying the values of attributes related to the category of the specified sensor, when considering the practical operations. Usually the compliance from standards including specifying these attributes is necessary, when a categorized sensor as a product is released into actual markets. However, complying with these by the standards completely sounds empirically difficult. Without complete compliance, it would not be guaranteed to gain or prepare the required information. This could cause some cases where values as the physical quantity yielded by sensors in unconformity could not be managed in the storages in order. If we were to ignore these compliances, the functionalities such as seeking suitable sensors to traverse by applying the standardized Ontologies, and calculating group averages among huge numbers of sensors, would depend on the high cost preprocessing, because of taking individual differences in configuration and features into account. Thus, we could greatly lose the performance of operationalization.

5.3. Issues in the Practical Operations and Potential Solutions

In this section, we mention the issues in the practical operations and their potential solutions

1) Due to the rapid expansion of sensing technologies, the new types of sensors which are based on the new principles of sensing, measuring, and new products have always been, invented, developed and commercialized. Thus, we need to take into account how deal with these new emerging, specialized and customized sensors. Clearly, we need to consider not only the treatment for generic sensors, but also that for customized sensors, a typical instance of which we can see in the remote sensing area. Even for customizing cases, we rigidly need to define the attributes of these categories and comply with them. In maintaining the Metadata schema, we need to start from creating an instance of class (META) Category due to constraints from reference as seen in Figure 4. However, it is really commonplace to become a time consuming work when trying to define the type of a sensor rigidly until being a matured definition, because it must rely on experts’ knowledge and discussions. Therefore, in our IM, we implemented the class (CON) CustomizedSensor, and also prepared the space for instances of class (META) DeviceCategory named as “emerging sensors”. So that, we can handle these exceptional cases in the new emerging, specialized and customized sensors, by specifying that instance “emerging sensors” and making direct links between the instance of class (CON) CustomizedSensor and new created instances under the class (META) DeviceAttribute. When dealing with modeling, it should be considered a practical and operational requirement.

2) When importing the data contents of the Metadata schema from multiple data sources to make the Metadata be more of an expressional richness, we need to clarify the contexts of instances of class (META) Attribute in the importing process. In our actual evaluation on the class organization in Figure 4, we referred to the ECALS dictionary which has a strong reputation [31] . However, we found out that there were some shortages of definitions, especially for that of (META) DeviceAttribute in that dictionary. For instance, we could not find anything about “Electric Current” for “Electric Current Sensors”, rather than the defined “Terminal Value”. This is because this dictionary was originally aimed to establish standardized expressions of the electronic components and devices mostly for electronic commerce, and there are some mismatches of the purposes with others like SSN. Eventually, these mismatches derive from the differences of viewpoints related to use cases. Therefore, it is naturally required in defining the instances of class (META) Attribute, to use them differently for different objectives after clarifying their suitable contexts. This seems to be related to the two relationships of “Is_De- fined” and “Is_Applicable” between the Properties and the Classes in PLIB of ISO13584-42 [4] [16] , as already pointed out.

5.4. Evaluations on the Potentiality of New Standardization and the Native Flexibility

Finally in this section, we evaluate our proposing IM on the two viewpoints about the potentiality of new standardization and the native flexibility. As for the possibility to the new standardization, it is still insufficient and there is room for improvement because of the following two reasons: The first reason is its insufficient basic stance. The two following points are to be considered: the first one is to reveal several issues that have arisen in integrating pieces in the multiple standards, which have evolved independently or under loose relationships in their focused domains. And the second is just to propose some potential solutions with evaluation results. In this sense, our work is not intentional for establishing the new standards.

The second reason is the native orientation which our IM has. Based on the following assumption on the standardization activities, it is obvious; as the industrial standard should be defined to establish a common understanding on the trendy major challenges at that time, the targeted challenges and basic models, furthermore stances and strategies on them could naturally change according to expansion of the focused areas. In this sense, it might be quite difficult that a standard itself can enjoy its own position without any evolutions or declinations. Accordingly, it should be naturally accepted that the standards themselves should have changeable and integrative abilities as their natives. In the case of the natives of IMs, it might be more general to express them as a conceptual and meta model rather than those as an implementing and architecture oriented model. However, there are naturally certain cases where IMs themselves should be reconfigured at the implementation stage due to solving various constraints. As mentioned previously, our IM is not purely oriented to a conceptual model, and partly includes some elements influenced by the implementation. This means that there is certain disadvantage for standardization in what it is natively.

As our conclusion, we can say here that there are still some issues for being contributable directly to standardization activities without any improvement; however we can also highlight that our IM has sufficiently the flexibility, the capability to which has been required in standards for a long time. In particular, it is still difficult to completely exclude the caused ambiguities when importing and integrating with another independent element, although there has been a long term effort to develop and improve on the modeling sensors themselves, their behaviors and their contexts by many initiatives such as SSN. This fact about that ambiguity suggests that there are still other potentialities of similar risks in future due to another requirement about importing an independent element. In this sense, it should not be negatively conservative to consider establishing a new standardization which can be responsible for the requirements of sensitivity to the integration. We believe that due to our work on this IM, we can make a sufficient contribution towards this.

6. Conclusions

In accordance with expanding the network overlay, it is foreseeable to increase the opportunities of the data integration in sensor network areas. Accordingly, we presented our IM, which is highlighted on the integration from the point of view of a structure containing the specified sensors in this paper. Our IM is proposed due to responding to the potential requirements for suitable solutions to the above. The above points have been vague in the existing Ontology and IM. Additionally, we pointed out the issues through our following evaluations; comparison to the existing Ontology and IM, and mapping it to the actual implementation. The comprehensive conclusions are summarized as follows:

1) We clarified the relationship between configurations and physical measured quantities of the structures implementing a set of sensors.

2) As the results of comparison to SSN, we reconfirmed that our IM is oriented to architecture and actual implementation due to taking the practical operations into account.

3) However, we confirmed that we could relatively make a balance in building our IM by integrating the partial related Ontologies and IMs which have individual backgrounds and outlooks. Furthermore, we also confirmed the differences between them. And we also confirmed the pros and cons for pushing the standardization. In particular, those in the native flexibility were identified.

As for the future works, the above provisions should be verified more through the actual implementation. And it is also required to purify our IM more into a conceptual and meta model which is contributable for the standardization. Furthermore, we have also felt that it is required to clarify the meta features in regard to “acceptability and flexibility to integration” across the partial Ontologies and IMs.

Acknowledgements

Prof. Hayashi of the University of Aizu gave us several helpful comments on this research. Here, we express our appreciation and gratitude.