Computers & Geosciences 56 (2013) 45–55

Contents lists available at SciVerse ScienceDirect

Computers & Geosciences

0098-30http://d

n CorrE-m

journal homepage: www.elsevier.com/locate/cageo

A direct registry service method for sensors and algorithms basedon the process model

Nengcheng Chen n, Xiaolei Wang, Xunliang YangState Key Lab for Information Engineering in Surveying, Mapping and Remote Sensing, Wuhan University, 129 Luoyu Road, Wuhan 430079, China

a r t i c l e i n f o

Article history:Received 3 December 2012Received in revised form5 March 2013Accepted 7 March 2013Available online 21 March 2013

Keywords:Sensor registryAlgorithm registryCatalogue information modelProcess modelCSW

04/$ - see front matter & 2013 Elsevier Ltd. Ax.doi.org/10.1016/j.cageo.2013.03.008

esponding author. Tel.: þ86 13886019231; faail address: cnc@whu.edu.cn (N. Chen).

a b s t r a c t

To characterize and monitor environmental quality in real time, significant efforts must be made to makesensors accessible on the Web. Although a number of services have shown great potential to improve theaccuracy and reliability of sensor registry, comprehensive methods that register sensors and algorithmsin a catalogue service based on a process model are lacking. This paper addresses the registry ofprocesses, including physical and non-physical processes, by using the OGC catalogue service. To providemore information on sensors and algorithms, the process catalogue information model extends theebXML Registry information Model. The mapping between the metadata encoded in SensorML and theextended model includes more information for all types of processes. Moreover, the mapping includesthe 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, followingthe OGC “transaction” interface. Flooding experimental results demonstrate that the service caneffectively and directly register sensors and algorithms so that processes can be flexibly executedaccording to users' demands.

& 2013 Elsevier Ltd. All rights reserved.

1. Introduction

Existing sensors, including in-situ, airborne, and spaceborne sen-sors, will be Web-ready in the future. A large number of algorithmsexist to describe the mathematical operations of sensors. Sensors andalgorithms require effective management on the Internet. In theSensor Web, the metadata for data and services could be registeredin a catalogue that enables users to locate, access, discover, and makeuse 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, andmanaging numerouskinds of resource. The management of sensors and algorithms basedon the process model remains lacking, and will become an increas-ingly urgent matter in the Earth observation community. Therefore, acatalogue service must be built to manage processes given the largenumber of sensors and algorithms in use.

Processes in Sensor Web Enablement derived from AbstractProcessare conceptually divided into two types (Botts and Robin, 2007; Bottset al., 2007; Chen et al., 2012): (1) non-physical or “pure” processes(ProcessModel and ProcessChain), which can be treated merely asmathematical operations and (2) physical processes (Component andSystem), such as detectors, actuators, and sensor systems, whereinformation regarding their positions and interfaces may be relevant.

ll rights reserved.

x: þ86 27 68778229.

Processes are encoded in standard models and in XML Schema, whichis the core information model (SensorML) in the Sensor Web.SensorML provides descriptions of sensors and algorithms neededfor sensor management as well as for the location of sensor observa-tions, processing of low-level sensor observations, and listing oftestable properties (Broring et al., 2011). All processes in SensorMLcan provide inputs, outputs, parameters, and additional information.The information required for resource discovery, qualification ofresults, and for assistance to humans are included within Metada-taGroup, for example, the properties of identification, classification,and capabilities (Jirka et al., 2009). So the registry of process modelsshould include the above information.

The proposed registry service has a specific registry modelwhich needs a normative XML Schema for the representation ofregistry objects. Current registry models include UniversalDescription, Discovery, and Integration (UDDI) (Clement et al.,2004) and the ebXML registry information model (ebRIM), both ofwhich are sponsored by the Organization for the Advancement ofStructured Information Standards (OASIS). The UDDI specificationdoes not adequately facilitate the autonomous discovery andinteroperation of disparate Web services, while ebRIM enablesthe sharing of content and metadata among organizational entitiesin a federated environment (Fuger et al., 2005). The ebRIMconstitutes a public schema that specifies how the cataloguecontent should be structured and interrelated for discovery andpublication purposes, using a set of classes and the relationships

