Printer Friendly

Dynamic and context-based GIS interoperability to support infrastructure management in municipalities.

INTRODUCTION

Information exchange among infrastructure companies is critical in achieving effective cooperation in the service of society. To facilitate this information exchange, the problem of interoperability between different GISs needs to be resolved and much research effort has been devoted to this issue (Fallahi et al. 2008, Pundt and Bishr 2002). The available studies, mostly concerned with constructing spatial data infrastructures, show that interoperability is facilitated by using a common data format for transmission between different GISs. The Open Geospatial Consortium (OGC) and the International Organization for Standardization (ISO) have issued data model standards that are effective in resolving data-transmission problems.

In modern cities, essential supplies and services, such as natural gas, water, electricity, and telecommunication facilities, are delivered to local users via various entangled infrastructures. Achieving cooperation between these infrastructures is one of the problems concerning the administration of a city. These infrastructures typically are maintained by various companies, which make different design decisions when constructing their GISs and may use different GIS tools. This diversity results in difficulties in ensuring that the GISs are interoperable.

Consider a utility company that needs to carry out a maintenance operation on one of its infrastructure elements. A service or a supply may have to be interrupted in a particular area. For example, for an electricity supply company to repair a midvoltage line, the power may need to be cut. This type of interruption can affect the network elements of other infrastructure systems such as the local exchange or a field cabinet of a telecommunication network. Moreover, in some cases, a maintenance operation requires excavation to reach a subsurface element and in this process the delivery system of another organization may be damaged. This situation is likely to arise because of a lack of information about the infrastructure laid by other organizations. To ensure that other essential services are minimally disrupted, it is necessary to devise a mechanism through which the utility companies can share their spatial data. Evidently, some infrastructure company operations, such as investment for which existing low-voltage or midvoltage line is replaced, do not require service interruption, which does affect distribution networks.

In addition to maintenance operations, several emergency situations may affect the subsurface infrastructures. For example, in the event of a flash flood in a municipality, the subsurface electricity infrastructure or various distribution transformation centers may be affected. The consequence of a flood on an electricity network will be a power cut, which implies situation changes in the elements of the electricity network. These changes have a ripple effect on other infrastructures such as the telecommunications network.

In the metropolitan municipalities in Turkey, maintenance planning is coordinated by the Infrastructure Coordination Headquarters (AYKOME). The duties of AYKOME include gathering the maintenance and investment programs of the infrastructure companies and issuing relevant permission to related companies taking into account the activity, when and where maintenance operations will be undertaken, with special attention being paid to those activities where excavation is necessary. AYKOME has a Web site and all the maintenance or investment plans are collected over that site. The site has mainly two user interfaces to collect the information related with the maintenance operation. In the first interface, the operator describes the job, the planning date, and the steps to complete the job. The second interface is used to submit the location of excavation. The contact person of an infrastructure company adds the location by using interconnected drop-down lists. The system acts like a mediator. The actual maintenance plan is prepared and finalized by the engineers in AYKOME. Therefore, the system does not provide an actual information exchange mechanism; rather, it serves as a repository to store investment and maintenance information of different companies. Moreover, the most important defect of the AYKOME system is its non-GIS based nature.

Dey (2001) defines a context as the information that characterizes the situation of an entity, which can be a person, place, or object. For the purposes of this work, we adopted an application-specific version of Dey's definition. We define a context as information comprised of an event, an action, and an organization related to an element of some infrastructure network. The existence of a maintenance activity or natural event such as a flash flood may change the situation of some elements in certain infrastructure networks; then these events may trigger a change in the context of another part of the infrastructure network. To complicate matters, the reaction to some events may be handled by more than one organization. To handle these events, a prepared set of actions is required. For example, a maintenance activity on a midvoltage line requires that the power supply to that line should be cut by the relevant distribution transformation center.

In this paper, the interoperability problem is examined from the perspective of urban infrastructure management. A sample district named Cukurca in the Cankaya municipality located within the metropolitan municipality of Ankara was selected. As a result of the data obtained from face-to-face interviews conducted with utility companies' staff, we concluded that at present, the information systems of the two utility companies provide no guidance to the relevant personnel concerning the steps required to handle maintenance operations. Furthermore, the company carrying out a maintenance operation does not have the capability to determine whether any other existing infrastructure will be affected. In this work, an ontology-based approach is adopted to model the simplified networks of the Bakent Electricity Distribution Company (BEDA) and the Turkish Telecommunications Company (TT) and to model their operations in a context-dependent way.

How urban infrastructure companies' GISs detect the current situation they are in and how maintenance operations held by one company on its network can affect the other company's network and possible emergency situations affect both companies networks are modeled in this study. To accomplish these aims, a proof-of-concept system that is composed of a set of ontologies, GIS add-ons and Web services are designed and implemented. A set of ontologies is designed as upper-level ontologies and application ontologies. Upper-level ontologies model spatial and common behavioral characteristics of network elements. On the other hand, application ontologies are designed to express the infrastructure networks by using upper-level ontologies. The possible actions during the maintenance operations and emergency conditions are found by semantic rule execution using the ontologies. The results of these actions are determined by the capabilities such as buffer and network analysis of the GIS tool, which is MapInfo in this study.

The approach used in this study addresses terminology-related semantic differences, syntactic and schematic heterogeneity problems, as well as context-based interoperability.

The remainder of this paper is organized as follows. In the second section, related works on GIS interoperability are summarized. The third section describes the building blocks of the sample infrastructure and introduces the system architecture. In the fourth section, the selected sample case studies are examined and the tools developed as an add-on to the existing GISs are demonstrated. Finally, the results are discussed and the conclusions are drawn in the fifth section.

RELATED WORK

In this section, we examined the related studies from two perspectives. In the first part, semantic interoperability problem is examined with special emphasis on ontology-based semantic interoperability. The second part of this section discusses studies in which context is used as an ingredient of the interoperability solution. The third and final part of this section provides an overview of the latest context modeling techniques.

Semantic Interoperability Studies

In any reasonable attempt at interoperability, the shared data should be interpreted and processed in a compatible fashion by all participating systems. Bishr (1998) and Stuckenschmidt et al. (2000) stated that to achieve interoperability, the syntactic, structural, and semantic integration problems should be solved.

