Abstract
E-government services are subject to a growing level of complexity, which requires a disruptive approach that better support the citizen needs concerning the government administration. Nowadays, available information technologies facilitate the description and online execution of administrative tasks, saving time and reducing possible errors. These technologies reduce administrative costs but require a complex electronic government system.
We propose using semantic technologies to describe the e-government organisational units and services in the Open Government Data and Services context. The use of semantics improves government management, service delivery and decision-making processes.
This article presents an extension of related work, introducing the evolution of the Ontology for Electronic Government (EGO): integrating other existing ontologies, supporting new features to describe e-government services and widening the usage scenarios. This extension enables the use in a real scenario with four use cases: the electronic government in the Province of Misiones (Argentina). However, the use in the domain of electronic government in a provincial context is also a proof of concept that this approach is general enough to expand into superior domains of countries that adopt the republican system of government with the division of government into the executive, legislative and judicial branches.
1. Introduction
Citizens are intensive users of mobile communication technologies, and they demand complex and sophisticated information and services from public service providers. To meet these demands, the governments’ service agencies must orchestrate much information from heterogeneous data sources (in formats and semantics) and deliver them to the terminals that citizens commonly use: computers and smartphones. This information is also distributed in a wide geographical area in data silos, depending on the governmental service providing it. However, these systems do not usually interact with each other, providing citizens with data in different and incompatible formats. Thus, citizens must reconstruct a puzzle of places, people and processes to consume a government service.
Using ontologies and Linked Open Data in strategic areas of the State such as education, health and security will substantially improve the access and provision of government services [1]. Thus, the representation of the State organisational structure as an Electronic Government Ontology (EGO) will not only provide a way of managing the data but also will enable machines to carry out automated reasoning, semantic and conceptual search, and provide decision support systems.
In this article, we propose a semantic model (using OWL2 ontologies), based on a related work [2], for the conceptual representation of the organisational units and services of the State (viewed as Electronic Government entities).
The advantage of expressing the government’s organisational structure as an EGO is that it can build an information model that allows meaningful data exploration in terms of the explicit semantics declared in the ontology. The definition of a formal ontology will enable automated reasoning, semantic and conceptual searches, and decision-support systems.
The related work [2] proposed a semantic model for the administrative structure of the State, expressed as the EGO 1 . That model is suitable as a supportive framework for the integration and interoperability of public services provided by administration offices, scattered throughout the provincial administrative territory.
As an extension of this related work, we represent public administration as a large virtual organisation [3]. The solution we present to orchestrate the diversity of electronic public services proposes to expand the public administration services, supported by a Semantic Web Services architecture, based on the EGO, Public Services Ontology, street-level images of public offices and geo-located open databases. This model provides citizens with new features, such as the intelligent search for services, location-based search for offices to use these services and the information on paperwork required to use these services.
This extension, called Linked Electronic Government Ontology (LEGO), improves the quality of the information provided to citizens by adding links to new ontologies and Linked Data sources. Besides, by adding georeferenced street-level images, a new location perspective is incorporated so that citizens can find the offices where they should go more efficiently.
This extension has been tested for a real scenario with four use cases: the electronic government in the Province of Misiones (Argentina). These use cases prove that this ontology is general enough to expand into superior domains of countries that adopt the republican system of government with the division of government into the executive, legislative and judicial branches.
The rest of the article is organised as follows. In section ‘Background and Related Work’, related works are presented. Section ‘EGO’ briefly describes EGO ontology. Section ‘Linked Electronic Government Ontology’ describes LEGO, the ontology extension developed in this work. A use case to illustrate the use of this extension in the Province of Misiones (Argentina) is presented in ‘Use Cases for the LEGO Model’. Section ‘Conclusions’ includes concluding remarks and future work.
2. Background and related work
2.1. Open government and linked data
Open Government (oGov) is a political doctrine that recognises the right of citizens to access public information and facilitates citizen participation to effectively monitor public actions. Wallace Parks introduced the term in his 1957 article ‘The principle of open government: applying the right to know under the Constitution’, later used as a synonym for government transparency [29].
In recent decades, there has been a resurgence of oGov practices, aligned with the philosophy of the Free Software movement and supported by information technologies. In this new paradigm, Open Government aims to strengthen transparency and accountability, citizen participation and citizen collaboration in the creation and innovation of public services.
Revived in England in the 1970s, the main objective was to demand government openness and citizen participation in the face of the secrecy with which they acted. The concept became the term ‘Open Government’, which means free access to public information, knowledge of the activities planned by the government and citizen participation in the construction and execution of services.
Initially, the focus was on public value in the context of Information and Communication Technology [ICT]-enabled public sector reforms. It was seen as a contribution to making government processes more efficient, effective, transparent and accountable through transformational reengineering of governments and their business processes.
In 2009, during Barack Obama’s presidency in the United States, the Open Government Directive was published and the website data.govfootnoteDataGov: http://www.data.gov to increase the public’s ability to easily find, download and use data sets generated by the federal government. This site is an example of how a government website can relate to the semantic web using [30] ontologies. The directive is based on three principles that form the cornerstone of open government:
Transparency promotes accountability by providing the public with information about what government does. It is the first step towards Open Government, pragmatically represented by Open Data initiatives and portals that publish relevant data online and share it with the people to increase accountability, promote public participation, and create economic opportunities.
Participation allows citizens to contribute ideas and expertise so that government can make policy with the benefit of information widely dispersed throughout society.
Collaboration improves the effectiveness of government by fostering partnerships and cooperation within the federal government, across levels of government, and between government and private institutions.
In 2010, McDermott [4] discussed President Obama’s Open Government Directive and the launch of the Open Government Partnership (OGP), aimed at establishing a system of transparency, public participation and collaboration. Where every government agency will be required to take immediate steps to ensure access to information by making it available online in open formats. The presumption will favour openness (to the extent permitted by law and subject to valid privacy, confidentiality, security or other restrictions).
According to Calderón and Lorenzo [5], Open Government is the form of relationship between public administration and citizens, characterised by establishing channels of communication and direct contact between them. An Open Government engages in a constant conversation with citizens to listen to what they say and ask who makes decisions based on their needs and preferences, which facilitates the cooperation of citizens and officials in the development of the services they provide and the communication of everything they decide and makes it an open and transparent system.
While Lee and Kwak [6] in 2012 proposed a five-level open government maturity model for social media-based public engagement in response to Obama’s directive. This model proposes five levels of maturity: Initial Conditions, Data Transparency, Open Participation, Open Collaboration, and Pervasive Engagement. The maturity model identifies approaches, key capabilities, processes, outcomes and metrics for each maturity level. Government agencies should focus on achieving one maturity level at a time and address challenges related to implementation, leadership, governance and culture.
Harrison et al. [7] analysed the concept of open government from an ecosystem perspective, as systems of interdependent social actors, organisations, infrastructures, and symbolic resources, and proposed that policymakers engage in such strategic ecosystem thinking.
Gascó-Hernández [8] published a comprehensive collection of papers on open government and the opportunities and challenges for public governance. These are papers that propose open government models, their contextual and cultural foundations and the development and dynamics of open data and big data for public governance.
Open Government has been taken up globally as a set of principles that are the basis for action, underpinned by an open philosophy and a mindset towards openness, as evidenced by the creation in 2011 of the OGP. OGP was founded by eight governments (Brazil, Indonesia, Mexico, Norway, the Philippines, South Africa, the United Kingdom and the United States), currently representing 79 countries.
In the Open Government paradigm, government-held information should be accessible to anyone for any purpose. According to the eight Principles of Open Government Data, to qualify data as ‘open’, it must meet these principles: it must be complete, primary, timely, accessible, machine-processable, non-discriminatory, non-proprietary, non-proprietary, and licence-free: https://opengovdata.org.
To retrieve knowledge from various domains such as ontologies, government information, geospatial data and publications, among other information [9], promoted by data.gov and data.gov.uk, propose a web-based open ecosystem that organically interconnects original data owners (such as government agencies), data processing service providers (such as entity resolution services) and data consumers (businesses and citizens). It is a way to facilitate the openness, linking and reuse of open government data. This is known as Linked Open Government Data (LOGD).
To encourage the publication of government data, emphasising standards and methodologies, enabling the public to use this data in new and innovative ways, the W3C eGov Interest Group has published a recommendation for Publishing Open Government Data 2 .
To extend the scope of our previous model, we incorporated external Open Data sources to the ontology we developed, following the Ontology Integration Framework proposal [10], obtaining a new model enriched with the possibilities offered by Linked Open Data. These external sources are collaborative systems with open licences.
2.2. Street-level information
Geospatial data, describing information tied to some locations on Earth, constitute an essential category of government data assets. This kind of data is critical for planning, policy-making and delivering innovative location-based services in domains including disaster mitigation, public health, geology, civil protection, and agriculture [11].
Michael Goodchild coined the term Volunteered Geographic Information to describe a particular case of the web phenomenon of user-generated content for harnessing tools to create, assemble, and disseminate geographic data provided voluntarily by individuals. The result is a set of sites that often provide the cheapest source of geographic information and sometimes the only source, particularly in locations where geographic information is challenging to obtain [12].
In recent years, numerous projects have been developed to capture images at the street level of the world’s leading cities. Google Street View and Bing Map Streetside are the products that lead this initiative and are the most used services. However, these companies indicate in their licence agreements that the images are their property, not for share, and not aimed for use in critical applications. They also do not provide the metadata of these images.
The collaborative applications developed by users for planning, transport, security or emergencies need open-licenced georeferenced images to share without legal restrictions. This context is where services originated in crowd-sourcing appear, such as Mapillary or OpenStreetCam, based on the collaborative work of voluntary users worldwide to create a world map of free images. This new way of integrating shared and Linked Open Data sources and public image systems at the street level offers an immersive experience close to augmented reality.
Mapillary 3 is a photography image service at street level under the model of distributed open collaboration or open outsourcing of tasks (crowd-sourcing). Since April 2014, Mapillary has used the Creative Commons Attribution-ShareAlike 4.0 International (‘CC-BY-SA License’), 4 which allows openly share and re-use the images. Currently, Mapillary is a world community that seeks to make the world accessible to all by creating a global representation with images. Connecting images over time and users create an immersive view of street-level images for people to explore virtually different places. In July 2020, the Mapillary database had more than 1.6 million images, covering more than 30 major cities across six continents and more than 8 million kilometres of ways.
OpenStreetCam 5 is an application developed by the Telenav company that collects, stores and distributes georeferenced images at the street level to help the OpenStreetMap community to improve the quality of the map data. OpenStreetCam was developed to create the largest possible open repository of street-level photography images. Therefore, Telenav licences its images under the Creative Commons Attribution-ShareAlike 4.0 International ( ‘CC-BY-SA License’).
Wikidata 6 is a semantic wiki of the Wikimedia Foundation that serves as a database to provide a common source for certain types of data. A semantic wiki is a wiki that has an underlying knowledge model described on its pages. Semantic wikis offer the possibility of capturing or identifying information about the data within the pages and the relationships between these pages. Thus, this information can be consulted or exported as a database. Semantic wikis were proposed at the beginning of the 2000s and began to be seriously used around 2005. To date, the best-known semantic wiki software can be Semantic MediaWiki [13]. 7
The W3C vCard Ontology 8 is a specification developed by the Internet Engineering Task Force 9 for the description of people and organisations. vCards are standard in other domain areas and have been implemented using other technologies, like contact management applications that support vCards as a custom content type. This standard may maintain contact information for people who have both variant forms of their name as part of one identity and, in some cases, multiple distinct identities.
2.3. Ontology design
We have considered two different proposals for the design of the LEGO ontology: Methontology [14] and Ontology 101 development process [15].
Methontology divides the ontology design methodology into several tasks:
Task 1. Build a glossary of terms. This task aims at listing the main terms to be taken into account in the ontology.
Task 2: Build concept taxonomies. This task aims to structure the defined terms as a taxonomy. Thus, these terms are categorised in a hierarchy.
Task 3: Build ad hoc binary relation diagrams. This task aims at discovering relationships between the ontology terms.
Task 4: Build a concept dictionary. The main terms are translated as ontology classes in this task.
Task 5: Describe ad hoc binary relations. Relations defined in Task 3 are then translated to ontology properties.
Task 6: Describe instance attributes. For the ontology classes, several data properties are defined at this stage.
Task 7: Describe class attributes. Instance attributes described in Task 6 are then translated to the corresponding classes (domain of these data properties).
Task 8: Describe constants. This task will discover constant elements in the ontology.
Task 9: Describe formal axioms. This task will define any axiom identified by the domain experts.
Task 10: Describe rules. Production rules will be defined in this task of the methodology.
Task 11: Describe instances. The set of instances is defined in this task.
The standard Ontology 101 development process is divided into seven steps:
To determine the domain and scope of the ontology.
To consider reusing existing ontologies.
To enumerate important terms in the ontology.
To define the classes and the class hierarchy.
To define the properties of classes and slots.
To define the facets of the slots.
To create instances.
As can be seen, both methodologies are similar, and they are commonly used as the main approaches for ontology design. To build the EGO, we used the Methontology [14] methodology, which was created in the Artificial Intelligence Laboratory at the Technical University of Madrid. The reason for this choice is the excellent support with software tools, and independence from the platform. It is also recommended by Foundation for Intelligent Physical Agents (FIPA) 10 for ontology development. It has been tested in several large-scale projects and has been successfully applied in the development of ontologies for knowledge management of open government [16].
However, in developing the LEGO extension, we have included the second step of Ontology 101 (to consider reusing existing ontologies) to incorporate concepts from other existing ontologies to increase interoperability with similar systems.
2.4. Electronic government ontologies
Klischewski [17] identified the semantic problems in e-government as a prerequisite for discussing the requirements for applying Semantic Web technologies in this domain.
One of the first well-documented approaches to describe the e-government using ontologies as a natural way of representing the structure of concepts and relationships in this area of knowledge was the OntoGov Project 11 [18]. This project produced an ontology-enabled platform that was intended to ease the consistent composition, re-configuration and evolution of e-Government services. The OntoGov project was specified and developed for deployment as a holistic framework and a supporting platform to improve public service provision by enabling semantically rich representations and refinement of public processes and services to citizens and businesses.
The oeGOV (Ontologies for eGovernment) project 12 developed by TopQuadrant and led by Hodgson and Allemang [19], was a pioneering work in the creation of an ontology for the e-government. The starting point for the project was a model of U.S. agencies and their bureaus. As a result of their work, several foundational ontologies for the U.S. government were created and published.
The EGO Ontology Model proposed by Ortiz-Rodríguez and Villazón-Terrazas [20] in 2006 was presented only in its initial state as support for semantic applications to retrieve legal documents and to provide public administration services to citizens. The ontologies they present are oriented to the legal scope for real estate transactions within the domain of the Spanish government. To build the ontologies, they used the Methontology methodology and the WebODE workbench, independent of the application. However, they agree that the e-Gov domain has not been modelled at all.
In 2007, Moulin et al. [21] proposed a method to automatically classify instances of concepts in knowledge bases and a module that allowed to obtain all the information required about the categorisation of citizens’ categorisation. The categorisation of the elements of the knowledge base was applied in the Terregov project, 13 which uses semantic technologies to achieve the integration between electronic government systems. Instead of providing ontologies, they implemented ontology creation and storage tools to allow domain experts to create the ontologies.
To solve the representation problems, Lacasta Miguel et al. [22] proposed an ontology model in three levels:
A top-level ontology that defines data types and general relationships (independent of the context).
A domain ontology with concepts and reusable relationships defined in the context of administrative models from different countries.
An ontology application where specific types of administrative units in each country are represented, together with specific instances of existing units.
Gómez-Pérez et al. [23] have presented in 2005 a set of legal ontologies for real state transactions within the Spanish government domain, as a part of their EGO Ontology model, for support semantic applications to retrieve legal documents and to deliver services from the public administration to citizens.
In 2007, The W3C published the Geospatial Ontologies, 14 a report of the W3C Geospatial Incubator Group (GeoXG) to summarise geospatial foundation ontologies to represent geospatial concepts and properties for use on the Worldwide Web.
Brusa et al. [24] proposed a method to solve the complexity of conceptual modelling in complex scenarios based on semantic interoperability through domain ontologies, where information sources are databases, legal documents and people.
There is increasing pressure for spatial data infrastructures (SDIs) to open up access to geospatial information in the public sector. This pressure implies adopting Open Data strategies and the need to integrate spatial data through Linked Open Data. These efforts to take advantage of Linked Open Data and the Semantic Web to allow global access to spatial data managed within national and regional SDIs are emerging [11].
In 2013, the Korean government adopted the ‘Government 3.0’ agenda (Gov3.0) with the vision of creating a government ‘transparent, competent and service-oriented’. The Gov3.0 phenomenon has been associated with desirable attributes in government institutions, such as increased dynamics and innovation capacity. This conceptualisation defines innovation in government as a government enabled to the Semantic Web [25].
The Organization Ontology 15 is a W3C recommendation published in 2014 to support Linked Data publication of organisational information across several domains. This recommendation enables domain-specific extensions to add other elements and support additional information as organisational activities.
2.5. Discussion of related work
Table 1 shows a comparison of different approaches, the scope and the current status of the different initiatives found in the bibliography to develop an ontology for electronic government. The first impression that is evident is that there has been little significant progress in this line of research in the last decade. These projects are oriented to describe the administrative structure, their services and the citizens, focusing on the executive power branch. Some of them are operational, and most do not have a SPARQL endpoint to make queries. Considering how old the projects are, they do not usually provide access to download the ontologies. They are generally not aligned with the new paradigm of linked data or the concept of open government.
Comparison of developed ontologies for e-Government.
Analysing these approaches, we note that there is evidence of the lack of adequate semantic representation of administrative structures, in public services and their spatial, temporal and dependency relationships. The majority assume that information is centralised, and only some incorporate the new paradigms of linked data or open government.
Besides, the data they contain are not exhaustive, presenting only a partial focus of the model of public services from the executive branch perspective. They also assume that users will search and use the services from their personal computers using a web page, so these models do not consider the mobility variable and do not guarantee that the names used to identify the units are officially recognised.
The absence of harmonisation and standard semantics in the definition and configuration of e-government services causes problems such as the functional disintegration of the governmental structures that affect the quality of the provided services. The related works highlight some common characteristics: most proposals focus on local developments and specific aspects of ontologies (the semantic web technologies, the electronic government, the public data, the services, viewed as separate entities). These ontologies are modelled assuming a centralised database approach, in which all the data resides in the same place where queries have full access. There is a lack of proposals for general-purpose ontologies that can be easily adapted to the Latin-American region.
Furthermore, most of the developments of ontologies for e-government services have been designed by experts for a specific purpose and based on the premise that they will be consumed from a website, not consider web standards and interoperability and few have considered mobile technology and the ubiquity of users.
The reviewed models focus on a partial approach or some types of specific services that do not cover the complexity required or are difficult to adapt. Moreover, they do not take into account the emerging new technologies and the citizen’s ubiquity and only a few relate to other external ontologies.
3. EGO
This section describes our previous work: EGO. Our main motivation was to use ontologies in e-government applications as a semantic integration schema. This proposal was based on the need for formal representation that could fit to the whole State in their three branches, including domain knowledge and procedures. With our model, we aimed at providing a general ontological model of the State and then move towards the agencies and their services to citizens.
Starting from Ralph Hodgson’s work in the oeGOV project, and the three-layer model proposed by Lacasta-Miguel, we developed a conceptual representation of the whole State, based on ontologies designed under the Government Linked Open Data and Open Government principles, adding the standard W3C and ISO/IEC definitions for political organisation and geospatial information, to achieve a reusable and inter-operable model. This model is a large and heterogeneous ontology-based data set, with large amounts of interlinked instances.
The conceptualisation that produced EGO first release 16 using Methontology included several tasks:
Task 1. Build glossary of terms. In order to model a general ontology compatible with the political organisation of different countries, we used the basic jurisdictional domains: ‘State’, ‘Division’, ‘Organisation’ and ‘Sub-organisations’ as defined in ISO/IEC 15944-5:2008. ‘State’ is an entity with its own legal nature which may be national in scope (country), or sub-national (region). The ‘Divisions’ are different partitions of higher level organisations (ministries) which are turned into smaller entities: under secretariats, and departments which are the basic division entities. And to guarantee the internationalisation of the denomination of the ontologies we adopted the ISO/IEC 3166-2 standard, which allowed us to uniquely identify a subdivision of the country in a global context [22].
Task 2: Build concept taxonomies. These concepts were not organised in a hierarchy, as they were related by means of properties.
Task 3: Build ad hoc binary relation diagrams. The main terms were binary related as follows: - Goverment HasSuborganisation Ministry Ministry IsPartOf Government - Ministry HasSuborganisation UnderSecretariat UnderSecretariat IsPartOf Ministry - UnderSecretariat HasSuborganisation GeneralDirections GeneralDirections IsPartOf UnderSecretariat - GeneralDirections HasSuborganisation Directions Directions IsPartOf GeneralDirections - Directions HasSuborganisation Departments Departments IsPartOf Directions
Task 4: Build concept dictionary. The main terms were translated as ontology classes using the Protègè ontology editor 17 as shown in Figure 1.
Task 5: Describe ad hoc binary relations. Relations defined in Task 3 were translated also with Protègè.
Task 6: Describe instance attributes. For these classes several OWL data properties were defined: ProcedureID, denomination, Province, Department, Address, PostalCode, Place, BuildingName, phone, OSM_node, Coordinates, email, ResponsiblePerson, url.
Task 7: Describe class attributes. Instance attributes described in Task 6 were then linked with the corresponding classes (domain of these data properties).
Task 8: Describe constants. This ontology did not include constants.
Task 9: Describe formal axioms. This relationship between the state, government and its divisions can be represented in Description Logic with a has property, the subset, existential quantification, and union symbols as follows:
Task 10: Describe rules. This ontology did not define rules.
Task 11: Describe instances. Initial set of instances defined for the use cases of EGO where: Procedures: New_ID_Card Infrastructure: CDR-POS-DEL1 Territory: Posadas LinkedGeoData: 143320491 OSMNode: 3661832864