N. Chen et al. / Computers & Geosciences 56 (2013) 45–5546

among these classes (Chen et al., 2009).The process registryservice would use ebRIM to specify the metadata for processmodels. But it is necessary to provide a common vocabulary thatextends the abstract information model (ebRIM) and supports thedisplay, retrieval, and search of the processes in process registryservice. The CSW-ebRIM profile, which is developed by the OpenGeospatial Consortium (OGC), provides guidance for the registra-tion of metadata. The proposed registry service could apply theOGC–CSW interfaces to ebRIM to provide a general and flexibleWeb-based registry service (Martell, 2009).

Some existing catalogues currently store metadata describingresources 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 forebRIM application profile for managing Earth Observation dataproducts. The method done by Houbie and Begali is easy to use andexpand, while the registry objects only address the data products forearth observation. Deegree-CSW (Deegree, 2010, 2011) is a simple butefficient test tool for CSW transaction requests and responses withhigh performance and excellent scalability. However, the service lacksCSW harvest support and could be slow because of the heavy use ofXSLT transformations over procedural code (Deegree, 2010). GeoNet-work CSW (GeoNetwork, 2010) is used for publishing and accessingdigital catalogues of metadata for geospatial data, services, andapplications. This service provides an easy-to-use Web interface forthe search of geospatial data and connects distributedmap services forpublishing and discovery. Although the core queryable properties inthe GetRecords response include spatial reference elements, the spatialfilter is only applied to LatLongBoundingBox and not to other formatsfor spatial relationships. Researchers at the Laboratory for AdvancedInformation Technologies and Standards at George Mason University(GMU, 2006) are also building a catalogue service based on OGCstandards. The catalogue service enables the Earth-science communityto exchange geospatial resources by searching for pre-registeredspatial and temporal metadata information that can be used for thepublication and discovery of geospatial services and data (GMU, 2010);(Yue et al., 2011). However, the tool only contains the basic operationsof GetCapabilities, GetRecords, and GetRecordsByID, which fall short ofusers' requirements. The current 52North Sensor Instance Registryrelease (Jirka and Nust, 2010), enables users to insert metadata, searchfor sensors, handle the status of sensors, and link SIR instances to OGCCatalogs (52 North, 2012). It can manage the metadata as well as thestatus information of sensors in a manner compatible with OGCcatalogs. However, the administrators of SIR must establish a connec-tion with a generic catalogue service, such as CSW, to enable theregular publishing of all data to a certain catalogue instance. Thesesystems have several limitations.

(1)

Some sensor registry systems must establish a connectionbetween the sensor catalogue and a generic catalogue service(such as the OGC–CSW). When the system establishes a linkwith CSW through the catalogueID, clients can discoversensors which are registered by data providers into the sensorcatalogue. The clients cannot register the sensor and obtainthe query results directly through CSW.

(2)

Current sensor registry services do not include enough infor-mation to satisfy the users' requirements with a unified andstandardized model for storing and managing heterogeneoussensors. For example, SIR only defines the mappings betweenSensorML and ebRIM that contains System and Componentobjects. The mappings include the definitions of ID, long Name,short Name, description, observedBBOX, input, output, location,validtime, lacking of parameters and connections. When usersrequire the accurate discovery of a specific sensor with givenparameters, the catalogue service cannot return the corre-sponding results.

(3)

Currently implemented CSW systems cannot register anddiscover all types of processes. These services (for example,the work done by Houbie et. al. in OGC 09-163r2) only providea physical process registry and do not support the registrationof all processes, especially ProcessModel and ProcessChain.