Fonseca and Egenhofer (1999) use multiple ontologies with an object-oriented environment for GIS interoperability. In their work, geographic objects are placed in a container and these objects implement all the methods of the application ontology classes from which they are derived. In this way, the interoperability of different data sources can be achieved.

To solve the semantic issue, Kuhn (2005) argued that there must be a shared understanding of the messages that the two systems exchange. The need for shared understanding points to semantic interoperability problem, and Kuhn (2005) proposed a semantic reference system to address the problem. A study about water levels in the Elbe River is an example in which a domain ontology, an application ontology, and a reasoner were used to formulate user queries and retrieve the desired information from the related systems (Lutz and Klein 2006). A study by Bittner et al. (2005) presents another example of an ontology-based approach. They proposed two ways of applying ontologies to interoperability problems. Their first strategy used data standards and the second used reference ontologies. In addition, to achieve a shared understanding, Pundt and Bishr (2002) analyzed data from stream surveying, which also was based on the ontology approach. The data from stream surveying is used by many organizations in which the shared understanding is facilitated by a domain ontology. Visser et al. (2002) built an ontology for land-cover catalogs such as CORINE and ATKIS to solve a semantic interoperability problem. Fonseca et al. (2000) proposed generating software components from ontologies to enable data sharing and knowledge reuse. Fonseca et al. (2002) attempted GIS integration using multiple ontologies. They focused on the integration of remote sensing systems and GISs. On the other hand, Brodaric (2007) considered the interoperability problem by adopting a pragmatic approach in which geospatial, geographical, and geoscientific concepts are defined and their pragmatic context is rationalized.

Similar to Lutz and Klien (2006), logic-based reasoning was used to solve semantic heterogeneity problems in another study (Lutz et al. 2009). They used a shared vocabulary, application ontologies, and subsumption reasoning and description logic (DL)-based queries.

Yu and Peuquet (2009) used a rule and geoagent-based system for cooperating companies. In their study, each company was represented by an agent and each agent had a rule base derived from the regulations that the company personnel were required to obey. These agents worked individually or cooperatively to determine the steps to be taken during an emergency situation.

Taking a different perspective, Fallahi et al. (2008) concentrated on geoservices that contain field-based geospatial data. In their study, the properties of each geoservice were described by ontologies and DL queries were used to find the desired geoservice. Similar to Fallahi et al. (2008), Vaccari et al. (2009) proposed a geoservice semantic integration for spatial data infrastructure. Janowicz et al. (2010) also undertook research on the interoperability of the Open GIS Consortium (OGC)-based Web service and presented a semantic enablement layer that provided ontology and reasoning as Web services. The Web Feature Service (WFS) by OGC was used as the basic building block of geospatial feature discovery and integration by Zhang et al. (2010). They enhanced WFSs with the Web Ontology Language (OWL) semantically to achieve geospatial feature data interoperability at the semantic level.

Context-based Interoperability Studies

The studies discussed previously examined the interoperability problem particularly from the semantic interoperability point of view. They focused on the shared understanding between the systems. However, this understanding may change according to the context, but these studies did not delve into how contextual information should be incorporated into an interoperability solution.

Cai (2007) applied a context-based approach in the geospatial domain; to achieve semantic interoperability, he used context alignment and common contextual knowledge instead of a common ontological commitment. However, he did not abandon the ontology approach; rather, the ontology is surrounded by contextual knowledge. In other words, geospatial data semantics are expressed by ontologies that range from top-level generic ontologies to application-specific ontologies and each ontology is associated with a context. There is a generalization/specialization relationship between the ontology and its context. Cai (2007) selected a problem scenario related to a concept of nearness. For example, a person can request a computer to display a map near a town, but "near" is context-dependent because for the purposes of going on vacation or grocery shopping, the nearness concepts differ. Even for grocery shopping, different contexts are involved, such as going by car, cycling, or walking to the shop.

Ma (2011) used contextual information to achieve geological data interoperability. He aimed to achieve pragmatic interoper ability for distributed geological data. The motivation for the study came from the National Mineral Resource Assessment project of which China has several provincial and national-level subprojects. Each subproject is regarded as having individual geodata contexts, each consisting of human, machine, and nature information agents. The nature information agent represents an earth domain and the human information agent represents the project staff and their tacit knowledge. The staff of the project expresses their understanding about the earth domain via the machine information agent, which contains a local ontology and a local database. Different contexts are aligned by semantic negotiation, and as each context evolves, the semantic negotiation continues to ensure consistency. For the overall project, the provincial subprojects feed the national subprojects. However, how the semantic negotiation is differentiated between national and provincial context was not elaborated. Thus, how contexts are changed for each entity in a local ontology and a local database and the consequences of the possible changes was not discussed.

One of the recent studies by Viau et al. (2012) emphasized the context-based nature of information that makes the interoperability problem more complex. They examined the problem between a distribution network and a management information system such as a customer information system. However, the way in which context is handled was not revealed in their study.

Regarding the interoperability of the information systems, Tolk et al. (2009) proposed a seven-level framework to define the interoperability between systems, as follows: (1) no interoperability, (2) technical, (3) syntactic, (4) semantic, (5) pragmatic, (6) dynamic, and (7) conceptual interoperability. Within this framework, the technical level means the existing communication protocol for data exchange between participating systems, and the syntactic level typically is handled by a common data format, generally used for systems that have the ability to exchange data in the right forms and right order. At the semantic interoperability level, the meaning of data is shared. Above the semantic level, three interoperability levels depend on the context information. Tolk et al. (2008) determined that the pragmatic interoperability is achieved when the interoperating systems are aware of the context and the meaning of the information exchanged between each other under a specified context. Moreover, within interoperating systems, there should be an awareness of the context changes at the dynamic interoperability level. At the top level, the conceptual models of the interoperating systems are aligned. This requires, in particular, that hidden assumptions implicit in the conceptual models are made explicit and harmonized. The Tolk study recognized the importance of context, but it did not provide guidelines about how a context can be applied to create a solution for the interoperability problem (Tolk et al. 2008). In our case studies, there are two context definitions, maintenance and emergency, for which pragmatic interoperability has to be achieved. Furthermore, if a context of an infrastructure network changes, that change can be captured and handled by the proof-of concept system presented in this paper, a notion that corresponds to dynamic interoperability.