Electronic government ontology as designed in Protègè.
From a global view, we used an incremental-recursive ontology scheme development following the three layers approach, adding classes, relationships and creating specific instances of classes as needed. Instead of developing a single large ontology, in our proposed model we developed several ontologies containing specific concepts, and later establish relationships and dependencies between them as shown in Brys and Aldana-Montes [2]. These ontologies emerge from the definition of the state, which has concepts such as: political and administrative organisations, institutions, territory, legal framework, procedures and services. The global ontology was created by establishing relationships between these different, more specific sources that maintain their own portion of the ontology. At the same time that the ontology is populated, the mapping to external ontologies can be created as it is described in Section Linked Electronic Government Ontology, using the Linked Open Data principles.
4. LEGO
Brys and Aldana-Montes [2] proposed a semantic model for the administrative structure of the State, expressed as the EGO.
Thus, EGO provides a general ontological model of the State that is related to the agencies and their services for citizens. A taxonomic ontology could not satisfactorily answer the competence questions of a useful ontology: What, Who, When, How and Where. In the proposed new model, we will extend it incorporating elements and principles of Open Government, as well as public Open Data sources (Figure 2). In the new model, we propose LEGO by aligning the EGO (in its extended version) with other geospatial and people related ontologies and integrate data from other resources to bring to the citizen enriched information about how, where and with whom to use the government’s services.