This paper addresses the aforementioned issues. All processtypes could be registered directly in an on-demand catalogueservice, which contains more information on sensors comparedwith the existing implementations such as the 52N-SIR.The mappings in this paper demonstrate the management ofalgorithms in the form of process model. The remainder of thispaper is organized as follows: Section 2 introduces the methodused to design the process catalogue schema for the representa-tion of the registry content and the main mappings from SensorMLto the processes. The implementation of the registry service andregistry experiments are presented in Section 3. In Section 4, thecharacteristics 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 asa common super class for most classes in ebRIM. A RegistryPackageinstance is a logical collection of related rim:RegistryObjectinstances as its members (Wilson, 2007). The rim:RegistryPackageis a formal method of representing an extension package through aset of elements and extensibility points that enables it to betailored for specific purposes (Houbie and Bigagli, 2010; Houbieet al., 2010). The extension package provides several standardclassification schemes such as ObjectType, AssociationType, Classi-ficationSchemeType and SlotType. These extensibility points, whichinclude new extrinsic Objects, associations, classifications, andslots, could be used to represent the Registry Object metadatafor information resources (Fuger et al., 2005).

According to that, the Process_Catalogue is created as rim:RegsitryPackage, which is not explicitly implemented in the pro-cess registry. Process_Catalogue package members are RegistryOb-jects which include the extensibility points. In the paper, thecreation of extensions store information on processes in thecatalogue for various sensors and algorithms. And the extensionpoints include the core attributes that are useful for discoveringprocesses encoded in SensorML, as mentioned below.

An overview of the catalogue information model of the processregistry based on ebRIM 3.0 is shown in Fig. 1. Note that in Fig. 1the classes by white icons come from the ebRIM 3.0; the classes byyellow icons are the same as the classes in OGC 09-163r2 (Houbieet al., 2010); the classes in green icons have additions compared tothe classes defined in OGC 09-163r2; the new classes by red iconsare created in this paper.

2.2. The extension based on ebRIM for process model

2.2.1. Additional ExtrinsicObject typesAbstractProcess could be divided into two types: physical

processes and non-physical (pure) processes, as mentioned inSection 1. These classes (AbstractProcess, PhysicalProcess and Non-PhysicalProcess), are conceptual and are mapped from abstractconcepts in [OGC 07-000], so they do not appear as explicit classeswhen implemented. Accordingly, three abstract classes(Abstract-Process, AbstractPhysicalProcess and AbstractNonPhysicalProcess)are created, as shown in Fig. 1.

Table 1The definition of ProcessMethod ExtrinsicObject in extension package basedon ebRIM.

Property Value

Identifier urn:liesmars:def:objectType:CSW-ebRIM-Process:ProcessMethodName ProcessMethodDescription Describes a ProcessModel as defined in OGC07-000Parent Urn:oasis:names:tc:ebxml-rerep:ObjectType:RegistryObject:

ExtrinsicObjectCode ProcessMethod

Fig. 1. Process catalog information model inheritance view.

N. Chen et al. / Computers & Geosciences 56 (2013) 45–55 47

System and Component represent the instances of AbstractPhy-sicalProcess. ProcessChain and ProcessModel inherits all the para-meters from AbstractNonPhysicalProcess. These classes are used todescribe four process types, inheriting all the properties from theAbstractProcess. Besides that, in SensorML, the sml: ProcessMethodis used to describe the algorithms for the sml:ProcessModel andsml:component. So a class of is built and inherited from rim:ExtrinsicObject (refer to Table 1 for details on the properties ofProcessMethod). Accordingly, five new classes (System, Component,ProcessModel, ProcessChain, and ProcessMethod) are defined, whichare built and added for process registry by extending the canonical

ObjectType ClassificationScheme in the extension package.The possible value for the ExtrinsicObject@objectType attributewill be assigned to represent new kinds of resource elements.

2.2.2. Additional Association typesFive new Association classes are implemented as instances of

rim: Association and represent relationships between sourceObjects and target Objects, as shown in Figs. 2 and 3. They areregarded as new ClassificationNodes to add to the canonicalAssociationType ClassificationScheme. After these new classesare included in the extension package, the instances of associa-tions can be created. The value for the Association@associationTypeattribute is used created to represent new kinds of associationsthat link registry objects. Since the available attributes in theAssociation classes were insufficient to describe the relationship,new attributes derived from SensorML were added through Slots.The constraints for the sourceObject and targetObject attributes ofthese new kinds of Associations are represented by using Meta-Associations.

