Based on generic requirements posed by information sharing initiatives, analysis ... business processes enabling their users to perform desired tasks. [2]. Thus, beyond ... services, components, and technical standards for ICT implementation [2]. .... instance the Legal ontology to describe legal documents, Domain ontology.
Semantic Interoperability Architecture for Electronic Government Adegboyega Ojo, Tomasz Janowski, Elsa Estevezi Center for Electronic Governance United Nations University – International Institute for Software Technology P.O. Box 3058, Macao SAR
{ao,tj,elsa}@iist.unu.edu ABSTRACT Semantic Interoperability is arguably the least developed aspect of Government Interoperability Frameworks. This could be explained by poor understanding of the semantic interoperability problem in government, considering its substance and scope, difficulties encountered in aligning technical solutions with the practice of government organizations, and the paucity of mature semantic technologies and complete semantic interoperability architectures and solutions (beyond metadata specification and semantic annotation of resources). As a result, most governments prefer to concentrate on technical and organizational aspects of their information sharing and interoperability efforts. Based on generic requirements posed by information sharing initiatives, analysis of semantic interoperability scenarios in Electronic Government, and emerging semantic interoperability practices, this paper articulates a set of semantic interoperability requirements for Electronic Government considering policy, governance, organizational and technology dimensions. Based on such requirements, it develops a pair of reference models to guide the development of semantic interoperability capabilities for individual agencies involved in collaborations, and for the government as a whole. The paper also discusses how a concrete Semantic Interoperability Architecture (SIA) could be developed from the two reference models.
Categories and Subject Descriptors D.2.12 [Interoperability], J.1 [Administrative Data Processing]: Government
[2]. Thus, beyond achieving physical connectivity between heterogeneous government applications, the full interoperability should: (i) enable the execution of cross-agency processes that can deliver seamless services to citizens and businesses; (ii) guarantee that different systems involved in such processes share information in a semantically-compatible manner; and (iii) support the widest possible access to information and capabilities available in the government ICT environment, particularly with respect to citizens and businesses. This understanding is increasingly shared by experts, evidence of the recent updates to the first generation of the national Interoperability Frameworks (IFs) which until now focused on technical aspects of interoperability. There is also some concession to the lack of understanding how various dimensions of interoperability – organizational, technical and semantic – and their components interact [1]. In addition, recent IFs are better situated within well-defined policy guidelines to determine their use, management and evolution. In fact, emerging IFs include policy guidelines, governance principles, enterprise and ICT architectures, semantic frameworks (metadata, ontologies etc.), services, components, and technical standards for ICT implementation [2]. Overall, the fundamental nature of organizational interoperability is largely accepted and the need for comprehensive semantic interoperability solutions is increasingly recognized. For instance, emerging IFs now require organizational interoperability as cross-cutting and explicitly define semantic interoperability needs and strategies. However, the clarity and understanding of the semantic interoperability problem in the context of electronic government remains generally poor. In this paper, we define semantic interoperability as follows.
General Terms Management, Standardization
Definition 1: Semantic Interoperability
Keywords
The capability of organizations in public, private, voluntary and other sectors, and their information systems to:
Semantic Interoperability, Semantic Interoperability Framework, Electronic Government, Enterprise Architecture
1) 2)
1. INTRODUCTION
3)
Interoperability remains one of the most critical factors in enabling the required connectedness within government and between government and its major stakeholders – citizens, businesses, intermediaries and suppliers. Interoperability here is considered as the ability of systems to communicate, to share semantically-compatible information, to perform compatible transactions, and to interact in the ways that support compatible business processes enabling their users to perform desired tasks
The paper examines general information sharing needs of government organizations, based on the analysis of the semantic interoperability problem in the Electronic Government domain, and available government semantic interoperability frameworks (Section 2). Based on this examination, the paper defines three categories of requirements to enable semantic interoperability:
discover required information; explicitly describe the meanings of the data they wish to share with other organizations; process received information in a manner consistent with intended purpose of such information.
policy and governance, organization and technology (Section 3). These requirements are refined into to a pair of reference models that prescribe the required semantic interoperability capability for a government as a whole (network of collaborating entities) and for individual agencies involved in collaboration (Section 4). A process for developing Semantic Interoperability Architectures from the reference models is presented in Section 5, while applications of the reference model are highlighted in Section 6. Finally, the paper provides concluding remarks in Section 7.
2. SEMANTIC INTEROPERABILITY IN ELECTRONIC GOVERNMENT The section examines the nature of semantic interoperability when applied to Electronic Government. Section 2.1 considers interoperability in the context of information sharing in general. Section 2.2 focuses on semantic interoperability and Section 2.3 examines Government Semantic Interoperability Frameworks.
is captured by Definition 1. From this definition, several semantic interoperability challenges arise, in particular: the need to integrate information across agencies to support strategic decision making, delivery of seamless services, and improved response to emergencies such as natural disasters or terrorism [15].
2.2.2 Elements of Semantic Interoperability In addition to organizational and policy requirements underpinning information sharing and interoperability activities, our definition make explicit three technical elements that define semantic interoperability capability as in Figure 1: o o o
Describe - semantic description of information assets based on some form of conceptualization; Mediate - semantic mediation to resolve differences in conceptualization when searching for information assets; Discover - semantic discovery of assets based on semantic descriptions and, if necessary, semantic mediation.
2.1 Information Sharing and Interoperability Information sharing capability is a defining feature of the socalled connected or networked government, a government in which information flows across organizational boundaries and along government hierarchies. Information sharing in government can be limited to a single organization (intra-organizational); across organizations but within the same public administration (inter-organizational); and across public administrations e.g. involving different levels of government (inter-governmental) [20]. Concomitantly, information sharing initiatives could either support specific government programs, e.g. the delivery of an integrated social-welfare system, or more general governmentwide initiatives, e.g. the submission of statistical information to the national databank. These two information sharing dimensions (organizational and program-specific) define potential scenarios for analyzing the interoperability challenge in government. Collaboration readiness – a major dimension of information sharing capability [8] is a pre-condition for successful interoperability initiatives [9]. According to [9], addressing interoperability requires collaborating organizations to: (i) invest in changes to internal organizational arrangements, practices and technical resources to align with externally-agreed priorities; (ii) create new and renewed relationships; and (iii) recognize and manage the challenges to network formation such as modification of legal framework and organizational infrastructure. At the same time, [20] recommends the following actions by government leaders to develop their interoperability capabilities: building network leadership skills in government leaders, creating effective cross-boundary governance structures, and creating resource allocation models that support interoperability initiatives.
2.2 Semantic Interoperability This section defines Semantic Interoperability (Section 2.2.1), presents its core elements (Section 2.2.2), and outlines a number of scenarios for its use (Section 2.2.3).
2.2.1 Definition of Semantic Interoperability Several definitions of semantic interoperability have been presented, largely in the context of government interoperability frameworks [1], [2], [11], [12] and [14]. Considering different interpretations, our working definition of semantic interoperability
Discover
Describe
Mediate
Figure 1. Core Semantic Interoperability Elements Semantic description capability entails the use of some form of metadata in annotating information assets. This aspect is perhaps the most fundamental and mature of the three elements. In fact, most Government Interoperability Frameworks (GIF) already include comprehensive metadata specifications, e.g. [16]. Existing semantic technologies support semantic discovery when semantic descriptions are provided - [22] elaborates on this requirement. Semantic mediation is the least developed aspect of semantic interoperability. The objective of semantic mediation is to resolve semantic differences that may arise in the context of information exchange between participants in an interaction, e.g. service delivery. All information exchanged between participants in an interaction can be implicitly or explicitly associated with some semantic domain or conceptualization which represents the meaning of the information regardless of its format or syntax. Therefore, the semantic mediation involves providing translation services to interacting entities form different semantic domains. For instance, on receiving a message M from a party A to be delivered to another party B, belonging to a different semantic domain than A, a mediation device (or semantic gateway [3]) must be able to automatically discover and gather necessary information from other sources to build an equivalent message M’ with the same meaning in the target semantic domain of B. Figure 2 depicts an abstraction of the mediation process. Message M from A
Semantic Mediation Device
Equivalent Message M’ for B
Figure 2. Abstract Representation of Semantic Mediation
2.2.3 Scenarios for Semantic Interoperability Semantic domains or conceptualizations are represented in practice as ontologies. An ontology is a formal representation of a conceptualization which provides definitions of concepts relevant to a domain, system or application [4]. Simply, ontologies provide meanings to concepts. Formally, ontologies represent concepts as classes while attributes of concepts are represented as properties (or relations) of these classes. Constraints and restrictions are expressed as axioms and rules over the classes. For example Figure 3 (source – FEA-RMO Report at https://www.osera.gov/ web/guest/projects/fea-rmo) below shows an ontology describing the Business Reference Model (BRM) of the US Federal Enterprise Architecture (FEA). The ontology shows a concept hierarchy for “Lines of Business” and the various sub-functions under “Management of Government Resources” function such as “Administrative Management”, “Supply Chain Management”, etc. Simple ontologies include taxonomies and thesauri.
Figure 3. Fragment of FEA Reference Model Ontology In addition to FEA-RMO, a number of generic Public Administration (PA) ontologies have been developed in major semantic interoperability-related projects, particularly among the European Commission’s IST projects. These include Service Model ontology of the Governance Enterprise Architecture (GEA) model (http://www.semantic-gov.org) and e-Government Services Ontology for modeling and conceptual description of government services (http://smartgov.e-gov.gr/). Moreover, the OntoGov project (http://www.ontogov.com/) provides a set of ontologies for modeling e-Government services, for instance the Legal ontology to describe legal documents, Domain ontology containing domain-specific knowledge, Service ontology to describe services, Lifecycle ontology to describe information flows and decision making processes in Public Administrations, and Web Service Orchestration Ontology. Semantic differences in government transactions arise as a result of the use of multiple ontologies (implicitly or explicitly) by agencies. Technically, the task of semantic mediation is
essentially ontology mediation. Significant amount of work has been carried out in this area based on the earlier work on schema mapping in databases. For instance, [13] provides an ontology mediation pattern language (i.e. a language to describe basic mappings) and a library of these patterns. Differences in ontologies may lead to the following types of semantic conflicts in messages or information exchanged among interaction parties [3]: o Data Value Conflicts – different representations for the same value type, for instance sex values represented as “M” and “F” in one system, while “male” and “female” in another. o Data Precision Conflicts – differences in the units or scales of values, for instance one system represents length in “meters” and the other in “feet”. o Spatial Domain Conflict – different legal implications for the same piece of data, for instance “blood group” information as part of personal details is allowed in one context, while it violates privacy rights in another. o Labeling Conflicts – different concepts described by the same word (homonyms) and multiple alternative words describing the same concepts (synonyms) o Confounding Conflicts – actual meaning of information is dependent on the content or value of another data, for instance “today’s weather”. o Schema Isomorphism Conflicts – same concept is described with different set of attributes. o Integrity Conflicts – data considered correct in one context violates integrity constraints in another, for instance a citizen may be permitted to have more than one address in one context and only allowed one address in another. o Generalization Conflicts – data held in one context may be a subset or superset of another, therefore data with mandatory attributes in one context may be invalid in another. o Aggregation Conflicts – data stored in one context is defined collectively in another (or vice versa), for instance individual student records are grouped by ages in another system. In [3], these conflicts are associated with different aspects of public service delivery in an inter-governmental perspective based Government Enterprise Architecture Model presented in [7, 17]. Semantic differences related to: evidences, eligibility conditions, public service provision, customers, outcome of services, etc. are discussed, which also apply to inter-organizational context. Consider a typical authorization service consisting of the steps below: (1) submitting application; (2) verifying completeness of application; (3) checking eligibility of the applicant; (4) evaluating the application; (5) requesting for external information from third-party entities; (6) making decision; (7) notifying the applicant on the result; (8) propagating the outcome to third parties; and (9) closing the case. In Table 1 below, we highlight the kind of semantic differences that may arise in the evaluation, decision and propagation steps of this process. Semantic mediation devices or semantic gateways are expected to handle all major semantic differences arising from the interactions between government, citizens and third-party entities in interorganizational and inter-governmental contexts.
Table 1. Semantic Conflicts in Public Service Delivery Process Step
Actions
Evaluation
o o o
Decision
o o o o Propagation o
Providing technical opinion on information internally External evaluation of information provided Request for actions to third party entities
Consolidating external inputs Documenting decision Communicating decision Seeking additional input Update third-party agencies with application results
2.3 Government Semantic Interoperability Frameworks We examine the available Government Semantic Interoperability Frameworks (GSIF) and evaluate the scope of these frameworks as input to developing the necessary semantic interoperability in government. Five GSIF were considered in this work: 1) 2) 3) 4) 5)
Comments
US Data Reference Model (DRM), one of the five reference models of the Federal Enterprise Architecture (FEA); EU Content Interoperability Strategy, a part of the European Interoperability Framework; UK e-Government Metadata Standard, a part of the eGovernment Interoperability Framework; Dutch Interoperability Framework (proposed); and Australian Information Interoperability Framework, part of the Australian Government Interoperability Framework
Each of these frameworks is briefly discussed below: FEA Data Reference Model (DRM) – The reference model provides no definition for semantic interoperability. It serves as a means for identifying what data the federal government has and how such data can be shared in response to business/mission requirements. It facilitates information exchange within communities of interests and enables credible cross-agency agreements on governance, data architecture and information sharing frameworks. The reference model consists of three areas of standardization – data description, data context and data sharing. Data description standard facilitates discovery through uniformity in approach to describing data. Data context standard provides taxonomies and definition of data assets associated with specific communities of interest and also establishing a basis for data governance. Data sharing standard supports access and exchange of data supported by the earlier data description and context standards. The reference model is documented in [18]. EU Content Interoperability Strategy – Content or semantic interoperability is to ensure that precise meaning of exchanged information is understandable by any other application that was not initially developed for this purpose. Semantic interoperability here is facilitated by the semantic interoperability assets (SIA) information resources developed to address semantic interoperability requirements in information systems. SIAs include dictionaries, thesauri, taxonomies, mapping-tables, ontologies and service registries. Other aspects of the content interoperability strategy include developing semantic gateways for
The semantic differences are associated with: (i) information supplied to third-party organization, (ii) the eligibility of the originating agency to make request for the evaluation service, (iii) the expected outputs from the evaluation and (iv) possibly the security context for the type of evaluation sought. Most of the semantic differences here will be associated with the consolidation of facts from different sources. In addition, semantic issues may also arise when requesting for clarification or more information from the customer. The semantic differences in this context relate to the anticipated effect of the update made to other agencies.
translation, developing clearing houses and registries to manage SIAs, and developing the required organizational processes. This strategy is provided in [19]. UK e-Government Metadata Standard – This standard does not define semantic interoperability since it only addresses one aspect of it. It aims to ensure maximum consistency of metadata across public sector organizations. The standard is part of the eGovernment Interoperability Framework (e-GIF) and specifies the elements, refinements and encoding schemes for creating metadata. The standard is documented in [16]. Dutch Interoperability Framework – The proposed framework will include guidelines for developing semantics for Electronic Government. The objective is to ensure that information exchanged is meaningful to all parties within a community of interest. It specifies that semantic interoperability involves: (i) data definition - a computational basis for deriving data, (ii) terminology and controlled vocabularies, (iii) computational models and assumptions for producing results, (iv) conceptual and functional model, (v) business process models, and (vi) key policies such as access, authentication, authorization, security, transparency, accountability, privacy, etc. The proposed Dutch IF is documented in [16]. Australian Information Interoperability Framework – The framework describes information interoperability as the ability to transfer and use information in a uniform and efficient manner across multiple organizations and information technology systems. This framework provides the principles that underpin sound information management and establishes the concepts, practices and tools that can drive successful sharing of information across government boundaries. The framework identifies six enablers including: partnership and collaboration, agreed authoritative sources of information, common business language and standards, appropriate governance structures, legal and policy frameworks, and tools to support information sharing. The framework is documented in [14]. Table 2 presents the description, major elements and responsible organizations for the five semantic interoperability frameworks. These frameworks implicitly prescribe some basic requirements for semantic interoperability. In addition, [23] argues that governance is a cross-cutting concern for all layers of interoperability.
Table 2. Major Elements of Government Semantic Interoperability Frameworks Country
Description
US
The Data Reference Model is one of the five Federal o Data Description - provides a means to uniformly Enterprise Architecture Reference Models. It is the FEA describe data to facilitate its discovery and sharing mechanism for identifying what data the federal government o Data Context - facilitates discovery through has and how such data can be shared in response to categorization of data according to taxonomies and business/mission requirements. It facilitates communities of definition of data assets within a community of interest interests and enables the needed conversation to reach o Data Sharing - supports access and exchange of data credible cross-agency agreements around governance, data where access consists of ad-hoc request and exchange architecture and information sharing frameworks. consists of fixed reoccurring transactions between parties
Office of the Management and Budget and Chief Information Officer Council
Content Interoperability Strategy is part of European Interoperability Framework (EIF). It ensures that the meaning of the information exchanged is not lost in the process. It also defines semantic interoperability assets - the resources required to enable semantic interoperability such as terminologies, thesauri and mapping rules.
Interoperable Delivery of PanEuropean e-Government Services to Administrations, Business and Citizens (DABC), supported by Gartner Inc.
EU
UK
Elements
o Development of sophisticated semantic assets o Developing semantic gateways to provide translation for exchanged messages through contextual information o Developing clearinghouses and registries for publishing information on the semantic assets o Organizational processes
e-Government Metadata Standard, a part of the e- o Metadata Government Interoperability Framework (e-GIF), it provides the elements, refinements and encoding schemes to be used by governments officers when creating metadata for their information resources or when designing search interfaces for information systems.
Netherlands A section of the proposed Dutch Interoperability Framework. o Data definition, unit of expression, and computational The focus is on aligning semantic issues across basis and assumptions that are used to derive data organizational, sectoral and system boundaries. o Terminology and controlled vocabularies o Computational methods and assumptions o Conceptual and functional models o Business process models o Key policies, such as access, authentication, security, transparency, accountability Australia Information Interoperability Framework is part of the o Partnership and collaboration Australian Government Interoperability Framework. It aims o Agreed authoritative sources of information to assist agencies in improving their capacity for information o Common business language and standards management in support of information exchange. o Appropriate governance structures o Legal and policy framework o Tools to support information sharing
Organization / Version
DRM Version 1.0 July 2002, DRM 2.0 in June 2005
2005, Recommendations for EIF version 2 in April-June 2007 Metadata Working Group; Interoperability Working Group 2006
Forum Standaardisatie, Europe
RAND
2008
Australian Government Information Office (AGIMO) 2006
Specifically, the frameworks prescribe that Government IF include both Political- and IT Governance be explicitly addressed in any interoperability solution. This perspective is supported by [21], which also indicates that any information sharing between government agencies must contend with legal, policy, organizational, managerial, social processes, in addition to technological issues.
3. SEMANTIC INTEROPERABILITY CAPABILITY REQUIREMENTS The section presents three capability dimensions for semantic interoperability (Section 3.1) and then elaborates of each of them: policy and governance (Section 3.2), organizational (Section 3.3) and technical dimension (Section 3.4).
3.1 Capability Dimensions To define capability dimensions for semantic interoperability, the generic information sharing requirements in Section 2.1 help define organizational requirements; analysis of semantic interoperability in Section 2.2 defines technical requirements, while Government Semantic Interoperability Frameworks in Section 2.3 help identify policy, governance, organizational and technical requirements. We streamline these requirements into the following three categories: 1) Policy and Governance – These are requirements which provide the strategic framework for developing semantic interoperability capabilities within government. They cover issues related to guiding principles underpinning semantic interoperability, roles and responsibilities of participants and compliance with respect to related regulations. 2) Organizational – They consist of the requirements related to the processes for cooperation, enlisting participation of government organizations, evolution of communities of interests (COIs) and adoption of common business vocabularies and standards across government (for shared or common contexts) or with specific COIs. 3) Technical – They relate to technical or technological capabilities that collaborating networks and individual participants (organizations) should possess, for instance availability of semantic descriptions of relevant enterprise data and assets in a clearinghouse and availability of a semantic gateway to resolve semantic differences for communication between communities of interests (COIs). Policy and governance as well as organizational requirements are enablers and constraints for the realization of the technical requirements. Therefore, governance and organizational factors are at least as critical to achieving semantic interoperability as technical requirements. Specific requirements under each category are elaborated below.
3.2 Policy and Governance Dimension We define five requirements in this category: R1) Guiding Principles – Clear principles and strategic drivers underpinning semantic interoperability within government and between government and its stakeholders should be specified to guide the process for developing the required
semantic interoperability capability. For instance, supporting seamless service delivery and information aggregation for emergency management. R2) Legal Framework – Major legal issues in the area of accessibility, authentication, authorization, security, transparency, accountability and privacy that constrain semantic interoperability and must be clearly specified to guide solutions and capability development. For instance, semantic interoperability solutions must not undermine privacy or security of data on government and its customers by enabling excessive access to information by government agencies or third-party organizations. This implies that related roles must be conversant with legal obligations and restrictions related to data sharing and other cooperation initiatives, and have processes for compliance review. R3) Roles and Responsibilities – There is a need to identify the important roles in the major collaboration and data sharing initiatives and indicate specific responsibilities for these roles. For instance, different roles are needed for core processes such as clearing processes (for clearinghouse) and audit processes in compliance review. R4) Stewardship – Clear identification of lead entities and ownership structures for information and semantic assets is critical for authority and necessary for successful semantic interoperability. The integrity, availability, publishing and updates of these assets will be guaranteed by their owners. R5) Compliance Strategy – A strategy is necessary to ensure that participating (or interoperating) organizations comply with stipulated processes and discharge legal obligations. This should be developed along with an incentive system. Table 3: Governance Requirements - Summary Id
Description
R1 R2 R3 R4 R5
Providing guiding principles Specifying legal requirements Specifying roles and responsibilities of participants Providing stewardship for semantic assets Developing compliance strategy for participants
3.3 Organizational Dimension Four requirements are specified in this category: R6) Communities of Interest (COI) – There is a need to define a process for creating communities of interest consisting of organizations with shared collaboration goals. The communities will describe their collaboration and create semantic assets to underpin exchanges involved in their collaboration. The evolution and maintenance of the shared semantic assets is undertaken by these communities and relevant participants. R7) Information Context – To ensure consistent use of shared data, there is a need to adopt a common business language (similar to the FEA-Business Reference Model and Common Business Language in the Australian Information Interoperability Framework) for describing the context for the use of data assets. Therefore, a process for defining business taxonomies along functional lines for the whole of
government is required. The various COIs will be involved in the definition of such business taxonomies.
through the clearinghouse in resolving these differences. The gateway must be able to semantically validate data with respect to a semantic asset and also mediate semantic conflicts arising in different information exchange scenarios such as: collaboration parties could have different labels or names for the same information; parties use same terms but with different meanings; and one party requests information or service with no direct equivalence to the receiving party. Semantic differences arise in various aspects of a service delivery process, in particular with respect to evidences, evidence placeholders, preconditions or rules, effects and outputs of services, selection of service providers, customer characterization and security.
R8) Semantic Asset Processes – Processes for managing the lifecycle of semantic assets must be defined for the clearinghouse, along with standards and processes for creating and managing local semantic assets. R9) Collaboration Processes – Processes must be developed to enable the provision of semantic support for collaborations between government, intermediaries and suppliers. Table 4. Organizational Requirements - Summary Id
Description
R6 R7 R8 R9
Identify and develop communities of interests Develop semantic assets for shared information context Develop processes for building semantic assets Develop processes for enabling semantic support for service delivery processes
3.4 Technical Dimension Eight requirements are cataloged in this section:
R17) Interfacing with Collaboration Platforms: The Semantic Gateway, Clearinghouse and other infrastructural elements would be required to interface with collaboration platforms such as messaging gateways and workflows. Table 5. Technical Requirements – Summary Id
Description
R10
Develop semantic descriptions (metadata) for enterprise resources including data and processes Provide Local Semantic Asset Repositories for storing semantic descriptions Develop Local Metadata Registries for accessing semantic descriptions stored in local repositories Provide Central Semantic Asset Repository for storing community- or government-wide assets Develop a Clearinghouse for publishing and accessing semantic assets government-wide Develop Discovery Services for accessing Clearinghouse and Local Registries Develop Semantic Gateway for resolving semantic conflicts during information exchange Develop interfaces for integrating semantic infrastructure to other collaboration infrastructure
R10) Semantic Description – Collaborating organizations should be able to provide semantic descriptions of core enterprise elements as semantic assets, including: shared data, collaborative processes (both required and provided), services and related regulations. Semantic descriptions will be based on agreed government-wide specifications and ontologies. Such assets include dictionaries, taxonomies, mapping tables and XML schemas and ontologies.
R11
R11) Local Semantic Asset Repository – There is a need to provide storage services for semantic assets at different organizations or collaboration parties.
R15
R12) Local Metadata Registry – There is a need for collaborating (or participating) organizations to provide a Local Metadata Registry for publishing and managing the lifecycle of semantic assets. These organizations should be able to push updates of their local registries to the clearinghouse (or the central metadata registry). R13) Central Semantic Asset Repository – There is a need to establish a repository of semantic assets at the community and whole-of-government levels. R14) Clearinghouse - There is a need to develop a clearinghouse (central metadata registry) which manages the lifecycle of semantic assets on the central semantic asset repository. The Clearinghouse is expected to provide search and retrieval capabilities for semantic assets in the central repository as well as those in local repositories managed by individual organizations. R15) Semantic Discovery – Collaborating organizations should be able to search the central metadata registry for required data, services and other resource types, through the clearinghouse. R16) Semantic Gateway: To enable semantic translation (mediation) of information between collaborating parties, there is a need to provide semantic gateway services. The gateway services rely on the semantic assets provided
R12 R13 R14
R16 R17
4. SEMANTIC INTEROPERABILITY ARCHITECTURE FRAMEWORK (SIAF) Based on the requirements in Section 3, this section presents the Semantic Interoperability Architecture Framework, its scope and notation (Section 4.1), and two architectures representing the network (Section 4.2) and participant (Section 4.3) views.
4.1 Architecture Scope and Notation To address the requirements, a pair of complementary reference architectures was developed to guide collaborating organizations and the central coordination entity in developing semantic interoperability capabilities. They present complementary views of the required semantic support for collaborations: (i) Network View, based on Collaborative Network Organizations (CNO) discussed in [5], and (ii) Participant View based on the traditional enterprise architecture framework. By reference architecture, we mean a prescriptive (abstract) model for developing concrete enterprise architectures - a strategic information asset-base, which defines the mission, the information necessary to perform the mission, the technology necessary to perform the mission, and the transitional processes for
implementing new technologies in response to changing mission needs [10].
N3 Processes
4.2 SIAF View - Collaboration Network The CNO model provides four dimensions for describing the network: Structural – to identify participants in the interactions and their roles; Componential – describing the resources supporting the network; Functional – describing the major operations or processes of the network, and Behavioral – specifying the principles, policies and governance of the network [5]. In the context of the Semantic Interoperability Framework, these four dimensions are mapped respectively to the following dimensions – Participants, Resources, Processes and Governance (Figure 4).
N4 Resources
R6 – Communities of Interest R7 – Information Context R8 – Semantic Asset Processes R9 – Collaboration Processes R10 – Semantic Description R13 – Central Semantic Asset Repository R14 – Clearinghouse R15 – Semantic Discovery R16 – Semantic Gateway R17 – Interface with Collaboration Platform
4.3 SIAF View - Participating Organization The Participant view of the reference model shows the required capability for each collaborating organization. The components of this architecture consisting of the following dimensions: Processes, Information, Services and Technology, similar to the traditional domains of typical enterprise architectures (Figure 5).
Figure 4. Reference Model – Network View Figure 5. Reference Model – Participant View
The dimensions are explained below: N1) Governance – Specifies the overall principle guiding the development of the semantic interoperability capability across the government and within specific organizations. This dimension addresses requirements R1, R2, R4 and R5. N2) Participants – Identifies various organizations, consisting of government, suppliers and intermediary organizations, involved in the collaboration, and specifies their roles. This dimension addresses the requirement R3. N3) Processes – Specifies various collaborative processes that require semantic interoperability (government-supplier, government-intermediary, cross-agency, data-sharing) and organizational support required for semantic interoperation. This aspect addresses the requirements R6, R7, R8 and R9. N4) Resources – Consists of various information and technology resources required to implement semantic interoperability, e.g. semantic assets for description and mapping, semantic gateway, and the clearinghouse. Requirements R10, R13 through R17 are addressed through this view. Table 6 provides the mapping between network dimensions and the semantic requirements addressed by them. Table 6. Network Dimensions versus Requirements No Dimension
These four domains are highlighted below: P1) Processes – It specifies the collaborations required by a government agency or a third-party organization to fulfill its obligations and duties. It also indicates collaborations provided by the organization towards achieving governmentwide, community-level or collective goals. This view addresses the requirements R6, R7, R8 and R9. P2) Information – It specifies major semantic (interoperability) assets to be developed, including semantic descriptions of key aspects of the organization (data, processes, objectives, and regulations). This view captures the requirement R11. P3) Services – It includes applications, services and components to support semantic description, discovery and processing capabilities. This view addresses the requirements R10, R12, R15, R16 and R17. P4) Technology – It specifies semantic technology capabilities that organizations must acquire to develop other aspects of the semantic interoperability reference model. Table 7: Participant Dimensions versus Requirements No
Dimension
Requirements
P1
Processes
P2 P3
Information Services
R6 – Communities of Interest R7 – Information Context R8 – Semantic Asset Processes R9 – Collaboration Processes R11 – Local Semantic Asset Repository R10 – Semantic Description R12 – Local Metadata Registry
Requirements
N1 Governance R1 – Principles R2 – Legal Framework R4 – Stewardship R5 – Compliance Strategy N2 Participants R3 – Roles and Responsibilities
P4
Technology
R15 – Semantic Discovery R16 – Semantic Gateway R17 – Collaboration Platforms Interface Supports the other three dimensions
5. DEVELOPING SEMANTIC INTEROPERABILITY ARCHITECTURE 5.1 Purpose The Semantic Interoperability Architecture (SIA) to be developed from the Semantic Interoperability Architecture Framework (SIAF) specifies concrete updates for existing government-wide or agency-level enterprise architectures, to enable development of the semantic interoperability capability. SIA serves as the “tobe” or the target architecture for government organizations, lines of business in government or communities of interest.
5.2 Method
specifications identified in Section 5.2.1, for both the baseline and the target SIA in line with existing organizational practices.
6. Using SIAF – An Example In addition to using SIAF as guideline for developing government semantic interoperability architectures (SIA), it equally provides a good basis for evaluating the maturity of semantic interoperability capabilities of government agencies since a comprehensive semantic interoperability assessment or readiness instruments (e.g. questionnaires) could be developed from SIAF. For instance, a superficial evaluation of the GSIFs in Table 2 could indicate relative completeness of the EU, Dutch and Australian approach to semantic interoperability as they appear to cover technical and organizational and governance issues from specifications. Note that comprehensive assessment of semantic interoperability capability would require a detailed study of specifications as well as existing structures and infrastructures to implementation these GSIFs along both views prescribed by SIAF.
5.2.1 Product
7. CONCLUSIONS
The architecture to be developed would consist of the following types of concrete artifacts:
The goal of this paper is to provide a reference model to guide the development of Semantic Interoperability capability for Electronic Government. Towards this goal, a set of Semantic Interoperability requirements were developed from the analysis of: (i) general information sharing requirements, (ii) Semantic Interoperability problem, and (iii) Semantic Interoperability aspects of selected government interoperability frameworks.
o Structured Descriptions – to capture collaboration goals and other elements of the governance dimension. o Functional, Informational and Organizational Models – These are required to describe Information, Process, Resource and Service and Technology dimensions. UML Use Case, Class and Activity diagrams could be used to describe functional, informational and organizational models. o Conceptual Models – Conceptual models could be used for describing ontologies and related semantic assets (taxonomies, thesauri, mapping rules, etc.). UML Class diagram could be used for ontological descriptions in general. In terms of modeling notation, a UML profile for Semantic Interoperability Architecture Framework could be developed as a basis for creating semantically-consistent set of SIA models or artifacts. The SIA products are required to be conceptually and technologically aligned with the “As-Is” Enterprise Architecture. Two sets of SIA products are expected in line with the reference models – SIA products for the Collaboration Network as a whole (i.e. the Network view) and the SIA products for participating organizations (i.e. the Participants view).
5.2.2 Process A detailed four stage process is described in [10] for developing baseline and target Enterprise Architectures: 1) Data Collection – Review of documents, holding preliminary meetings and interviews with collaboration participants, etc. 2) Preliminary Product Generation – Develop the various models and other artifacts identified. 3) Review and Revision of Products – Arrange individual and group review for models and revise them as required. 4) Publication and Delivery of Final Products – Publish revised products and update enterprise repository with new products. This process may be customized and adopted in developing the required SIA products – models, descriptions and ontology
A major contribution of this paper is to provide a comprehensive perspective on the problem of Semantic Interoperability, particularly to Electronic Government, which to date is arguably still not well understood. While there are a number of ongoing and concluded research projects related to Semantic Interoperability in Electronic Government, particularly part of European Commission’s Information Society Technologies (IST) program, e.g. SmartGov, SemanticGov, Access-eGov, OntoGov, UDEF, SEEMP [6] and ATHENA projects, a consolidated view of the problem is yet to emerge. In fact, we observe that the results from earlier projects are rarely considered in latter ones even when carried out within the same program framework. Thus, a consolidated view of the problem and solution is desirable. So far, we observe two major approaches to addressing the Semantic Interoperability problem: (i) implicitly, as part of a broader information-management and -sharing strategy and (ii) explicitly, as part of an e-government interoperability framework. The first approach is adopted by US and Australia, while the UK, EU and Netherlands fall into the second category. Finally, most research projects on Semantic Interoperability concentrate on the technical aspects of the problem – related to semantic description, discovery and mediation. We believe that research on the enabling aspects such as policy, governance and organization are equally important in addressing the problem. This viewpoint agrees with arguments made in [21] and [23].
8. ACKNOWLEDGEMENTS This work was partly funded by Microsoft Corporation through the Semantic Interoperability for Electronic Government Project.
Education Sector Architecture Framework (ESAF), June 2007, at: http://www.d-m-s.co.nz/Model-driven_Semantic_ Interoperability_V1.0.pdf.
9. REFERENCES [1] Gartner, Preparation for Update European Interoperability Framework 2.0 – Final Report, Engagement 221402470, 2007, at http://ec.europa.eu/idabc/servlets/Doc?id=29727. [2] Rothenberg, J., Botterman, M. and van Oranje-Nassau, C., Towards a Dutch Interoperability Framework – Recommendations to the Forum Standaardisatie, RAND Corporation, 2008, at http://www.rand.org/pubs/technical_ reports/2008/RAND_TR552.sum.pdf. [3] Billet, M., Bonomi, S., van der Graaf, E., Kirgiannakis, E., Loutas, N., van Overeem, A., Peristeras, V., Tarabanis, K, and Witters, J., Business, Semantic and Technical Requirements for Semantic e-Government Services at National and Pan-European Level, SemanticGov, FP6-2004IST-4-027517, 2006, at: http://www.semantic-gov.org/index, php?name=UpDownload&req=getit&lid=311. [4] Moca, S. Nasir, A. v. Overeem, A., Paristeras, V., Russo, R., Tarabanis, K., Triantafyllou, E., Vitvar, T., Waterfeld, W., Winkler, K., and Witters, J., SemanticGov Project – Overall Conceptual Analysis – State of the Art Report, Deliverable D1.2, IST STREP Project, FP6-204-IST-4-027517, ICT Research for Innovative Government, January 2006, at: http://www.enterprisearchitecture.info/Images/EIF/semanticg ov_ ITI_D012_Final_State-of-the-art_Report.pdf. [5] Camarinha-Matos, L.M. and Afsarmanesh, H., A Modeling Framework for Collaborative Networked Organizations, IFIP International Federation for Information Processing, Volume 224, Networ-Centric Collaboration and Supporting Fireworks, Boston Springer, pp 3-14, 2006. [6] Della Valle, E., Cerzza, D., Celino, I., Estublier, J., Vega, G., Kerrigan, M., Ramirez, J., Vallazon, B., Guarrera, P., Zhao, G., and Monteleone, G., SEEMP: a Semantic Interoperability Infrastructure for e-Government Services in the Employment Sector, at: http://www.seemp.org/. [7] Peristeras, V. and Tarabanis K., The Governance Enterprise Architecture (GEA) High-Level Object Model, LMGov 2004, Lecture Notes Artificial Intelligence (LNAI) 3035, pp. 85-94, 2004. [8] Creswell, A.M., Pardo, T.A., Canestraro, D.S, Dawes, S.S., and Juraga, D., Sharing Justice Information: A Capability Assessment Toolkit, Center for Technology in Government, University at Albany, August 2005, SUNY, at: http://www. ctg.albany.edu/publications/guides/sharing_justice_info/shari ng_justice_info.pdf. [9] Pardo, T.A. and Burke, G.B., Improving Government Interoperability: A Capability Assessment Framework for Government Managers, Center for Technology in Government, University at Albany, SUNY, October 2008, at: http://www.ctg.albany.edu/publications/reports/improving _government_interoperability/improving_government_intero perability.pdf. [10] CIO Council, A Practical Guide to Federal Enterprise Architecture Version 1.0, Enterprise Interoperability and Emerging Information technology Committee, Federal CIO Council, 2001, at www.gao.gov/bestpractices/bpeaguide.pdf. [11] Tschumperlin, J., Model-driven Semantic Interoperability using Open Standards: A Case Study, New Zealand
[12] E-Government Unit, European Commission, Study on Interoperability at Local and Regional Level. Interoperability Study Version 3, December 2006. [13] de Bruijn, J., Foxvog, D., and Zimmerman, K., Ontology Mediation Patterns, Deliverable D4.3.1, EU-IST Integrated Project (IP) IST-2003-506826 SEKT – Semantically Enabled Knowledge Technologies, Library Version 1, 2005, at: http:// www.sekt-project.com/rd/deliverables/wp04/sekt-d-4-3-1Patterns%20library.pdf. [14] Australian Government, Australian Government Information Interoperability Framework, Australian Government Information Management Office – AGIMO, April 2006, at http://www.finance.gov.au/publications/agimo/docs/Informat ion_Interoperability_Framework.pdf. [15] Program Manager – Information Sharing Environment, Information Sharing Environment – Enterprise Architecture Framework, August 2007, at: http://colab.cim3.net/file/work/ Expedition_Workshop/2007_09_18_OrganizingWorkshops_ EnvisioningPossibilities_2008/ISE-FEA_v1.0_20070830.pdf [16] Cabinet Office, e-Government Metadata Standard, eGovernment Unit, Cabinet office, United Kingdom, Version 3.1, August 2006, at: http://www.govtalk.gov.uk/documents/ eGMS%20version%203_1.pdf. [17] Peristeras, V., and Tarabanis, K., The Governance Enterprise Architecture (GEA) High-Level Object Model, LMGov 2004, LNAI 3035, pp. 85-94, 2004. [18] FEA Program, Data Reference Model, CIO Council, Office of the Management and Budget, 2005, at http://www.ocio. usda.gov/e_arch/doc/DRM_2_0_Final.pdf. [19] IDABC, IDABC Contents Interoperability Strategy, Working Paper, IDABC European e-Government Services, September 2005, at: http://ec.europa.eu/idabc/servlets/Doc?id=24405. [20] Pardo, T.A., Burke, G.B., Government Worth having: A briefing on interoperability for government leaders, Center for Technology in Government, University at Albany, SUNY Oct. 2008, at http://www.ctg.albany.edu/publications/reports/ government_worth_having/government_worth_having.pdf. [21] Scholl, H.J., Interoperability in e-Government: More than Just Smart Middleware, Proceedings of the 38th Hawaii International Conference on System Sciences, pp. 1 – 10, 2005. [22] Klichewski, R., Semantic Web for E-Government, Electronic Government: Second International Conference, EGOV 2003, Prague, Czech Republic, September 2003. [23] Kubicek, H. and Cimander, R., Three dimensions of organizational interoperability, European Journal of ePractice, No. 6, January 2009, epractice.eu. i
Elsa Estevez is on leave from Universidad Nacional del Sur, Bahia Blanca, Argentina.
