Competitiveness and Innovation Framework Programme s1
Total Page：16
File Type：pdf, Size：1020Kb
COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ICT Policy Support Programme (ICT PSP) ICT PSP call identifier: ICT PSP-2008-2 ICT PSP main Theme identifier: CIP-ICT-PSP.2008.1.1
Project acronym: SPOCS Project full title: Simple Procedures Online for Cross-border Services Grant agreement no.: 238935
Guidelines for WP4 Interoperability Framework and Schemes - Update
Deliverable Id : D4.6
Common governance scheme/guideline Deliverable Name : for directories of public services
Status : Draft
Dissemination Level : SPOCS Internal
Due date of deliverable : 31.08.2011
Actual submission date : 31.08.2011
Work Package : WP4 Interoperable eService Directories
Organisation name of lead contractor BVA (DE) for this deliverable :
Author(s): Fraunhofer FOKUS (DE)
Update: InfoCamere (IT) Partner(s) contributing : Updated Deliverable: InfoCamere (IT), ILIM (PL)
Abstract: This deliverable provides guidelines and best practices based on the scenario overview and updated specifications. This deliverable represents the updates of deliverable D4.3 including parts of deliverable D4.2. The technical overview is described in the dependent deliverable D4.7.
1 History
Version Date Modification reason Modified by
0.1 15.06.2011 Initial draft and inclusion of D4.4 content FOKUS
0.5 08.08.2011 Deliverable ready for Internal Review FOKUS
0.7 <
Deliverable ready to be submitted to the 1.0 <
2 Table of contents History...... 2 Table of contents...... 3 List of figures...... 6 List of Tables...... 7 List of Abbreviations...... 8 1 Introduction to the deliverable...... 12 The project: SPOCS...... 12 1.1 Methodology...... 13 1.2 Relations to internal SPOCS environment...... 13 1.3 Relations to external SPOCS environment...... 13 1.4 Quality management...... 14 1.5 Risk Management...... 14 2 Scenarios...... 15 2.1 Transformation and Search...... 15 2.2 Equivalence...... 16 2.2.1 Benefits and relation to scenarios...... 16 2.2.2 Storage and mapping method, relation to semantics...... 18 2.2.3 WP4 Workflow and Governance mechanism...... 18 2.2.4 Realisation within open modules...... 21 3 Specification...... 22 3.1 Pilot Feedback and Update...... 22 3.2 Overview...... 23 3.3 Outlook...... 26 4 Guidelines...... 29 4.1 SPOCS identification scheme...... 29 4.2 Multilingualism...... 31 4.2.1 Usage of language codes...... 32 4.2.2 Creation of separated textual tables...... 33 4.2.3 Support of universal text representation...... 33 4.3 Service and eService Descriptions...... 34 4.3.1 Commonly usable naming...... 34 4.3.2 Golden rules on how to write description of procedures...... 34 4.3.3 How to describe a procedure...... 35
3 4.3.4 Procedure description attributes...... 36 4.3.5 eServices description...... 36 4.3.6 eServices technical description...... 37 5 Mapping and Recommendations...... 39 5.1 Localization...... 39 5.2 Organizational Back Office Processes and National Infrastructure...... 41 5.2.1 Collecting and gathering information from CAs and other sources...... 41 5.2.2 Conversion of administrative procedure to computer processing format...... 44 5.2.3 Procedure description archives and maintenance...... 44 5.3 Best Practices National Connectors...... 45 5.3.1 Development status...... 45 5.3.2 National Connectors Implementation...... 46 5.4 Guidelines for Loading...... 48 5.5 Greenfield Strategies...... 49 5.6 Political and Legal Recommendations...... 50 6 Outlook...... 53 6.1 Update Data Models and WP4 Ontology approach...... 53 6.2 Semantic Needs and Interoperability...... 54 6.2.1 European Interoperability Framework Basics...... 54 6.2.2 Interoperability Principles...... 54 6.2.3 Public Services Conceptual Model...... 55 6.2.4 Interoperability Levels...... 55 6.3 Outlook Semantic Concept...... 55 6.3.1 Linked Data and Semantic Web...... 56 6.3.2 Open Government and Open Data...... 56 6.3.3 Rule-Based Solution...... 57 Conclusions...... 58 A. Appendix A – Acceptance Criteria...... 60 B. Appendix B – Risk List...... 62 C. Appendix C – MIDB Data Model...... 63 D. Appendix D – Code Lists...... 78 E. Appendix E – Obsoleted Parts of Deliverable D4.3...... 82 2 Load and Update MIDB - Transformation...... 82 2.1 Load and Update MIDB - Transformation...... 83 2.2 Syndication - Syndication Interface...... 84
4 2.3 Search / Look-Up for Core and Full Information - Search, Access, Provision...... 84 2.4 Configuration Set and Internal Routing...... 85 3.2.2 Usage of language property...... 85 5.1 Components...... 85
5 List of figures Figure 1: WP4 Relations to National Infrastructure and WP1...... 15 Figure 2: Inter-WP Relations...... 16 Figure 3: Equivalence Governance Workflow...... 19 Figure 4: Overview Entities of MIDB and Schemas...... 24 Figure 5: Multilingual Realisation (Update)...... 25 Figure 6: Information Objects (actual and possible further)...... 26 Figure 7: Mapping administrative procedure cycle...... 42 Figure 8: National Connector Environment...... 46 Figure 9: National Connector Use Cases...... 48 Figure 10: Code List and Deprecated Tables (Update)...... 63 Figure 11: MIDB data model overview (Update)...... 64 Figure 12: Overview WP4 Open Modules (OMs), their Integration Points (WP4 NCs) and the Technical Use Cases they support [obsoleted]...... 82
6 List of Tables Table 1: Acceptance Criteria List...... 61 Table 2: Example risk list...... 62 Table 3: Main Attributes of Entities...... 66 Table 4: Additional Attributes of Service...... 66 Table 5: Additional Attributes of Eservice...... 66 Table 6: Additional Attributes of Profession...... 67 Table 7: Additional Attributes of Document...... 67 Table 8: Attributes Overview of the Entities...... 68 Table 9: Main Attributes of Textual Elements...... 69 Table 10: Additional Attributes of Stext...... 70 Table 11: Additional Attributes of Etext...... 70 Table 12: Attributes Overview of the Textual Elements...... 72 Table 13: Attributes of Sagency...... 73 Table 14: Attributes of Sinter...... 73 Table 15: Attributes of Needdoc...... 74 Table 16: Attributes of Outdoc...... 74 Table 17: Attributes of Eagency...... 75 Table 18: Attributes of Einter...... 75 Table 19: Attributes of Ses...... 76 Table 20: Attributes of Parameter...... 76 Table 21: Attributes Overview of the Associated / Mapped Elements...... 77 Table 22: Language Code List...... 79 Table 23: Document Type Code List...... 79 Table 24: Status Code List...... 80 Table 25: Condition Code List...... 81
7 List of Abbreviations Abbreviation Explanation
BPEL Business Process Execution Language
BPMN Business Process Modeling Notation
CA Competent Authority
CIP Competitiveness and Innovation Framework Programme
DB Database
DoW Description of Work
EIF European Interoperability Framework
ELKAT Elektronischer Leistungskatalog eSD eService Directory
EU European Union
FIM Federative Information Management
HTTP Hypertext Transfer Protocol
ICT Information and Communication Technology
ID Identifier
IETF Internet Engineering Task Force
IF Interoperability Framework
IL Interoperability Layer
IMI Internal Market Information System
INSPIRE Infrastructure for Spatial Information in the European Community
ISIC International Standard Industrial Classification
ISO International Organization for Standardization
LEIKA Leistungskatalog
8 LSP Large Scale Pilot
MIDB Meta Information Database
MS Member State
NACE Statistical Classification of Economic Activities in the European Community
NC National Connector
NUTS Nomenclature of territorial units for statistics
OID Object Identifier
OM Open Module
OWL Web Ontology Language
PSC Point of Single Contact
PSP Policy Support Programme
QA Quality Assurance
RDF Resource Description Framework
REA Real-Estate Agent
RFC Request for Comments
SC Service Catalogue
SME Small and Medium Enterprises
SP Service Provider
SPOCS Simple Procedures Online for Cross-border Service
TA Technical Annex
UNCEFACT United Nations Centre for Trade Facilitation and Electronic Business
UNESCO United Nations Educational, Scientific and Cultural Organization
URI Uniform Resource Identifer
URL Uniform Resource Locator
URN Uniform Resource Name
UTF Unicode System Transformation Format
9 WP Work Package
WS Web Service
WSDL Web Services Description Language
XML Extensible Markup Language
XSD XML Schema
10 Executive summary
SPOCS – Simple Procedures Online for Cross-border Services – aims at providing seamless cross-border electronic procedures for setting up a business in another EU country in the context of the Services Directive. The project builds on solutions developed in Member States as they implement the Services Directive. Building on compliancy with the Services Directive, SPOCS is also about competitiveness and it has been set up on the basis of the 2008 CIP ICT PSP Programme of Work (project reference: 238935). As described in the SPOCS Technical Annex, the current deliverable is the result of the task “T4.9: Update of Governance scheme/guideline”. The update of the schemes and guidelines has to integrate the requirements, amendments and other feedback of the enlargement participants and pilots. This deliverable represents the updated specifications and best practices using the WP4 solution. After several discussions with enlargement participants and pilots from the first phase a simplification of the WP4 architecture and scenarios was realized. The main purpose is to focus on syndication as cross-border interoperability mechanism and use WP4 as connection between National Connectors and the Meta Information Database storing the national and syndicated foreign information in the updated common schema. An update of the scenario and the usage of the equivalence information are given in section 2. Based on the feedback the specifications were especially extended for further document information and the existing entities were aligned to a common set of attributes (see section 3 and appendix C). The technical implementation of the Open Modules using the specifications is done through task T4.10 and described within deliverable D4.7. Guidelines related to the specification and schemes are the naming scheme of identifier, multilingualism or the guidelines how to describe services (see section 4). Moreover the deliverable provides best practice approaches related to the mapping of SPOCS solution with national infrastructure including the setup of the SPOCS solution. Also some political and legal recommendations on a high level based on the experience within WP4 are described (see section 5). This leads directly to the outlook marking especially the dependency to the next major release and the work in the semantic task (see section 6). This deliverable is based on deliverable D4.3 and includes some of the previous sections with small updates as well as deliverable D4.2 for updating the specification. The deliverable focuses on the organizational and semantic aspects of the WP4 solution. The results are based on several discussions and experiences from WP4 partners especially the pilots and WP5. The update has to be continued beside the ongoing work for the semantic task.
11 1 Introduction to the deliverable WP4 is handling information needed to select the right procedures, documents, services and eServices within an application process between Service Provider and Point of Single Contact. WP4 focus on providing foreign information cross-border based on a common specification implemented by open modules that enhance the Point of Single Contact solutions. The information of different member states is combined to improve the user experience by well- known services and documents from his home member state. Moreover WP4 is a basement to support further alignment, discussions and orchestrations of services and eservices. The deliverable D4.6 “Guidelines / Schemes” provides the updated guidelines and specifications for WP4 and gives a basic overview of the scenarios and benefits. The update integrates requirements from the first piloting partners and the enlargement participants. The deliverable is an update of deliverable D4.3 “Guidelines” and D4.2 “Specifications” and has a strong dependency to deliverable D4.7 “Open Modules”. The guidelines and specifications will be further developed during the piloting phase as support (further best practices) and involvement of results of the semantic task (T4.11 / D4.8 – release 2.0). The project: SPOCS SPOCS – Simple Procedures Online for Cross-border Services – aims at providing seamless cross-border electronic procedures for setting up a business in another EU country in the context of the Services Directive. The project builds on solutions developed in Member States as they implement the Services Directive. Building on compliancy with the Services Directive, SPOCS is also about competitiveness and it has been set up on the basis of the 2008 CIP ICT PSP Programme of Work (project reference: 238935). In other words, SPOCS is expected to: Improve the competitiveness of European businesses and particularly SMEs by providing a fully interoperable PSC (point of single contact) across all Member States. Enable all Member States to quickly adopt the solutions developed and enable all businesses to benefit from the reduction of administrative burdens. Furthermore, SPOCS is also expected to: Build on MS activities as they implement the Services Directive Improve the efficiency of cross-border cooperation Support service innovations for businesses by reducing time and energy loss Increase cross-border activities Foster competitiveness and contribute to the development of trade Accelerate the development of common technology requirements Modernise the services offered by the public administrations.
12 The output of the project is to provide for the necessary building blocks to achieve the second generation Points of Single Contact (PSC) by providing seamless cross-border electronic procedures. 1.1 Methodology The deliverable has four parts: the update of the specifications including definition of schemes and data models, the onboarding of the enlargement participants related to semantic and organizational issues, the description of guidelines and best practices within this document and the coordination of the activities with the pilots. The description of the guidelines and the update of the specifications are realized by a small team. Further contribution was envisaged but not available. The coordination was aligned by the sub-leader of WP4. The onboarding was realized through several bilateral discussions between enlargement participants and WP4 coordination. The descriptions are organized by the enlargement participants on their own. A basic analysis was made by the WP4 coordination. Feedback of first pilots and enlargement was combined. The coordination with the pilots is also organized on bilateral and regular WP4 conference calls. The results are integrated into the task list. After alignment of the development activities the implementation issues are forwarded to this group and other issues are discussed bilaterally or forwarded to WP5 and WP7. There was no specific task force or group concentrating on a specific subtask. The results and feedbacks are discussed in an open approach within the whole WP4 group. There is no difference in requirements or priorities between amendments of enlargement participants or first pilots. The priority is based on the given timelines and available resources. Moreover all common procedures (e.g. QA) are used to align WP4 activities with SPOCS framework. 1.2 Relations to internal SPOCS environment The WP4 guidelines and specifications are using feedback and results from WP5 piloting activities. Moreover the enlargement feedback influenced the update and lead to changes in the focusing of the scenarios and architecture. The update of this deliverable leads to a better understanding of the scenarios and usage of the open modules as well as organizational process for the national infrastructure (WP5 pilots). The dependencies are managed through conference calls. This deliverable is especially dependent on deliverable D4.7 describing the update of the technical overview and open modules. 1.3 Relations to external SPOCS environment The results of this deliverable are especially available for the pilots and the national infrastructure and can also be used by external stakeholders. There is actually no standardization activity as previously the semantic tasks needs to produce first results and piloting feedback needs to show the usability of the concept.
13 The basic solution is envisaged to be used also in different scenarios. The main idea of the update is also to switch to uncoupled catalogues and directories that can be combined for different objectives and projects. WP4 starts collaborating with specific member state projects. Industry stakeholders are mainly involved through the piloting activities using WP4 results to connect / enhance their products. 1.4 Quality management The quality management follows the described quality assurance process from WP7. The acceptance criteria are listed in the appendix. The update of the specification was cross- checked by two piloting partners. The guidelines and specifications are checked by several internal and an external reviewer. 1.5 Risk Management The risks have to be assigned to the different subtasks within this deliverable. Risks are addressed and measures defined. Most of the measures did not lead to a complete successful handling. Impacts based on this are also addressed especially to the SPOCS coordination and pilots. The risks of this deliverable are listed in the appendix. The risks related to resources and development is also listed in the risk reports for WP7 and the executive board. Risks and problems are addressed by technical coordination through WP coordination up to SPOCS coordination.
14 2 Scenarios The scenarios section describes the recommended usage of the identified WP4 interoperability framework based on the piloting feedback. The major result of the feedback is to simplify the communication structures and to focus on syndication as cross-border interoperability mechanism. The WP4 interoperability layer will not further developed until a specific pilot request appears. Figure 1 shows the scenario pilots will focus for the cross-border information provision. The member states (MS A) are loading information from their national infrastructure to their WP4 eservices infrastructure. WP4 is invoking their WP1 syndication which is providing the information to the foreign member states (MS B). Now the foreign member state can retrieve information from MS A in his WP4 eservices infrastructure. MS B is doing the same like MS A, thus loading the information to the WP4 eservices infrastructure which is invoking syndication and sending information to the infrastructure of MS A. In sum through the cross-border syndication mechanism the WP4 eservices infrastructure is synchronized with the information from all connected MSs.
cmp SPOCS
SPOCS
M S A M S B
National Infrastructure WP4 eservices WP1 syndication WP1 syndication WP4 eservices National Infrastructure
Figure 1: WP4 Relations to National Infrastructure and WP1 2.1 Transformation and Search Figure 2 shows more detailed the WP4 eservices infrastructure / WP4 interoperability framework. The national infrastructure is loading the information through the WP4 transformation open module to the WP4 midb access module (MIDB). The information is mainly loaded from the Catalogues and Directories (central ones or the ones of the PSC). The WP4 transformation open module is also invoking the WP1 syndication to provide the national information for the foreign MSs. The WP1 syndication is retrieving the relevant information from the MIDB and is providing foreign information to the MIDB. The second use case is the retrieval of information. The national infrastructure is retrieving information from the MIDB through the WP4 search open module and is getting directly the result. Search and provision is a synchronous communication. The retrieval can be full text or categorized search. The categorized search is using the attribute codes (appendix C) and filters the amount of possible answers. The national infrastructure capsulate the backend infrastructure with different catalogues, directories and solutions (e.g. PSC software) through implemented national connectors that are able to deal with the SPOCS common specifications and communicate with the WP4 open modules for transformation and search.
15 The MIDB is the decentralized and synchronized data source for all SPOCS enabled content. The SPOCS WP4 open modules offer the functionality to handle the information. The technical overview of the modules is described in deliverable D4.7. The SPOCS WP4 specifications are the basement for the data base model of the MIDB and structure of entities and interfaces.
cmp WP4 eservices
WP4 eservices
WP4 transformation WP1 syndication
National Infrastructure WP4 midb access
WP4 search
Figure 2: Inter-WP Relations 2.2 Equivalence The storage of equivalence information is a major task for realising the semantic interoperability as it connects information objects from different member states to realise cross-border activities. This text is partially taken from section 3.4 of deliverable D4.3 and extended to improve understanding the usage of equivalence within SPOCS WP4. SPOCS is concentrating on allowing the connection of information objects, but can actually not work on aligning the different meanings and thus harmonization of terms. WP4 will start working on understanding terms and semantics with task 4.11 and based on first discussions done by WP5 for creating cross-border piloting scenarios. Equivalence definition is based on the idea of the Internal Market Information (IMI) system. IMI is used to clarify and verify profession and certificate information between Competent Authorities of different member states. SPOCS is using this idea by storing such acceptance information for the SPOCS relevant information objects in a structured way to allow a further usage of this information in different context. SPOCS is starting with simple equivalence relations and will evolve to an ontology describing the relations of different semantic objects. This includes the work on the relation of attributes as well as the major part for connecting the content with the different meanings. Thus SPOCS semantic activities are a basement for aligning administrative procedures and requirements. Further information is described in section 6.
2.2.1 Benefits and relation to scenarios Equivalence information is used in the piloting scenario in the following way. The SP is applying for business in the foreign member state through the foreign PSC. The foreign PSC is providing the SP information about the business registration and related procedures. These procedures need documents from other services, mainly the ones from the SPs home member state. Thus
16 the PSC is enriching the information about the procedures and needed documents with equivalent documents, organizations, services and eservices, producing them, from the SPs home member state. The SP, which is more familiar with the procedures in his home country, has a real benefit from this equivalence information as he does not need to understand all related procedures in the foreign member state only the related ones in his home country. Moreover PSC can define equivalence for professions and services to simplify the understanding of the whole procedure. The information is retrieved through WP1 and WP4 mechanisms from the different SCs and eSDs, which are part of the national infrastructure. As SPOCS is concentrating on stimulating business development, the PSCs are main contacts and can connect through these mechanisms. SPOCS is concentrating on the communication between SP and PSC, with using the connection of this PSC to national infrastructures including other PSCs. Nevertheless SPOCS is actually not supporting forwarding scenarios or the usage of PSCs in the home member state of the SP (see deliverable D4.2). In sum, equivalence is used to enrich the provided information from foreign PSC to the SP by describing equivalent services, eServices and documents well known by the SP. Equivalence information starts with a basic relation and will evolve during task semantic concept to a more complex ontology including attributes relations and content. The workflow for equivalence (see section 2.2) is considering a “bottom-up” approach. At the moment we are assuming that the equivalence definition is determined directly by the countries involved, provided that they are using the SPOCS WP1-4 infrastructure. In case the local CAs will take part in the process. At the moment this seems the only possible approach, as there are no trans-national rules or regulations on this issue, apart from some peculiar initiatives like e- certis, DG-MARKT initiative1. The system is freely available and related to public procurement. But some documents are also related to SPOCS domain. The “bottom-up” approach can be useful as a starting point, in order to store concrete cases of cross-border equivalence. It is true that the equivalence is valid as a result of bilateral agreement among different countries, perhaps a harmonisation of these procedures at trans- national level through a “top down” approach should be desirable, at least for those document that occur more often in administrative procedures. The national solutions and implementations concerning SPOCS WP1-4 components encompasses also the availability of the MIDB structure, that will contain the information extracted from the national Service Catalogues and eService Directories of the country. Moreover, they will be updated with information coming from the other countries, through the syndication mechanism. Therefore, a complex network of administrative information will be built. The pilot phase of the SPOCS project will demonstrate the value and feasibility of these solutions (mainly from the technical and organisational point of view). The problem of the official value of the content exchanged needs to be taken into consideration. In the future, the SPOCS WP1-4 solutions could be extended to other professions (apart from the pilot professions), even to other domains. In perspective, it may be necessary to “certify” the data contained in the various national MIDB, e.g. according whether they are managed under the responsibility of the national official PSC in the different countries and whether they are provided from the official Service Catalogues and/or eService Directories of the different countries. The confidence on the information is particularly important as the data are retrieved by external users, in order to find information on the start-up procedure. Moreover, the information on
1 http://ec.europa.eu/internal_market/publicprocurement/index.htm
17 documents will be used to define equivalence (e.g. according to the workflow) so all the data involved in these transactions need to be reliable.
2.2.2 Storage and mapping method, relation to semantics Equivalence is defined by combining two equivalent SPOCS identifiers of information objects (e.g. actually service, eService, organization, profession, process document). The equivalence relation should be defined by starting with the more generic object, followed by the specific one. Thus e.g. for definition of a local profession to an EU NACE coded profession equivalence should start with identifier for EU NACE code and followed by the national one. Bilateral equivalence relations can be defined as preferred. The recommendation should help semantic experts for starting with the objectives of the semantic concept. For the usage of equivalence within the pilots and modules ordering is not mandatory. The equivalence table is actually not checking the semantic relation of equivalence objects. Thus it is possible to e.g. define equivalence between an organization and a profession. Checking is actually no benefit as such a semantic relation would not be used in a practical situation. During the semantic concept it will be defined whether and how a semantic check is useful. Equivalence information is not exchanged for the first piloting phase as other member states do not have a real use case for this information. The information is created manually by each member state based on their regulations and legal framework and in alignment with the related MSs (see next section). Moreover the information will be collected for the ontology, which is supposed to be distributed to all member states. Semantic task will also check whether more complex relations, like done in e.g. a thesaurus , are necessary and how the ontology can represent them.
2.2.3 WP4 Workflow and Governance mechanism This section aims at describing a proposal for a sustainable and consistent workflow to manage the “document equivalence” process, and the archiving of up-to-date information, particularly through the WP1 and WP4 components developed in SPOCS project. To sum up, WP4 components will provide the data model and the interoperability infrastructure, while WP1 components will provide the syndication mechanism. Anyway it is clear that to establish the equivalence among documents implies also legal and organisational issues; therefore it is necessary to define a flow that will include also unstructured (back-office) operations. This description is made from a non-technical but procedural point of view. It is possible that the semantic activity in WP4 (in progress at the time of writing of the present deliverable) will bring further ideas and instruments in order to enhance especially the non-automated (back-office) steps. In the following, a description of the workflow through a process-flow diagram is provided. This is the “sample” case taken into consideration: Two different member states, MS-A and MS-B, are going to define the equivalence of some documents required in an administrative procedure (e.g. start-up activity for a Real Estate Agent in MS-A). Point of view: MS-B needs to find equivalence for documents required in MS-A.
18 These considerations have been done according to the current MIDB schema, the tables/attributes that are syndicated, and the ideas under discussion for the future versions and enhancements of the architecture. Figure 3 shows this workflow.
Figure 3: Equivalence Governance Workflow
As this is a mirror process the actors are the same for the two MSs. A logical structure is described. The real one that will be deployed in the different organisations is depending on the situation in each PSC. MS-X MIDB management: The organisational structure in charge of the management of the national implementation of the MIDB in the different countries (*) MS-X MIDB syndication: The organisational structure in charge of the management of the syndication activities of the MIDB in the different countries (*) MS-X back office team: In the context of this process, a team with legal competences is supposed to take care of all the activities and investigations in order to determine the
19 correct ‘equivalence’ for a document requested in a foreign country. In this process other CAs will be involved. (*) The national PSC is supposed to manage these issues
The steps of the workflow are the following: A national implementation of MIDB is activated and maintained. At the beginning the national information are stored (coming from the national SC/e-SD, the ‘origin’ attribute will be ‘N’ or ‘L’). In particular, the MIDB database will contain the services, eservices, organizations and documents involved in the administrative procedures. After the initial installation and data storing, an update mechanism is to be activated. Publish syndication information – instances of services, eservices, organizations and documents with ‘origin’ attribute “N” (according to the current syndicated tables and attributes from WP1). The information published by MSA are aggregated by MS-B through the syndication mechanism. The aggregated information will be stored in the MIDB with origin attribute set to “F”. This regards in particular the documents needed in the administrative procedures: now they are stored in MS-B MIDB with the point of view of MS-A. Provision of a human-readable list of the new documents coming from MS-A, in particular the needed-documents regarding the administrative procedures. These reports will be the initial material for the back-office activities on equivalence. Governance Part for Equivalence: o The list of the foreign documents will be studied and carefully examined by a qualified back-office team. o An off-line process will start up, that might involve CAs from MS-B, and discussion with MS-A counterparts MS-A back-office team. This process will probably take some time. Also IMI authorities could be involved for opinions. o As soon as equivalence is defined by MS-B team, these decisions might be double-checked with the MS-A counterparts. Of course the equivalences decisions will be taken in MS-B after an accurate discussion and final approval with the local CAs. Now the decisions on document equivalence established in MS-B have to be transformed in MIDB language. Therefore all the new documents that occur in an equivalence need to be stored in national MIDB of MS-B, and also all the services and eservices that have these documents as an output-document. Publish syndication information – instances of services, eservices, organizations and documents with origin attribute “N”. The information published by MS-A is aggregated by MS-B through the syndication mechanism. The aggregated information will be stored in the MIDB with the origin attribute set to “F”.
20 The couples of equivalent documents need to be stored in the national MIDB, as occurrences of the table equivalence. At the moment these table is not syndicated, so the update is to be done autonomously by the MS-A MIDB management procedures. The native information about equivalence will be transmitted off-line through the MS-A back- office team.
At the moment, the most significant use-case (that has been implemented in the pilot phase of the SPOCS project) is the possibility to visualize the equivalent documents according to the final user (foreign service provider / intermediary) with origin country (question: where are you from?). These functions can be implemented in the PSC. Further information on these equivalent documents (service or eservice, organization, etc.) may be obtained as they have been stored in the MIDB through the syndication mechanism The information exchanged among the countries belonging to this network will set up a knowledge base and the procedures to define equivalence are expected to be fine-tuned. It is likely that most documents will be considered at the beginning, so an initial peak of activities on document equivalence setting is expected. As already said, the semantic activity in WP4 is expected to give further input on how to manage the unstructured activities regarding document equivalence setting. Also the real-life first cases and experiences will be useful in order to organise properly and fine-tune the workflow. The described process considers the cases in which the document equivalence is one-to-one. Further extension is needed for some use cases like: A document from MS-A is equivalent to a couple of documents from MS-B. A document from MS-A is equivalent to one or another document according to the administrative procedure. At the moment the infrastructure is able to manage the one-to-one equivalences. After examination of real use cases in the piloting phase need for more complex equivalences might arise.
2.2.4 Realisation within open modules The WP4 open modules are supporting the equivalence in the following way. The WP4 transformation interfaces offer operations for loading and obsoleting equivalence information to the MIDB. The WP4 transformation open module is checking only for direct and unique equivalence relations. This means that provided id1 is actually only checked with id1 in MIDB and not with id2. This allows definition of separated equivalence relations where every MS is defining its own equivalences starting with their identifiers. But this also complicates the alignment and harmonization activities. The semantic task has to show whether a more flexible solution has more benefits. The WP4 search interfaces provide directly equivalent services and eservices based on the request. Thus the open module is directly retrieving whether equivalence for the requested entity and their associations is registered. Moreover equivalence can be used within the categorized search.
21 3 Specification The specification of WP4 is the basement for the realization of the data models for the MIDB, for the interfaces and objects of the open modules and for the cross-border information exchange through syndication. The technical realisation uses different languages. The MIDB is based on a relational database scheme. The open modules are required to realise web service interfaces and thus use XML schemes. The syndication is based on RDF schemes. The updated data model and schemes are detailed in appendix C. The schemes for the syndication are defined within WP1 and based on the structure of the schemes in this appendix. The appendix defines next to the format and structure also a code for every attribute thus that every attribute could be used in a categorized search (see section 2.1). The schemes and data models will be aligned between WP1, WP2 and WP4 through the semantic task. Within this task another update is envisaged. The following sections describe briefly the update, gives an overview and outlook of the specifications 3.1 Pilot Feedback and Update The piloting requirements are based on their detailed analysis of the specification within deliverable D4.2 and D4.4 (each appendix C). The old and enlargement partners especially focused their feedback on the piloting and definition of amendments. The major feedback was to realign some of the attributes to be more suitable for the pilots to extend the provided information through the MIDB. Moreover some semantic and technical requirements were defined based on specific chosen structures and technology. The major updates based on the feedback and amendments are: Extension of the data base model to a more complete information provision based on the XSD for full information and amendments from partners, Alignment of common attributes for entities, Extension of restricted formats and data types, Renaming of all attributes to shorten and lower case them, Extension of the document entity to a full entity with complete textual description, Definition of the mapping between service and eservice, Redefinition of some cardinalities especially for output document, Realignment of attributes for change tracking, Uncoupling of code lists and Clarification of understanding for several attributes. The following chapter provides a brief overview of the basic structures for the entities.
22 3.2 Overview The specification defines entities, textual elements, associated elements and mappings between the entities. The entities are the basic / core elements for the information provision. An entity in the context of SPOCS WP4 is an object with a specific information purpose that can exist as loose object and has relations to other information objects. The idea is based on creating core directories where every entity has a globally unique identifier, textual parts with multilingual realisations, optional code lists for classification of the object, hierarchical relations of objects of the same entity and relations to other attributes and information objects.2 The following part is an update and extension of section 5.2 of deliverable D4.3 and strongly dependent to section 2.2 of deliverable D4.7. The text is completely realigned. Within the context of SPOCS the entities are: Service for representing the offers of the CAs and PSCs, eService for representing communication channels of the CAs and PSCs, Document for input and output of administrative procedures of the CAs and PSCs, Organization for the CAs and PSCs, Profession for the context of the application procedure. The WP4 solution is realizing an equivalence relation especially between professions, services and documents. The equivalence defines the cross-border relation and alignment of the entities. See also section 2.2. Figure 4 shows the entities and their relations.
2 Hartenstein, H.; Welzel, C.; von Lucke, J.: „Design and standardisation of Core Directories for e- Government“ in: Charalabidis, Y.: “Interoperability in Digital Public Services and Administrations – Bridging E-Government and E-Business“, IGI-Global, ISBN: 978-1-61520-887-6
23 class MIDB
Profession
b el ong s to cro ss-b o rder
Equivalence Service eService cro ss-b o rder e le ctron ically operates
offe rs offe rs
need s pro d uce s cro ss-b o rder Organization
offe rs Document
Figure 4: Overview Entities of MIDB and Schemas
The entities are represented through the attributes (meta information): identifier (id) to have a unique naming, versioning information (vstart, vend) to realise change tracking (see section 3.2 in D4.7), validity date times (valstart, valend) and status to realise planning and deprecation of entity information, origin to define the source of information for selection within syndication (National, Foreign, Local – see D4.2), owner to define the mainly responsible contact and contact to define a contact for support questions. The entities can be extended by types like doctype for documents or nace for professions. Used code lists are listed in appendix D. Code lists should be based on common standards. The code lists can be stored in the MIDB or only referenced through the namespace and code. Moreover the entities can be extended by core information not dependent on the language code like address for the eservice.
The entities are detailed through separated textual elements to support multilingualism (see section 4.2). Figure 5 shows the relation between entities and the textual elements. There can be a text for every language that is supported by the information source. The language is referenced by the ISO 639 three character alphanumeric code. The relation between entity and text is realized through direct constraints. This can be changed too if needed. As there is a strong dependency it is actually not recommended. An open point for future releases could be
24 the change of internal identifiers to composite keys, here a primary key of entity id, entity version and language code.
class MultilingualUpdate
Entity Text Language
- Lang uage: ISO639v3 - ISO639v3: varch ar 1 1..*
Configuratio n Set (External co de lists)
Figure 5: Multilingual Realisation (Update)
The textual elements contain mainly: identification (id, iso639v3, entity reference) to realize unique identification and dependency to the entity, naming (name, shortname, abbreviation) to have a readable naming, descriptions (outline, description) to have a comprehensive understanding of the entity, owner (descowner) being responsible for the text, datetime (descdatetime) to define the date time of creation or approval of the text, keywords and synonyms to support retrieval of the entities, territory to define / limit the area where the entity is used, legal basis to define the legal framework of the entity and related textual information (e.g. fees, respites) based on the specific context of the entity.
The entities might have associated information. The eservice for example can have further parameters for the operation. These can be security or policy profiles.
The relation of the entities are realised through the connection to the identifiers of the entities. For n:m relations mapping tables are defined. This is done for service agency, service intermediary, eservice agency, eservice intermediary, needed documents, output documents and the service-eservice relation. The actual data base model is mainly defining direct relations and constraints (coupled entities). The XML schemes define both as for transformation the usage of uncoupled entities is easier to be maintained. Piloting feedback and semantic results will show whether uncoupling of entities for the data base model is useful to be realised with release 2.0.
25 3.3 Outlook The specification is not fixed as new amendments and requirements based on the piloting and semantic results have to be included. This section shows basic questions that are already in focus but not finally discussed and analysed. The text is taken from section 5.2.2 of deliverable D4.3 as the open questions are still the same. The update described with this deliverable focused on the extension of the document information and extension of the data base model. Next to the following description of further entities another main question is the provision of information as Open Data. The actual approach does not define access verification anymore. Open Data also requires a defined and documented structure of the information. This is done by the specification. Open activity in this context is the provision of the information to Open Data Platforms or the definition of an own.
Figure 6 shows the actual and possible further information objects.
Figure 6: Information Objects (actual and possible further)
Further information objects could be Territory / Area, Roles / Responsibilities, Processes, Conditions, Forms, Fees / Pricing and Legal Basis. The mentioned further objects are recommendations to support a long-term sustainability and a broader usage of the arising information infrastructure of SPOCS WP4 / WP1. The territory attribute is actually used for localizing or restricting the usage of a service or eService to a specific region. Actually territory is used only for informing the SP, thus a textual representation is enough. If a structured usage in automatic processes with related parameters to geographical coverage or identification is needed, an own Area information object should be defined. The information object should consider that areas are not only bound to political or administrative borders, thus a concept for Area needs a comprehensive approach including
26 geographical coordinates, classifications of area types and relations to geospatial specifications. Concepts may include results from INSPIRE activities or other geographical oriented projects.3 The relation between service / eService and organization is strongly needed and used in different semantic interpretations. Thus having a specific information object defining the Role or Responsibility of an organization to another information object like service or eService could be helpful and would minimize complexity of the data model. Possible roles are owner, description owner, agency and intermediary as already defined in the specifications. Further roles are possible, but the actual data model is not able to store further roles apart from making an update of the scheme. Related to this aspect three levels of responsibility have to be determined: generic responsibility, organisation definition and operational realisation. The generic responsibility is based on the legal framework and defines a generic assignment of a service to a type of organization being responsible. This can be defined by rule-based languages as LKIF.4 The organizational definition is the instantiation of the generic responsibility based on the basic parameter of the user and the organisational framework of the organizations. Thus this is a dynamic relation which can be realised by pre-defined parameter-instantiation relations. The operational realisation is the connection of the defined instance of an organization for a specific use case (parameter) with the communication channels offered by this instantiated organization. This could be an eService including addresses and phone numbers. It would also support the uncoupling of communication parameters used in different contexts with e.g. eServices related to a more specific technical interface. Another optional information object is Process which is directly related to service. For a better understanding a short clarification of the understanding of the terms is necessary. Service is the generic definition of the procedure and outcome, where the process is the detailed description of the activities. Nevertheless process should be a good information object to determine the different activities and setting their input and output related to the domain or region framework as well as giving the option to detail the procedures and process steps. It could be used for aligning processes and combining them for complex process chains. Processes in the context of services are directly related to the needed documents and the output of the service. Specific inputs are forms, which can be defined as a specific needed document. Thus an own information object related to forms is not recommended. Conditions (Pre/Post) can be a further information object, if a rule-based solution is envisaged as this attribute is defining the parameters for choices during inference of a rule-set. The conditions are describing the status and parameters for decisions within the inference. The Legal Basis, meaning a definition of references to legal documents or parts of them, should be an optional information object. The definition of such an object would increase the systematic usage of legal references. Moreover it could support inference and responsibility definition. Pricing can be an own information object if price information is used in different contexts or simplifies the usage. Moreover pricing models can be structured and thus allow calculation of dynamic prices based on different services and eServices. The PSC would be able to calculate prices for the full application procedure on the fly. As most member states are actually not storing the price information in a structured way, such a solution would be sophisticated.
3 INSPIRE: http://inspire.jrc.ec.europa.eu/ 4 LKIF: http://www.estrellaproject.org/
27 BusinessEvent is not recommended to be an own information object as the information is not evolving in a short or medium term. BusinessEvent could be used for classification purposes and thus might be a candidate for another code list.
28 4 Guidelines The section is taken from section 3 of deliverable D4.3. So far there are no major changes. Some lines are updated related to the changed specifications and data models. The guidelines can be extended related to piloting feedback.
The section guidelines gives an overview about recommendations for the way of describing information about services and eServices. The chapter shows specified or standardised solutions for descriptions and naming. Most of the mentioned aspects are quality criteria to improve usability of the provided or retrieved information. This section includes the SPOCS identification scheme for describing how resources or objects are identified in the context of WP4. This section also describes recommendations for the usage or integration of multilingualism as already started in deliverable 4.2. The last section describes recommendations on a quality level for the names and descriptions, meaning the meta and core information, of services and eServices. This guidelines section is not a complete list of recommendations and also not mandatory. The recommendations can be extended and improved during the piloting of SPOCS. 4.1 SPOCS identification scheme The SPOCS identifier used within WP4 will be designed based on the following structure: SPOCS :
The parts of the identifier are interpreted as follows: SPOCS – unique naming of the identifier related to SPOCS project, every SPOCS identifier starts with SPOCS. Type – defines the type of information object the identifier belongs to. Actually only “Service”, “Eservice”, “Organization”, “Document” and “Profession” are used. The type is especially needed for verification of equivalence. As additional type “Module” was defined to identify the SPOCS open modules for internal routing. In a future version WP4 will assess whether “Module” can be skipped by a specific “Eservice” naming. Type is mandatory.
5 URN Syntax – IETF RFC 2141, http://tools.ietf.org/html/rfc2141, Network Working Group, May 1997 6 URI Syntax – IETF RFC 3986, http://tools.ietf.org/html/rfc3986, Network Working Group, January 2005 7 IANA URI registry - http://www.iana.org/assignments/uri-schemes.html
29 Semantic Group – defines a semantic relation to a common entity in the ontology as it will be defined in the task semantic concept. Actually this is related to the selected professions and some kind of life events / related documents. The usability of this part will be checked during piloting and definition of semantic concept. Actually it is optional. Local – defines the namespace of the identification scheme, especially oriented on member state level. This part always starts with ISO 3166 alpha 2 code.8 The namespace can be only a Member State (nationwide identification, e.g. AT, DE) or a region (e.g. DE.BW) or a catalogue (e.g. DE.Leika). Local is mandatory. ID/Nr – defines the identifier in the namespace mentioned within the local part. ID is mandatory.
The same in Backus-Naur Form:
Related to URI and URN “SPOCS” is the identifier of the scheme. The following parts are describing the path. There is actually no authority, query and fragment part. The identifier will not differentiate between lowercase and uppercase characters. Allowed are all signs as mentioned in URI and URN syntax. Allowed are alpha, digits, hyphen, period, underscore and tilde. Colon is used to separate the semantic parts of the identifier as mentioned above. Thus it is used in URN syntax instead of slash for URI syntax. Apart from URN syntax period is allowed within a semantic part. SPOCS WP4 is actually not verifying and using other identifiers like Universally Unique Identifier (UUID) or Object Identifier (OID).9 10 11 They should be used on a technical level and be combined with URN. The usability of the identifier will be proven for sustainability within the task for the semantic concept and the piloting phase. Possible extensions for the identifier are version and language to globally identify textual parts and their versions. Actually versioning and multilingualism are handled by the database scheme and not included into the identifier.
Examples: SPOCS:Profession:REA:EU.NACE:L68.3.1
8 ISO Country Codes – ISO 3166, http://www.iso.org/iso/country_codes.htm 9 ITU on UUID, http://www.itu.int/ITU-T/asn1/uuid.html 10 UUID URN namespace – IETF RFC 4122, http://www.ietf.org/rfc/rfc4122.txt, Network Working Group, July 2005 11 OID Repository - http://www.oid-info.com/
30 SPOCS:Service:REA:GR.Ermis:12345 SPOCS:Eservice:CR:DE.FHB:CROnline SPOCS:Document.Certificate:BR:EU.SPOCS:BRC SPOCS:Module:Common:GR.Ermis:SearchOM
The identifier should be described as it is done by UNCEFACT and done in XML scheme (xsd). This means that the used identifier should consist of the following attributes. For the SPOCS identification scheme it is supposed to be filled as follows: SchemeName – SPOCS WP4 Identification Scheme SchemeID – WP4Identifier SchemeURI – SPOCS:Code list:Common:EU.SPOCS:WP4Identifier SchemeAgencyName – EU LSP SPOCS SchemeAgencyID – CIP-ICT_PSP-2008-2_no238935 SchemeVersionID – v.1 (2011) SchemeDataURI – the specific reference to the identifier information (optional), e.g. http://www.eu-spocs.eu/schemes/wp4identifier Value – the specific identifier within the identification namespace, e.g. SPOCS:Profession:REA:EU.NACE:L68.3.1
For the SchemeAgencyID the UNCEFACT 3055 recommends the usage of a 9 digit number. Organization identifiers are a complex mechanism with different solutions (e.g. GS1, Dunn&Bradstreet, …), thus a 9 digit number is not useful. This part can be verified if further experience on organization identification exists in SPOCS project during piloting phase.
Further SPOCS code lists should be configured with the same kind of meta information.
If descriptions are referring to identifiers, the widely accepted standard should be used. For example telephone numbers should be identified in tel scheme12. 4.2 Multilingualism Multilingualism has to define two scenarios: provision of translated content and (automatic) translation of content after provision by the national infrastructure. As defined in deliverable D4.2 multilingualism in the context of SPOCS is especially about understanding textual descriptions. Thus for main parts like Names and Outlines a translation in at least one major language understood by the European Citizens is mandatory. Suggestion is English as SPOCS is dealing with business activities.
12 Tel scheme – IETF RFC 3966, http://www.ietf.org/rfc/rfc3966.txt, Network Working Group, December 2004
31 Detailed descriptions do not need to be translated as the Point of Single Contact can handle translation manually or integrates automatically texts from the home member state of the Service Provider that are already understandable by him. Mandatory is the translation of legally binding parts as far as it is necessary for the Point of Single Contact or the transaction with the Competent Authority. SPOCS is not detailing whether translation is on the behalf of the Service Provider, Point of Single Contact or Competent Authority as this has a direct impact on local restrictions and laws as well as it allows establishment of different quality levels for the Points of Single Contact. At least SPOCS assumes that the Service Provider has basic knowledge about the language of the foreign member state. Otherwise he will have challenges making business locally. Automatic translation can be integrated by Points of Single Contact, but without support of SPOCS and without guarantee for translation. This requirement is actually necessary as existing translation methods are not feasible in the context of communication between Competent Authorities, Points of Single Contact and Service Providers. The provision of textual information in all European languages (especially the official ones) is not feasible as the editing effort is actually higher than the benefit, especially by assessing the process and lifecycle of an information entity. The provision of translation is on the behalf of the national infrastructure and their binding legal framework. These local and national decisions have to be incorporated with anti-discrimination frameworks and regulations.
Considering the before mentioned aspects, SPOCS WP4 is concentrating on four major decisions regarding multilingualism: Usage of language codes Usage of language property Creation of separated textual tables and Support of universal text representation.
4.2.1 Usage of language codes Language codes are representing the existing or historical languages and dialects. There are many standardisation activities. SPOCS is concentrating on the globally used standards within ISO, named ISO 639 family. The ISO 639 family consists of: ISO 639-1 – 2 letter alphanumeric code, representing actual single languages and language groups, maintained by International Information Center for Terminology (Infoterm – UNESCO)13 ISO 639-2 – 3 letter alphanumeric code, representing next to codes from 639-1 more specific languages based on language families, maintained by United States Library of Congress14
13 ISO 639-1: http://www.infoterm.info/standardization/iso_639_1_2002.php, Infoterm – UNESCO 14 ISO 639-2: http://www.loc.gov/standards/iso639-2/, US Library of Congress
32 ISO 639-3 – 3 letter alphanumeric code, representing additional artificial and historic languages as well as dialects, maintained by SIL International15 ISO 639-5 – 3 letter alphanumeric code, representing the disjoint parts to 639-3 and allows hierarchical classification, maintained by United States Library of Congress ISO 639-6 – 4 letter alphanumeric code, representing the comprehensive list of languages. As SPOCS is designed for supporting actual activities the ISO 639-3 code list should be comprehensive enough and long term stable. Nevertheless SPOCS is allowing also the usage of ISO 639-1 codes and a mapping through the language code list / table. Next to the language codes a geographic code and codes for font types can be necessary. Concepts are described in Request for Comments / RFC 5646.16 The usage of this concept allows a more detailed description of usage for languages in specific areas (country code ISO 3166-1, see chapter Error: Reference source not found) and with specific script codes (see paragraph “universal text representation”). The usage of this concept is possible within WP4 and recommended for the usage if detailing is necessary. In sum, mandatory is the usage of ISO 639-3. Optional is a further detailing under consideration of RFC 5646 concept. Optional solution will not be supported in the first piloting phase.
4.2.2 Creation of separated textual tables SPOCS WP4 is storing the textual information for the MIDB in a separate table to the object with a one-to-many relation as an object can be described in multiple languages. This has the impact that providing information in multiple languages results in providing at least all mandatory fields as defined in D4.2 with this language. Such a set of provided textual information in one language, should consist only of information described within this language. Each description in another language will result in a further record. See also section 3.2.
4.2.3 Support of universal text representation The universal text representation is important as within the European Union different alphabets are used. SPOCS is using the widely accepted standard of UNICODE / ISO15924 for storing and providing information. 17 Information provider can define specific codes for their alphabets by using the RFC 5646 concept as described in paragraph “Usage of language codes”. Thus they allow end-users applications to handle different typefaces. Recommended is the usage of the 4- letter version as it can be used within IETF language tag concept. The definition of script code is optional, default value is Latin (Latn). For the encoding UTF is mandatory.
Versioning is actually dependent on the object and thus adding or changing textual parts will result in a new version of the information object. Assessment during the piloting phase will show whether versioning of textual parts is more useful as changes might reflect especially them. For information on versioning see deliverable D4.4.
15 ISO 639-3: http://www.sil.org/iso639-3/, SIL International 16 IETF RFC 5646, http://tools.ietf.org/html/rfc5646, Network Working Group, September 2009 17 ISO 15924 – UNICODE: http://www.unicode.org/iso15924,
33 Moreover the piloting assessment and work on the semantic concept will show whether an update of the identification scheme will include a multilingual part to globally address textual parts of the information objects. 4.3 Service and eService Descriptions This section defines recommendations how to write textual elements for entities based on services and eservices.
4.3.1 Commonly usable naming In order to provide a clear and understandable administrative procedure description, the providers of the content should use popular naming and commonly used words. This way the reader is not put-off by the administrative or legal jargon and understands the description in full. There are some commonly known administrative phrases that can be used but they need to be described (e.g. as a bubble help). The service description can contain information that comes from specific dictionaries e.g. business classification. Such elements should be imported from the official dictionaries and should not be provided by hand in order to limit the mistakes and confusion of the reader. There are different attributes referring to different levels of wording. The name should always be the official administrative wording of the service or eService. Commonly used naming can be done by the short name, PSC can use dictionaries or thesauri or synonym databases for linking dialects and phrases to the official name and (unofficial) short name. Synonyms and keywords can be added to the description to improve retrieval of the entity. The same difference is recommended to be chosen for the descriptions. The description of a service or eService should be the official description aligned to be understandable, but still legally correct. Outlines can sum the key facts and use commonly used wording.
4.3.2 Golden rules on how to write description of procedures The sound and well organised content of any service might determine audience and range of service. Service Catalogue relies mainly on description of procedures, their attributes, requirements and products. Some of them are easy to comprehend and common sense is sufficient to precede all steps and requirements. There may be complex regulations and many conditions for others procedures, which make understanding the procedure challenging. The ten golden rules of writing a good description of a procedure make service easy to understand and follow: 1. Put yourself in the place of the reader. 2. Do not write lengthy descriptions and do not repeat information in different parts of the description. 3. Make sure your key messages are easy to find. 4. When writing use common sense. The description should be understood by the average person. 5. Be consistent and clear. Use short impactful sentences and bullet points. 6. Use graphics or other eye-candy tricks to point out relevant differences (e.g. different parts of description). 7. Always list ALL requirements (e.g. required documents).
34 8. Always include explanations for abbreviations or new uncommon words. 9. The procedure summary should be concise and should include all relevant information in a way that everybody can understand it. 10. Provide legal references for the description as well as the time of the creation of the procedure description. 11. Consider the multilingualism recommendations as mentioned in chapter 3.2 and provide the outlines in at least one major European language next to your native one.
4.3.3 How to describe a procedure Deliverable 4.2 of the SPOCS project “Specifications for interoperable access to public service directories” defines in the C.1 appendix the list of attributes exchanged in WP4 of the project. This list should be the guide for the providers of the description on which description elements they should provide for the procedure. It is especially important to provide the following elements: • official name of the service • short description of the service giving an overview about the scope and purpose • activities of the procedure of the service - how the procedure for this service will be enforced including the process steps of the customer and the responsible CA • agency that is providing the service • agency that is responsible for the service • fees - describing all dues and rates that have to be paid for using the service • laws and legal/administrative regulations that are related to the service • conditions need to be fulfilled for starting with the application procedure • outcome of the service (product or status) - the result of the procedure • alternate path of procedure It is also recommended to provide the following in the service/procedure description: • limits and durations regarding the procedure of the service • procedure activities divided into simple steps • corresponding or similar procedures • classification of business activity under the service • business entity type corresponding to the service • needed documents and forms
4.3.4 Procedure description attributes Service description containing information about procedure flow in many places will provide standardized information (e.g. timeframe of the procedure, type of administrative body). Such information should be provided with the use of specific dictionaries in order to provide information that is always up-to-date. Such dictionaries facilitate an easy update of existing data and addition of new data elements inside.
35 It is also advisable to provide validation rules corresponding to the logic of the service description e.g. if a business entity type is not corresponding to the classification of business or to the type of agency responsible for the service, it should be pointed out to the person creating the description.
4.3.5 eServices description Deliverable 4.2 of the SPOCS project “Specifications for interoperable access to public service directories” defines in the C.2 appendix the list of attributes exchanged in WP4 of the project concerning the eService. This list should be the guide for the providers of the description on which description elements they should provide for the eServices. It is especially important to provide the following elements: official name short description of the eService giving an overview about the scope and purpose policies and procedures regarding registration, authentification and secure messaging used security protocol and token formats for using the eService policy requirements for using the eService parameters, used protocols and functions of the eService agency that is providing the eService agency that is responsible for the eService conditions needed to be fulfilled for starting the eService status of the service starting date when the eService is available
It is also recommended to provide the following in the service/procedure description: comprehensive description of the purpose and scope of the eService who is the audience or the target group of the offered eService legal conditions and related regulations for securing the privacy of the eService dues and rates that have to be paid for using the eService person or virtual contact point for inquiries regarding the eService conditions needed to be fulfilled at the end of eService usage area where the service is available and legally usable other channels delivering this service requirements about qualified signature
Electronic services are different in terms of descriptive information than the Services as the former describe the technical aspects (i.e. what kind of website to use, what kind of security to
36 provide, what will be the answer) of the activities and the latter describe the business aspects (what documents must be used, to whom should they be sent, what will be the result of the procedure). Electronic services should be described in different ways dependent on the receiving audience. If a description is addressed to a common citizen, it should be formatted in the same way as a service description. Technical audience should get more information about integration and interface of service. It must contain all the data about set up connection protocol providing required data for eDelivery channels and others information which allow executing the procedure.
4.3.6 eServices technical description As mentioned in the previous section eService are described with different textual attributes. Next to this an eService needs at least one technical description describing the parameter to address him. The technical addressing can be done in different ways and using different architectural approaches. Deliverable D4.2 discussed some aspects on addressing eServices using WSDL and REST. SPOCS is supporting two parts for the technical communication: First the basic addressing through the eService owners or eService agencies or eService intermediaries contact details like email, phone, etc. This includes contact and altchannels attributes of eService itself for communicating if eService is actually not available. This is recommend for support requests but not for regular communication. The main idea of seamless communication is based on technical interfaces described in specific formats. The technical interface defines the type, e.g. WSDL, HTTP/URL. The name defines the addressing literal. For example Restful services can be addressed by typing HTTP/URL and naming the specific website, WSDL is referenced by typing WSDL and naming the URL of the WSDL-file. Other addressing mechanisms can also be represented, if a technical protocol for the communication and addressing is defined, e.g. typing mailto and naming spocs@eu- spocs.eu. Technical interface is not bound to a specific protocol. But sender and receiver have to check whether they can use the chosen technical interface for establishing communication between them by validating their available communication channels and technical realisations through interfaces. Also important are additional parameter like security or policy profiles. The eService has already an attribute describing the security requirements of the eService. A parameter security profile is describing the security in a structured way using existing specifications like WS-Security. A policy profile describes e.g. in a technical way the underlying policies for using the eService. An example is WS-Policy. It is recommended to add this profile descriptions if the eService is expecting specific tokens or behaviour and is integrated into a complete security and policy model. It is recommended to describe the available eServices as far as possible in the mentioned technical and structured way based on protocols and specifications. This allows the setup of seamless automated process chains including eServices of different owners, agencies and intermediaries combined with the own solution. It is recommended to use protocols and specifications that are widely used.
37 5 Mapping and Recommendations The following section is taken from section 4 of deliverable D4.3. There are no major changes. The structure of the section was realigned to focus strongly on connection between SPOCS and national infrastructure. The fourth section is new and describes the way how information has to be loaded to avoid exceptions.
The section Mapping describes how SPOCS WP4 specification, as defined in deliverable 4.2, should be used regarding the connection of the (national) infrastructure. The localization chapter discusses how information is identified to be of local origin and how local extensions or adjustments can be made. Localization is not discussing the routing to the objects or resources. The next section describes recommendations for the organizational back office. This includes administrative functionality needed for running SPOCS WP4 modules in a good manner like archiving. Moreover it includes especially criteria and solutions how the gathered information on the national or regional level needs to be addressed or exchanged. The third section recommends solutions on implementation of the national connectors integrating SPOCS modules with national infrastructure. The recommendations will be based on piloting and implementation activities within SPOCS as well as on the national level. The fourth section gives guidelines how to load information to the MIDB to avoid exceptions from the open modules. 5.1 Localization Localization in the context of SPOCS is to be understood as the way to represent local information. This implicates two aspects: the addressing and identification of local information and the description of and extension to local information. The first aspect is related to code lists for areas, mainly countries and the traceability. This includes also the definition of responsibilities and roles of organizations in the meaning of owner for descriptions. The second aspect is especially related to multilingualism, extension options for textual elements including their structure and related back office processes. SPOCS is realising localization through the identifiers (see section 4.1) using a local part, support of multilingualism (see section 4.2), best practices for descriptions (section 4.3) and recommendations for back office processes related to information collection (section 5.2). The mainly used code list for referencing regions is the ISO 3166 country code. This code list offers a reference to countries as a two letter alphanumeric code, three letter alphanumeric or three digit numeric code. SPOCS is recommending using the two letter alphanumeric code. SPOCS is recommending the usage of this widely accepted standard for addressing regions. Moreover some multi-state structures like the European Union are not listed as they are not eligible to be listed as country. SPOCS is recommending the usage of the widely accepted abbreviations. SPOCS is recommending not to use codes from specific topics like sport, logistics, traffic or internet (e.g. from International Olympic Committee country codes, Internet Assigned Numbers Authority root codes). Some of the used codes are aligned with ISO coding. Their domain context is too specific and impacted by historical reasons. SPOCS recommends the usage of ISO 15924 which is referencing ISO 3166.
38 To detail the coding for regions, SPOCS is recommending the usage of the European NUTS code. This is mandatory as localization starts always with ISO 3166 alpha 2 code and can be followed by a national or regional classification. Moreover during semantic concept task, SPOCS will assess the used identifiers and parts of them for creating the ontology. This assessment will show also whether more details of regions etc. are necessary, as assignments of areas are not restricted to political or administrative borders. Moreover different administrative domains are using different area coding. SPOCS tries to define a best practice for working with the differences.
Retrieving foreign information is always related to questions of trust or objective correctness of delivered information. Thus the traceability is another key question for WP4. SPOCS recommends the usage of best practices and the realisation of traceability for the origin of the content through the identifiers. SPOCS allows the assignment of a description owner and service / eService owner. The description owner is responsible for the description content, where the service / eService owner is responsible for the service / eService itself. For localization it is therefore necessary to address the concrete local responsible organisation by using SPOCS identifiers including the local part. Information itself is available for free, but overflow scenarios to the SPOCS network need to be realised.
Next to the identifier, SPOCS is providing an attribute for localization. With “territory” descriptions can be marked that the service / eService is only available in a specific region. The attribute is text based and allows details of restrictions and conditions for the territorial availability. It is recommended to describe them in a clear, simple and distinct way. Currently it is not used in a structured way. If needs arise during piloting or work on the semantic concept, scheme and recommendation can be updated.
The content, especially the textual parts, can be described in multiple languages. Each information provider has to decide how they are using the multilingualism options considering their organisational and legal framework. Localization is not restricting them, but offers chances to deliver various descriptions of the same service as used in the different local areas. The member states should align descriptions and naming based on their project for the SCs and the corresponding back office processes (see section 5.2 and projects like ELKAT, LEIKA, FIM). Recommended is the usage of basic and localized supplementary texts. A SPOCS description can refer to the basic text with a more generic identifier as well as to localized texts with localized identifiers.
In sum, main objective is the usage of localization for detailing information where necessary, especially because of organisational and legal framework. SPOCS is allowing the reference to different kinds of description with different levels of detailing and localized information. Mandatory is the usage of ISO 3166 alpha 2 code as a root for addressing localization.
39 5.2 Organizational Back Office Processes and National Infrastructure This section describes activities that are performed in order to provide required and up-to-date data describing administrative procedures exercised electronically via the PSCs to the CAs. With the aim that there are different processes realized in order to provide the description for the SC as well as for the definition and running part of the electronic services for specific procedures. The structure of the information describing a procedure in service catalogue (SC) and their electronic application at service dictionary (eSD) is influenced by legal regulations, organizational and technological changes in the environment of the respective CAs. This section outlines the life cycle of procedure implementation in service catalogue and directory, from investigation legal regulations, gathering information, management changes and archiving of the procedure descriptions. In order to harmonize the descriptions, common assumptions are made connected to the search and interpretation of the administrative procedure descriptions. These activities are explained below.
5.2.1 Collecting and gathering information from CAs and other sources Each administrative procedure may be performed by one or more CAs. The procedure description must be aligned with the information about the currently used versions by CAs or should be created from scratch according to the applied rules. Procedures have always to be executed based on current legal regulation. Some of them always produce defined outputs, while others might only give the service provider feedback in some special conditions. Actors and technical implementation of electronic procedure determine the sequence of its execution, main and alternate flows. Organizational rules of public administration on the country level as well as on the local level influence the number and the range of steps in particular procedures. The countries might have different degree and scope of the PSC implementation. With that in mind it is possible that the range of activities required to obtain complete information on the procedures will be different. In addition, administrative procedure descriptions should contain consistent information and support common attributes discovered in many European Countries. The appendix C in deliverable 4.2 contains used attributes by Service Catalogue and eService Directory by piloting countries. Furthermore in many cases, the creation of the electronic procedure (eService) is an additional burden of creating electronic forms or applications that provide the possibility of electronic data exchange with the required safety and security level of the information transferred by the Service Provider. Procedure mapping encompass generally a number of activities, which is depicted in the figure below.
40 Figure 7: Mapping administrative procedure cycle
The steps are realized in cycle and are started by process “Legal Analysis”. Process “Legal Analysis”. – Analysis of law concerning the administrative procedure: o Proper execution of the procedure can only be modeled after all legal regulations concerning the procedure directly or indirectly are analyzed. The procedure execution is dependent on local, national and European regulations. Every procedure description should contain information on legal regulation acts, required procedure elements, required documents and the output of the procedure. o Depending on the procedure complication level and the range of the relevant law it may be required to acquire a legal expert to work on the procedure. Process “Authority”. – Starting connections to the Competent Authorities (CAs): o It is vital to contact the CA in order to provide verification body for the administrative procedure description, for the electronic forms and the rules of using an electronic version of the procedure. o CA specialists create an expert group for the administrative procedure being analyzed and described. o In order to push forward the work within the CAs, interviews take place aiming to gather information on existing descriptions for the administrative procedure. If such descriptions exist they are obtained and introduced to the descriptions in the SC and eSD. Process “Procedure”. – Description of administrative procedure: o The first step of creation an administrative procedure description is to verify if the information in the source description provided by the CA is up-to-date.
41 o Then a procedure description should be created, based on a predefined template. During the creation the information provided by the CAs is used. If necessary the description elements are consulted with legal experts. o In order to present the whole flow of the procedure and alternate flows or to help the analysis of the procedure, all the actions are presented with a standard BPMN diagram. Process “Verification”. – Verification of administrative procedure: o A draft version of the description is created and verified by the CA. With approved verification the description is placed into an on-line repository. o With the description and the BPMN model in hand, specialists process modeling and analyze the data describing administrative procedure. Requested amendments create an upgrade of the description into a higher version. o The whole set of documents describing the administrative procedure is presented to a panel of experts (legal and branch) and the results of the panel’s work are incorporated into the final version of the description. Process “Outreach”. – Publication of administrative procedure description in the SC: o After the administrative procedure description was accepted it is presented to the CA for approval and publication in the SC. o Publication at the SC allows linking the procedure via the PSC.
From the description correctness point of view, monitoring legal changes introduced to the legal system and changes in the procedure flow is a very important process. This is permanently executed with the “Monitoring” process. Changes are registered and assessed in the light of their influence on the procedure flow and in case needed corrections are adopted. The description of administrative procedure must be accepted by the Competent Authority. If the CA agrees with this description, it is the source for the SC. The administrative procedures description consists of: Procedure identification including the version number; Competent Authority data; Process flow description: o Short summary of administrative procedure; o Preconditions; o The main flow; o Alternative flows; o Post conditions; o Actors; o Optionally notes.
42 Document templates
The crucial activity is monitoring. The members of project team (in contact with experts) must check out the impact of law changes and emerging new concepts in area of administrative operations. They should construct the plan of implementing the changes. These activities depend on local implementation.
5.2.2 Conversion of administrative procedure to computer processing format The new electronic procedure should be built on the base of the description of administrative procedure approved by the CA. The procedure of conversion of administrative procedure to the electronic form is divided into the following steps: Analysis of the description of administrative procedure: o This step aims to qualify the procedure to the electronisation process and what the electronic aspects of the procedure may occur (this mainly touches requirements for original documents). o In case of accepting the procedure to create it’s electronic counterpart a list of required documents is created – they are the basis for the creation of electronic forms suitable to go through the procedure flow. Electronic forms development and their assessment: o Based on information from the process description (references to legal regulation) electronic forms are proposed; o Branch experts and legal experts verify the forms; o Draft version of the forms is presented to the CA and supervising body; o Electronic procedure is created (with naming, adding electronic forms, XML schemas, styles etc.); o Steps of procedure flow in the electronic environment should be defined with BPEL process notation in order to create automatic communication between actors in the procedure; o eService description is created allowing to know the conditions to perform the service (required documents, legal references, actors, fees, time of procedure). Publication of electronic procedure description in the eService catalogue: o Every procedure is provided to the users via their description, which can be found in the list of procedures under a specific category; o The procedure description has a hyperlink to run the procedure with correspondence to a specific CA – the user requesting the service is verified by login/password and the documents are provided with electronic signature for safety and security;
43 o While the electronic procedure is executed, there can be multiple references to other electronic services of payments or different administrative procedures.
5.2.3 Procedure description archives and maintenance Descriptions of the procedures must be updated accordingly to the changes implemented into the legal regulation and accordingly to the new technological possibilities implemented on national and local level. This can be implicit on the list of attributes describing the procedure. The SPOCS open modules do not support versioning, and that problem must be solved on the level of description archiving and computer applications used by the local administrative bodies. This issue is complicated also by the fact that administrative procedures must be executed under the law effective at the date the application is submitted in the CA. With this in mind it is vital to secure versioning and archiving of procedure descriptions that should provide different procedures for different timeframes of effective law. Procedure execution is assessed and based on gathered information the changes are suggested, which might speed up execution and lower processing costs. Output of this action can influence the description and new attributes may be needed. Especially technological changes (e.g. concerning information safety) and law regulations connected to them, usually will require new parameters to be defined with the new approach towards procedure execution. 5.3 Best Practices National Connectors The Best Practices for National Connectors are giving an overview about recommendations for connecting the national infrastructure with SPOCS Open Modules. This section is evolving during the piloting phase by feedback of the member states and their change requests for the Open Modules as well as for the National Connectors. The chapter is divided into the development status describing actual realisation activities and implementation describing the core idea of National Connectors.
5.3.1 Development status This chapter will deal with the technical issues related to the connection of the national infrastructure to the SPOCS infrastructure. At the moment the implementation of the WP4 Open Modules and of the National PSC is at a very early stage. As a consequence, due to the lack of Open Modules, none of the pilot countries have really started the development of the National Connector. The current status, for the member states participating to the piloting phase, is the following: Greece already has an available PSC and also a SC system in place; they are now working on the eSD. Regarding the analysis of the NC, they have already produced a mapping between the attributes stored on the national SC/eSD and the WP4 Extended Attributes adopted by SPOCS. Poland already has an active PSC with functions of browsing and searching the available services. At the moment they are working on the loading of the SC with the available services. At the moment the PSC is available only in Polish and only domestic users can apply to the available services. They will provide an English version of the PSC limited to the professions selected for the pilot and they will load into the SC a version of these services suitable for the foreign users.
44 Austria has a quite different situation, because each region has a PSC connected to the others by a national syndication network. For the piloting phase the PSC of Wien has been chosen. SC and eSD are already available by means of web services. Germany has different solutions for SC and eSD. The piloting partner Bremen is using a PSC solution with a wizard of a company linked to the chamber network. The connection of this solution and the local PSC databases is planned for March and April. The connection to the other SCs and eSDs is in discussion, but realization will take more time related to the complexity of the German federal system. Italy, at the moment of the writing, has already selected the portal “Impresa in un giorno” as its official PSC and is working to enhance the PSC in order to fulfill the requirements of the Services Directive. Actually, this is an ongoing project and in addition some national regulations are pending, therefore for the pilot a dedicated instance of SC and eSD will be provided.
The lack of working implementation for the NC does not allow us to provide best practices about them at the moment, therefore on this first version of the deliverable we will provide some guide lines trying to uniform the approaches to the implementation of the national connectors. This deliverable will be improved in a later version with the best practices that will arise from the piloting phase.
5.3.2 National Connectors Implementation Figure 8 illustrates the environment for the National Connector and shows the other components the NC have to communicate with.
Figure 8: National Connector Environment
Currently, from the SPOCS’s point of view, the national infrastructure is composed by the Point of Single Contact, the Services Catalogue and the eServices Directory while, from the PSC’s point of view, the SPOCS infrastructure is represented by WP4 Interoperability Framework, and specifically by the WP4 Open Modules. Therefore the National Connector should act as an adapter or a separation layer between the PSC and the WP4 Open Modules and should then guarantee a strict separation of the PSC from the WP4 IF internal structure.
45 The adapter, to effectively decouple the two infrastructures, should provide to the PSC a set of API that encapsulates all the functionalities of the WP4 Open Modules. So the PSC, to execute a search for both core information and full information, should have to communicate only with the NC. On the other side, when the local WP4 OM instance receives a request of full information from another PSC, it should be able to accomplish the task interacting only with the NC. Therefore the NC should be able to access both the SC and the eSD to extract the information concerning Services and eServices. This means that any direct interaction between the WP4 OM and the PSC, or other components of the national infrastructure, should be avoided. The NC should expose its API to the national infrastructure by means of web services. These web services should expect to receive information related to Services and eServices encoded with the national or native format, the same format used to store them inside the SC or the eSD. On the other side, the exchange of core or full information about services between the NC and the WP4 OM should be encoded using the WP4 Extended Attributes. The NC should be the only responsible for the translation of the data stored into the SC/sSD from the national format to the SPOCS WP4 EA format. The translation will be based on transformation tables owned by the NC and accessed only by the NC. The NC should provide a GUI, or at least a set of dedicated API, for the maintenance of the transformation tables. The MIDB, containing the core information about the services and eServices exposed by each member state, is a critical component of the SPOCS infrastructure, and should not be accessed directly by the NC but only by means of the API provided by the WP4 OM. Although the schema of this relational database is publicly available, this approach, with the concealing of the schema behind the interface of the open modules, will guarantee the independence of the NC implementation, and therefore of the PSC, from any possible modification of the database structure. If the SC or eSD of the national infrastructure for some reason cannot be accessed directly by the NC, a replica or a dedicated instance of those databases can be provided within the National Connector but it should not be directly integrated into the MIDB.
46 Figure 9: National Connector Use Cases
Figure 9 illustrates some use cases of the NC connector. As the owner of the transformation tables, the NC should be responsible for the alignment of the core information that is stored into the local MIDB and broadcasted to the foreign MIDB instances. After the initial loading, that will require a complete export of information data from SC and eSD, the NC should be responsible for the successive updates of this information data. Therefore it should be able to periodically retrieve from the SC and eSD the information data related to new Services, as well as changes to old services, and broadcast them to the other member state trough the WP4 IF. Working with a geographically distributed infrastructure, it will be very important to know when the infrastructure is working or if a remote PSC is working, therefore the National Connector should provide the PSC a probe function to check the status of the WP4 IF and possibly the status of a remote WP4 IF node. 5.4 Guidelines for Loading To successful load the MIDB through the SPOCS WP4 open modules avoiding exceptions some recommendations should be considered. The need for these guidelines is the exception handling and the structure of uncoupled entities as well as semantic checks realized in the transformation module. See section 4.5 and appendix C of deliverable D4.7. The recommendations are: All used codes in the entities or textual elements should be registered in the MIDB.
47 All to be loaded entities have to be registered in the MIDB. Thus loading should be in the following order: o Organization o Eservice o Document o Service o Profession Origin has to be of N for national, L for local or F for foreign, F is automatically used by the syndication module Identifier of entities have to start with “SPOCS:
So far there is no common approach and strategy for newcomers. There are some best practice steps that help starting with the SPOCS WP4 solution. They are: Become familiar with the use cases, scenarios and main architecture approach as described in section 2 Become familiar with the specifications and the latest data models and schemes as described in section 3 and appendix C based on the original specifications from deliverable D4.2 Analyze your national infrastructure for information sources and provision as well as management aspects related to the SPOCS needed information about services, eservices, organizations, documents and professions (see e.g. deliverable D4.1 or piloting partner description) Align your national procedures and infrastructure to be able providing information to SPOCS, especially define which sources and structures fulfill the SPOCS common specifications Define amendments and change requests where needed Set up the SPOCS infrastructure, especially the MIDB, see section 5 in deliverable D4.7 Implement your national connector to connect with the SPOCS WP4 modules
48 Integrate your national connector with the relevant solutions, especially the Point of Single Contact solution Define organizational and technical procedures managing the information process Load information to your MIDB through the WP4 modules Document all your activities Give feedback to the SPOCS team and support the sustainability as well as the operation of the SPOCS solution Increase awareness of your enabled solution 5.6 Political and Legal Recommendations The recommendations are based on the experience with the first pilots, the discussions with the partners building specifications and architecture as well as discussions with stakeholders. This set of recommendations needs to evolve related to ongoing feedback from pilots and stakeholders. The actual recommendations are: Support for increasing communication on organizational and semantic level. The pilots are involved with their frameworks into the national infrastructure. Most of the semantic structures are handling the same issues but are realized in different ways. Mainly without specific reasons apart from having a historical grown situation based on national interests. Thus at least on a European level there needs to be common schemes and data models for the core information. This includes also cross-domain activities, but this is rather more complicated as there are some domain driven specials that need to be handled. SPOCS will start working on a common set of schemes and data models focusing on the used entities within the SPOCS context. Moreover there is the need for semantic and organizational support and coordination especially with a linkage to standardization activities and other European projects. SPOCS will collaborate with Semic but also contact directly relevant stakeholders. Also there is the need for increasing communication with the semantic web, linked data and open data stakeholders. SPOCS will start collaborating with some of the groups but there needs to be a complete strategy how to handle the different groups and interests within an organizational support from member states and on the European level. Legally binding standards to ensure interoperability. The defined schemes and specifications need to be defined as legally binding as otherwise there is no pressure on the industry stakeholders to realize some solutions. Especially for the cross-border interoperability scenarios which have a lower usage level than national ones a legally binding framework could boost harmonization. An orientation can be the activities of some member states related to their national eGovernment strategies and the integration of legally binding structures to the constitutions within federal structures with many different interests. The standardization itself is not always the right instrument to boost harmonization. For example WP4 focuses not on standardization of the schemes and data models so far as
49 the usage of them should be increased first. Thus the approach is to start collaborating with other projects in the same context and defining common approaches and specifications to have a broader base for specifications. These specification need to be legally binding to ensure the usability in the different contexts. This will be mainly useful for core or infrastructural and not for domain-dependent schemes and solutions. This leads also to the requirement to encapsulate core information and services from business or application driven ones. Evolvement of interoperability solutions from small to large scales. The WP4 discussions about the scenarios and the alignment with the other WPs showed a big difference in political requirements and support to the real implementation and operation. The European idea is based on heterogeneous and decentralized approaches for enriching the cultural differences. This is useful for being innovative and supporting a broad cultural heritage. Decentralized solutions are also preferred to ensure influence of the different stakeholders. On an operational level centralized solutions offering an easier maintenance and control of the information flows as well as scalability. SPOCS started with being as decentral as possible. During the evolution of the SPOCS solution the pilots criticized this approach for the actual scope of SPOCS. More useful is to start with a small centralized solution tested for their usability within one domain or one region and then evolves the scope to different regions and domains. Later on the solution might be switched to a more decentralized approach. The assumption of SPOCS having existing catalogues, directories and PSC solutions with just different kind of schemes and technologies that only need to be made interoperable through common specifications is mainly wrong. The analysis already showed differences but the pilots did not showed the complete scope and scenarios as they are planning for. During the discussions about the specifications first realignment raised. They became very relevant discussing the specific implementations including focusing on a smaller scope for interoperability. This shows also that it is better to start on a small level which is defined as being bounded by all levels from political commitments through legal frameworks up to technical implementations. Later on these bindings from a specific domain or region can be used as best practice and evolve to others. Simple infrastructures, also central elements but they need to be financed The financing and organization instruments for the evolvement of interoperable solutions need to be clarified. A project structure like SPOCS can help in the evolvement itself but needs a long-term basement for sustainability where member states have also to commit their engagement. SPOCS coordination in alignment with the WPs works on sustainability activities that will also be part of an overall sustainability solution for many projects, especially the Large Scale Pilots. Long term objective has to be a complete European administration infrastructure that is connecting the different national infrastructures based on defined interoperable standards and specifications supported by a centralized organization. This organization might offer also some services and eservices directly. Support for common platforms and portals offering data in the context of core information of administrative procedures in a standardized way. Different European projects and initiatives are working on specific platforms to provide information and data for European businesses and citizens. Actually there is no
50 supporting instance for them establishing the platforms and, that is the main issue, supporting them with the communication to the data providers (e.g. mainly the CAs and Ministries). The actual regulations on information freedom are not evolving in the same way like the initiatives. Thus they need to be boosted related to their actual needs. Some legal procedures need a fast-lane solution to align political engagement and legal realization. The bigger issue is based on the organizational part. As mentioned before the procedures for gathering and providing information are freely regulated, restricted by practical usage and not automatized. The practical restriction is the main discussion point that needs further awareness. Offering the raw data should only be restricted by strong security aspects. Thus for SPOCS the raw data should be completely free available. The access is not restricted at all but limited to members of the SPOCS network to avoid attacks on the network itself. The usage and interpretation of the data and information is still in the sovereignty of the member states or participants. For SPOCS data this are the Points of Single Contact collecting, combining and selecting the relevant information. This also leads to the desired differences of the PSCs. The member states should support the automatized information provision on a structured raw data level for a broad amount of data. The provided information should be from reliable sources and being as actual as possible. For core information there should be no business model as the data is already financed by the tax payers. Nevertheless for specific requests where a significant workload arises fees should be allowed. Europe is on a good way but needs to boost and align the activities and initiatives, especially for the procedures and structures of the information provision. Next to this information providers are free to provide also combined or interpreted information on their behalf. Alignment of national procedures based on a common legal framework. Next to the information level the procedures are not aligned. There is no advantage of having different procedures apart from realizing different legal requirements. Thus there needs to be further alignment in the underlying legal frameworks with a detailed scope and not only basic regulations. The Services Directive seems clear in the way of defining the requirements but the realization differs. Moreover the small differences in the interpretation lead to more different procedures and they lead to more different procedures that are invoked by the previous ones and they have more different underlying organizational structures, schemes and technical realizations. The procedures and the semantic interpretation differ partially too much to realize interoperability at all. Piloting phase of SPOCS and the work on the semantic task will show the differences. Based on the semantics and the defined scenarios SPOCS might give recommendations for aligning or harmonizing procedures within the scope of business registration. Organization, legal and political level should use them as input for their activities. Aligned economy promotion and open provision of the information about them. Service Providers are not only focusing on the administrative procedure if they are establishing business. During the SPOCS discussions about the benefits and scenarios the acceptance and awareness scope was enriched to stakeholders outside the previously defined scope. SPOCS is giving input to them and raises awareness of the
51 solutions. Nevertheless SPOCS cannot work on their activities like aligning or promoting regions or business domains.
52 6 Outlook This section is mainly taken from the section 6 of deliverable D4.3. The update of this is mainly based on results of the semantic task thus there are no major changes so far. Small alignments are directly integrated.
Semantics are a major task for the further development of the information architecture of SPOCS WP1 and WP4. As several discussions during the piloting preparation showed, semantics need further alignment and research. Thus task T4.11 was designed to define a semantic concept. Moreover the development of the Open Modules and the creation of these guidelines showed that the data and information models need an update and further alignment to simplify the complexity and support the efficiency as well as the sustainability. Especially the work on Transformation Module, Syndication and equivalence information demonstrates the need to update the semantic approaches. The data model and schemes are already simplified but this process will be continued based on the results of the semantic task. The results of the SPOCS semantic task can be used for aligning administrative procedures and requirements. Moreover actually realised manual tasks like equivalence can be combined and process chains can be automated. This chapter provides an outlook for updates of the data models and an idea for the ontology approach. Moreover it marks the needs and interoperability relations. The last part marks principles for sophisticated approaches to realise rule-based solutions and open government. 6.1 Update Data Models and WP4 Ontology approach This section references the recommended updates mentioned in the sections before and combines them to requirements for the envisaged ontology approach. The identification scheme has a semantic part for classifying the information object with a part of the ontology. This allows the relation of the object with a part of the ontology or a specific ontology. Piloting and work on the semantic concept need to verify, whether this part of the identifier is needed, optional or not useful. Actually it is used to support the work on the ontology. To reduce complexity of the data model, the exchange of relations and their foreign keys by the usage of the identifiers is recommended. This leads to flat directories and catalogues, but increases the need for internal functional requests as a direct navigation within one function is not possible. This considers also the idea of core directories. Another task for building the semantic concept and updating the data model is the usage of code lists. They are used for classifying the information objects by long-term stable indicators. The semantic concept has to assess, whether all code lists are necessary or whether there are code lists missing. Moreover the usage of the right codes has to be assessed. Code lists can help reducing the complexity, thus for the update of the data model it is recommended to uncouple relations and use directly the codes as it is realized now for the language codes.
Another update of the data model related to the simplification of the complexity is the establishment of further loose information objects. They are realised as flat / simple structures and relations are realised by the identifier. Possible further information objects are described in
53 section 3.3 and need to be assessed during piloting and semantic concept task. A first uncoupling for testing purpose is used between document and organization. There is no direct relation between them in the MIDB data model. 6.2 Semantic Needs and Interoperability The semantic task will discuss the needs related to the semantic layer of the European Interoperability Framework. Interoperability in this context is bridging different organizations for supporting interaction based on common agreements and to improve information sharing.
6.2.1 European Interoperability Framework Basics The EIF defines five needs and benefits which have also a close relation to SPOCS WP4. Cooperation is supported by enhancing the information provision for reaching services and eServices of different business domains and regions, especially cross-border. The exchange and sharing of information is the basement for achieving improved information provision to the Service Providers and thus to reduce administrative burdens on businesses. As eService Directories are storing the communication parameter of the available electronic services, the delivery of services is improved in the way of a Point of Single Contact. Moreover costs are reduced as consultation activity is concentrated at the Point of Single Contact and reduced on Competent Authority level. The SPOCS WP4 activities are based on the Guidelines and Services & Tools level. The guidelines are giving recommendations for the implementation and the semantic interpretation and alignment is based on the piloting / operational activities. SPOCS WP4 tries to design a concept for the ontology and recommends their usage as well as organisational back office processes within the member states to improve quality of information and establish an information lifecycle.
6.2.2 Interoperability Principles SPOCS WP4 is also considering the interoperability principles. Subsidiarity is considered as information gathering is assigned to the lowest level, especially the ministry or Competent Authority, and information provision is made for the Service Provider. Thus the established Points of Single Contact are only intermediary of information provision between Competent Authorities and their customers. User centricity is also fulfilled. Personalization can be used as far as the Points of Single Contact allow such a specific functionality. SPOCS WP4 can handle information exchange for personalized requests, but is not dealing with personal information itself. WP4 accounts security and privacy in the meaning of establishing trust for information exchange and not dealing with personal information. Advanced technologies (inclusion) will be used for second piloting phase related to the evolving work on the semantic concept including the requirement for no discrimination and accessibility to the information. Provided information is available regarding principles of open government (openness and transparency), with the restriction of access to full information allowing the storage of technical interfaces requiring a minimum level of trust and securing the information exchange network by denial of service attacks. Therefore SPOCS WP4 is using the Trust-service Status List mechanisms of WP3. The principle multilingualism is realized as defined in chapter 3.2. SPOCS is dealing with the objectives of the European Services Directive, but the designed information architecture is not limited to this topic. Thus reusability, administrative simplification and the increase of efficiency are achieved in this context. SPOCS is based on open source software and tries to support the technologies already existing in the member states.
54 6.2.3 Public Services Conceptual Model The core approach of the information infrastructure is based on connecting reliable sources of basic information as defined for Base Registries. Evolving to the recommended updates related to semantics and uncoupling of information objects, the SPOCS information architecture of WP1 and WP4 are realizing the concept of core directories. These can be understood as Base Registries. Another level would be the realisation of aggregation and orchestration of process chains for public services. The actual solution is supporting this objective by establishing a source for information about objects that can be orchestrated. As discussion and assessment within the project showed that there is actual no data source for orchestration, SPOCS is not concentrating on it. Key question is whether there is a need for orchestrated models to be exchanged. The question is similar to equivalence discussion. SPOCS WP4 is actually supporting the manual creation of equivalence information on the behalf of the Points of Single Contacts. The same should work for orchestration objective.
6.2.4 Interoperability Levels SPOCS considers all levels of the interoperability framework. WP4 is concentrating on organisational, semantic and technical interoperability. The technical interoperability is handled by the development task creating the Open Modules, data models and establishing the WP4 interoperability framework. The organisational interoperability is handled by the Points of Single Contact collecting the information from WP4IF. The main objective is the semantic interoperability. Therefore WP4 defined in deliverable D4.2 appendix C the common attributes. Within development activities data models are defined. For the semantic task an alignment of the precise meaning is envisaged. The work on semantic interoperability is a significant challenge and thus an ongoing process integrating feedback from piloting. 6.3 Outlook Semantic Concept This section of the outlook for semantic concept gives an overview on principles and technologies related to semantics. Actually it references to Linked Data and the Semantic Web, Open Government and Open Data as well as Rule-Based approaches. Further principles and technologies can be added during update of the guidelines and work on the semantic concept. The semantic concept will be developed within the semantic task. For the process the following steps are envisaged based on alignments and agreements at the WP4 meeting: Definition of semantic use cases based on the WP4 use cases and scenario, especially focused on speeding business registration by usage of equivalence. The benefit is a clear definition of the scope and the achievements. Definition of criteria to evaluate and then assessment of the approach for choosing a semantic technology as well as their usage within the context of SPOCS. Results are an overview of the semantic technologies and how they might be used in the SPOCS context including a prioritization based on the assessment and piloting feedback. Definition of the structure, schemes and ontologies based on the existing schemes and piloting feedback using the approach for a chosen semantic technology. Integration of the schemes and ontologies to the existing open modules and the underlying architecture.
55 Documentation of the chosen approach, results and the semantic as well as technical integration within SPOCS.
6.3.1 Linked Data and Semantic Web Linked Data is an approach for making information available in a structured way. The results can be navigated. For structuring the information existing internet standards are used. Four rules are the principles for Linked Data: name objects using URIs, make information electronic available (locate information), use standard formats like RDF/XML and include links to other information objects. Apart from the standard RDF/XML, SPOCS is considering these principles. It is recommended to extend availability of information to RDF/XML using RDF Triple Stores. This objective is planned for the second phase and already integrated and tested for the syndication mechanism. During the creation of the semantic concept further governance on dependencies with other European activities like Linking Open Data 2 or Open Cities is necessary. SPOCS WP4 will establish ontology about semantics within the scope of SPOCS. This aligns content and structures to allow further investigation and future use of cross-border scenarios. Details for used technology and integration into developed WP4 / WP1 solution need to be assessed during semantic task. Results will increase acceptance and dissemination of SPOCS WP4 results including dissemination into other domains.
6.3.2 Open Government and Open Data Open Government is an initiative combining collaboration, participation and transparency to change the culture and behaviour of administrative thinking. Therefore SPOCS fits into this initiative with the establishment of the information architecture and enhancement of the Points of Single Contact. Open Data is concentrating on opening the information silos for the society to support investigation, participation and innovation. To assess the maturity of openness, SPOCS WP4 activities should be measured by the Open Data Principles. Completeness can be fulfilled by establishing recommended back office procedures and involve further member states and Competent Authorities. The information architecture approach is not limited to information about European Services Directive, but needs a further alignment on political, legal and practical level within the member states. Moreover sustainability needs to be handled for reaching effectiveness and efficiency. Personal information is not used, thus information should be accessible. Nevertheless some information as the technical interfaces is restricted to specific requests including security and trust mechanisms. This is necessary to avoid electronic attacks as the mentioned information should also be used for transactions and establishment of automatic communication. Primacy is reached as information is collected at the level of the Competent Authorities through the national infrastructure. SPOCS is not generating information that already exists, but stores some new information that is actually not stored like the equivalence. This information can also be integrated into an information process located at Competent Authority level if the local procedures are aligned. The information is collected timely. SPOCS recommends an update on the fly based on the recommended back office procedures. Establishing automatic editing and approval processes allows a direct invocation of changes from the source of the information to the use within SPOCS.
56 Accessibility as described above is given to everyone connecting to an MIDB. As SPOCS is concentrating on enhancing the communication between Service Providers and Points of Single Contact, the envisaged audience is restricted. An extension to make the MIDB accessible to the society is possible, but on the behalf of the member states with their national infrastructure. The stored information can be used for different purposes and is not limited to specific business domains, apart from the restriction for the full information to avoid electronic attacks on communication architectures. The changed focus for the interoperability mechanisms allows provision of more information as Open Data as the access to a more complete set of information is free. Nevertheless there is actually no plan for an Open Data Platform or the collaboration with one. The information is stored in a structured form and therefore usable within automatic processes. The machine readability can be improved by using generic concepts like core directories or base registries, improving the meta information and documentation as well as simplifying the structure of the directories and catalogues through uncoupling of information objects. Core information is stored without registration and thus fulfils the principle of non-discrimination. Storage of information is reduced to textual elements. Used code lists need to be available for free. The information exchange is non-proprietary. Storage itself can be based on specific technologies related to the organisational framework of the member states or organizations. SPOCS is offering a common solution based on Open Source software. Request for information or syndication is not based on fees, thus they are license-free and free of costs. Referenced information provided by the member states or organizations is also recommended to be license-free, especially as it supports SPOCS objectives of business growth and innovation. Nevertheless SPOCS is bound to the legal and organizational framework of the information providing organization. Permanence has to be solved by the national infrastructures. SPOCS is supporting a versioning mechanism, but is not working on archiving solutions. But SPOCS defines requirements and recommendations about back office processes including archiving.
6.3.3 Rule-Based Solution This paragraph marks the approach of rule-based solutions. Legal, organisational and procedural frameworks are realised in rules. Mainly they are described in a textual form, what is not allowing further processing. Thus it is necessary to transform the text in structured information that can be inferred. Rule-based solutions can handle them. As SPOCS deals with such information, it would simplify the information generation process and reduce various interpretations with allowing different decisions. The existing data model needs to be updated especially regarding conditions and responsibilities (see chapter 4.2.2). Conditions are used for the inference of different services, eServices and documents leading to construction of process chains (semi-automatic orchestration). Responsibilities and eServices are especially used to determine the communication partners including their roles and their technical interfaces.
Major task for the semantic concept is the work on the content and structure for the information exchange. Thus key work is related to the ontology and updates of the schemes and data model based on advanced approaches as mentioned above.
57 Conclusions This deliverable contains two main objectives. First the update of the specifications based on deliverable D4.2 and the feedback of the partners. The update included especially the extension of information about documents and the alignment of the common set of attributes for information entities. Moreover some minor changes like uncoupling the language property and renaming all attributes are realized. The second major objective is the update of the usage of the modules including the setup of them thus documentation of guidelines how to use the WP4 results. Major decision in this context was to focus on syndication as cross-border interoperability mechanism. Moreover an improvement of the organizational and semantic setup for pilots is realized. This includes also recommendations based on the experience within WP4 like to start with small solution regardless interoperability aspects and to evolve later on. SPOCS WP4 was not in the position as assumed in advance as piloting feedback was not accurate and scenarios differ too much. Thus the recommendations are also to be used as objectives for member states to further align structures and procedures. The main guidelines have not been changed since the first version of guidelines (D4.3). The deliverable is especially extended by parts that were raised by the piloting and enlargement partners. The outlook gives a reference to open activities related to the semantic task and how to use WP4 results in other contexts or with other solutions than it is realized now. This should ensure long-term stability and common acceptance.
There are still some open discussion points, e.g. the uncoupling of the entities or the semantic meaning / setup of entities with localized scope. They will be further investigated and the guidelines updated. This should include also further governance processes related to information provision. A major MIDB schema update can only be done with release 2.0 as otherwise a backward compatibility is not possible. Release 2.0 will include feedback from semantic task and piloting support.
The deliverable shows the progress and evolution of the schemes and guidelines. Restructuring and extension was done. Further requirements and activities are defined and planned for the next releases. Further major improvements can only be expected by release 2.0.
58 59 A. Appendix A – Acceptance Criteria
Acceptance criteria Norm Process Priorit y 1. Conform to SPOCS Template issued by Gov2u(12- Check against template High template 2009) by WP6 2. Language & Spelling English (UK) Review by an English Mediu language specialist by PD m 3. Readability Comprehensible English Review by PD and each High Comprehensible for the partner assigned to audience chapter Clear structure & interesting presentation Highlight of outcomes and advantages Benefits from using WP4 are marked, No complicated structure, no nested sentences, - in this context- no unusual vocabulary 4. Consistency with Alignment between this Examine this deliverable High description in DoW deliverable and the DoW and the DoW and regarding the effected compare the effected account/statements about account/statements. objectives and the description Review by Sub-Leader of the deliverable 4.7 Team and partners 5. Consistency within No contradictions and To check that there are no High the document unnecessary repetitiveness contradictions and needless repetitiveness Review by sub-leader and partners 6. Content is suitable for Deliverable fulfils the Verification of results by High purpose objectives by delivering the sub-leader in cooperation necessary facts with contributing partners
7. Contents is fit for use Implementation and Piloting quality Verification of results by High (for the second wave) can be sub-leader in cooperation increased with contributing partners o especially with the additional the experiences of the first wave piloting countries Recommendations are given for structure, information, mapping Evolvement of scheme and architecture is described
60 8. Commitment within Partners of this WP are Partner experts and WPs High WP committed with the objectives experts are involved in and acceptance criteria in creation and QA process advance Regular conference calls Partners committed with the results 9 Delivered on time Planning for the Work Package Regular check of work High plan and conference calls for update on delivery by WP leader and sub-leader
Table 1: Acceptance Criteria List Legend: - Deliverable - a description of the deliverable for which the acceptance criteria must be met. - Acceptance criterion – a description acceptance criterion - Norm – a description of the norm that is applied to measure conformance - Process – a description of the process that is used to test conformance - Priority – the priority to meet a acceptance criterion (Low = nice to conform to, Medium = important to conform to, High = necessary to conform to)
61 B. Appendix B – Risk List
Threat Consequence(s) Measure(s) Chance Impact Risk Specifications Implementation Increase awareness of L H L cannot be cannot continue available updated specs updated Updated Pilots cannot use Raising awareness at L H L Specifications specifications and modules pilots do not suit Increase communication pilot needs between WP4 and pilots Guidelines do Usability is low Improvement of M H M not increase description usability of Inclusion of further pilot modules and feedback specifications Missing Delays for Realignment of work H M M resources and guidelines, deliverables Reconfiguration of scope partner and pilots Improvement of contributions awareness and communication Missing / Lack Delays for Communication with M M M of expertise in guidelines, deliverables partners and coordination governance, and pilots semantics and documentation Feedback lead Pilots cannot go Complete restructuring L H L to insolvable live of architecture issues Missing / Late Documentation / Increase awareness and H M M feedback Guidelines without communication alignment to pilots needs Deliverables provided to late Guidelines Update of Analysis of failures / M H H deliverable is deliverable expectations not accepted Increase resources for deliverable update Table 2: Example risk list
Legend: - Threat - Description of a potential danger towards the project. - Consequence - Description of the negative effect the threat can have towards the project. - Measure - Description of the measures that can be taken to prevent a threat from happening or to reduce negative the effects. - Chance - Defines the likelihood of a threat to happen. - Impact - Measure of the negative effect on the project. - Risk - Chance * Impact, representing the priority.
62 63 C. Appendix C – MIDB Data Model
This section contains the updated MIDB data model. It is represented by the figure and tables. It is an update of appendix C in deliverable D4.2 and appendix C/D/E in deliverable D4.4 including especially the extension of information for documents. Columns for Meta and Syndicated from appendix C in D4.2 are skipped as there was no real benefit for them. This data model represents the model for release 1.2. The namespaces for the XSD are http://www.eu-spocs.eu/eservices/ns/midb/
C.1 MIDB data model overview
Figure 1Figure 10 shows the uncoupled code lists and deprecated tables from previous releases. Routing and access are not used anymore related to the change of the scenario focus. Change is used for the change tracking and will be verified within one of the next releases. Equivalence will be updated after the analysis of the semantic task. Doctype represents the document types. Attributes represents all attributes in the MIDB tables. Condition is the condition status for entities. Status represents the status of the entity. Language represents the languages used in the textual elements. Within one of the next releases deprecated elements will be skipped from the data model. Moreover code lists (doctype, attribute, condition, status, language) will change the primary key to the code itself and maybe externalized. Equivalence might be extended after feedback of the semantic task.
Figure 10: Code List and Deprecated Tables (Update)
Figure 11 shows the entities and associated elements of the MIDB. The data model has entities (service, eservice, doc, org, prof), textual representations of them (stext, etext, dtext, otext, ptext), associated tables and mapping tables (needdoc, outdoc, sagency, sinter, eagency, einter, ses, parameter). Names are shorten and only with lower case for compatibility with some pilot solutions. Within the MIDB for release 1.2 tables are coupled to ensure backward compatibility. They might be uncoupled for release 2.0. Following sections describe the attributes in detail.
64 Figure 11: MIDB data model overview (Update)
65 C.2 MIDB entities
The following section describes the MIDB entities. They are representing the core objects used within the scenarios. They are detailed through textual, associated and mapping tables described in the following sections. The entities are service [10 XX], eservice [20 XX], organization (org) [30 XX], profession (prof) [40 XX] and document (doc) [50 XX]. Further entities might be defined for one of the next releases. Profession is under verification for extension or change to a code list thus is not designed the same way like the other entities. Table 3 details the main attributes used in the entities. The XSD references the defined namespaces for the XML model.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD XX 01 id VARCHAR(255) 1..1 The identifier (ID) is the id/common:spocsid:id xsd:string primary unique naming of the element. key It is valid within a namespace (incl. country code and business domain) defined by the naming scheme. Primary key in combination with vstart. XX 02 vstart INT 1..1 The version number the id/common:spocsid:vstart xsd:int primary record starts with. Primary key key in combination with id. XX 03 vend INT 0..1 The version number the meta/common:meta:vend xsd:int record ends with. XX 04 valstart DATETIME 1..1 The start date where the meta/common:meta:valstart xsd:dateTime entity is valid from. XX 05 valend DATETIME 0..1 The end date where the entity meta/common:meta:valend xsd:dateTime is not valid anymore. XX 06 origin VARCHAR(1) 1..1 The code showing whether it meta/common:meta:origin xsd:string is foreign (F), national (N) or local (L) information. Needed for syndication selection. XX 07 status INT 1..1 The status of the entity based status xsd:int on the status code list. XX 08 contact VARCHAR(255) 0..1 The contact that can be
66 meta/common:meta:contact xsd:string contacted if problems arise with this information. XX 09 owner VARCHAR(255) 1..1 The id of the owner of this owner/ common:spocsid:id xsd:string information. The owner is legally responsible. XX 10 ownerv INT 1..1 The version start number of owner/ common:spocsid:vstart xsd:int the owner. The owner is legally responsible.
Table 3: Main Attributes of Entities
Table 4 shows additional attributes for the service entity.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 10 41 prof VARCHAR(255) 0..1 The ID of the associated prof/common:spocsid:id xsd:string profession. 10 42 profv INT 0..1 The version start number of prof/common:spocsid:vstart xsd:int the associated profession.
Table 4: Additional Attributes of Service
Table 5 shows additional attributes for the eservice entity.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 20 41 address VARCHAR(255) 1..1 The address of the eservice. address xsd:string It is the minimum parameter for communicating with the eservice. 20 42 type VARCHAR(255) 1..1 The type of the eservice type xsd:string defining the kind of used channels. Has to be defined by a code list.
Table 5: Additional Attributes of Eservice
Table 7 shows additional attributes for the profession entity.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB
67 XSD MIDB XSD 40 41 nace VARCHAR(10) 1..1 The code of the profession nace xsd:string based on the NACE Rev. 2 code of Eurostat. 40 42 name VARCHAR(200) 1..1 The name of the profession. name xsd:string
Table 6: Additional Attributes of Profession
Table 7 shows additional attributes for the document entity.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 50 41 doctype INT 1..1 The type of the document doctype xsd:int defined by the doctype code list.
Table 7: Additional Attributes of Document
Table 8 shows all attributes of the entities. The table shows the name and the code within the attributes code list.
Service Eservice Organization Profession Document Service.Id Eservice.Id Org.Id Prof.Id Doc.Id 10 01 20 01 30 01 40 01 50 01 Service.Vstart Eservice.Vstart Org.Vstart Prof.Vstart Doc.Vstart 10 02 20 02 30 02 40 02 50 02 Service.Vend Eservice.Vend Org.Vend Prof.Vend Doc.Vend 10 03 20 03 30 03 40 03 50 03 Service.Valstart Eservice.Valstart Org.Valstart - - 10 04 20 04 30 04 Service.Valend Eservice.Valend Org.Valend - - 10 05 20 05 30 05 Service.Origin Eservice.Origin Org.Origin Prof.Origin Doc.Origin 10 06 20 06 30 06 40 06 50 06 Service.Status Eservice.Status - - Doc.Status 10 07 20 07 50 07 Service.Contact Eservice.Contact Org.Contact - Doc.Contact 10 08 20 08 30 08 50 08
68 Service.Owner Eservice.Owner - - Doc.Owner 10 09 20 09 50 09 Service.Ownerv Eservice.Ownerv - - Doc.Ownerv 10 10 20 10 50 10 Service.Prof Eservice.Address - Prof.Nace Doc.Doctype 10 41 20 41 40 41 50 41 Service.Profv Eservice.Type - Prof.Name - 10 42 20 42 40 42
Table 8: Attributes Overview of the Entities
C.3 MIDB Textual Elements for Entities
The following section describes the textual representations of the MIDB entities. They are stext for service [12 XX], etext for eservice [22 XX], otext for org [32 XX] and dtext for doc [52 XX]. Profession is under verification for extension or change to a code list thus is not designed the same way like the other entities. Table 9 details the main attributes used in the textual elements. The XSD references the defined namespaces for the XML model.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD XX 01 id INT 1..1 The internal identifier id xsd:int primary (primary key) for the key textual element. Might be switched in a later release to a composite key. XX 02 iso639v3 VARCHAR(3) 1..1 The language code for the iso639v3 xsd:string textual element based on the language code list represented by the iso 639 code with a 3 character alphanumeric code. XX 03 name VARCHAR(200) 1..1 The official name of the text/common:text:name xsd:string entity. XX 04 shortname VARCHAR(64) 0..1 The unofficial name of the
69 text/common:text:shortname xsd:string entity. XX 05 abbreviation VARCHAR(12) 0..1 The abbreviation of the text/common:text:abbreviation xsd:string entity. XX 06 outline LONGTEXT 1..1 The short description of text/common:text:outline xsd:string the entity giving an overview about scope and purpose. XX 07 description LONGTEXT 0..1 The long description of the text/common:text:description xsd:string entity giving a comprehensive description of the scope and purpose. XX 08 desdatetime DATETIME 1..1 The date time when the text/common:text:descdatetime xsd:dateTime description was created / approved. XX 09 descowner VARCHAR(255) 0..1 The owner of the descowner/common:spocsid:id xsd:string description. This owner is responsible for the content of the entity. If no descowner is defined the owner of the entity is responsible. XX 10 descownerv INT 0..1 The version start number descowner/common:spocsid:vstart xsd:int of the description owner. XX 11 synonyms LONGTEXT 0..1 Synonyms related to the text/common:text:synonyms xsd:string entity in the given language. XX 12 keywords LONGTEXT 0..1 Keywords related to the text/common:text:keywords xsd:string entity in the given language. XX 13 territory LONGTEXT 1..1 The area where this entity text/common:text:territory xsd:string can be used or is responsible for. XX 14 legalBasis LONGTEXT 0..1 The legal basis describes text/common:text:legalbasis xsd:string what laws and legal/ administrative regulations are related to the entity.
Table 9: Main Attributes of Textual Elements
Table 10 shows additional attributes for the service text.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 12 41 consumer LONGTEXT 0..1 The audience or the target
70 consumer xsd:string group of the entity. 12 42 preconditions INT 1..1 The conditions that need to preconditions xsd:int be fulfilled for using the entity. 12 43 output LONGTEXT 1..1 The output of the service output xsd:string 12 44 fees LONGTEXT 1..1 The dues and rates that have fees xsd:string to be paid using the entity. 12 45 respites LONGTEXT 0..1 The time limits and durations respites xsd:string of the entity.
Table 10: Additional Attributes of Stext
Table 11 shows additional attributes for the eservice text.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 22 41 consumer LONGTEXT 0..1 The audience or the target consumer xsd:string group of the entity. 22 42 preconditions INT 1..1 The conditions that need to preconditions xsd:int be fulfilled for using the entity. 22 43 servicelevel LONGTEXT 0..1 The levels commited to the servicelevel xsd:string eservice. Should include at least availability and performance based on the agreements (SLA). 22 44 pricing LONGTEXT 0..1 The dues and rates that have pricing xsd:string to be paid using the entity. 22 45 termsconditions LONGTEXT 0..1 The economical aspects termsconditions xsd:string those have to be accepted using the eservice. 22 46 altchannels LONGTEXT 0..1 Alternative channels / altchannels xsd:string supporting channels. 22 47 securitydesc LONGTEXT 1..1 The relevant security securitydesc xsd:string regulations using the eservice. 22 48 privacyconstraints LONGTEXT 0..1 The relevant privacy privacyconstraints xsd:string regulations using the eservice.
Table 11: Additional Attributes of Etext
71 Table 12 shows all attributes of the textual elements. The table shows the name and the code within the attributes code list.
Service (Stext) Eservice (Etext) Organization (Otext) Document (Dtext) Stext.Id Etext.Id Otext.Id Dtext.Id 12 01 22 01 32 01 52 01 Stext.Iso639v3 Etext.Iso639v3 Otext.Iso639v3 Dtext.Iso639v3 12 02 22 02 32 02 52 02 Stext.Name Etext.Name Otext.Name Dtext.Name 12 03 22 03 32 03 52 03 Stext.Shortname Etext.Shortname Otext.Shortname Dtext.Shortname 12 04 22 04 32 04 52 04 Stext.Abbreviation Etext.Abbreviation Otext.Abbreviation Dtext.Abbreviation 12 05 22 05 32 05 52 05 Stext.Outline Etext.Outline Otext.Outline Dtext.Outline 12 06 22 06 32 06 52 06 Stext.Description Etext.Description Otext.Description Dtext.Description 12 07 22 07 32 07 52 07 Stext.Descdatetime Etext.Descdatetime Otext.Descdatetime Dtext.Descdatetime 12 08 22 08 32 08 52 08 Stext.Descowner Etext.Descowner - Dtext.Descowner 12 09 22 09 52 09 Stext.Descownerv Etext.Descownerv - Dtext.Descownerv 12 10 22 10 52 10 Stext.Synonyms Etext.Synonyms Otext.Synonyms Dtext.Synonyms 12 11 22 11 32 11 52 11 Stext.Keywords Etext.Keywords Otext.Keywords Dtext.Keywords 12 12 22 12 32 12 52 12 Stext.Territory Etext.Territory Otext.Territory Dtext.Territory 12 13 22 13 32 13 52 13 Stext.Legalbasis Etext.Legalbasis Otext.Legalbasis Dtext.Legalbasis 12 14 22 14 32 14 52 14 Stext.Consumer Etext.Consumer - - 12 41 22 41 Stext.Preconditions Etext.Preconditions - - 12 42 22 42 Stext.Output Etext.Servicelevel - - 12 43 22 43 Stext.Fees Etext.Pricing - - 12 44 22 44 Stext.Respites Etext.Termsconditions - - 12 45 22 45 - Etext.Altchannels - -
72 22 46 - Etext.Securitydesc - - 22 47 - Etext.Privacyconstraints - - 22 48
Table 12: Attributes Overview of the Textual Elements
C.4 MIDB Associations and Mappings for Entities
The following section describes the associated tables for and n:m mappings between the MIDB entities. They are sagency between service and org [16 XX], sinter between service and org [17 XX], needdoc between service and doc [18 XX], outdoc between service and doc [19 XX], eagency between eservice and org [26 XX], einter between eservice and org [27 XX], ses between service and eservice [28 XX] and parameter for eservice [29 XX].
Table 13 shows the attributes for the service agency. The mapped organization is workload responsible for the service.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 16 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 16 02 sid VARCHAR(255) 1..1 The identifier of the service. sagency/common:spocsid:id xsd:string 16 03 sv INT 1..1 The version start number of sagency/common:spocsid:vstart xsd:int the service. 16 04 oid VARCHAR(255) 1..1 The identifier of the sagency/common:spocsid:id xsd:string organization.
73 16 05 ov INT 1..1 The version start number of sagency/common:spocsid:vstart xsd:int the organization.
Table 13: Attributes of Sagency
Table 14 shows the attributes for the service intermediary. The mapped organization is handling the service but is not responsible. If no intermediary is defined the agency has to handle the service.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 17 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 17 02 sid VARCHAR(255) 1..1 The identifier of the service. sinter/common:spocsid:id xsd:string 17 03 sv INT 1..1 The version start number of sinter/common:spocsid:vstart xsd:int the service. 17 04 oid VARCHAR(255) 1..1 The identifier of the sinter/common:spocsid:id xsd:string organization. 17 05 ov INT 1..1 The version start number of sinter/common:spocsid:vstart xsd:int the organization.
Table 14: Attributes of Sinter
Table 15 shows the attributes for the needed documents. The mapped documents are the needed input for the service.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 18 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 18 02 sid VARCHAR(255) 1..1 The identifier of the service. needdoc/common:spocsid:id xsd:string 18 03 sv INT 1..1 The version start number of needdoc/common:spocsid:vstart xsd:int the service.
74 18 04 did VARCHAR(255) 1..1 The identifier of the needdoc/common:spocsid:id xsd:string document. 18 05 dv INT 1..1 The version start number of needdoc/common:spocsid:vstart xsd:int the document.
Table 15: Attributes of Needdoc
Table 16 shows the attributes for the output documents. The mapped documents are the output of the service.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 19 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 19 02 sid VARCHAR(255) 1..1 The identifier of the service. outdoc/common:spocsid:id xsd:string 19 03 sv INT 1..1 The version start number of outdoc/common:spocsid:vstart xsd:int the service. 19 04 did VARCHAR(255) 1..1 The identifier of the outdoc/common:spocsid:id xsd:string document. 19 05 dv INT 1..1 The version start number of outdoc/common:spocsid:vstart xsd:int the document.
Table 16: Attributes of Outdoc
Table 17 shows the attributes for the eservice agency. The mapped organization is workload responsible for the eservice. It is the operator of the eservice.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 26 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 26 02 eid VARCHAR(255) 1..1 The identifier of the eagency/common:spocsid:id xsd:string eservice. 26 03 ev INT 1..1 The version start number of
75 eagency/common:spocsid:vstart xsd:int the eservice. 26 04 oid VARCHAR(255) 1..1 The identifier of the eagency/common:spocsid:id xsd:string organization. 26 05 ov INT 1..1 The version start number of eagency/common:spocsid:vstart xsd:int the organization.
Table 17: Attributes of Eagency
Table 18 shows the attributes for the eservice intermediary. The mapped organization is handling the eservice but is not responsible. If no intermediary is defined the agency has to handle the eservice. This is the communication endpoint.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 27 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 27 02 eid VARCHAR(255) 1..1 The identifier of the eservice. einter/common:spocsid:id xsd:string 27 03 ev INT 1..1 The version start number of einter/common:spocsid:vstart xsd:int the eservice. 27 04 oid VARCHAR(255) 1..1 The identifier of the einter/common:spocsid:id xsd:string organization. 27 05 ov INT 1..1 The version start number of einter/common:spocsid:vstart xsd:int the organization.
Table 18: Attributes of Einter
Table 19 shows the attributes for the service - eservice relation. The mapped eservices are the communication channels for the service.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 28 01 id INT 1..1 The internal identifier of the mapping. This primary key primary might be switched to a key composite key in a later release. 28 02 sid VARCHAR(255) 1..1 The identifier of the service.
76 ses/common:spocsid:id xsd:string 28 03 sv INT 1..1 The version start number of ses/common:spocsid:vstart xsd:int the service. 28 04 eid VARCHAR(255) 1..1 The identifier of the eservice. ses/common:spocsid:id xsd:string 28 05 ev INT 1..1 The version start number of ses/common:spocsid:vstart xsd:int the eservice.
Table 19: Attributes of Ses
Table 20 shows the attributes for the parameters of an eservice. Further parameters are optional.
Attribute Attribute Format / Data Cardinality Description Code Type MIDB XSD MIDB XSD 29 01 id INT 1..1 The internal identifier of the parameter:id xsd:int mapping. This primary key primary might be switched to a key composite key in a later release. 29 02 parameter VARCHAR(255) 1..1 The parameter value. parameter:parameter xsd:string 29 03 type VARCHAR(255) 0..1 The parameter type. parameter:type xsd:string
Table 20: Attributes of Parameter
Table 21 shows all attributes of the associated / mapped elements.
Document Service Organization Eservice Sagency.Id 16 01 Sagency.Sid Sagency.Oid 16 02 16 04 Sagency.Sv Sagency.Ov 16 03 16 05 Sinter.Id 17 01 Sinter.Sid Sinter.Oid 17 02 17 04 Sinter.Sv Sinter.Ov 17 03 17 05
77 Needdoc.Id Eagency.Id 18 01 26 01 Needdoc.Did Needdoc.Sid Eagency.Oid Eagency.Eid 18 04 18 02 26 04 26 02 Needdoc.Dv Needdoc.Sv Eagency.Ov Eagency.Ev 18 05 18 03 26 05 26 03 Outdoc.Id Einter.Id 19 01 27 01 Outdoc.Did Outdoc.Sid Einter.Oid Einter.Eid 19 04 19 02 27 04 27 02 Outdoc.Dv Outdoc.Sv Einter.Ov Einter.Ev 19 05 19 03 27 05 27 03 Ses.Id 28 01 Ses.Sid Ses.Eid 28 02 28 04 Ses.Sv Ses.Ev 28 03 28 05 Parameter.Id 29 01 Parameter.Parameter 29 02 Parameter.Type 29 03
Table 21: Attributes Overview of the Associated / Mapped Elements
78 D. Appendix D – Code Lists
This section lists the code lists used within the MIDB or XML schema. The codes for the attributes are already defined in appendix C. The technical code lists like exception codes are listed in the appendix of deliverable D4.7. Most lists were already defined in deliverable D4.4.
D.1 Language and Script Code
The Language Code is used for every textual attribute by integrating a language property to each tag in the XML scheme. Moreover Language Code is stored in the Language Table and referenced by all Text Tables. SPOCS is recommending the usage of ISO 639-3 (three character alphanumeric) as the coverage is sufficient for SPOCS objectives.18 The two character alphanumeric code is referenced in the language table. Based on feedback by the pilots the referenced language can also be switched to the script code like “de-Latn-AT” (German with latin script in Austria) or “el-Grek-GR” (Greek with greek script in Greece). Therefore SPOCS would recommend the usage of RFC 5646 and ISO 15924.1920 The code list in the MIDB is actually limited to the SPOCS partner main languages, thus the following: Table 22: Language Code ListTable 22 shows all attributes of the associated / mapped elements. ISO 639v3 ISO 639v1 Name deu de German ell el Modern Greek (1453-) eng en English fra fr French ita It Italian lav lv Latvian ltz lb Luxembourgish mlt mt Maltese nld nl Dutch nor no Norwegian
18 ISO 639-1: http://www.infoterm.info/standardization/iso_639_1_2002.php, Infoterm – UNESCO 19 IETF RFC 5646, http://tools.ietf.org/html/rfc5646, Network Working Group, September 2009 20 ISO 15924 – UNICODE: http://www.unicode.org/iso15924
79 pol pl Polish por pt Portuguese ron ro Romanian slv sl Slovenian swe sv Swedish
Table 22: Language Code List
D.2 Document Type Code
The Document Type Code is used in the Document Entity and is a basis for the semantic grouping of documents within the SPOCS identifier naming scheme. SPOCS WP4 is referencing to the defined document types of WP5.21 Table 22: Language Code ListTable 23 shows all document types.
Code Name 1100 Attestation 1200 License 1300 Application 1400 Solemn Declaration 1500 Certificate 1600 Educational Institute Degree 1700 Identity Card / Passport 1800 Payment Receipt 1900 Authorization 2000 Notary Act 2100 Contract 2200 Diagram 2300 Drawing 2400 Translation 2500 Photo 2600 Other 2700 Form
Table 23: Document Type Code List The Code List was extended for the form code.
21 SPOCS WP5 deliverable D5.2 “SPOCS Pilot Requirements”, chapter 3.1.3 “Document templates”
80 D.3 Status Code
The Status Code is used in the Status Table defining the status of services or eServices. SPOCS WP4 defines a basic code list for status information. Table 22: Language Code ListTable 24 shows all status codes.
Code Name 001 Available / Open 002 In Preparation / Planned 003 Deprecated
Table 24: Status Code List
D.4 Profession Code
The Profession Code is used in the Profession table for classifying the profession on a semantic level. SPOCS is references the NACE Rev. 2 code provided by the European Commission (Eurostat).22
For the SPOCS identifier the NACE code can be referenced as follows: SPOCS:Profession:
Within the relational datamodel table “Profession”, attribute “NACE” the code is used only by the 4 digits number separated by “.” after the first two. Example (Real Estate Agencies): 68.31
SPOCS allows the reference to groups of professions. Recommendation is to use lowest possible level.
22 NACE Code Rev. 2 (2008) – Ramon: Eurostat’s Metadata Server - http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm? TargetUrl=LST_NOM_DTL&StrNom=NACE_REV2&StrLanguageCode=EN&IntPcKey=&StrLayoutCode= HIERARCHIC
81 SPOCS is not referencing to ISIC (Rev. 4) code or other national codes (some are more specific). Never the less these codes can be stored in the profession part of MIDB or national catalogues by referencing to the specific namespace. Equivalence can be defined by the equivalence table. Example (Real Estate Agencies): SPOCS:Profession:REA:DE.Destatis.WZ2008:L68.31 SPOCS:Profession:REA:UN.UNStats.ISIC:6820
D.5 Country Code
The Country Code is used for the SPOCS identifier naming scheme and all area based entities. SPOCS is using the ISO 3166 alphanumeric code with two digits. If country is not listed the alphanumeric three digit code can be used. Examples: DE, AT, GR SPOCS country coding can be detailed by using further codes (e.g. DE.BW). It is recommended to use NUTS classification as described in guidelines (e.g. DE1).23 Country code in the SPOCS identification scheme can also be detailed by Systems (e.g. GR.Ermis, DE.Leika, AT.Elkat).
D.6 Condition Code
The Condition Code is used for the preconditions of the MIDB entities. Feedback of the piloting phase has to show whether this has to be realized as texts or whether codes can be used for inferencing a procedure with pre and post conditions based on codes or relations.
Table 22: Language Code ListTable 25 shows all condition codes.
Code Name 001 No PreRequisites
Table 25: Condition Code List
23 NUTS: Nomenclature of Territorial Units for Statistics (NUTS): http://ec.europa.eu/eurostat/ramon
82 E. Appendix E – Obsoleted Parts of Deliverable D4.3
This section contains obsoleted texts of the deliverable D4.3. The texts are still in the appendix to show evolution of decisions on architecture and guidelines. The numbers are related to the headings in D4.3. The first paragraph gives a short explanation for making this part obsolete.
2 Load and Update MIDB - Transformation This section is obsolete as the focus for the WP4 interoperability framework focuses on the syndication part and the WP4 interoperability layer will not be further developed as far as there is a specific need by a piloting country.
This chapter concentrates on supporting the understanding of the usage of the Open Modules. Specific technical inline documentation and a technical overview is part of deliverable D4.4. The Open Modules and their functionality are already described in deliverable D4.2.
Member State A WP4 INTEROPERABILITY FRAMEWORK (WP4 IF) Member State B Use Case “Lookup full information” (5) Access Use Case “Search Core Information” module UM (6) (4) Provision Search module module PSC optional
Use Case “Load & update MIDB”
SC (2) Transformation (1) module MIDB
eSD (7) (3) Orchestration Syndication module Interface Use Case “Execute semi-automatic Use Case transaction” (optional) “Syndication” SPOCS optional,will initially NOT be available configuration
Legend internal connections WP4 Open Modules of WP 4 IF and within MSs are not shown Existing national infrastructure Integration Points (WP4 National Connectors)
Figure 12: Overview WP4 Open Modules (OMs), their Integration Points (WP4 NCs) and the Technical Use Cases they support [obsoleted]
83 As can be seen in Figure 12, the WP4 Interoperability Framework (WP4IF) supports the two mechanisms “Content Syndication” (WP1) and “Interoperability Layer” (WP4IL). Syndication is used for synchronizing the core information within the Meta Information Databases (MIDB). WP4IL is used for lookup of full information in foreign Service Catalogues (SC) and eService Directories (eSD). Both mechanisms support the cross-border objective of SPOCS. As a preparation for the MIDB, the PSCs or responsible organisations in the national infrastructure are loading the national core information about services and eServices including related information about process documents, professions and organizations to the MIDB. Uploading can be done through the Transformation Open Module. The module expects the input in the defined XML schema format as described in D4.2 and D4.4 and provides a Java interface. Transformation from national formats is handled by the National Connectors developed in WP5. An updated version of the Transformation Open Module can integrate common transformation mechanisms as described in D4.2, if piloting shows synergy effects. The sub chapters and are describing Transformation and Syndication Interface usage. D4.2 defines a two-step search scenario what is recommended using WP4IF. Therefore the PSC is searching first within the MIDB for core information and then makes a look-up at the foreign SC or eSD. Search Open Module interprets through the request flag “Full Info” whether it is a local (MIDB) search or a lookup in a foreign member state. Routing information is part of the header and if lookup includes a SPOCS identifier (recommended lookup) it can verify it by the local part of this identifier. Access is verified through the Access Open Module, triggered by the foreign Search Open Module receiving a foreign request. The Provision Open Module is providing the answers based on local or cross-border request. Details can be found in chapter . Configuration and routing is described in chapter . Manuals will be detailed during first piloting phase related to the needs of the users. 2.1 Load and Update MIDB - Transformation The scenario loading of core information to the MIDB includes three use cases to be considered. First the loading of new information, second the update of information and third the archiving of information. The member states are connecting their national SCs and eSDs through the National Connector (NC). The NC invokes the method of the Transformation Open Module. Parameter for this method is the data to be loaded, actually in the format of the defined XML scheme (see deliverable D4.4). Support of further formats will be assessed, as far as the work on the ontology and transformation rules is detailed. The method expects data of service or eService including related information like organizations. The input is extracted and transformed to the database objects. Furthermore the versioning information is set and records are updated related to the database objects. Changes are triggering a notification for the syndication. Information of the Transformation Open Module is related to the information from the national infrastructure, thus the origin level of the information is set to “National” (N). Some information like equivalence, routing and / or access need to be updated manually for the first phase of piloting.
84 The transformation functionality of the Transformation Open Module can be used in further scenarios, e.g. the provision of results. Transformation Open Module offers actually methods for transforming from XML based Java objects to database based objects and vice versa. The Transformation Open Module will be extended and updated related to the changes of the data model and functionality needed to support semantic approaches (see chapter Error: Reference source not found). 2.2 Syndication - Syndication Interface The Syndication Interface is connecting the MIDB with the Open Modules of WP1 to synchronize information in the decentral MIDBs. The Syndication Interface has two functionalities: First sending the information from MIDB to the WP1 Publisher Module and second receiving information from the WP1 Aggregation Module to the MIDB. The scenario is reading the information from the MIDB, transforming it to the RDF format needed in the syndication, based on the notification sent by changes. The information is given to the WP1 Publisher Module. Aggregation Modules retrieve information and send it to their Syndication Interface. This is extracting the content and transforming it from RDF to database objects, which are updating the MIDB. Syndication interface is supporting the retrieval of snapshots. Further information of syndication can be found in deliverable D1.4. 2.3 Search / Look-Up for Core and Full Information - Search, Access, Provision Search has two major options: searching for core information in the MIDB and lookup of full information through the WP4IL. Details are described in deliverable D4.2. Search is done through the national Points of Single Contact portal or solution. The National Connector is creating a service or eService request based on the search parameters. This request is given to the Search Open Module which is making a search in the MIDB (“FullInfo” false) or forwards the request to the foreign Search Open Module (“FullInfo” true). If search in MIDB is done, the Search OM will get the result in database objects and forward them to the Provision Module. This is creating the XML answer including the transformation. The answer message is forwarded to the National Connector. For full information lookup the request is forwarded to the foreign Search Open Module, which is sending the request to the responsible National Connector for making the lookup in the foreign directory. Before giving the request to the NC, the foreign Search Open Module is asking the Access Open Module to verify the user by the sent user credentials. Result is given in XML format from National Connector to the Provision Module, which is forwarding it to the home Provision Open Module. The home Provision Open Module is giving the answer message to the National Connector. The National Connector itself delivers the answer to the PSC portal or solution. It is recommended to use the two step search scenario as it is the efficient way doing first a research of relevant services and eServices and in a second step if necessary the lookup of full information.
85 2.4 Configuration Set and Internal Routing The Configuration Set is defined to be a central point in every national deployment storing configuration information, code lists and routing information. For the first piloting these information elements are stored in the MIDB to have a single place of information storage. Internal routing of the Open Modules is realised by a routing table, where every Open Module has a specific and unique identifier including a localized part (see chapter 4.1). The Open Modules can retrieve routing information through functions of the Transformation Open Module. The Open Modules are part of a Trust-service Status List to realise a minimum level of trust between them. They are especially integrated to avoid electronic attacks on the information architecture.
3.2.2 Usage of language property This section is obsolete as the XML schemes are updated and do not use the language tag anymore.
SPOCS WP4 is using a language property within a semantic defined tag as several XML schemes doing the same.24 For SPOCS the language property is assigned to all elements defined by TextType. The usage is optional, but strictly recommended to divide between multilingual descriptions. The default value is native, meaning the first official language from the information provider region. Information provision in XML format is not separating the textual part from the core information of an object. Thus an XML file can consist of the same set of semantic tags multiple times by setting the language property to the different language.
5.1 Components This section is not taken into the main body of the updated deliverable as the benefit is not clear enough. The basic requirements and recommendations for code lists are mentioned in section 3.2 and appendix D.
This chapter gives recommendations for the usage of code lists in SPOCS. At least the definition is oriented on the UNCEFACT model for creating XML structures as already described in chapter 3.1 for the SPOCS identifier scheme. Every code list should address the meta information for the scheme like name and ID as well as maintaining agency and location for scheme and data. The values should correspond to the primary codes. CodeName should refer to the corresponding name of the value. The guidelines will give information which code should be used (e.g. alpha 2 for ISO 3166). Mainly it is the one accepted widely. SPOCS is using external code lists as much as possible. Some codes are not standardized or aligned like the one for document types. For these cases SPOCS is defining code lists and if useful tries to standardize them. Standardization activities will start earliest by starting with the
24 W3C recommendation on Language tags in HTML and XML, W3C, http://www.w3.org/International/articles/language-tags/,
86 work on the semantic concept as it is necessary to include feedback from piloting and the member states. SPOCS is offering code lists in the MIDB or the configuration set to fulfil the objectives of SPOCS and PSCs. The MIDB offers a local partition where PSC can store further codes if this is necessary for their communication with the national infrastructure. SPOCS is not supporting this part. For the first phase SPOCS is realising the database scheme with direct relations. The upcoming solutions are uncoupling code lists and entities to decrease complexity of the schemes. From then the foreign keys and xml attributes will only address the value of the recommended code. SPOCS is using the following code lists with the mentioned recommendations: • Language – ISO 639-1 (e.g. “de”, “en”, “el”) • Country – ISO 3166 alpha 2 (“DE”, “GR”, “EU”) • Script – ISO 15924 (e.g. “Latn”, “Cyrl”) • Document Types – SPOCS (e.g. “1100” (Attestation), “1200” (License), “1500” (Certificate)) • Professions – NACE Rev. 2 (2008) (e.g. “41”, “68.31”, “79.11”) • Status – SPOCS (e.g. “001” (Available), “002” (Planned), “003” (Deprecated)) • Categories/Attributes – SPOCS (e.g. “1001” (ServiceID), “2204” (eService Name)) The code list for categories/attributes represents the specified attributes of the SPOCS common specification (see appendix C of deliverable D4.2). The code list is used for filtered / categorized retrieval of information. The code aligns to search in the specific column meaning for content within the selected records fulfilling the search parameter. National code lists can be used where national detailing is allowed, e.g. for the local part of the identifiers. Otherwise it is recommended using only codes that are already enlisted in the MIDB or configuration set. If there is a need for further alignment or update of codes a process will be defined within the work on sustainability and specific for WP4 on semantic concept.
87