ProcessChain adds zero or more component properties that takeProcess (both physical and non-physical) as their value. Thus, the“ComposedOf” association relates a ProcessChain with a sub-system that could be a System item, a Component item, a Process-Model item, or a ProcessChain item. Similar to ProcessChain, the

Fig. 2. Object Type constraints for the association “ComposedOf”, “AccessibleThrough” and “Contains”.

Fig. 3. Object Type constraints for the association “InputConnection” and “OutputConnection”.

N. Chen et al. / Computers & Geosciences 56 (2013) 45–5548

“ComposedOf” association could be built between System andsub-system. The “AccessibleThrough” association relates a processwith a Service through which it can be accessed. The association“Contains” relates ProcessMethod and ProcessModel/Component forvalidating and possibly executing individual processes. The threeassociations are shown in Fig. 2.

In SensorML, one important property of ProcessChain is con-nections, which provides a list of all connections between inputs,outputs and parameters within ProcessChain. The link object inSystem follows the same rules as that in ProcessChain. So it isnecessary 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, “Input-Connection” indicates that the Component's input value originatesfrom the System that provides such value, stored in the contentfrom sml:connection; “OutputConnection” relates a System and

the component when the Component's output value is assigned asthe system’s output value.

2.2.3. Additional ClassificationScheme typesFive new classification schemes are used to classify and to organize

objects within this registry. A Registry Object may be classified innumerous ways for various applications and metadata. The classifica-tion information model in ebRIM is described by three classes:ClassificationScheme, ClassificationNode, and Classification. A Classifi-cationScheme instance describes a taxonomic hierarchy, whichmay beinternally defined in the registry or externally defined in the Registryby instances of ClassificationNode. A Classification is a specialized formof an Association and could be internal or external depending on thecorresponding ClassificationScheme (Fuger et al., 2005).

N. Chen et al. / Computers & Geosciences 56 (2013) 45–55 49

Therefore, two new classification schemes are informatively pro-posed for all processes: (1) IntendedApplication refers to the applicationfor which the process could be used. For example, if the process can beclassified as flood detection, the ClassificationNode “water” and itssubclass “flood detection”will be added to this process; (2) ServiceTypeis similar to “SOS” and “SPS.”

Two classification schemes are built specifically for physicalprocesses: (1) SystemType: This platform type is similar to “Satel-lite,” “Aircraft,” and “Helicopter,” whereas the sensor typeis similar to “scanning imager”; (2) OrbitType: The orbit typeis similar to “Sun-Synchronous,” “Geosynchronous,” “Geostationary,”and “Low_Earth”.

The PureProcessType classification scheme is built specificallyfor non-physical processes. The pure process type is similar to“TimeProcessType,” “SpatialProcessType,” “MetadataProcessType,”and “ThematicProcessType”. The time process type describes thealgorithm about time. The spatial process type often expresses thecoordinate transformation model in the use of remote sensingimages. For example, the process model called LLAtoECEF definesthe method used to transform coordinates from “epsg4329” to“WGS84”. The metadata process type provides statistical comput-ing algorithm services, based on which thematic process type forspecific applications could be designed.

2.2.4. Additional RegistryObjects SlotsSlot instances provide a dynamic method of adding arbitrary

attributes to RegistryObject instances, thus enabling extensibilitywithin the information model. All additional classes includefurther particular characteristics of registry objects that can beadded to the classes by using Slot. The characteristics are based onthe related content from the OGC 07-000 profile. For example,through the execution of implementations specified within theProcessMethod definition, the process could understand how toexecute individual process models within a process chain, so we

Fig. 4. The Mapping Flowchart fro

create a Implementation Slot for ProcessMethod. Details on the slotsfor registry object are shown in Fig. 1.

2.3. Mapping from SensorML to ebRIM

The process mapping choices are shown in Fig. 4. Mappingchoices enable users to understand the structure of the mappedresources and the way such resources are represented within theebRIM metamodel. Moreover, mapping enables fast search andretrieval by using the standardized OGC catalogue interface.The use of the following mapping flow is recommended formapping processes that will be mapped to ebRIM (Fig. 4).

