Some thoughts about how to "facilitate the digital interaction between administrations and citizens/businesses for high-quality public services". A key enabler should be the standardization of digital interfaces through which eGovernment public resources could be made available to software applications used by private citizens/businesses. To demonstrate the idea, the following discussion uses some terms from the web programming domain, but their usage is today widespread and the presented example does not go far into technical details, so that everybody should be able to grasp the idea. The key term is Application Programming Interface (API), that represents the digital interface used by client applications running on user PCs or tablet/smart-phones to access the resources hosted by an Internet web site.

The API supported by the web site of a public institution should not only be open, but also standard, as much as possible. The standardization effort would unleash the production of many new mobile and web applications. These applications would be developed and distributed by competing software houses in compliance with the standard, and would deliver innovative free and pay services, in the latter case rewarding the institutions that make available the used API. Having a standard API across different institutions would greatly reduce the development costs and would increase the intelligence of the software applications, thanks to the leverage offered by the plenty of resources becoming accessible via the same standard interface and thanks to the opportunity to retrieve and merge data from different application domains.

Just to give a simple example, let's imagine how a Museum of Art could expose its web resources via an open and standard Representational State Transfer (REST) API. One of the applicable strategies to the web interface standardization could be inspired by the Hypermedia As The Engine Of Application State (HATEOAS) approach, so that a generic software client could navigate through rooms and paintings without knowing much in advance of the museum structure. We could also say that such an API design would enable Hypermedia As The Engine Of Resource Structure (HATEORS), since the interface is used to discover the structure of the resources exposed by that interface.

Continuing with the example, the content retrieved accessing the base Uniform Resource Locator (URL) pointing at "http://www.museum.org/api" could contain the following information:
[
{
resourceType: "ItemContainer",
resourceOwner: "Museum of Art",
name: "Museum of Art Root Resource Container",
description: "Museum of Art Application Programming Interface Base Resource",
path: "/api",
children: [
{
resourceType: "ItemContainer",
name: "Ancient Art Room",
description: "Ancient Greek and Roman Sculptures",
childrenCardinality: 2,
path: "/api/ancientArt"
},
{
resourceType: "ItemContainer",
name: "Medieval Art Room",
description: "Middle Age Tapestries",
childrenCardinality: 8,
path: "/api/medievalArt"
},
{
resourceType: "ItemContainer",
name: "Modern Art Room",
description: "Modern and Contemporary Paintings",
childrenCardinality: 32,
path: "/api/modernArt"
},
]
}
]

The content structure is quite readable and self-explaining. More specific content belonging to the art domain could be present, but has been omitted in this example, since not relevant to show the generic information structure. The key point is that the name and role of shown properties - like "resourceType" or "children" - are on purpose generic and not constrained to the resource application domain used in this example. The retrieved information contains also properties - like "path" - that enable further automatic navigation towards other hosted resources, therefore enabling the application to retrieve additional information either automatically or on-demand. E.g. if the application navigates the link to the Ancient Art Room (http://www.museum.org/api/ancientArt"), the following resources could be discovered:
[
{
resourceType: "Item",
resourceOwner: "Museum of Art",
name: "Venus",
description: "Statue of the Goddes of love, beauty and desire..",
path: "/api/ancientArt/venus",
parentPath: "/api/ancientArt"
},
{
resourceType: "Item",
resourceOwner: "Museum of Art",
name: "Dionysus",
description: "Statue of the God of wine, fertility and drama..",
path: "/api/ancientArt/dionysus",
parentPath: "/api/ancientArt"
relatedResources: [
{
resourceType: "ItemReference",
resourceOwner: "Town Library",
name: "Histories",
description: "A Book by Herodotus",
url: "http://www.library.org/api/ancientBooks/histories"
}
]
}
]

Here the key point is to show that it should be possible to navigate automatically between resources held by different institutions. The "relatedResources" hyper-link should allow the application to jump out of the Museum resource structure and dive in the set of resources exposed by the linked Town Library, using the referenced book as entry point, e.g. the url "http://www.library.org/api/ancientBooks/histories" could return the following information:
{
resourceType: "Item",
resourceOwner: "Town Library",
name: "Histories",
description: "A Book by Herodotus",
path: "/api/ancientBooks/histories",
parentPath: "/api/ancientBooks",
relatedResources: [
{
resourceType: "ItemReference",
resourceOwner: "Town Library",
name: "The Father of History",
description: "Herodotus Biography",
path: "/api/modernBooks/theFatherOfHistory",
}
]
}
and so on..

We can easily imagine that a similar generic and standard way of structuring the public available information could be used to describe other completely different set of resources, e.g. the city map maintained by the Town Hall or the set of orders issued by the Municipal Council. I think that only the lack of imagination could pose a limit to the software services that could be built accessing via an open and standard interface the huge set of resources managed by public institutions.