Agency: The agency is a government association. In this model for Turkey, the agency can have its own web services and legacy systems such as different types of databases. The E-government agencies are able to interact with other agencies, citizens, companies. In addition, agencies can share their data/information by using web services on the WWW.
E-Citizen: The E-Citizen is an individual. E-Citizens can access any permitted data/information about the e-government and make their government related works or processes by using governments web services.
Portal: Portal is the door for e-government services. It is a place where the individuals or companies find the ways to access government agencies’ web sites. In
other words, portal provides a single point access to other part of the e-government structures or e-government agencies. It is an appropriate way for finding government information and services from one place. For a state government, the web portal serves as the integrated gateway, or main user interface, into the website. It provides both external constituents and internal government personnel with a single point of contact for online access to state information and resources. Through this gateway, millions of web users can access the vast landscape of information, services, and applications available on the state web sites [32].
E-Company: The E-Company is the commercial institution that wants to make its government related works via the internet and e-government structure.
CHAPTER 4
THE MODEL ARCHITECTURE
In this chapter, the technical architecture of the IF and the workflow in data interchanging model are presented.
4.1 Interoperability Framework
The IF, which includes the high-level policy statements, technical policies, implementation and compliance regimes, covers the exchange of information between government systems and the interactions between:
• Government and e-citizen
• Government and e-company (worldwide) • Government and agency
• Government and other governments
In order to provide these types of interactions, the interoperability framework should consist of important core elements. These elements play key roles for providing secure, seamless, and fast data/information interchanging across the government. The core elements of interoperability framework can be listed as:
• Metadata Standard • XML Schema Structure • Data Standard Catalogue • E-Service Registry
Metadata Standard (MS)
The metadata is data about data. Search engines can use it when they search the web or an intranet looking for information on a particular subject. The usage of metadata concept is the mandatory for accessing any type of data/information about the government since the other e-government players like e-citizens, agencies, e- companies usually want to reach specific government resources. In the data interchange model proposed for Turkey, the metadata descriptions should be defined for all resources that someone might search for via the web.
A metadata record should describe, manage, and catalogue these resources in a consistent and efficient way that makes data/information easily accessible. It also means that people searching government websites are more likely to get relevant and meaningful hits when they search for government information. A metadata record should be made up of a number of separate elements. People should use these elements when they want to search government resources. As a sample, the author, title, and publisher can be elements about the book that is to be searched in government resources. Creator, function and availability can be other elements about the service that is given by the government agencies. The table 4.1 shows the example metadata descriptions and their explanations.
Metadata Meaning
DATE.CREATED: 2002-12-02 ISSUED: 2002-12-03T11:00
For a press release approved and sent to editors on 2nd December 2002 but not available for public viewing until 11:00 a.m. the following day
DATE.ACQUIRED:1997-07-03T15:37 For an e-mail received on 3rd July 1997
CREATOR: Assistant Director;
Technology Strategy Team, Office of the e-Envoy, Cabinet Office
For a resource for which chief responsibility for content rests with the Assistant Director
Metadata standard should define the structure and rules governing metadata used by the public sector. This standardization is essential since the data/information interchanged in e-government and citizens should be able to find government information and services without having knowledge of the structure of government. In addition, agencies may use the metadata standard for the definition and discovery of government services and resources.
The Metadata standard should be based on the internationally recognized Dublin Core standard, but has additional elements and refinements to meet the specialist needs of the public sector. In the model, the metadata standard should be developed and managed according to following principles:
• It should be independent. It should not be software, application, or project based.
• It should be simple to use by those with widely varying experience of preparing resource descriptions.
• It should be compliant with other government standards and policies, such as the data standards catalogue. It should be compliant with international standards.
• It should be extensible. XML Schema Structure
Many of operations occurred in e-government initiative require data interchanging. While data/information is flowing from one agency to another across government, the meaning of the data should not be changed. Data should have same meaning for communicated parties. At this point, the “inconsistent data definition” is a critical problem. In order to solve this problem across the government, XML Schema may be used that support an environment in which data is always in the same meaning.
XML Schemas can be used for data integration, validation, and management and may be placed in data standards catalog. With this approach, “data can be defined once and used many”. So, data standards catalog structure may be considered
as the huge list of data definitions based on XML Schemas. The tables 4.2 and 4.3 illustrate the basic examples of the XML document and its schema definition.
<?xml version="1.0" encoding="ISO-8859-1"?> <shiporder orderid="889923" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="shiporder.xsd"> <orderperson>John Smith</orderperson> <shipto> <name>Ola Nordmann</name> <address>Langgt 23</address> <city>4000 Stavanger</city> <country>Norway</country> </shipto> <item> <title>Empire Burlesque</title> <note>Special Edition</note> <quantity>1</quantity> <price>10.90</price> </item> <item>
<title>Hide your heart</title> <quantity>1</quantity> <price>9.90</price> </item>
</shiporder>
Table 4.2 XML Document (shiporder.xml)
The XML document above consists of a root element, "shiporder" that contains a required attribute called "orderid". The "shiporder" element contains three different child elements: "orderperson", "shipto" and "item". The "item" element appears twice, and it contains a "title", an optional "note" element, a "quantity", and a "price" element. The top line: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tells the XML parser that this document should be validated against a schema. The line: xsi:noNamespaceSchemaLocation="shiporder.xsd" specifies where the schema resides (here it is in the same folder as "shiporder.xml").
<?xml version="1.0" encoding="ISO-8859-1" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="shiporder">
<xs:complexType> <xs:sequence>
<xs:element name="orderperson" type="xs:string"/> <xs:element name="shipto">
<xs:complexType> <xs:sequence>
<xs:element name="name" type="xs:string"/> <xs:element name="address" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="country" type="xs:string"/> </xs:sequence>
</xs:complexType> </xs:element>
<xs:element name="item" maxOccurs="unbounded"> <xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="note" type="xs:string" minOccurs="0"/> <xs:element name="quantity" type="xs:positiveInteger"/> <xs:element name="price" type="xs:decimal"/>
</xs:sequence> </xs:complexType> </xs:element> </xs:sequence>
<xs:attribute name="orderid" type="xs:string" use="required"/> </xs:complexType>
</xs:element> </xs:schema>
Table 4.3 XML Schema Document (shiporder.xsd)
The Table 4.3 shows the schema that is used to describe data, which is in the form of XML document (shiporder.xml). From now on, this data definition (shiporder.xsd) can be used in data standards catalogue, which is used as huge list of data definitions book in the framework. Thus, the usage of the “shiporder” data does not create ambiguities across the government network since it was defined in data standards catalogue once.
The IF should mandate the adoption of XML and the development of XML Schemas as the cornerstone of the government interoperability and integration strategy. A key element in the development of the XML Schemas is an agreed set of data standards. The data standards catalogue should set out the rationale, approach and rules for setting and agreeing the set of data standards that may be used in the schemas and other interchange processes. In addition, the advantages of the XML Schema Structure for the model can be generalized as:
• It can provide means for defining the structure, content and semantics of XML documents.
• It can be used for data integration.
• By XML Schema, processors receiving data know what to expect, and how to handle it.
• XML Schema can enable data interchange with much–reduced ambiguity. E-Service Registry (UDDI Registry)
E-Service registry may be considered as a structure that is responsible for storing e-government web services. By this approach, classifying, categorizing, integrating web services may become easy and fast. Table 4.3 can be an example record in the e-service registry.