2.3.1. ObjectType mappingAs mentioned in Section 2.2.1, five Classification Nodes (System,

Component, ProcessModel, ProcessMethod and ProcessChain) areadded in the ObjectType ClassificationScheme as a sub-class ofrim:ExtrinsicObject. Upon the submission of these classificationnodes to the process registry through the “transaction-insert”operation, a rim:ExtrinsicObject within it may be typed as asystem or as another object. Depending on the type of process,the following mapping procedure is used to choose the mappingsamong specific attributes and associations.

2.3.2. Attribute mappingAttributes such as identifier, name, description, classification,

contact, inputs, outputs, parameters, and so on, are required tofacilitate efficient discovery. Different attributes exist for differentExtrinsicObjects (Fig. 1).

1.

m S

Map to identifier: The identifier property uniquely identifiesthe sensor and is of type URN. This property is mapped to rim:ExtrinsicObject/@id.

2.

Map to Name/Description: The LongName property provides acommon name for the sensor. This property is mapped to rim:

ensorML to ebRIM.

N. Chen et al. / Computers & Geosciences 56 (2013) 45–5550

Name. The Description property provides a description for thesensor and is thus best mapped to rim:Description.

3.

Map to classification: A rim:ClassificationScheme will be built tomap the classification's value to rim:ClassificationNode, which iscreated within the said scheme to represent the value. Whenthe process is registered, the mapping to classification requirestwo steps. For example, when a System is registered, the firststep is to define the SystemType ClassificationScheme, whichincludes two ClassificationNodes for each physical process. Thesecond step is the creation of a Classification instance, whichrefers to ClassificationNodes in the Data Source Scheme when aSystem instance is added into the registry. The correspondingrim:ClassificationNode and rim:Classification for different pro-cesses will be created according to Section 2.2.3.

4.

Map to Organization/person: Suitable mappings between thecontact information in SensorML to the contact attributes inebRIM, are created.

5.

Map to Slot: In most cases, the specific domain attributes thatrequire exposure within the target ebRIM model for discoveryare mapped to Slots. Similar to the mappings in OGC09-163r2,the Slot of System and Component are added. In the case of thesource SensorML, the attributes for ProcessChain includinginputs, outputs, and parameters are mapped to Slots. The coreattributes are mapped to Slots for ProcessModel and Process-Method (Fig. 5).

2.3.3. Association mappingTo define a new association type, the canonical AssociationType

ClassificationScheme is extended, and a new ClassificationNode is builtas a child or descendant of the AssociationType ClassificationScheme.When the association mapping is determined to be valid, thecorresponding association will be created, as shown in Fig. 4.

Fig. 5. The Correspondence between SensorML metadata xpath and the

3. Process registry experiments

3.1. Implementation of a process registry service prototype

A demonstration of this registry service has been deployed inthe “GEOSENSOR-CSW” server. Web services and Java technologyhave been used to implement the service with the OGC-CSW andebRIM standards. The registry service for processes uses theextension package which is mentioned in Section 2. The demoextension package application can be viewed at http://swe.whu.edu.cn:8080/MyCswPro/jsps/login.jsp.

GetCapabilities: The program generates an XML request toenable a user to retrieve information about the service when theuser takes the action “GetCapabilities.” The body of the responsewill describe the basic operational and non-operational character-istics of the GEOSENSOR CSW.

SensorMLtoebRIM: The transformation of the process descrip-tion is based on a suitable XSLT and closely follows the mappingdescribed in Section 2.3. The program offers a basic interface thatenables a transformation from SensorML to ebRIM. When theinput text field is the SensorML description and a user selects theaction “transform,” the output document created is ready forinsertion.

Transaction-Insert: Users could insert a process in three ways:input parameters, input documents in the form of “insert” andinput documents encoded in SensorML. Through the former twomethods, the information could be inserted into the system.Through the last method, users select a document of a processencoded by SensorML, then the service will automatically call theappropriate conversion document (XLST) and generate an XMLrequest called “Transaction-insert.” This request will register theprocess as a rim:ExtrinsicObject object in the registry service, asshown in Fig. 6.

attribute of ProcessModel and ProcessMethod ExtrinsicObject.

Fig. 6. A registry example, using documents encoded in SensorML.