[FIGURE 1 OMITTED]

The seven-level interoperability model proposed by Tolk et al. (2009) is a hierarchical interoperability model in which to arrive at the next level the operations in the previous levels should be accomplished to a large extent. Manso et al. (2009) also proposed a seven-level interoperability model created for a spatial data infrastructure; however, between the technical, syntactic, semantic, pragmatic, dynamic, conceptual, and organizational layers there was no hierarchy. Furthermore, Manso et al. (2009) offered a definition of layers that differed from that proposed by Tolk et al. (2009), who considered that at the pragmatic level, the layers refer to the capability of different systems to use application or service interfaces to invoke methods or procedures. In addition, Manso et al. (2009) hold that systems interoperating at the dynamic level should monitor each other's context and respond to changes in the transfer of information. However, they did not mention context changes explicitly at both levels.

Context Modeling Studies

As mentioned in the first section, an event, an organization, and an action are the three components of a context and in the literature there are different approaches to context modeling. CONON (Wang et al. 2004), mySAM (Bucur et al. 2005), CoBrA (Chen et al. 2003), SOUPA (Chen et al. 2004), and OWL-C (Maamar et al. 2006) are OWL-based context models. Another type of context modeling is performed by extending the OWL schema or using another language, such as C-OWL (Bouquet et al. 2004), CoOL (Strang et al. 2003), and COM (Ou et al. 2006).

SOUPA is the acronym for the "standard ontology for ubiquitous and pervasive applications" and it consists of two related sets of ontologies. The SOUPA Core contains the generic vocabularies that are valid for a variety of applications. The vocabularies express concepts that are associated with person, policy and action, agent, belief-desire-intention (BDI), time, space, and event. The SOUPA Extension is derived from the generic concepts and introduces additional vocabularies to support specific applications (Chen et al. 2004). The SOUPA notion of context involves a set of modular ontologies designed to express situations of the interacting entities in a pervasive environment. SOUPAs modular ontologies are appropriate for the modeling of context for our purposes, as we construct a context composed of the organization of an infrastructure element, events that affect the element, and actions that influence the element. Thus, a context change is triggered by an event affecting an element, and then a set of actions are performed by a concerned organization to respond to that event.

Some of the GIS interoperability studies discussed in this section emphasize the importance of contextual information. In particular, Cai (2007) and Ma (2011) discussed the importance of context in GIS interoperability studies. Although Tolk et al. (2008) discussed context usage in regard to simulation interoperability, they derived their approach from information systems interoperability in general. However, the questions of how context change can be captured and managed dynamically and how it can be incorporated into an interoperability solution have not been answered in the GIS literature. This current study intends to respond to these two questions.

SYSTEM ARCHITECTURE

In the capital city of Turkey, Ankara, the electricity network is managed by the Backent Electricity Distribution Company (BEDAS), which is a branch of the electricity distribution company of Turkey (TEDAS), while the telecommunication network is managed by the Turkish Telecommunications Company (TT). The maintenance planning of these infrastructure companies is coordinated by AYKOME.

[FIGURE 2 OMITTED]

The main target of this study is focused on the geographic component of GIS data; therefore, in the design of the architecture, the nongeographic or attribute data is not addressed. For the case study, the data was drawn from the network elements; other data such as subscription data is beyond the scope of this study. These network elements are physical entities in the world and are modeled as geometric features in the GIS.

Data transmission between separate GISs is handled using a shared store. In our implementation, the shared store is only a collection of the instances of ontology classes, called individuals, created by AYKOME, BEDAS, and TT Web services. These Web services are described in later sections. As the shared store is accessed through these three Web services by the GISs, their implementation details and data models are hidden from all of the interoperating systems.

The Electricity and Telecommunication Infrastructure

TEDAS maintains the electricity service in Turkey at the municipality level. The distribution center is the top element of the system; from this point TEDAS is responsible for the transmission of the electricity to the clients. There are two major structures other than the distribution center and the clients, which are distribution transformation units and boxes. A diagram of the electricity distribution network is shown in Figure 1.

Performing a maintenance operation on the electricity network can have impacts on other networks. For example, during maintenance, power to a midvoltage line may need to be cut, which may affect the operation of the telecommunication network. To determine the impact on the elements of this network, the street segments affected by electricity cutoff are determined, and then the other network elements inside this area are found. The assumption here is that if electricity is cut off along a street, then electricity will not be available within a certain range around that street. The reason for using street information is that some elements of the TT network, such as the field cabinets, are not marked in the BEDAS network.

The most extensive land-based telecommunication infrastructure in Turkey is established and maintained by TT. The elements of the TT network on a municipal scale are local exchanges, fiber junctions or trunks, field cabinets, principle cables, cabinets attached to buildings, communication lines, and clients. A diagram of the relationship between these elements is given in Figure 2.

Knowledge Base

In this section, we discuss the way in which the commonalities and spatial characteristics of the BEDAS and TT systems are modeled as a set of ontologies. In our system, the knowledge base is composed of three groups of ontologies and a rule base, as shown in Figure 3. These three groups are upper ontologies, application ontologies, and context ontologies. There are two context ontologies, namely, the maintenance context ontology and the emergency context ontology.

The application ontologies are based on the upper ontologies. The context ontologies are, in turn, based on the application ontologies. In other words, upper and application ontologies are imported to constitute application and context ontologies, respectively. The rule base is constructed over both the application ontologies and the context ontologies. All the ontologies were constructed using the Protege ontology editor (2009).

Context-based interoperability is supported by the knowledge base depicted in Figure 3. The TT and BEDAS application ontologies import the upper ontologies. Therefore, the semantic level heterogeneity between TT and BEDAS can be overcome by using the abstract concepts in the ontologies of both companies, whose ancestors come from the abstract network elements ontology. In addition, different contexts are handled by the context ontologies. The rules in the rule base are complementary to the context ontologies in the sense that when the context is changed, the situations of all elements in the context are automatically changed according to the actions prescribed by the rules. Thus, an element changes its "mode of operation" depending on the context.