Extended electronic government ontology context.
At the high-level (see Figure 3), we define the superclasses related to general concepts such as state, government, branches of power, legal framework and territory. Then, for the domain-specific level, we define the eGovernment classes for the administrative structure and positions, head of state, and ministerial structure, infrastructure, offices, and agents. In this stage, we have modelled the administrative organisation according to the W3C recommendation for the organisation’s ontologies (W3C, 2013). Finally, at the application level, we define the classes for procedures and services for citizens. For each class, we look for its instances, to incorporate them into the specific ontology and map others if necessary.

Linked electronic government ontology model as designed in Protègè.
Our work is centred on the executive branch of power. This ontology represents the governorship, 10 ministries, 37 under secretariats, 68 general directions, 114 directions and 326 departments. The classes alone do not provide sufficient information to answer the most basic competency questions. Therefore, some properties of the classes and restrictions on them must be determined. The attributes that relate classes with the properties of the data types were defined in the classes and subclasses.
From the mapping point of view, we have taken other ontologies into account to expand the domain of LEGO:
OSMonto 18 : an OpenStreetMap label ontology, where each administrative organisation in the general ontology is represented in OpenStreetMap by a ‘node’. These nodes have the ‘labels’ defined in the OSMonto that match the attributes of the individuals in the ontology;
LinkedGeoData: vocabularies used by LinkedGeoData to publish OpenStreetMap data as an RDF knowledge base [26].
DBpedia: vocabularies and ontologies used by DBpedia to publish Wikipedia data as an RDF data source.
From the data integration point on view, LEGO keeps a strong adherence to the standards following the guidelines of W3C eGov Interest Group 19 linking data with:
LinkedGeoData: an effort to add a spatial dimension to the Semantic Web. LinkedGeoData uses the information collected by the OpenStreetMap project and makes it available as an RDF knowledge base according to the Linked Data principles. It interlinks this data with other knowledge bases in the Linking Open Data initiative.
DBpedia: a project that aims at publishing Wikipedia data as an RDF data source.
vCard FOAF (to identify public agents): (an acronym of friend of a friend) is a machine-readable ontology describing persons, their activities and their relations to other people and objects.
GeoNames: a geographical database available and accessible through various web services, under a Creative Commons attribution license.
OpenStreetMap (for the place names that describe the cities and places): a collaborative project to create a free editable map of the world.
Mapillary (for street-level images): a service for sharing crowdsourced geotagged photos.
4.1. LEGO street level extension: the mapillary ontology
In order to integrate government data with images at street level, Mapillary is proposed as an Open Data source. Mapillary offers us the computer vision to connect images through time and space to create immersive views at street level. However, Mapillary did not provide their ontology or semantic vocabulary. Therefore, based on Juhász and Hochmair [27], we have created the MapillaryOnto ontology to link and access the images on the Mapillary service to OpenStretMap nodes described in OSMonto.
The MapillaryOnto 20 ontology has been developed using the OWL2 language (Figure 4). It is made up of two main classes: Resources and Layers. The Resources class has six subclasses: Images, Sequences, Changesets, MapFeatures, ObjectDetections and Users; and the Layers class has four subclasses: Lines, Points, Segmentations and Traffic_Signs. Our main interest is in the key of the street-level picture, so we define also 11 Data Properties for the class Images: ca, camera_make, camera_model, captured_at, key, organization_key, pano, private, sequence_key, user_key and username. To maintain strong compatibility with the images provided by Mapillary service, we defined the ontology according to the specifications of the Mapillary V3 API, 21 which allows us to read the resources provided by the service.