N. Chen et al. / Computers & Geosciences 56 (2013) 45–55 51

Transaction-Update: The program generates an XML requestcalled “Transaction-update,” which includes the description of theprocess when a user selects a document to describe the existingprocess. The operation replaces the existing object with the newdescription in an update statement.

Transaction-Delete: When a registry object is to be deleted, theprogram generates an XML request after the user selects the action“Transaction-delete.” If a given registry object is deleted, thisdeletion cascades to the corresponding components, such as,rim:ExternalIdentifier, rim:Classification, and rim:ServiceBinding.

Batch Upload: For the management of a large number ofprocesses, the user can select the operation “BatchUpload” toregister the many processes simultaneously.

3.2. Experimental data

Floods have been a part of the human experience sincesettlements were built along riverbanks. People can undertakefield measurements of rainfall, groundwater, and river levels byusing the data collected through sensors. Algorithms enable usersto assess water movements and drive process models quantita-tively to undertake analyses such as flood risk assessment andflood warning (Ip et al., 2006; Auynirundronkoola et al., 2012;Khan et al., 2011). In particular, the use of satellite remote sensingand related algorithms (for example, the Normalized DifferenceWater Index (NDWI), which is derived from the green and NIRchannels,) hold the key to flood monitoring, which requires themanagement of physical and nonphysical processes (Martiniset al., 2011) (Gao, 1996). GEOSENSOR CSW could provide efficientmanagement of sensors and algorithms. The sensors (such as TM,

SPOT5, HRG and AQUA), and algorithms (NDWI) could be regis-tered in the registry service(GENSENSOR-CSW). The experimentaldata 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 respondsto changes in both water content and spongy mesophyll invegetation canopies. The users could set “ProcessChain” as theProcessType, “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 usingthe transaction-insert operation. The three components are“Green”, “NIR”, and “NDWIDetector.” The association “Compose-dOf” is built between the NDWI ProcessChain and the threecomponents. The association “Contains” shows that ProcessModelhas a ProcessMethod to define the algorithm of NDWI. There aretwo new associations “InputConnection” and “OutputConnection”.The association “InputConnection” describes the input connectionsbetween the system and components, whereas the association“OutputConnection” represents the output connections. Fig. 8illustrates the implementation of the two associations.

3.4. The registry of AQUA-MODIS

The experiment adopts sensor-MODIS and platform-AQUA torepresent the registry procedure. Both of them are described bySystem in SensorML. AQUA is considered as a new ExtrinsicObject-

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”.

N. Chen et al. / Computers & Geosciences 56 (2013) 45–5552

system instance and inherits the main attributes (Fig. 9). Theseattributes include the ID, keywords, inputs, outputs, ProcessType,IntendedApplication, and so on. The MODIS instrument is regis-tered as a new ExtrinsicObject “System” instance, with a newassociation “ComposedOf”. A new association “AccessibleThrough”is built between MODIS and the SOS service. The above informa-tion about MODIS will be registered in the service through the“Transaction-insert” operation.

As shown in Fig. 10, MODIS contains four components: MSC-RED-Detector, MSC-GREEN-Detector, MSC-NIR-Detector, and clock,all of which are described by new ExtrinsicObjects. The imple-mentation of associations “InputConnection” and “OutputConnec-tion” is similar to those in NDWI, and the representations of themare shown in Fig. 10.

4. Discussion

4.1. Direct registry for process model

In comparison to the 52N-SIR registry, clients can retrievesensor information only after the SIR connects to an OGC catalo-gue. Within GEOSENSOR-CSW, a user can store sensor informationdirectly. However, only a part of the information on sensors isdiscoverable in the SIR. Some information will be lost during thetransfer of sensor metadata from the SIR to the catalogue service.In the GEOSENSOR CSW, the direct registry method reduces dataloss, and could ultimately satisfy users' requirements better. Lastly,the push process of sensor metadata in the SIR can be executedeither once or with a continuous automatic repetition interval.

Fig. 9. The registry package of AQUA and MODIS based on ebRIM.

Fig. 10. The mapping of “InputConnection” and “OutputConnection”.