As stated in the framework proposed by Tolk et al. (2009), levels 4 and 5 are the pragmatic and dynamic levels, respectively. Level 4 is facilitated by context ontologies in the proposed knowledge base structure. In our prototype implementation, a context change is captured by a class instance. When an emergency event or maintenance activity is created, a representative class instance of the event is created in the shared store. The GIS systems periodically check the AYKOME Web service for the event and determine which context they should adopt, so that the GIS systems can interoperate dynamically at level 5.

[FIGURE 3 OMITTED]

The upper ontologies are the spatial representation ontology and the abstract network elements ontology. The spatial representation ontology defines the geometric entities and the relationships between them using ISO 19107 (2003) as a guide. In the infrastructure network, most elements are defined by lines and points; therefore, in the spatial representation ontology, the lines-and-points representation is used extensively. The classes used to express lines and points shown in Figure 4 are within a concept hierarchy. The terminology is from ISO 19107. In the spatial representation ontology, the GM_LineSegment consists of the GM_PointArray. Each GM_PointArray has any number of GM_DirectPositions, which is a class holding the x and y coordinates for a position. However, as at least two points are required to define a line, we put at least two GM_DirectPositions into a GM_PointArray. The relation between the GM_CurveSegment and the GM_PointArray is captured by an object property called controlPoint. The controlPoint is a sequence of positions between which a GM_CurveSegment is interpolated. For the GM_LineSegment, the interpolation is linear. Similarly, the object property named column indicates an inclusion relationship between the GM_PointArray and the GM_DirectPosition.

Figures 1 and 2 show the basic building blocks of the two networks. These basic elements can be abstracted as network nodes and edges, so the abstract network elements ontology is constructed in terms of network nodes and edges. The nodes are called DistributionUnits and the edges are called DistributionLines. In the leaves of the network are the clients with the closest distribution unit to a client being the first-level distribution unit. Similarly, the closest distribution line is the first-order distribution line. Therefore, clients are connected to the first-level distribution unit by the first-level distribution lines. In the ontology, the first-level distribution line is represented by a class named ToClient_DL, meaning that it is a class for a distribution line attached to a client. For example, the Client Line in Figure 1 is an instance of ToClient_DL. Similarly, the first-level network node is represented by a class named ClientLevel_DU, referring to a distribution unit responsible for delivering a service to a client. The other commonalities are abstracted following this approach and formulated in the abstract network elements ontology. The DistributionUnit, DistributionLine and their subclasses are presented in Figure 5.

[FIGURE 4 OMITTED]

There are two DU_DL structures in Figure 5. In these structures, DU stands for the distribution units and DL is for the distribution lines. The first is ToDistrictLevelDU_DL, which denotes a distribution line connecting two district-level distribution units (for example, the midvoltage line that connects two distribution transformation units). The second is ToClientLevelDU_DL, which denotes a distribution line that is connecting two client-level distribution units (for instance, a low-voltage line that connects boxes).

An important use of the upper-level ontologies is that an information request and a response between the BEDAS and TT GISs are performed through the upper-level ontologies for each GIS does not know the details of the other structure. For example, in the BEDAS GIS, when an operator plans a maintenance activity at a specific location where there is an underground midvoltage electricity line, he or she may need information about the whole subsurface network infrastructure at that point. However, the operator at BEDAS does not have the details of the other networks; therefore, he or she queries the other systems in terms of the abstract network ontology terms, which is the DistributionLine in this case. Thus, terminology-related semantic heterogeneities are resolved by using upper-level ontologies.

Application Ontologies

The application ontologies formalize the structures of the BEDAS and TT networks. To construct the BEDAS and TT ontology, each element is derived from the terms in the abstract network elements ontology. In addition, the spatial characteristics of the elements are defined using the spatial representation ontology by defining an object property named hasGeometry. The property has the domains DistributionLine and DistributionUnit and the ranges GM_Point and GM_Curve. For instance, ClientLine is the first-level network edge in the BEDAS network, connecting the client and the box, so it is specialized from the ToClient_DL class from the abstract network elements ontology. In addition, being an instance of a subclass of DistributionLine it is a distribution line, which means it is distributing electricity to the network nodes, and its spatial characteristics, in particular the hasGeometry property, are derived from the GM_Curve from the spatial representation ontology. In Figure 6 part (a), the asserted conditions imply that the ClientLine class is derived from both the ToClient_DL and the GM_Curve. In part (b) of same figure, the relationship between ClientLine and GM_Curve also is shown. Each element in the BEDAS ontology is defined using the same approach. In the same way, the TT ontology is constructed on the basis of the upper ontologies.

[FIGURE 5 OMITTED]

[FIGURE 6 OMITTED]

[FIGURE 7 OMITTED]

Context Ontologies

Referring to the context discussion in the first section, events are the root cause of context changes and the event, action, and organization are the three components of a context. In addition, the start of maintenance operations or emergency situations may trigger the context change of the elements in the infrastructure networks. Therefore, to capture the situation changes of an infrastructure network element, the current context of that network element should be determined. For example, during normal service, a midvoltage electricity line is expected to remain operational. To safely repair this line, however, electricity needs to be cut. This change of situation also can result from an emergency situation; for instance, during a flood or earthquake, the power supply may need to be cut for public safety.

In this study, the adopted context modeling technique is SOUPA-based. Maintenance operations to be handled by an infrastructure organization or possible emergency situations are modeled as events. The handling of an event is prescribed by an action (or series of actions). Therefore, the context ontology has three imported ontologies: event, action, and organization. Three different variations of the event are (1) construction of a new network element (resulting from infrastructural investment), (2) maintenance, and (3) malfunction. These are specializations of the InfrastructureCompanyEvent class. Emergency situations are defined as the EmergencyEvent class; currently, there are three subclasses of the EmergencyEvent class, namely, Earthquake, Fire, and Flood. The application ontologies are derived from both the abstract network elements ontology and the spatial representation ontology. An event may be handled through a contractor hired by the infrastructure company; thus, the infrastructure companies and contractors are modeled by the organization ontology. BEDAS and TT are two instances of the InfrastructureCompany class. Also, an event can have consequences. For example, when a maintenance operation on a midvoltage electricity line has an estimated duration greater than 30 minutes, BEDAS makes an announcement on the local media about the operation, giving information about the districts where electricity will not be provided and the projected duration of the loss of service. This announcement is modeled as an action. The event, organization, and action ontologies and their class hierarchies are presented in Figure 7.