Class tree of the mapillary ontology.
From the Mapillary ontology, we only take for this project the class ‘Images’ that defines the street images, and we instantiate them to the photographs that we take of the buildings with the identification key that provides the service. These instances are linked to our infrastructure ontology that we create to identify public buildings.
Table 2 details the data properties of the Image class, according to the Mapillary API specifications.
Image class data properties.
We focus on the ‘key’ property of the ‘Images’ class since that key is the one that identifies the file that contains the image. That key is a string of 22 characters and is the one we use to construct the URL and relate the ontology of infrastructure with the street-level image stored in the Mapillary server.
4.2. Linked data search
The definition of the different services provided by the government will be done by defining instances for each service. Thus, developing new cases will only require the design of ontology instances, but the LEGO ontology structure will not change. Therefore, the development of support services will only need to define the extraction of the information using the required queries.
The objective of the proposed ontology is to provide citizens services with highly enriched data about governmental paperwork. LEGO is used as the core to orchestrate the interlink with other Linked Open Data sources to respond to citizens’ queries, as shown in Figure 5. Each data source will have its own ontology or vocabulary that is linked to LEGO. The collected data are integrated using SPARQL to provide users with relevant information to their needs. In the case of existing web services by formality with the State, the user is provided with the basic information, the requirements, the contact person, the spatial location and the street-level images of the office shown, creating an immersive experience where to make the appointment.