N. Chen et al. / Computers & Geosciences 56 (2013) 45–55 53

This requirement may affect timeliness and synchronization,whereas the GEOSENSOR CSW solution can easily be used forsearching processes and can minimize the time required fordiscovery.

4.2. More information storage for sensors

The parameters of sensors to be inserted include sensordescription, reference, identification, and service reference in theSIR, whereas the parameters in GEOSENSOR CSW are extended toinclude ProcessType, IntendedApplication, identification, and otherdescriptions. The mappings from SensorML to ebRIM in SIR

contain basic information (ID, name, description, keywords, valid-time, position, ObservedBBOX, inputs, and outputs), the ComposedOfand AccessibleThrough associations, the IntendedApplication andServiceType Classifications. Besides that, Houbie et al. (2010) definethe SystemType and OrbitType classifications for sensors.This paper realizes the above information in mappings, and themappings for System and Component from SensorML to ebRIMinclude more information. The following details are also added tothe mappings: parameters; the Contains, InputConnection, andOutputConnection associations, and the PureProcessType classifica-tion for nonphysical process. The improved mappings enable theacquisition of minimum sets for sensor discovery and enhance

N. Chen et al. / Computers & Geosciences 56 (2013) 45–5554

retrieval accuracy capabilities. Using the new mappings, the usercan transform more information about sensors and obtain morerelated 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 byHoubie et al. (2010). Compared to that, there are some additions inregistry package for all process types including the physicalprocesses and nonphysical processes. The details of additions areas follow:

(1)

New RegistryPackage: Process_Catalogue is created as rim:RegistryPackage, which is not explicitly implemented in theprocess registry.

(2)

New ExtrinsicObjects: Four Extrinsic Objects are created,which include the AbstractNonPhysicalProcess, ProcessChain,ProcessModel and ProcessMethod.

(3)

New Associations: Three associations are created, whichinclude the Contains, InputConnection and OutputConnection.

(4)

Additional properties for the System and Component: theSystem 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, butalso represents the association between a ProcessChain and asub-system.

In this paper, these employment of extensibility points ininformation model could help to registering processes. Themethod for enabling process registration allows catalogues tohandle different types of processes. The process with all typescan be registered and stored as corresponding classes into thecatalogue service (GEOSENSOR CSW).

The extended model is the basis of the query pattern to meetusers' demands. For example, if clients want to obtain processesthat could be applied in flood detection and the specified platformtype is “satellite”, they can choose the parameters “IntendedAp-plication” and “PlatformType” as query filter conditions. Theseparameters will then be matched to the process information in thedatabase through the OGC:filter function. The OGC:filter functionis used to filter the information in the service to ensure that theresponse is appropriate for the users. End users with a specificfield of expertise can more precisely query potentially interestingsensors within a catalogue client.

The results show the feasibility of registering all process typeswithin the GEOSENSOR CSW. The methodology improves on theexisting catalogue service and the sensor registry service men-tioned in Section 2. There are some issues which require in thefurther study. For example, a ProcessChain includes a connectionproperty that defines all connections between process inputs,outputs, and parameters through the chain. This paper onlydefines the mappings of connections between inputs and outputswithout considering the connections between parameters and thechain. A solution will determined in the future so that completeconnections in a ProcessChain could be represented.

5. Conclusions and outlook

This paper presents an approach for registering processes into acatalogue service. The registry for every types of processes(System,Component, ProcessModel, and ProcessChain), is organized andregistered in the GENSENSOR CSW by extending ebRIM. Theextension to ebRIM comprises four new types of classes basedon a process model, as well as the ProcessMethod class, which

addresses the requirements for process registry in the catalogueservice. The core extension to support all types of processes hasbeen developed in the GEOSENSOR CSW. This approach demon-strates that the extension can be used to implement a morerefined discovery for processes in a catalogue service. In conclu-sion, the proposed approach provides an important step towardthe registry of existing sensors and algorithms. Defining processesas new registry objects, describing the connections among theseprocesses, and using the extension to represent more informationare major work for the implementation registry service.