Furthermore, during maintenance operations and under emergency conditions, we take an action as a result of an event. The action is decided according to the type of network elements that are affected by that event. For example, the action to be taken in response to a maintenance event on the electricity network should consider the element affected by this action. If it is a midvoltage line, then we cut the electricity from a distribution center; but if it is a low-voltage line, the electricity is cut from a distribution transformation unit. Therefore, we need to relate the event ontology and BEDAS ontology. As the maintenance event is defined in the event ontology and the midvoltage or low-voltage line is defined in BEDAS ontology, to define such a relation, we need another ontology in which all the classes are related. Thus, we created the context ontologies, namely, the maintenance context ontology and the emergency context ontology. Then we imported all the application ontologies and the event, action, and organization ontologies into the context ontologies so that we are able to define such relations and state the SWRL rules. Establishing a relationship between different ontologies such as the event and abstract network elements or organization and event ontologies is achieved by using some properties such as hasObjectType and hasEvent. We define the hasObjectType property so that, as in the announcement action example, the maintenance operation and midvoltage line should be related to enable an appropriate decision. The domain of this property is the InfrastructureCompanyEvent from the event ontology and the range is the DistributionLine or the DistributionUnit from the abstract network elements ontology.
Figure 8. Definition of announcement by SWRL in the maintenance
context

eve:Maintenance (?x) ^
eve:hasDuration (?x,?y) ^
swrlb:greaterThan (?y,30) ^
eve:hasObjectType (?x,?z) ^
electricity:MidVoltageLine (?z)
[right arrow] resultIn (?x,act:Announcement)


[FIGURE 9 OMITTED]

Rule Base

The actions that should be taken as a result of the events are decided by semantic rules, defined in SWRL (Horrocks et al. 2004), which was chosen because of its expressiveness, easy programmability, and Protege ontology editor support.

The rule base contains separate sets of rules for each context. These rules define the set of actions caused by an event. For example, for the maintenance context, the local media announcement is determined to be a type of action caused by a maintenance event exceeding 30 minutes on a midvoltage line. If an event lasts less than 30 minutes, there will not be an announcement. The action is defined by the SWRL rule shown in Figure 8. In the figure, the prefixes eve and act stand for event and action, respectively.

An important use of rules is to define the action that results in changes to the modes of operation of network elements. For example, a set of conditions under which a DCIsolation action occurs is defined by rules. A DCIsolation action means that a distribution center should be isolated from the network, then the mode of operation of that distribution center is changed from "power on" to "power off," as well as all the network elements that are connected to that distribution center.

We have an organized collection of ontologies to provide interoperability in the GIS infrastructure in the maintenance or emergency context. However, the problem of sharing geographic data still exists. A standard protocol, WFS permits platform-independent transmission of geospatial data, and WFS services are used as a geographic data source. Other than the WFS services, three Web services have been developed, namely, the AYKOME, BEDAS, and TT services. The AYKOME Web service is designed to mediate between the BEDAS and TT GISs. The AYKOME system has the following the responsibilities:

To create and obtain class instances of spatial representation and context ontologies as a result of requests from the BEDAS and TT GISs;

* To store event, action, organization, and street information in the shared store; and

* To make inferences on the context ontology using SWRL rules to determine the necessary actions.

To fulfill these responsibilities, the AYKOME service has the ability to create information requests and responses between two GIS systems. The responsibilities of all three services will be discussed in a following section. The knowledge base, Web services, shared store, inference engine, WFSs, and GISs that constitute our system architecture are shown in Figure 9.

In this study, because of its capability of running SWRL rules, easy-to-use Java interface, and Protege integration, the Jess rule engine by Friedman (2008) was selected for reasoning, using the rules in the rule base.

To summarize, the three Web services use the knowledge base both to decide on an action in response to an event and to query an ontology. The BEDAS and TT GISs use these three Web services to achieve interoperability.

IMPLEMENTATION OF THE CASE STUDIES

To implement the interoperability solution, add-ons have been developed for the GISs and Web services. In this section, all the software components and their functionality are elucidated through two prototype implementation case studies. The first case study shows how the systems behave under regular maintenance activity. The second case study focuses on how systems behave under emergency conditions. As emergency conditions arise unexpectedly, neither the BEDAS nor TT network is initially aware of the new context. They both need to sense the context change and respond accordingly. To avoid duplication, only the differences from the first case are described in the second case. In particular, we elaborate on how both systems detect context changes dynamically.

In the case studies, there are two separate SWRL rule sets, one for the maintenance context and the other for the emergency context. The set of rules to apply in response to an event depends on the context. Context information also is used to determine the search radius centered on an event location in order to look for affected network elements. The details are provided in the case studies.

Case Study One: GISs Affecting Each Other

The first case study allows a two-way interaction between the GISs. When an operator in the infrastructure company plans an event, the possible effects of the event on the company itself and other companies should be examined. The flow of the first case study can be summarized as follows:

1. The BEDAS operator makes a plan to maintain a network element at some point by using an add-on in BEDAS GIS. The add-on communicates with the AYKOME Web service.

2. The AYKOME system responds with a list of preliminary actions by executing the SWRL rules, which should be completed before the maintenance operation.

3. The maintenance plan is sent to the AYKOME Web service by the add-on in BEDAS GIS to be kept in the shared store as the class instances from the maintenance context ontology.

4. The BEDAS operator performs the actions on the GIS, and the BEDAS elements and clients that are affected are displayed on the map for the BEDAS operator.

5. The streets that are affected by the action are sent to the AYKOME Web service by the add-on in BEDAS GIS to be stored in the shared store as class instances from spatial representation ontology.

6. The TT GIS sends a query periodically to the AYKOME Web service to check whether there is an event and to identify the affected streets if there is an event.