Ontology relations.
5. Use cases for the LEGO model
Based on the LEGO proposal, we have designed four use cases with the goal of providing citizen services based on Linked Data as depicted in Figure 6, taking into consideration the following elements:
The core system at the front-end consists in an orchestrator that takes the citizen’s requirements and inquires to the LEGO RDF dataset to solve the competence questions (using SPARQL): What, How, Where, Why and Who.
The first level of the back-end is the Extended EGO that resides in the Open Data Portal server with the other second-level ontologies. These ontologies describe the government’s administrative structure, the infrastructure and spatial location of public buildings, the services available and the persons responsible. The second-level ontologies have their own autonomous corporate systems (paper-works Guide) that run in the government data centre.
The last level is the external services and sources that provide the Linked Open Data and the images: DBpedia, GeoNames, LinkedGeoData, OpenStreetMap and Mapillary.

Architecture for the linked EGO model.
The developed use cases are the following:
Obtaining an ID card. In this use case, we consider a service where a citizen requires to obtain his ID card (DNI in Spanish). The citizen must go to the nearest documentation centre to begin the formality. For that, citizens provide the formality ID and their location (or it is taken from their cell phone); for example DNI, Posadas. This data search provides the citizen with a list of documentation centres in Posadas and other useful information (including pictures of the places).
Enrolling a Child in a School. We consider a service where citizens must enrol their child in an initial level school. The citizen must go to the nearest school to start the process. For this, citizens provide the level of the school and its location (or take it from their cell phone); for example, Initial School, Posadas. This data search provides the citizen with a list of the schools in Posadas, and other helpful information (including photographs of the schools).
Getting permission to transport wood. We consider a service where an implanted forest manager must transport the logs to a sawmill. The citizen must go to the Ministry of Ecology in Posadas. For this, managers provide the name of the Ministry and its location (or take it from their cell phone); for example, Ministry of Ecology, Posadas. This data search provides the citizen with the location of the Ministry, and other helpful information (including photos of the places).
Making a police report. We consider a service where a citizen must expose a crime to the police. The citizen must go to the police station closest to the event. To do this, the citizen provides the police code word and his location (or they take it from his cell phone); for example, Police, Posadas. This data search provides the citizen with the location of the nearest police station and other useful information (including photos of the places).
5.1. Linked data search
5.1.1. Use Case 1: obtaining an ID card
This use case aims to guide citizens to obtain their ID cards. SPARQL is used to query the LEGO dataset to get the list of documentation centres in Posadas where the formality (obtaining the ID card) can be done, and related data such as who is the responsible person, attention hours and costs, among others. Listing 1 shows an example of retrieving the location, phone and picture of the places to use this service.
Listing 1: Example of a SPARQL query to retrive the location, phone and pictures of the places to obtain the ID card PREFIX tys: <http://bit.ly/EGO-formalities#> PREFIX mapy: <http://bit.ly/EGO-mapillary#> PREFIX infra: <http://bit.ly/EGO-infrastructure#> SELECT ?address ?phone ?file WHERE{ ?Service tys:ID ‘NewIDCard’ ?Service tys:IsMadeIn ?Place ?Place mapy:key ?Image ?Image infra:CDR-POS-DEL1 ?file ?Image mapy:Photo ?imageurl. ?Place infra:Place ter:Posadas. ?Place infra:Address ?address ?Place infra:Phone ?phone . } Result of SPARQL query: address: Trincheras de San José 2385 phone: (376) 4-421-285 image:
https://images.mapillary.com/
0H1_OUh05y64JJPzvdfSvg/thumb-2048.jpg
In Figure 7, we show the links of NewIDCard and Posadas with instances of external datasets. NewIDCard and Posadas are individuals of LEGO class DNI and City, respectively.