Yue et al. propose the addition of semantics into currentgeospatial catalogue services (Yue et al., 2011). The next step isto investigate the methods by which semantic middleware can beadded to the GEOSENSOR CSW for process registry and throughwhich internal relations in the process can be represented.

Acknowledgments

This work was supported by grants from the National BasicResearch Program of China (973 Program) (No. 2011CB707101),National High Technology Research and Development Program ofChina (863 Program) (no. 2013AA01A608), National NatureScience Foundation of China (NSFC) Program (No. 41171315),Program for New Century Excellent Talents in University underGrant NCET-11-0394, and the Fundamental Research Funds for theCentral 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 theThailandCentralplain using RADARSAT and MODIS under a sensor web envir-onment. International Journal of Applied Earth Observation and Geoinforma-tion 14, 245–255.

Botts, M., Robin, A., 2007. OpenGIS Sensor Model Language (SensorML) Implemen-tation 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 Con-sortium, 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 sensorobservation 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 ageoprocessing 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 SpecTechnical Committee Draft.URL: ⟨http://uddi.org/pubs/uddi_v3.htm⟩ (accessed25.11.12).

Deegree, 2010. deegree Web feature service v2.5. ⟨http://download.deegree.org/deegree2.5/docs/wfs/html/deegree_wfs_documentation_en.html⟩ (accessed25.02.13).

Deegree, 2011. deegree 3 catalogueService, URL: ⟨http://wiki.deegree.org/deegreeWiki/deegree3/Catalogue Service⟩, (accessed 25.11.12).

Fuger, S., Najmi, F., Stojanovic, N., 2005. ebXML Registry Information Model Version3.0, OASIS Standard.URL: ⟨http://docs.oasis-open.org/regrep/v3.0/specs/regrep-rim-3.0-os.pdf⟩ (accessed 25.11.12).

Gao, B., 1996. NDWI-a normalized difference water index for remote sensing ofvegetation liquid water from space. Remote Sensing of Environment 58 (3),257–266.

GeoNetwork, 2010. CSW service-GeoNetwork opensource.URL: ⟨http://geonetwork-opensource.org/stable/developers/xml_services/csw_services.html⟩ (accessed25.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 ExtensionPackage for ebRIM Application Profile:SensorML. OGC 09-163r2. Open Geospa-tial 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 55

Houbie, F., Bigagli, L., 2010. OGC Catalog Services Standard 2.0 Extension Packagefor ebRIM Application Profile: Earth Observation Products. OGC 06-131r6. OpenGeospatial Consortium, Inc., 146pp. ⟨http://portal.opengeospatial.org/files/?artifact_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 andmonitoring 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, OGC10-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 hydrologicmodeling for flood inundation mapping in lake victoria basin: implicationsfor hydrologic prediction in ungauged basins. International Journal of AppliedEarth Observation and Geoinformation 49, 85–95.

Martell, R., 2009. CSW-ebRIM Registry Service—Part 1: ebRIM profile of CSW.OGC07-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-inducedbackscatter changes in SAR data using Markov image modeling on irregulargraphs. IEEE Transactions on Geoscience and Remote Sensing 49, 251–263.

Pandey, K.K., Patel, S.V., 2009. A design of sensor web registry for wireless sensornetworks with SOA approach. In: Proceedings of the 2009 First InternationalConference on Computational Intelligence, Communication Systems and Net-works (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 sensorweb registry services for wireless sensor network under x-SOA approach. In:Proceedings of 2010 2nd International Conference on Trendz in InformationSciences 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 ComplexComputer Systems (ICECCS 2007). pp. 129–137, URL:⟨http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4276309&isnumber=4276290⟩ (accessed25.11.12).

Wilson, T., 2007. OWS-4 CSW ebRIM Modelling Guidelines IPR. OGC 06-155. OpenGeospatial Consortium, Inc., 98pp. ⟨http://portal.opengeospatial.org/files/?artifact_id=20430⟩ (accessed 25.11.12).

Yue, P., Gong, J., Di, L., 2011. Integrating semantic web technologies and geospatialcatalog service for geospatial information discovery and processing in cyber-infrastructure. Geoinformation 15, 273–303, http://dx.doi.org/10.1007/s10707-009-0096-1.