[FIGURE 10 OMITTED]

When the TT operator selects one of the listed events, the TT GIS determines its context by checking whether the selected event is an instance of emergency event or infrastructure company event.

If there is an event, the TT operator obtains the list of affected streets from the shared store via AYKOME Web service, finds the action effect range, and the affected elements on the network.

TT GIS displays the affected elements on the map.

This case starts with the selection of an element in the electricity network in the BEDAS GIS and scheduling an event for the selected element. The event scheduling is performed through an event scheduling dialog box developed as an add-on to the BEDAS GIS.

When a maintenance event is scheduled in a GIS, the actions to be taken are decided by executing rules in a rule base for a maintenance context. An operator is informed about these actions through an event scheduling dialog box. In addition, the information about an event is stored in the shared store as a class instance of the maintenance context ontology. The maintenance class instance is presented in Figure 10.

In the next step, the BEDAS GIS calculates an affected network, based on a decided action. If an action is a DCIsolation, a distribution center in the BEDAS network is a starting point for where the interruption of electricity supply will take place. An add-on developed for the BEDAS GIS is used to calculate the street segments where the electricity will be cut because of an event and send those streets to the TT GIS. Sending is performed by storing those streets in the shared store as class instances from spatial representation ontology. The performance of the prototype system is far from industrial grade because of its reliance on class instances in XML form for communication.

Street data plays a critical role in sending information from the BEDAS GIS to the TT GIS. If the electricity supply is unavailable at a location, the affected locations can be identified in terms of street segments. In the BEDAS GIS, location identification is performed through the buffer analysis. Before the locations are sent to the shared store, all the affected electricity network elements are found by the network analysis capability of the BEDAS GIS. As the subsurface infrastructure elements run parallel with the streets, the street segments can easily be identified, again, by the buffer analysis capability of BEDAS GIS.

From the TT GIS perspective, the TT GIS checks periodically whether there is a scheduled event using an add-on developed for the TT GIS. If there is an event, it is retrieved from the shared store and listed in a drop-down list on the add-on. When a TT operator selects an event, the system checks whether the class instance belongs to an InfrastructureCompanyEvent class or an EmergencyEvent class of the event ontology. The TT GIS detects its context according to the class of the instance.

The TT GIS has the capability to analyze problems caused by an event scheduled in the BEDAS GIS. After the location of an event is found by obtaining an instance of related event class from the shared store, the problem analysis is undertaken. The analysis depends on whether a scheduled event that is stored in the shared store has an excavation process. For example, if there is an excavation process that requires the use of an excavator, the affected area will be larger than in the case of no excavator being used. For example, depending on the scale of an excavator, the area affected from the excavation process can be 10 to 15 [m.sup.2], which implies a two-meter radius from the event location. Therefore, a search for a TT network element is undertaken within a context-dependent radius of the event location. If an event has an excavation process and if there is a TT network element within the search radius, then there is a possibility of disturbing that element. Potentially endangered TT elements are investigated by the TT GIS add-on. The affected TT elements are displayed on the TT GIS to the operator. In addition to the problem analysis, the operator obtains the affected streets from the shared store provided by the AYKOME Web service so that he or she can identify the locations where the electricity cut-off will take place. After identifying the locations, the affected TT elements are displayed on the map as shown in Figure 11.

[FIGURE 11 OMITTED]

Case Study Two:

An Emergency Condition with a Context Change

To see how the interoperating GISs respond to context changes, an emergency context is defined, which, in this case study, is a flood. An instance of Flood class is inserted into the shared store and a flood area is marked in the BEDAS GIS.

The objective is to capture the context in which BEDAS GIS exists, to model the impact of a flood for BEDAS GIS, and to model the consequences of an action taken by the BEDAS GIS on the TT GIS.

This case begins by acquiring a flood area and the related instance of Flood class from the shared store by the BEDAS operator. Events are retrieved with the help of the add-on developed for this case study by periodically checking the shared store through the AYKOME Web service. If there is an event, the BEDAS GIS sends a message to the BEDAS operator as shown in Figure 12 (a). Furthermore, the events occurring in the current day event are listed in drop-down list as shown in Figure 12 (b). When the operator selects the Flood_1 event, the system checks for the event ontology to determine whether Flood_1 is an instance from the infrastructure company or an emergency event. Flood_1 actually is an instance of the Flood class, which is a subclass of the EmergencyEvent class from the event ontology. Therefore, the BEDAS GIS decides that it is an emergency context and adopts the appropriate rule base for this context when deciding actions. Figure 12 (c) shows that the resulting context is an emergency context.

When an operator presses the Get Action button in Figure 12 (b) and (c), the BEDAS GIS communicates with the AYKOME Web service and obtains the necessary actions. The actions are decided by executing the related set of SWRL rules. After deciding actions, the Take Action button is pressed to perform the actions that have just been decided. Finally, the affected locations from the actions are sent to the other GIS by pressing the Send Location button. In fact, when an action is decided, the remainder of the process is similar to case study one in terms of the effects of each GIS on the other.

[FIGURE 12 OMITTED]

DISCUSSION AND CONCLUSION

This paper presents a knowledge-based system that addresses the problem of the lack of interoperability between GISs maintained by different infrastructure companies taking into account the dynamic nature of contextual information. The knowledge-based system constructed in this work is based on a constellation of ontologies. As the interpretation of the meanings of the terms in multiple application ontologies depends on the context, the ontology-based context modeling is the key to interoperability.

Because the main target of GIS interoperability is geographic data, it is appropriate to construct an application-independent mechanism that allows for the exchange of geographic data. For this purpose, we used a spatial representation ontology based on the ISO 19107 standard and independent of any specific system. The application knowledge encoded in the ontologies, the rules themselves, is clearly application and case-specific. In contrast, the standard or upper ontologies are not application-specific and, in particular, the organization of the ontologies in our work is independent of any application. The Web services that have been developed are application-dependent except for the AYKOME Web service. The part of the AYKOME service that communicates with the spatial representation ontology and creates and retrieves class instances is not specific for our application. However, other parts of the AYKOME service that create and retrieve class instances from the shared store are necessarily application-specific.

The most important findings in this work are summarized as follows:

