Computers & Geosciences 56 (2013) 45–55
Contents lists available at SciVerse ScienceDirect
Computers & Geosciences journal homepage: www.elsevier.com/locate/cageo
A direct registry service method for sensors and algorithms based on the process model Nengcheng Chen n, Xiaolei Wang, Xunliang Yang State Key Lab for Information Engineering in Surveying, Mapping and Remote Sensing, Wuhan University, 129 Luoyu Road, Wuhan 430079, China
art ic l e i nf o
a b s t r a c t
Article history: Received 3 December 2012 Received in revised form 5 March 2013 Accepted 7 March 2013 Available online 21 March 2013
To characterize and monitor environmental quality in real time, significant efforts must be made to make sensors accessible on the Web. Although a number of services have shown great potential to improve the accuracy and reliability of sensor registry, comprehensive methods that register sensors and algorithms in a catalogue service based on a process model are lacking. This paper addresses the registry of processes, including physical and non-physical processes, by using the OGC catalogue service. To provide more information on sensors and algorithms, the process catalogue information model extends the ebXML Registry information Model. The mapping between the metadata encoded in SensorML and the extended model includes more information for all types of processes. Moreover, the mapping includes the relationship among processes and their categories based on the properties of sensors and algorithms. The effectiveness of the improved model is registered and implemented in GEOSENSOR CSW, following the OGC “transaction” interface. Flooding experimental results demonstrate that the service can effectively and directly register sensors and algorithms so that processes can be flexibly executed according to users' demands. & 2013 Elsevier Ltd. All rights reserved.
Keywords: Sensor registry Algorithm registry Catalogue information model Process model CSW
1. Introduction Existing sensors, including in-situ, airborne, and spaceborne sensors, will be Web-ready in the future. A large number of algorithms exist to describe the mathematical operations of sensors. Sensors and algorithms require effective management on the Internet. In the Sensor Web, the metadata for data and services could be registered in a catalogue that enables users to locate, access, discover, and make use of such resources through the catalogue service (Chen et al., 2009; Pandey and Patel, 2009). These methods (Park et al., 2007; Parhi et al., 2010) provide facilities for retrieving, storing, and managing numerous kinds of resource. The management of sensors and algorithms based on the process model remains lacking, and will become an increasingly urgent matter in the Earth observation community. Therefore, a catalogue service must be built to manage processes given the large number of sensors and algorithms in use. Processes in Sensor Web Enablement derived from AbstractProcess are conceptually divided into two types (Botts and Robin, 2007; Botts et al., 2007; Chen et al., 2012): (1) non-physical or “pure” processes (ProcessModel and ProcessChain), which can be treated merely as mathematical operations and (2) physical processes (Component and System), such as detectors, actuators, and sensor systems, where information regarding their positions and interfaces may be relevant.
n
Corresponding author. Tel.: þ86 13886019231; fax: þ86 27 68778229. E-mail address:
[email protected] (N. Chen).
0098-3004/$ - see front matter & 2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.cageo.2013.03.008
Processes are encoded in standard models and in XML Schema, which is the core information model (SensorML) in the Sensor Web. SensorML provides descriptions of sensors and algorithms needed for sensor management as well as for the location of sensor observations, processing of low-level sensor observations, and listing of testable properties (Broring et al., 2011). All processes in SensorML can provide inputs, outputs, parameters, and additional information. The information required for resource discovery, qualification of results, and for assistance to humans are included within MetadataGroup, for example, the properties of identification, classification, and capabilities (Jirka et al., 2009). So the registry of process models should include the above information. The proposed registry service has a specific registry model which needs a normative XML Schema for the representation of registry objects. Current registry models include Universal Description, Discovery, and Integration (UDDI) (Clement et al., 2004) and the ebXML registry information model (ebRIM), both of which are sponsored by the Organization for the Advancement of Structured Information Standards (OASIS). The UDDI specification does not adequately facilitate the autonomous discovery and interoperation of disparate Web services, while ebRIM enables the sharing of content and metadata among organizational entities in a federated environment (Fuger et al., 2005). The ebRIM constitutes a public schema that specifies how the catalogue content should be structured and interrelated for discovery and publication purposes, using a set of classes and the relationships
46
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
among these classes (Chen et al., 2009).The process registry service would use ebRIM to specify the metadata for process models. But it is necessary to provide a common vocabulary that extends the abstract information model (ebRIM) and supports the display, retrieval, and search of the processes in process registry service. The CSW-ebRIM profile, which is developed by the Open Geospatial Consortium (OGC), provides guidance for the registration of metadata. The proposed registry service could apply the OGC–CSW interfaces to ebRIM to provide a general and flexible Web-based registry service (Martell, 2009). Some existing catalogues currently store metadata describing resources and allow users to find these resources (Pandey and Patel, 2009; Park et al., 2007; Parhi et al., 2010). Houbie and Bigagli (2010) proposed service interfaces and encodings of catalogue service for ebRIM application profile for managing Earth Observation data products. The method done by Houbie and Begali is easy to use and expand, while the registry objects only address the data products for earth observation. Deegree-CSW (Deegree, 2010, 2011) is a simple but efficient test tool for CSW transaction requests and responses with high performance and excellent scalability. However, the service lacks CSW harvest support and could be slow because of the heavy use of XSLT transformations over procedural code (Deegree, 2010). GeoNetwork CSW (GeoNetwork, 2010) is used for publishing and accessing digital catalogues of metadata for geospatial data, services, and applications. This service provides an easy-to-use Web interface for the search of geospatial data and connects distributed map services for publishing and discovery. Although the core queryable properties in the GetRecords response include spatial reference elements, the spatial filter is only applied to LatLongBoundingBox and not to other formats for spatial relationships. Researchers at the Laboratory for Advanced Information Technologies and Standards at George Mason University (GMU, 2006) are also building a catalogue service based on OGC standards. The catalogue service enables the Earth-science community to exchange geospatial resources by searching for pre-registered spatial and temporal metadata information that can be used for the publication and discovery of geospatial services and data (GMU, 2010); (Yue et al., 2011). However, the tool only contains the basic operations of GetCapabilities, GetRecords, and GetRecordsByID, which fall short of users' requirements. The current 52North Sensor Instance Registry release (Jirka and Nust, 2010), enables users to insert metadata, search for sensors, handle the status of sensors, and link SIR instances to OGC Catalogs (52 North, 2012). It can manage the metadata as well as the status information of sensors in a manner compatible with OGC catalogs. However, the administrators of SIR must establish a connection with a generic catalogue service, such as CSW, to enable the regular publishing of all data to a certain catalogue instance. These systems have several limitations. (1) Some sensor registry systems must establish a connection between the sensor catalogue and a generic catalogue service (such as the OGC–CSW). When the system establishes a link with CSW through the catalogueID, clients can discover sensors which are registered by data providers into the sensor catalogue. The clients cannot register the sensor and obtain the query results directly through CSW. (2) Current sensor registry services do not include enough information to satisfy the users' requirements with a unified and standardized model for storing and managing heterogeneous sensors. For example, SIR only defines the mappings between SensorML and ebRIM that contains System and Component objects. The mappings include the definitions of ID, long Name, short Name, description, observedBBOX, input, output, location, validtime, lacking of parameters and connections. When users require the accurate discovery of a specific sensor with given parameters, the catalogue service cannot return the corresponding results.
(3) Currently implemented CSW systems cannot register and discover all types of processes. These services (for example, the work done by Houbie et. al. in OGC 09-163r2) only provide a physical process registry and do not support the registration of all processes, especially ProcessModel and ProcessChain. This paper addresses the aforementioned issues. All process types could be registered directly in an on-demand catalogue service, which contains more information on sensors compared with the existing implementations such as the 52N-SIR. The mappings in this paper demonstrate the management of algorithms in the form of process model. The remainder of this paper is organized as follows: Section 2 introduces the method used to design the process catalogue schema for the representation of the registry content and the main mappings from SensorML to the processes. The implementation of the registry service and registry experiments are presented in Section 3. In Section 4, the characteristics of the proposed registry method are discussed. Section 5 summarizes the findings and discusses the next steps.
2. Enabling process registration 2.1. Catalogue information model The rim:RegistryObject is the core metadata class and serves as a common super class for most classes in ebRIM. A RegistryPackage instance is a logical collection of related rim:RegistryObject instances as its members (Wilson, 2007). The rim:RegistryPackage is a formal method of representing an extension package through a set of elements and extensibility points that enables it to be tailored for specific purposes (Houbie and Bigagli, 2010; Houbie et al., 2010). The extension package provides several standard classification schemes such as ObjectType, AssociationType, ClassificationSchemeType and SlotType. These extensibility points, which include new extrinsic Objects, associations, classifications, and slots, could be used to represent the Registry Object metadata for information resources (Fuger et al., 2005). According to that, the Process_Catalogue is created as rim: RegsitryPackage, which is not explicitly implemented in the process registry. Process_Catalogue package members are RegistryObjects which include the extensibility points. In the paper, the creation of extensions store information on processes in the catalogue for various sensors and algorithms. And the extension points include the core attributes that are useful for discovering processes encoded in SensorML, as mentioned below. An overview of the catalogue information model of the process registry based on ebRIM 3.0 is shown in Fig. 1. Note that in Fig. 1 the classes by white icons come from the ebRIM 3.0; the classes by yellow icons are the same as the classes in OGC 09-163r2 (Houbie et al., 2010); the classes in green icons have additions compared to the classes defined in OGC 09-163r2; the new classes by red icons are created in this paper. 2.2. The extension based on ebRIM for process model 2.2.1. Additional ExtrinsicObject types AbstractProcess could be divided into two types: physical processes and non-physical (pure) processes, as mentioned in Section 1. These classes (AbstractProcess, PhysicalProcess and NonPhysicalProcess), are conceptual and are mapped from abstract concepts in [OGC 07-000], so they do not appear as explicit classes when implemented. Accordingly, three abstract classes(AbstractProcess, AbstractPhysicalProcess and AbstractNonPhysicalProcess) are created, as shown in Fig. 1.
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
47
Fig. 1. Process catalog information model inheritance view.
Table 1 The definition of ProcessMethod ExtrinsicObject in extension package based on ebRIM. Property
Value
Identifier Name Description Parent
urn:liesmars:def:objectType:CSW-ebRIM-Process:ProcessMethod ProcessMethod Describes a ProcessModel as defined in OGC07-000 Urn:oasis:names:tc:ebxml-rerep:ObjectType:RegistryObject: ExtrinsicObject ProcessMethod
Code
System and Component represent the instances of AbstractPhysicalProcess. ProcessChain and ProcessModel inherits all the parameters from AbstractNonPhysicalProcess. These classes are used to describe four process types, inheriting all the properties from the AbstractProcess. Besides that, in SensorML, the sml: ProcessMethod is used to describe the algorithms for the sml:ProcessModel and sml:component. So a class of is built and inherited from rim: ExtrinsicObject (refer to Table 1 for details on the properties of ProcessMethod). Accordingly, five new classes (System, Component, ProcessModel, ProcessChain, and ProcessMethod) are defined, which are built and added for process registry by extending the canonical
ObjectType ClassificationScheme in the extension package. The possible value for the ExtrinsicObject@objectType attribute will be assigned to represent new kinds of resource elements.
2.2.2. Additional Association types Five new Association classes are implemented as instances of rim: Association and represent relationships between source Objects and target Objects, as shown in Figs. 2 and 3. They are regarded as new ClassificationNodes to add to the canonical AssociationType ClassificationScheme. After these new classes are included in the extension package, the instances of associations can be created. The value for the Association@associationType attribute is used created to represent new kinds of associations that link registry objects. Since the available attributes in the Association classes were insufficient to describe the relationship, new attributes derived from SensorML were added through Slots. The constraints for the sourceObject and targetObject attributes of these new kinds of Associations are represented by using MetaAssociations. ProcessChain adds zero or more component properties that take Process (both physical and non-physical) as their value. Thus, the “ComposedOf” association relates a ProcessChain with a subsystem that could be a System item, a Component item, a ProcessModel item, or a ProcessChain item. Similar to ProcessChain, the
48
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
Fig. 2. Object Type constraints for the association “ComposedOf”, “AccessibleThrough” and “Contains”.
Fig. 3. Object Type constraints for the association “InputConnection” and “OutputConnection”.
“ComposedOf” association could be built between System and sub-system. The “AccessibleThrough” association relates a process with a Service through which it can be accessed. The association “Contains” relates ProcessMethod and ProcessModel/Component for validating and possibly executing individual processes. The three associations are shown in Fig. 2. In SensorML, one important property of ProcessChain is connections, which provides a list of all connections between inputs, outputs and parameters within ProcessChain. The link object in System follows the same rules as that in ProcessChain. So it is necessary to build the associations to represent the links. The associations of “InputConnection” and “OutputConnection” are added in the extension package. As shown in Fig. 3, “InputConnection” indicates that the Component's input value originates from the System that provides such value, stored in the content from sml:connection; “OutputConnection” relates a System and
the component when the Component's output value is assigned as the system’s output value.
2.2.3. Additional ClassificationScheme types Five new classification schemes are used to classify and to organize objects within this registry. A Registry Object may be classified in numerous ways for various applications and metadata. The classification information model in ebRIM is described by three classes: ClassificationScheme, ClassificationNode, and Classification. A ClassificationScheme instance describes a taxonomic hierarchy, which may be internally defined in the registry or externally defined in the Registry by instances of ClassificationNode. A Classification is a specialized form of an Association and could be internal or external depending on the corresponding ClassificationScheme (Fuger et al., 2005).
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
Therefore, two new classification schemes are informatively proposed for all processes: (1) IntendedApplication refers to the application for which the process could be used. For example, if the process can be classified as flood detection, the ClassificationNode “water” and its subclass “flood detection” will be added to this process; (2) ServiceType is similar to “SOS” and “SPS.” Two classification schemes are built specifically for physical processes: (1) SystemType: This platform type is similar to “Satellite,” “Aircraft,” and “Helicopter,” whereas the sensor type is similar to “scanning imager”; (2) OrbitType: The orbit type is similar to “Sun-Synchronous,” “Geosynchronous,” “Geostationary,” and “Low_Earth”. The PureProcessType classification scheme is built specifically for non-physical processes. The pure process type is similar to “TimeProcessType,” “SpatialProcessType,” “MetadataProcessType,” and “ThematicProcessType”. The time process type describes the algorithm about time. The spatial process type often expresses the coordinate transformation model in the use of remote sensing images. For example, the process model called LLAtoECEF defines the method used to transform coordinates from “epsg4329” to “WGS84”. The metadata process type provides statistical computing algorithm services, based on which thematic process type for specific applications could be designed.
2.2.4. Additional RegistryObjects Slots Slot instances provide a dynamic method of adding arbitrary attributes to RegistryObject instances, thus enabling extensibility within the information model. All additional classes include further particular characteristics of registry objects that can be added to the classes by using Slot. The characteristics are based on the related content from the OGC 07-000 profile. For example, through the execution of implementations specified within the ProcessMethod definition, the process could understand how to execute individual process models within a process chain, so we
49
create a Implementation Slot for ProcessMethod. Details on the slots for registry object are shown in Fig. 1. 2.3. Mapping from SensorML to ebRIM The process mapping choices are shown in Fig. 4. Mapping choices enable users to understand the structure of the mapped resources and the way such resources are represented within the ebRIM metamodel. Moreover, mapping enables fast search and retrieval by using the standardized OGC catalogue interface. The use of the following mapping flow is recommended for mapping processes that will be mapped to ebRIM (Fig. 4). 2.3.1. ObjectType mapping As mentioned in Section 2.2.1, five Classification Nodes (System, Component, ProcessModel, ProcessMethod and ProcessChain) are added in the ObjectType ClassificationScheme as a sub-class of rim:ExtrinsicObject. Upon the submission of these classification nodes to the process registry through the “transaction-insert” operation, a rim:ExtrinsicObject within it may be typed as a system or as another object. Depending on the type of process, the following mapping procedure is used to choose the mappings among specific attributes and associations. 2.3.2. Attribute mapping Attributes such as identifier, name, description, classification, contact, inputs, outputs, parameters, and so on, are required to facilitate efficient discovery. Different attributes exist for different ExtrinsicObjects (Fig. 1). 1. Map to identifier: The identifier property uniquely identifies the sensor and is of type URN. This property is mapped to rim: ExtrinsicObject/@id. 2. Map to Name/Description: The LongName property provides a common name for the sensor. This property is mapped to rim:
Fig. 4. The Mapping Flowchart from SensorML to ebRIM.
50
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
Name. The Description property provides a description for the sensor and is thus best mapped to rim:Description. 3. Map to classification: A rim:ClassificationScheme will be built to map the classification's value to rim:ClassificationNode, which is created within the said scheme to represent the value. When the process is registered, the mapping to classification requires two steps. For example, when a System is registered, the first step is to define the SystemType ClassificationScheme, which includes two ClassificationNodes for each physical process. The second step is the creation of a Classification instance, which refers to ClassificationNodes in the Data Source Scheme when a System instance is added into the registry. The corresponding rim:ClassificationNode and rim:Classification for different processes will be created according to Section 2.2.3. 4. Map to Organization/person: Suitable mappings between the contact information in SensorML to the contact attributes in ebRIM, are created. 5. Map to Slot: In most cases, the specific domain attributes that require exposure within the target ebRIM model for discovery are mapped to Slots. Similar to the mappings in OGC09-163r2, the Slot of System and Component are added. In the case of the source SensorML, the attributes for ProcessChain including inputs, outputs, and parameters are mapped to Slots. The core attributes are mapped to Slots for ProcessModel and ProcessMethod (Fig. 5).
2.3.3. Association mapping To define a new association type, the canonical AssociationType ClassificationScheme is extended, and a new ClassificationNode is built as a child or descendant of the AssociationType ClassificationScheme. When the association mapping is determined to be valid, the corresponding association will be created, as shown in Fig. 4.
3. Process registry experiments 3.1. Implementation of a process registry service prototype A demonstration of this registry service has been deployed in the “GEOSENSOR-CSW” server. Web services and Java technology have been used to implement the service with the OGC-CSW and ebRIM standards. The registry service for processes uses the extension package which is mentioned in Section 2. The demo extension package application can be viewed at http://swe.whu. edu.cn:8080/MyCswPro/jsps/login.jsp. GetCapabilities: The program generates an XML request to enable a user to retrieve information about the service when the user takes the action “GetCapabilities.” The body of the response will describe the basic operational and non-operational characteristics of the GEOSENSOR CSW. SensorMLtoebRIM: The transformation of the process description is based on a suitable XSLT and closely follows the mapping described in Section 2.3. The program offers a basic interface that enables a transformation from SensorML to ebRIM. When the input text field is the SensorML description and a user selects the action “transform,” the output document created is ready for insertion. Transaction-Insert: Users could insert a process in three ways: input parameters, input documents in the form of “insert” and input documents encoded in SensorML. Through the former two methods, the information could be inserted into the system. Through the last method, users select a document of a process encoded by SensorML, then the service will automatically call the appropriate conversion document (XLST) and generate an XML request called “Transaction-insert.” This request will register the process as a rim:ExtrinsicObject object in the registry service, as shown in Fig. 6.
Fig. 5. The Correspondence between SensorML metadata xpath and the attribute of ProcessModel and ProcessMethod ExtrinsicObject.
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
51
Fig. 6. A registry example, using documents encoded in SensorML.
Transaction-Update: The program generates an XML request called “Transaction-update,” which includes the description of the process when a user selects a document to describe the existing process. The operation replaces the existing object with the new description in an update statement. Transaction-Delete: When a registry object is to be deleted, the program generates an XML request after the user selects the action “Transaction-delete.” If a given registry object is deleted, this deletion cascades to the corresponding components, such as, rim:ExternalIdentifier, rim:Classification, and rim:ServiceBinding. Batch Upload: For the management of a large number of processes, the user can select the operation “BatchUpload” to register the many processes simultaneously. 3.2. Experimental data Floods have been a part of the human experience since settlements were built along riverbanks. People can undertake field measurements of rainfall, groundwater, and river levels by using the data collected through sensors. Algorithms enable users to assess water movements and drive process models quantitatively to undertake analyses such as flood risk assessment and flood warning (Ip et al., 2006; Auynirundronkoola et al., 2012; Khan et al., 2011). In particular, the use of satellite remote sensing and related algorithms (for example, the Normalized Difference Water Index (NDWI), which is derived from the green and NIR channels,) hold the key to flood monitoring, which requires the management of physical and nonphysical processes (Martinis et al., 2011) (Gao, 1996). GEOSENSOR CSW could provide efficient management of sensors and algorithms. The sensors (such as TM,
SPOT5, HRG and AQUA), and algorithms (NDWI) could be registered in the registry service(GENSENSOR-CSW). The experimental data can be viewed here: http://swe.whu.edu.cn:8080/MyCswPro/ jsps/data.jsp. 3.3. The registry of NDWI The NDWI is described by ProcessChain in SensorML responds to changes in both water content and spongy mesophyll in vegetation canopies. The users could set “ProcessChain” as the ProcessType, “flood detection” as the IntendedApplication, and “ThematicProcessType” as the PureProcessType to describe NDWI. Fig. 7 shows that a user register the NDWI as a new ExtrinsicObject “ProcessChain” instance and then add three components by using the transaction-insert operation. The three components are “Green”, “NIR”, and “NDWIDetector.” The association “ComposedOf” is built between the NDWI ProcessChain and the three components. The association “Contains” shows that ProcessModel has a ProcessMethod to define the algorithm of NDWI. There are two new associations “InputConnection” and “OutputConnection”. The association “InputConnection” describes the input connections between the system and components, whereas the association “OutputConnection” represents the output connections. Fig. 8 illustrates the implementation of the two associations. 3.4. The registry of AQUA-MODIS The experiment adopts sensor-MODIS and platform-AQUA to represent the registry procedure. Both of them are described by System in SensorML. AQUA is considered as a new ExtrinsicObject-
52
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
Fig. 7. The registry package of NDWI based on ebRIM.
Fig. 8. A snippet of the code which can achieve the mappings for the associations of “InputConnection” and “OutputConnection”.
system instance and inherits the main attributes (Fig. 9). These attributes include the ID, keywords, inputs, outputs, ProcessType, IntendedApplication, and so on. The MODIS instrument is registered as a new ExtrinsicObject “System” instance, with a new association “ComposedOf”. A new association “AccessibleThrough” is built between MODIS and the SOS service. The above information about MODIS will be registered in the service through the “Transaction-insert” operation. As shown in Fig. 10, MODIS contains four components: MSCRED-Detector, MSC-GREEN-Detector, MSC-NIR-Detector, and clock, all of which are described by new ExtrinsicObjects. The implementation of associations “InputConnection” and “OutputConnection” is similar to those in NDWI, and the representations of them are shown in Fig. 10.
4. Discussion 4.1. Direct registry for process model In comparison to the 52N-SIR registry, clients can retrieve sensor information only after the SIR connects to an OGC catalogue. Within GEOSENSOR-CSW, a user can store sensor information directly. However, only a part of the information on sensors is discoverable in the SIR. Some information will be lost during the transfer of sensor metadata from the SIR to the catalogue service. In the GEOSENSOR CSW, the direct registry method reduces data loss, and could ultimately satisfy users' requirements better. Lastly, the push process of sensor metadata in the SIR can be executed either once or with a continuous automatic repetition interval.
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
53
Fig. 9. The registry package of AQUA and MODIS based on ebRIM.
Fig. 10. The mapping of “InputConnection” and “OutputConnection”.
This requirement may affect timeliness and synchronization, whereas the GEOSENSOR CSW solution can easily be used for searching processes and can minimize the time required for discovery. 4.2. More information storage for sensors The parameters of sensors to be inserted include sensor description, reference, identification, and service reference in the SIR, whereas the parameters in GEOSENSOR CSW are extended to include ProcessType, IntendedApplication, identification, and other descriptions. The mappings from SensorML to ebRIM in SIR
contain basic information (ID, name, description, keywords, validtime, position, ObservedBBOX, inputs, and outputs), the ComposedOf and AccessibleThrough associations, the IntendedApplication and ServiceType Classifications. Besides that, Houbie et al. (2010) define the SystemType and OrbitType classifications for sensors. This paper realizes the above information in mappings, and the mappings for System and Component from SensorML to ebRIM include more information. The following details are also added to the mappings: parameters; the Contains, InputConnection, and OutputConnection associations, and the PureProcessType classification for nonphysical process. The improved mappings enable the acquisition of minimum sets for sensor discovery and enhance
54
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
retrieval accuracy capabilities. Using the new mappings, the user can transform more information about sensors and obtain more related information from the catalogue service for query. 4.3. A registry for all process types Only the physical processes are taken in account in the work by Houbie et al. (2010). Compared to that, there are some additions in registry package for all process types including the physical processes and nonphysical processes. The details of additions are as follow: (1) New RegistryPackage: Process_Catalogue is created as rim: RegistryPackage, which is not explicitly implemented in the process registry. (2) New ExtrinsicObjects: Four Extrinsic Objects are created, which include the AbstractNonPhysicalProcess, ProcessChain, ProcessModel and ProcessMethod. (3) New Associations: Three associations are created, which include the Contains, InputConnection and OutputConnection. (4) Additional properties for the System and Component: the System and Component classes have added the new property “parameters”, which is in bold font in Fig. 1. (5) Additions for the “Composedof” association: The “Composedof” association not only relates a System with a sub-system, but also represents the association between a ProcessChain and a sub-system. In this paper, these employment of extensibility points in information model could help to registering processes. The method for enabling process registration allows catalogues to handle different types of processes. The process with all types can be registered and stored as corresponding classes into the catalogue service (GEOSENSOR CSW). The extended model is the basis of the query pattern to meet users' demands. For example, if clients want to obtain processes that could be applied in flood detection and the specified platform type is “satellite”, they can choose the parameters “IntendedApplication” and “PlatformType” as query filter conditions. These parameters will then be matched to the process information in the database through the OGC:filter function. The OGC:filter function is used to filter the information in the service to ensure that the response is appropriate for the users. End users with a specific field of expertise can more precisely query potentially interesting sensors within a catalogue client. The results show the feasibility of registering all process types within the GEOSENSOR CSW. The methodology improves on the existing catalogue service and the sensor registry service mentioned in Section 2. There are some issues which require in the further study. For example, a ProcessChain includes a connection property that defines all connections between process inputs, outputs, and parameters through the chain. This paper only defines the mappings of connections between inputs and outputs without considering the connections between parameters and the chain. A solution will determined in the future so that complete connections in a ProcessChain could be represented.
5. Conclusions and outlook This paper presents an approach for registering processes into a catalogue service. The registry for every types of processes(System, Component, ProcessModel, and ProcessChain), is organized and registered in the GENSENSOR CSW by extending ebRIM. The extension to ebRIM comprises four new types of classes based on a process model, as well as the ProcessMethod class, which
addresses the requirements for process registry in the catalogue service. The core extension to support all types of processes has been developed in the GEOSENSOR CSW. This approach demonstrates that the extension can be used to implement a more refined discovery for processes in a catalogue service. In conclusion, the proposed approach provides an important step toward the registry of existing sensors and algorithms. Defining processes as new registry objects, describing the connections among these processes, and using the extension to represent more information are major work for the implementation registry service. Yue et al. propose the addition of semantics into current geospatial catalogue services (Yue et al., 2011). The next step is to investigate the methods by which semantic middleware can be added to the GEOSENSOR CSW for process registry and through which internal relations in the process can be represented.
Acknowledgments This work was supported by grants from the National Basic Research Program of China (973 Program) (No. 2011CB707101), National High Technology Research and Development Program of China (863 Program) (no. 2013AA01A608), National Nature Science Foundation of China (NSFC) Program (No. 41171315), Program for New Century Excellent Talents in University under Grant NCET-11-0394, and the Fundamental Research Funds for the Central Universities (No. 2012619020203). References 521North, 2012. 521North Sensor Discovery. URL:〈http://52north.org/communities/ sensorweb/incubation/discovery/index.html〉 (accessed 25.11.12). Auynirundronkoola, K., Chen, N., Peng, C., 2012. Flood detection and mapping of the ThailandCentralplain using RADARSAT and MODIS under a sensor web environment. International Journal of Applied Earth Observation and Geoinformation 14, 245–255. Botts, M., Robin, A., 2007. OpenGIS Sensor Model Language (SensorML) Implementation Specification. OGC 07-000. Open Geospatial Consortium, Inc., 180pp. 〈http://portal.opengeospatial.org/files/?artifact_id=21273〉 (accessed 25.11.12). Botts, M., Percivall, G., Reed, C., Davidson, J.,(Ed.), 2007. Sensor Web Enablement: Overview And High Level Architecture.OGC 07-165. Open Geospatial Consortium, Inc., 14pp. 〈http://portal.opengeospatial.org/files/?artifact_id=25562〉 (accessed 25.11.12). Broring, A., Echterhoff, J., Jirka, S., Simonis, I., Everding, T., Stasch, C., Liang, S., Lemmens, R., 2011. New generation sensor web enablement. Sensors 11, 2652–2699, http://dx.doi.org/10.3390/s110302652. Chen, N., Di, L., Yu, G., Gong, J., Wei, Y., 2009. Use of ebRIM-based CSW with sensor observation services for registry and discovery of remote-sensing observations. Computers and Geosciences 35 (2), 360–372. Chen, N., Hu, C., Chen, Y., Wang, C., Gong, J., 2012. Using SensorML to construct a geoprocessing e-Science workflow model under a sensor web environment. Computers and Geosciences 47, 119–129. Clement,L., Hately, A. Riegen,C.V., Rogers,T., 2004. UDDI Version 3.0.2.UDDI Spec Technical Committee Draft.URL: 〈http://uddi.org/pubs/uddi_v3.htm〉 (accessed 25.11.12). Deegree, 2010. deegree Web feature service v2.5. 〈http://download.deegree.org/ deegree2.5/docs/wfs/html/deegree_wfs_documentation_en.html〉 (accessed 25.02.13). Deegree, 2011. deegree 3 catalogueService, URL: 〈http://wiki.deegree.org/deegree Wiki/deegree3/Catalogue Service〉, (accessed 25.11.12). Fuger, S., Najmi, F., Stojanovic, N., 2005. ebXML Registry Information Model Version 3.0, OASIS Standard.URL: 〈http://docs.oasis-open.org/regrep/v3.0/specs/regre p-rim-3.0-os.pdf〉 (accessed 25.11.12). Gao, B., 1996. NDWI-a normalized difference water index for remote sensing of vegetation liquid water from space. Remote Sensing of Environment 58 (3), 257–266. GeoNetwork, 2010. CSW service-GeoNetwork opensource.URL: 〈http://geonetwor k-opensource.org/stable/developers/xml_services/csw_services.html〉 (accessed 25.11.12). GMU, 2006. OGC Catalog Service for Web at LAITS.URL: 〈http://geobrain.laits.gmu. edu/csw/discovery〉 (accessed 25.11.12). GMU, 2010. OGC-Compliant Catalog Service.URL: 〈http://geobrain.laits.gmu.edu/ csw/ogccsw.html〉, (accessed 25.11.12). Houbie, F., Skivee, F., Jirka, S., 2010. OGC Catalog Services Specification 2.0 Extension Package for ebRIM Application Profile:SensorML. OGC 09-163r2. Open Geospatial Consortium, Inc., 76pp. 〈http://portal.opengeospatial.org/files/?artifact_id= 37944〉 (accessed 25.11.12).
N. Chen et al. / Computers & Geosciences 56 (2013) 45–55
Houbie, F., Bigagli, L., 2010. OGC Catalog Services Standard 2.0 Extension Package for ebRIM Application Profile: Earth Observation Products. OGC 06-131r6. Open Geospatial Consortium, Inc., 146pp. 〈http://portal.opengeospatial.org/files/?arti fact_id=35528〉 (accessed 25.11.12). Ip, F., Dohm, J.M., Baker, V.R., Doggett, T., Davies, A.G., Castario, R., Chien, S., Cichy, B., Greeley, R., Sherwood, R., Tran, D., Rabideau, G, 2006. Flood detection and monitoring with the Autonomous Sciencecraft Experiment onboard EO-1. Remote Sensing of Environment 101 (4), 463–481. Jirka, S., Broring, A., Stasch, C., 2009. Discovery mechanisms for the sensor web. Sensors 9, 2661–2681, http://dx.doi.org/10.3390/s90402661. Jirka, S., Nust, D., (Ed.), 2010. OGC Sensor Instance Registry Discussion Paper, OGC 10-171. Open Geospatial Consortium, Inc., 111pp. 〈http://portal.opengeospatial. org/files/?artifact_id=40609〉 (accessed 25.11.12). Khan, S.I., Hong, Y., Wang, J., 2011. Satellite remote sensing and hydrologic modeling for flood inundation mapping in lake victoria basin: implications for hydrologic prediction in ungauged basins. International Journal of Applied Earth Observation and Geoinformation 49, 85–95. Martell, R., 2009. CSW-ebRIM Registry Service—Part 1: ebRIM profile of CSW.OGC 07-110. Open Geospatial Consortium, Inc., 53pp. 〈http://portal.opengeospatial. org/files/?artifact_id=31137〉 (accessed 25.11.12). Martinis, S., Twele, A., Voigt, S., 2011. Unsupervised extraction of flood-induced backscatter changes in SAR data using Markov image modeling on irregular graphs. IEEE Transactions on Geoscience and Remote Sensing 49, 251–263.
55
Pandey, K.K., Patel, S.V., 2009. A design of sensor web registry for wireless sensor networks with SOA approach. In: Proceedings of the 2009 First International Conference on Computational Intelligence, Communication Systems and Networks (CICSYN '09). IEEE Computer Society, pp. 247–252. doi: 10.1109/CICSYN. 2009.68. Parhi, M., Acharya, B.M., Puthal, B., 2010. An effective mechanism to discover sensor web registry services for wireless sensor network under x-SOA approach. In: Proceedings of 2010 2nd International Conference on Trendz in Information Sciences and Computing (TISC—2010). pp. 197–201. URL:〈http://ieeexplore.ieee. org/stamp/stamp.jsp?arnumber =05714638〉 (accessed 25.11.12). Park, J., Han, J., Kang, K., 2007. The registry for sensor network discovery. In: Proceedings of 12th IEEE International Conference on Engineering Complex Computer Systems (ICECCS 2007). pp. 129–137, URL:〈http://ieeexplore.ieee. org/stamp/stamp.jsp?tp=&arnumber=4276309&isnumber=4276290〉 (accessed 25.11.12). Wilson, T., 2007. OWS-4 CSW ebRIM Modelling Guidelines IPR. OGC 06-155. Open Geospatial Consortium, Inc., 98pp. 〈http://portal.opengeospatial.org/files/?arti fact_id=20430〉 (accessed 25.11.12). Yue, P., Gong, J., Di, L., 2011. Integrating semantic web technologies and geospatial catalog service for geospatial information discovery and processing in cyberinfrastructure. Geoinformation 15, 273–303, http://dx.doi.org/10.1007/s10707009-0096-1.
