Muriel Foulonneau et al.
applications based on these data. The community part is the collaborative section of the portal. It provides a space for discussion and if needed voting. The editing and writing is carried out through the CKAN software in version 1 10. The datasets are replicated and stored in the Portal Data Storage( local file‐storage). The demonstrator links to two applications doctype verifier and benchmark mashup.
Figure 6: User interface for the EBR Services for accessing structured information on companies
Although only at pilot stage, this portal illustrates the opportunity raised by using various data sources. It also shows the critical issue of maintaining them over time.
7.3 Towards governance mechanisms for semantic datasets
In this paper, we have illustrated the various components to be taken into consideration when setting up a semantic interoperability layer for supporting the implementation of a cross‐border procedure. Data collection is a core challenge for creating semantic resources. Their maintenance is however even more of a challenge. While large scale pilots for eGovernment in Europe, such as SPOCS, PEPPOL 11 or epSOS 12 have defined semantic resources and explored the issues related to their implementation, they all face the major challenge of maintaining the resources, i. e., ensuring the efficiency and reliability of the data collection process over time and the availability of high quality up‐to‐date datasets.
In the case of the eDocuments validation process, document types must be collected from the various administrations and authorities that issue the documents. This raises questions related to the governance of such datasets, i. e., the distribution of responsibilities and the rules that govern their maintenance. The storage of the registries of document types can be either centralized in a SPOCS infrastructure, or distributed( stored and maintained by each Point of Single Contact in each country).
Each Point of Single Contact can maintain its own Document type registry, possibly aggregating from various national administrations. These Document type registries can contain the equivalences with other countries’ document types. There are two options for the organization of registries. If equivalences are synchronized and potentially created in a central registry, as part of the SPOCS infrastructure, the data model used in the various registries should be similar. In this case, the central registry should use import functionalities. Alternatively, equivalences can be recorded in local registries but the content of local registries can be published as open data. In this case, the synchronizations can be performed through reasoning centrally with data gathered by a semantic aggregator. This requires using a similar data model and sharing concept identifiers. Therefore, each registry should aggregate data from other registries to be able to provide links to identifiers defined in a third party registry. If equivalences and reasoning processes are created in local registries, then synchronization 10
http:// ckan. org / 11 http:// www. peppol. eu / 12 http:// www. epsos. eu /
185