1. The dynamic level of interoperability or context-based interoperability is facilitated by the ontology-based approach adopted in this work. More specifically, the ability to handle a fixed context corresponds to the pragmatic level and the ability to switch between more than one context during the system operation is associated with dynamic interoperability in the terminology of Tolk et al. (2008). Thus, this work is well aligned with their levels of interoperability.

2. Performing data exchange at the level of abstraction represented by the upper ontology alleviates the semantic, schematic, and syntactic heterogeneity problems. Through the upper-level ontology, we define commonalities of the network elements of different systems with comparable functionality but with their distinct terminology; thus, terminology-related semantic differences can be resolved. In addition, while performing the data exchange, each system is unaware of the data model of the other systems. Therefore, syntactic and schematic heterogeneity problems are addressed.

3. In this work, the business processes of the two infrastructure companies are captured by the SWRL rules and the rule base is based on both of the application ontologies and the context ontology. This means that the business processes of each infrastructure company are defined at the context level using terms from the application ontologies and context ontologies. Therefore, the alignment of processes is undertaken at the ontology level. Other than reflecting the processes, rules are used to define the behavior and the states of network elements.

4. The use of the upper ontology should facilitate the extension of the system to any additional infrastructure GIS. The system developed within the current work is quite flexible. The stages that are presented in the paper are:

* Designing the upper-level ontology,

* Designing the application ontology,

* Developing the Web services to be offered by the infrastructure company, and

* Adding context-related rules.

If a third GIS is to be included in the set of interoperating systems, the following procedure would be adopted. First, the infrastructure company should define its application ontology, deriving it from the spatial representation ontology and abstract network elements ontology. As these are application-independent ontologies, they can be used to construct any application ontology. Second, the Web services should be developed. These two steps of the procedure are independent of the knowledge of the other GISs. For example, a designer does not need to know about the data models of other GISs or the terminology used in the other GISs. Finally, additional rules that define the processes of the third GIS should be added to the context ontologies. Application ontologies, Web services, and rules are application-specific for they differ for each infrastructure company and require knowledge of the business processes of each infrastructure company.

5. The heterogeneity resulting from the different GISs and different data models is addressed using the Web Feature Service and the reactive behavior of the system is modeled by the SWRL rules. The Web services developed for this research serve as a bridge between the GISs and the ontologies.

This paper shows how context modeling and contextual information can be successfully incorporated into an ontology-based solution to the GIS interoperability problem. The method implemented in this study meets the requirement of dynamic level interoperability. The two case studies demonstrate how the systems interoperate in the face of dynamic context changes, including key implementation details. Such depth has not been achieved in previously proposed solutions. Furthermore, this clarifies the key importance of context in overcoming interoperability challenges.

For future work, the utility of explicitly representing the context of other aspects of urban environment can be explored. For example, it is clear that excavation operations for maintenance may impact not only on other infrastructures but also on the traffic flow in the cities. Handling this type of impact would require interoperability with the traffic system. Another possible future extension is related to the inclusion of other infrastructure utilities, such as water and natural gas providers. In the matter of implementation, data exchange between two systems is through the ontology instances. Moving the data exchange to a platform with high performance and high reliability can be another line of future work.

Emrah Tufan received a B.Sc. in civil engineering from Middle East Technical University (METU), Ankara, Turkey, in 2000 and M.Sc. and Ph.D. degrees in Department of Geodetic and Geographic Information Technologies of METU in 2003 and 2010, respectively. He currently is a senior software engineer in Roketsan A[section], Ankara, Turkey and is establishing an information system for Roketsan A[section] for product life-cycle management and trying to find an effective way of interoperability between newly constructed information systems and an enterprise resource planning system.

Corresponding Address:

Department of Geodetic and Geographic Information Technologies

Middle East Technical University

Universiteler Mah

Dumlupinar Blv. No: 1,06800

Cankaya, Ankara, Turkey

E-mail: emrahtufan@gmail.com

Zuhal Akyurek is a professor in the Department of Civil Engineering at Middle East Technical University (METU), Ankara, Turkey. She received her B.Sc., M.Sc., and Ph.D. degrees in engineering from METU. She currently is lecturing and conducting the search on both civil engineering water resources management and geodetic and geographic information technologies.

Corresponding Address:

E-mail: zakyurek@metu.edu.tr

Halit Oguztuzun is an associate professor in the Department of Computer Engineering at Middle East Technical University. He obtained his B.S. and M.S. degrees from METU in 1982 and 1984, respectively, and a Ph.D. from the University of Iowa, Iowa City, in 1991. His current research interests include distributed simulation and model-driven development.

Corresponding Address:

E-mail: oguztuzn@ceng.metu.edu.tr

References

Bishr, Y. 1998. Overcoming the semantic and other barriers to GIS interoperability. International Journal of Geographical Information Science 12(4): 299-314.

Bittner, T., M. Donnelly, and S. Winter. 2005. Ontology and semantic interoperability. In D. Prosperi and S. Zlatanova, Eds. Large-scale 3D data integration: Problems and challenges. CRC Press (Taylor and Francis): 37-48.

Bouquet, P., F. Giunchiglia, F. Harmelen, L. Serafani, and H. Stuckenschmidt. 2004. Contextualizing ontologies. Web Semantics: Science, Services and Agents on the World Wide Web 1(4): 325-43.

Brodaric, B. 2007. Geo-pragmatics for the geospatial semantic Web. Transactions in GIS 11(3): 453-77.

Bucur, O., P Beaune, and O. Boissier. 2005. Representing context in an agent architecture for context-based decision making. In Proceedings of the Workshop on Context Representation and Reasoning, Paris, France.

Cai, G. 2007. Contextualization of geospatial database semantic for human-GIS interaction. Geoinformatica 11(2): 217-37.

Chen, H., T. Finin, and A. Joshi. 2003. Using OWL in a pervasive computing broker. In Proceedings of Workshop on Ontologies in Open Agent Systems, Melbourne, Australia.

Chen, H., F. Perich, T. Finin, and A. Joshi. 2004. SOUPA: Standard ontology for ubiquitous and pervasive applications. In the First International Conference on Mobile and Ubiquitous Systems, Boston.