Interlinked instances for New_DNI in Posadas.
5.1.1.1. Definitions
For the use case, we will have
5.1.2. Use Case 2: enrolling a child in a school
This service aims at helping citizens in enrolling their children in an initial level school. SPARQL is used to query the LEGO dataset to obtain the list of the nearest preschools in Posadas where your child can be enrolled (preschool enrolment). It also retrieves related data such as who is responsible for attending, scheduling attention and the necessary documentation. Listing 2 shows an example of retrieving the location, phone number and photo of the places to use this service.
Listing 2: Example of a SPARQL query to retrive the location, phone and pictures of the enroll a children in a school PREFIX tys: <http://bit.ly/EGO-formalities#> PREFIX mapy: <http://bit.ly/EGO-mapillary#> PREFIX infra: <http://bit.ly/EGO-infrastructure#> SELECT ?address ?phone ?file WHERE{ ?Service tys:ID ‘EnrollInitialSchool’ ?Service tys:IsMadeIn ?Place . ?Place mapy:key ?Image ?Image infra:SCHOOL1 ?file ?Image mapy:Photo ?imageurl. ?Place infra:Place ter:Posadas . ?Place infra:Address ?address . ?Place infra:Phone ?phone . { Result of SPARQL query: address: Félix de Azara 2200 phone: (376) 4440535
In Figure 8, we show the links of EnrollInitialSchool and Posadas with instances of external datasets. EnrollInitialSchool and Posadas are individuals of LEGO class School and City, respectively.

Interlinked instances for enrol a children in a school.
5.1.3. Use Case 3: permission to transport wood
This service aims at helping citizens in the procedure of transporting the logs to a sawmill. SPARQL is used to query the LEGO dataset to obtain the location of the ministry in Posadas where they can manage his transportation permit (permission to transport wood). It also retrieves related data such as who is responsible for attending to you, hours of operation, and necessary documentation. Listing 3 shows an example of retrieving the location, phone number and photo of the places to use this service.
Listing 3: Example of a SPARQL query to retrieve the location, phone and pictures of wood transportation permission PREFIX tys: <http://bit.ly/EGO-formalities#> PREFIX mapy: <http://bit.ly/EGO-mapillary#> PREFIX infra: <http://bit.ly/EGO-infrastructure#> SELECT ?address ?phone ?file WHERE{ ?Service tys:ID ‘WoodTransportationPermission’ ?Service tys:IsMadeIn ?Place ?Place mapy:key ?Image ?Image infra:MERNR ?file ?Image mapy:Photo ?imageurl. ?Place infra:Place ter:Posadas . ?Place infra:Address ?address . ?Place infra:Phone ?phone . } Result of SPARQL query: address: San Lorenzo 1538 phone: (376) 4447590
In Figure 9, we show the links of WoodTransportationPermission and Posadas with instances of external datasets. WoodTransportationPermission and Posadas are individuals of LEGO class Permissions and City, respectively.

Interlinked instances to obtain a wood transportation permission.
5.1.4. Use Case 4: make a police report
This service aims at helping citizen to expose a crime to the police. SPARQL is used to query the LEGO dataset to obtain the location of the ministry in Posadas where he can expose his report (crime report) and related data such as who is responsible for attending you, hours of operation, and necessary documentation, among others. Listing 4 shows an example of retrieving the location, phone number and photo of the places to use this service.
Listing 4: Example of a SPARQL query to retrieve the location, phone and pictures of police stations PREFIX tys: <http://bit.ly/EGO-formalities#> PREFIX mapy: <http://bit.ly/EGO-mapillary#> PREFIX infra: <http://bit.ly/EGO-infrastructure#> SELECT ?address ?phone ?file WHERE { ?Service tys:ID ‘CrimeReport’ ?Service tys:IsMadeIn ?Place . ?Place mapy:key ?Image. ?Image infra:POLICE-HEAD ?file. ?Image mapy:Photo ?imageurl. ?Place infra:Place ter:Posadas . ?Place infra:Address ?address . ?Place infra:Phone ?phone . } Result of SPARQL query: address: Félix de Azara 2417 phone: (911 image:
https://images.mapillary.com/eUcANaqFy9bJAOagjQdW2A/thumb-2048.jpg
In Figure 10, we show the links of CrimeReport and Posadas with instances of external datasets. CrimeReport and Posadas are individuals of LEGO class Reports and City, respectively.

Interlinked instances to make a crime report.
5.2. Data usage
Taking the Linked Data approach, it is possible to develop a user interface to provide users with this information (Figure 11). In this section, we focus on illustrating Use Case 1: Obtaining an ID card as shown in the following these steps:
Users with a thin client inquire about a facility using the key ‘DNI’ (The Id card). The user provides its location, or the App acquires the geo-position:
The Citizen Assistant receives the user request and inquires the LEGO using a SPARQL query for related paper-works with the provided key (services ontology).
The user picks an option, for example, selecting the nearest office.
The system displays a list of available paperwork processes and where they can be made.
The system orchestrates a query and inquires the second-level and linked ontologies: territory for locations, infraestructure for detailed data of offices, foaf for the responsible person, osm for map information, mapillary for a picture of the office, as described in Figure 7.
The system shows the user where they can do the paperwork and offers them the possibility to make an appointment.

Architecture for the LEGO model usage scenario.
5.3. Ontology evaluation
In this section, we discuss the results of the evaluation of LEGO using OOPS! [28]. 30 This tool provides a list of pitfalls classified depending on their importance:
Critical: These are the most relevant ones as they could affect the ontology consistency, reasoning and applicability.
Important: These are relevant but not critical for ontology function.
Minor: They are not really a problem, but by correcting them the ontology would be nicer.
The first evaluation done on LEGO listed a total of 15 critical cases (of two types), 91 important cases (of five types), and 255 minor cases (of six types). Most of these cases were produced by the evolution in the design of the ontology, producing some naming problems in the URIs. After correcting the most relevant issues, the final version of the ontology includes only one minor pitfall.
As a result of this evaluation process, LEGO is better prepared for its reuse in different contexts by other researchers in this domain.
6. Conclusions
In this article, we have presented an expanded model of the EGO, covering the whole branches of the State, incorporating one of the three pillars that support the Open Government: the transparency represented by the Government Open Data in their portals. LEGO’s extension is based on existing ontologies and the linking to external Open Linked Data repositories.
We have proposed an original approach that changes the way public services are provided, in which citizens must find where to do their paperwork. With this model, public services are those that find the citizens and deliver them wherever they are, on their own mobile devices.
By applying the proposed experimental model, we have shown that an ontology of electronic government geo-located public services could be used to integrate different government services relevant to the citizens.
In the absence of a specific ontology to integrate the images at the street level, we created the ontology for Mapillary, which allows us to obtain photos of the buildings under an open licence.
We also conclude that the current model is suitable as a support framework for integrating and interoperability public services provided by the geographically distributed administrative offices.
The LEGO ontology is a solid, standard, open and interoperable basis for linking complex information systems within public administrations.
The main limitation of this model is the existence of few scenarios of available services, so there is a need to work to scale the ontology to represent all kinds of procedures and services offered by the public administration.
In conclusion, the proposed model is a significant advance in the evolution of the electronic government in the province of Misiones. Evolving from electronic government to open government at a semantic level enables the integration and interoperability of information systems and the creation of work processes that go beyond geographical boundaries and state management. This work aims at achieving the most critical goal of electronic governments: to provide more efficient services for citizens, saving their time and money.
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work has been partially funded by grant (funded by MCIN/AEI/10.13039/501100011033/) PID2020-112540RB-C41, AETHER-UMA (A smart data holistic approach for context-aware data analytics: semantics and context exploitation). Funding for open access charge: Universidad de Málaga/CBUA.