Dey, A. K. 2001. Understanding and using context. Personal and Ubiquitous Computing 5(1): 4-7.

Fallahi, G. R., A. U. Frank, M. S. Mesgari, and A. Rajabifard. 2008. An ontological structure for semantic interoperability of GIS and environmental modelling. International Journal of Applied Earth Observation and Geoinformation 10(3): 342-57.

Fonseca, F., and M. Egenhofer. 1999. Ontology-driven geographic information systems. In C. B. Medeiros, Ed. Proceedings of the Seventh International Symposium on Advances in Geographic Information Systems. New York: Association for Computing Machinery: 9-14.

Fonseca, F. T., M. J. Egenhofer, P. Agouris, and G. Camara. 2002. Using ontologies for integrated geographic information systems. Transactions in GIS 6(3): 231-57.

Fonseca F. T., M. J. Egenhofer, C. A. Davis, Jr., and K. A. V. Borges. 2000). Ontologies and knowledge sharing in urban GIS. Computers, Environment and Urban Systems 24: 251-71.

Friedman-Hill, E. 2008. Jess (Version 7) [Rule Engine for the Java Platform]. Retrieved August, 2013. Available at http:// www.jessrules.com/jess/index.shtml.

Horrocks I., P F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean. 2004. SWRL: A semantic Web rule language combining OWL and RuleML. Available at http://www. w3.org/Submission/SWRL/.

International Organization for Standardization. 2003. ISO 19107. Geographic information--spatial schema.

Janowicz K., A. Broring, P Maue, S. Schade, C. Keler, and C. Stasch. 2010. Semantic enablement for spatial data infrastructures. Transactions in GIS 14(2): 111-29.

Kuhn, W. 2005. Geospatial semantics: Why, of what, and how? Journal on Data Semantics III: 1-24.

Lutz, M., and E. Klien. 2006. Ontology-based retrieval of geographic information. International Journal of Geographical Information Science 20(3): 233-60.

Lutz M., J. Sprado, L. Klien, C. Schubert, and I. Christ. 2009. Overcoming semantic heterogeneity in spatial data infrastructures. Computers and Geosciences 35(4): 739-52.

Ma, X. 2011. Ontology spectrum for geological data interoperability. Ph.D. dissertation, University of Twente, Netherlands.

Maamar, Z., N. C. Narendra, and S. Sattanathan. 2006. Towards an ontology-based approach for specifying and securing Web services. Information and Software Technology 48(7): 441-55.

Manso, M. A., M. Wachowicz, and M. A. Bernabe. 2009. Towards an integrated model of interoperability for spatial data infrastructures. Transactions in GIS 13(1): 43-67.

Ou S., N. Georgalas, M. Azmoodeh, K. Yang, and X. Sun. 2006. A model driven integration architecture for ontology-based context modelling and context-aware application development. In A. Rensink and J. Warmer, Eds. Model driven architecture--foundations and applications. Berlin Heidelberg: Springer-Verlag: 188-97.

Protege Ontology Editor (Version 3.4.1) [Software]. 2009. Stanford, CA: Stanford University School of Medicine. Available at http://protege.stanford.edu/.

Pundt, H., and Y. Bishr. 2002. Domain ontologies for data sharing--an example from environmental monitoring using field GIS. Computers and Geosciences 28(1): 95-102.

Strang, T., C. Linnhoff-Popien, and K. Frank. 2003. CoOL: A context ontology language to enable contextual interoperability. In LNCS 2893: Proceedings of 4th IFIP WG 6.1 International Conference on Distributed Applications and Interoperable Systems, Paris, France.

Stuckenschmidt, H., H. Wache, T. Voegele, and U. Visser. 2000. Enabling technologies for interoperability. In U. Visser and H. Pundt, Eds. In Workshop on the 14th International Symposium of Computer Science for Environmental Protection, Bonn, Germany: 35-46.

Tolk A., S. Y. Diallo, R. D. King, and C. D. Turnitsa. 2009. A layered approach to composition and interoperation complex systems. In A. Tolk and L. Jain, Eds. Complex systems in knowledge-based environments: Theory, models and applications. Springer Verlag: 41-74.

Tolk, A., C. Turnitsa, and S. Diallo. 2008. Implied ontological representation within the levels of conceptual interoperability model. Intelligent Decision Technologies 2(1): 3-19.

Vaccari L., P. Shvaiko, and M. Marchese. 2009. A geo-service semantic integration in spatial data infrastructures. International Journal of Spatial Data Infrastructures Research 4: 24-51.

Viau, M., A. Bouffard, A. Zinflou, and G. Vanier. 2012. ODAS: A multi-agent architecture for semantic interoperability in industrial context. Enterprise Interoperability V. London: Springer: 153-63.

Visser, U., H. Stuckenschmidt, G. Schuster, and T. Voegele. 2002. Ontologies for geographic information processing. Computers and Geosciences 28(1): 103-17.

Wang, X. H., D. Q. Zhang, T. Gu, and H. K. Pung. 2004. Ontology based context modeling and reasoning using OWL. In Workshop Proceedings of the 2nd IEEE Conference on Pervasive Computing and Communications. Orlando, Florida, 18-22.

Yu, C., and D. J. Peuquet. 2009. A geoagent-based framework for knowledge-oriented representation: Embracing social rules in GIS. International Journal of Geographical Information Science 23(7): 923-60.

Zhang C., T. Zhao, W. Li, and J. P. Osleeb. 2010. Towards logic-based geospatial feature discovery and integration using Web feature service and geospatial semantic Web. International Journal of Geographical Information Science 24(6): 903-23.
COPYRIGHT 2014 Urban and Regional Information Systems Association (URISA)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2014 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Tufan, Emrah; Akyurek, Zuhal; Oguztuzun, Halit
Publication:URISA Journal
Date:Jul 1, 2014
Words:9503
Previous Article:Engaging vulnerable populations using participatory mapping: lessons learned and guidelines for community advocates and transportation planners.
Next Article:Poverty analysis using alternative poverty measures and geospatial technology in the Buffalo-Niagara Falls, New York, metropolitan statistical area:...
Topics:

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters