[{"breadcrumbs":"Operation and development of I14Y › Accounts to access I14Y","content":"Anyone who wants to enter data on I14Y needs a user account. The same applies to those who want to view information of their own organisation that has not (yet) been published publicly. Access is controlled with the Enterprise Identity and Access Management (EIAM). This service is operated by the Federal Office of Information Technology for the Confederation.\nTo access the internal area of I14Y, an account with a provider of a digital identification solution is required. The Federal Administration\u0026rsquo;s employees can use their Fedlogin. In addition, there are other options to choose from, such as the CH login, the electronic identities of Switch or those of cantons such as Berne, Schaffhausen, Zug and Geneva. Further details can be found in the Table of identification options in the appendix.\nProceed as follows:\nOn I14Y, click on the icon in the top right-hand corner. Select the appropriate identification provider. Log in to the digital identity provider or create a new account. Attention: Federal Administration employees must use the Fedlogin instead of the CH-Login, otherwise errors may arise. If the process suddenly stops, the cookies may have to be deleted. You can access the corresponding dialogue by pressing the key combination Ctrl-Shift-Delete in the web browser.\nIn a second step, the authorisations must be assigned on I14Y. Larger organisations manage their accounts themselves (see below). Therefore, please contact your account administrator. If you do not use an organisation-internal standard solution such as Fedlogin, let them know which email address you used when creating the login (see step 1). As soon as read or edit access rights have been granted, you will receive an email. This contains a web link and a code. Visit the specified website and enter the code that was sent to you. This will link your digital identity to I14Y.\nflowchart TD user(fa:fa-user-circle \\n The user creates a digital identity, e.g. a CH login. \\2-factor authentication is activated). account(fa:fa-user-plus \\ I14Y-Admin assigns the read and edit permissions.) code(fa:fa-file-text \\The user receives a code by email. \\This is necessary to link the identity to the I14Y account). i14y(fa:fa-database \\The user can now access the internal area of their own administrative unit on the I14Y Interoperability Platform). user--\u003eaccount account--\u003ecode code--\u003ei14y These set-up steps are necessary once only. If you want to change the details of your account later, visit the Account Management Area of EIAM.\nHow much does the account cost? I14Y is being developed and operated by the Confederation as part of the National Data Management programme. The development work as well as the operation are financed by the Confederation. In the medium term, the portal can be used free of charge \u0026ndash; including by content providers from cantonal and communal administrations and by state-related companies. Longer-term financing will be decided at a later stage. Account management in larger organisations Larger organisations are responsible for managing the accounts themselves. They provide the necessary human resources. Depending on the situation, the steps to open an account may vary.\nThe read and edit rights are usually assigned via the Delegated Management Portal. If you are responsible for managing the user accounts and do not yet have access to this portal, or if you would like to set up an automated onboarding process, contact the Interoperability Unit.\nTo open an individual user account, visit the Delegated Management Portal. In the \u0026ldquo;User Management\u0026rdquo; tab, select the item \u0026ldquo;Delegated Management\u0026rdquo;. Click on the arrow in front of \u0026ldquo;I14Y\u0026rdquo; and on the name of your organisation. Click on \u0026ldquo;Next\u0026rdquo; to open the detailed view with the list of authorised users. If your organisation does not yet exist, contact the Interoperability Office. Click on \u0026ldquo;Add new user\u0026rdquo;. The fields with the name and the email address must be filled in. Make sure that you use the email address with which the person to be saved has registered with the identity provider (such as CH-Login). Select the new person to be added. Click on \u0026ldquo;Next\u0026rdquo;. Now you will be prompted to assign the access authorisations. First adjust the profile. To do this, click on the pencil icon on the left. Replace the name with a meaningful description and replace the number with the profile ID you see at the start. Under \u0026ldquo;Profile name\u0026rdquo; it should say something like \u0026ldquo;LocalDataSteward-1159123\u0026rdquo;. Enter the character * in the input field below. Click on \u0026ldquo;Save\u0026rdquo;. Select the appropriate role under \u0026ldquo;Business roles\u0026rdquo;. As a rule \u0026ldquo;StewardshipOrganizationViewer\u0026rdquo; (read-only access),\u0026ldquo;Submitter\u0026rdquo; (rights to collect metadata, but not to publish) or \u0026ldquo;LocalDatasteward\u0026rdquo; is selected there. Add the corresponding edit and read rights to the profile by clicking on the \u0026ldquo;Authorise\u0026rdquo; button. Finally, click on \u0026ldquo;Next\u0026rdquo;. Caution: Only one role should be assigned to each profile. However, it is possible to open several profiles for one account. To do so, click on the corresponding link. In this case, the person concerned must select which profile he or she wants to log in with when logging in. Briefly describe the new account. Finally, click on \u0026ldquo;Send notification email\u0026rdquo; to send the onboarding message to the person concerned. In the message, the person is asked to click on a link and enter a code sent with the message into a web form. This assigns the necessary read and edit permissions to the digital identity. At any time, on the overview of the Delegated Management Portal, you can see which persons have successfully completed the onboarding. ","description":"","keywords":"I14Y, I14Y interoperability platform, user account, account, connection, EIAM, Login","title":"Accounts to access I14Y","url":"/handbook/en/platform/accounts/"},{"breadcrumbs":"Changelog › Next release","content":"The next release of I14Y is planned for the evening of 6 May 2026. It includes the changes and enhancements described below. I14Y partner organisations with the appropriate access can test the updated software immediately on the I14Y acceptance environment. Please contact the Interoperability Unit if you do not yet have access to this environment, which is used for software testing.\nPlease note that the release date may be postponed at short notice if problems arise. Individual features may also be removed from the release and only activated at a later point in time. If you have any questions or issues related to this release, please contact the Interoperability Unit (i14y@bfs.admin.ch).\nEditing structures in the user interface: Classes, attributes and associations of a data structure can now be edited directly in the user interface. All properties displayed in the sidebar are editable. When editing an attribute, it is also possible to search for a concept and link to a specific version.\nSystem metadata in the Partner API: All objects now include a \u0026ldquo;system\u0026rdquo; section in the JSON responses of the Partner API. It contains the creation date (createdAt), the date of the last modification (modifiedAt) and the creation type (creationType). The latter indicates whether an object was created manually via a browser token (Manual) or automatically via an M2M token (Automated).\nMultiple identifiers for concepts and public services: Concepts and public services can now carry multiple identifiers. For this purpose, the identifiers property has been introduced as an array. To avoid disrupting existing integrations, the previous identifier field will continue to be returned for the time being; both fields appear in API responses at the same time. Note: the identifier field (singular) will be removed in a future release. Scripts that use this field when creating objects will need to be updated in time.\nCreate a new version of a mapping table: It is now possible to create a new version from an existing mapping table.\nCatalog search via the Partner API: The endpoint for catalog search is now also available via the Partner API. The search supports various parameters such as query term and language.\nExtended editing rights for submitters: Submitters can now edit objects with the registration status \u0026ldquo;Initial\u0026rdquo; or \u0026ldquo;Candidate\u0026rdquo;, even if they are already publicly published. The condition is that they must not have been locked beforehand.\nDistributions on the dataset detail page: Distributions belonging to a dataset are now displayed directly on the dataset description page.\nExport of codelists without annotations: Codelists can now optionally be exported without annotations; the supported formats are JSON and CSV.\nTechnical updates as well as minor improvements and bug fixes\n","description":"","keywords":"I14Y, Interoperability platform I14Y, IOP, Changelog, Releases, Versions, Software development","title":"Next release","url":"/handbook/en/changelog/next-release/"},{"breadcrumbs":"Gouvernance and Roles › Roles","content":"Some users of the I14Y interoperability platform want to retrieve entries only. Others collect metadata. Others validate the information and make it publicly available. In order to regulate access rights and editing competences, the Confederation\u0026rsquo;s role-based model for data management is used on I14Y. Among others, the following roles are distinguished:\nData owners (data owners) make decisions on the content and the purpose of a data set. They commission it and they are responsible for it. Data stewards (data stewards) are responsible for the technical aspects of data maintenance. They coordinate the work on standardisation and harmonisation of the data sets. This role exists both within the organisation (local data steward) and on a national level (Swiss data steward) or in a specialist area (e.g., data steward statistics). Data custodians (data custodians) are responsible for technical tasks, such as database support. Data consumers (data consumers) retrieve and process data. Those who want to access only public data on I14Y do not need to log in. However, in order to view non-public entries of one\u0026rsquo;s own organisation or to save, edit, validate and publish metadata, an account with the appropriate rights is needed. The corresponding access rights are usually assigned by the organisation\u0026rsquo;s internal account administrators when the account is created (see under account administration).\nThe table below shows which tasks can be undertaken in which role. There are two levels: that of the organisation concerned \u0026ndash; for example, a federal office, a canton or a commune \u0026ndash; and the highest national level. In practice, in smaller organisations it is possible for one person to take on several of these roles. In large organisations, several people often share the work in question.\nRoles Authorisations Data Consumers The I14Y interoperability platform can be visited without a user account. Users who are not logged in can only see the publicly published metadata. Furthermore, no metadata can be saved without a login. Registered and logged-in users can see the non-public entries of their own organisation in addition to the publicly published metadata. They can only read them, but not edit or publish them. Stewardship Organization Viewer The Organizational Viewer sees the internal metadata of their own organisation in addition to the publicly published metadata. However, they cannot edit it. Submitter The submitters save the metadata on behalf of the Local Data Stewards. They cannot validate and activate the entries themselves. They see the publicly published metadata as well as the contents of their own organisation. Local Data Steward The local data stewards in the individual organisations ensure that the information is as complete as possible. They also check whether formal criteria have been met and they work towards harmonising and standardising data sets. If the information on I14Y is correct, they publish the metadata. If an entry is to be publicly listed and labelled as compliant with the standard, the local data stewards pass the metadata on to the Interoperability Office for validation. Interoperability Office The Interoperability Office (IOS), the I14Y team based at the Federal Statistical Office, coordinates data standardisation and harmonisation throughout Switzerland. It develops tools, ensures the coordination of standardisation and harmonisation tasks between the participating organisations, and supports the local data stewards in modelling the metadata. The staff of the interoperability unit must confirm whether a data offer on the I14Y interoperability platform is to be marked as standard-compliant. Swiss Data Steward In its role as Swiss Data Steward, the Federal Statistical Office coordinates Switzerland-wide standardisation and harmonisation work on administrative data from public administrations. ","description":"","keywords":"I14Y, I14Y interoperability platform, interoperability, role-based model, Data Steward, Data Stewardship, Data Owner, Data Consumer","title":"Roles","url":"/handbook/en/gouvernance/roles/"},{"breadcrumbs":"Introduction › Handbook","content":"This manual explains the main features of the I14Y interoperability platform. It contains numerous step-by-step instructions. It also provides technical details and background information on data harmonisation and standardisation.\nThe first chapter highlights the Roles and Processes in data management. The chapter Retrieve Metadata describes how to obtain information from the I14Y interoperability platform. The following chapter Publishing metadata explains how to publish descriptions of data sets, electronic interfaces and data elements on the platform. It also shows how the directory of government services is compiled.\nThe handbook also contains a Glossary with technical terms, a list with web links, an overview of the partner organisations as well as a Log of the most important changes that have been made to the platform.\nThe functionalities of I14Y are constantly being developed. This manual is also revised on a regular basis. Do you have any suggestions on how it could be improved? Or would you like to share your experiences with the manual or the platform? Write to us. This manual is revised on the Code Management Platform Github. You are welcome to submit a pull request with your change requests there.\nHow to submit a pull request The I14Y manual is written in a markup language. The software Hugo converts the text data into a website. The contents of this manual are maintained on the code management platform Github. Suggestions for changes can be documented and submitted there. This can be done using the standard Git workflow, or otherwise directly in your web browser.\nCreate an account on the code management platform Github. Log in. Open the manual repository. The text contents are located in the content directory, sorted by language, chapter and subchapter. Files with the extension .md contain the actual text contents and the graphics. Search for the text part to be revised. Display the raw text. Click on the pencil icon in the top right-hand corner. Make the necessary changes. Pay attention to the Markup Syntax Rules. Briefly describe the modification in the box below and then click on the button to submit. Your suggestion will be reviewed by the I14Y team and, if appropriate, will be incorporated into the manual. ","description":"","keywords":"I14Y, I14Y interoperability platform, IOP, introduction, interoperability, multiple use, Switzerland, user manual, manual, handbook","title":"Handbook","url":"/handbook/en/introduction/handbook/"},{"breadcrumbs":"Operation and development of I14Y › Support","content":"Sometimes things don\u0026rsquo;t work out as expected. If you experience any issues when working with I14Y, please proceed as follows:\nConsult the manual: The manual documents the most important functions of the platform. And it contains answers to most common questions. If information is missing, the interoperability office would be grateful for a note. You are also welcome to add the relevant sections yourself and submit a pull request on Github.\nSupport level 1: If you cannot solve the problem with the help of the manual, contact the I14Y support of your own organisation. Usually, I14Y partners provide their own support organisation. This can solve simpler problems. If you belong to an organisation with its own I14Y support, problems must first be reported to the internal support department.\nSupport Level 2: The second point of contact is the Interoperability Centre. It can be reached on working days by email at i14y@bfs.admin.ch; a ticketing system is to be implemented in a later phase. The Interoperability Body processes non-time-critical enquiries to the best of its ability within the scope of the organisational, financial, personnel and technical resources available to it (best effort). Time-critical enquiries are handled under the point process for serious technical faults.\nSupport level 3: Enquiries and problems with a technical focus that cannot be answered or solved by the interoperability office are sent to the Federal Office of Information Technology, Systems and Telecommunication (FOITT). These messages must be sent by the interoperability office. The interoperability office coordinates the work required to restore normal operations.\nProcess for serious technical faults A serious technical fault is an incident that severely restricts normal work on the platform for an unreasonably long period of time or even makes it impossible. If a serious technical fault appears to be occurring, the users affected report to the technical support of their organisation. If, in their opinion, it is a serious fault, they report the problem to the interoperability unit.\nThe Interoperability Unit will assess whether the technical fault is serious. If it classifies the incident as serious, it will provide an initial assessment of the problem within one working day. It will also indicate how the fault is to be rectified. The interoperability unit ensures appropriate communication with the management of the organisations affected by the disruption, provided that the basic IT systems are working. The email address provided by the organisation is used for this purpose.\n","description":"","keywords":"I14Y, I14Y Interoperability Platform, Metadata Catalogue, Software as a Service, SaaS, Support, Technical Help, Problems, Bug","title":"Support","url":"/handbook/en/platform/support/"},{"breadcrumbs":"Gouvernance and Roles › Work process","content":"A clearly defined work process governs how metadata is published on I14Y. Depending on whether the metadata are published publicly or only within the organisation, the work process has two or three stages. The work process is designed to ensure quality. Firstly, the metadata are saved. Secondly, they are checked and published by_Local Data Stewards_. Thirdly, , if desired and appropriate, they are checked in cooperation with the Interoperability Office, marked as standard-compliant if necessary and finally released to the public.\nflowchart LR A(initial) B(candidate) C(registered) D(qualified) E(standard) F(superseded) G(retired) A--\u003eB B--\u003eC C-.-\u003eD C-.-\u003eE D-.-\u003eE E-.-\u003eF E-.-\u003eG Newly saved metadata are initially given the status Initial. As soon as the documenting work is completed, the status Candidate is proposed. This change of status must be confirmed by a person from the own organisation with Local Data Steward-rights. If all checks are successful, the entry can be changed to Registered. To keep the metadata stable and consistent, entries with this status cannot be modified. If a concept is to be modified again, a new version must be created.\nFor data sets, services and concepts that are not standardised and only used internally, the documenting work ends there.\nIn a second step, the Local Data Stewards check whether the data offer is standard-compliant. Offers that comply with a standard adopted by a board such as eCH or ISO, receive the status Standard. Those ones that could become a standard are marked as Qualified; the following procedure is then determined in exchange with the interoperability office and in specialist groups. Data offers based on an obsolete or abolished standard are given the status Superseded or Retired. If the data are only visible to the users of one\u0026rsquo;s own organisation, these classifications can be applied by the Local Data Stewards without consulting the Interoperability Office. If an entry marked as \u0026ldquo;standard\u0026rdquo; is to be published publicly, the Interoperability Office must be consulted.\nFurther information on status management and responsibilities is compiled in the following table. The status concept used in the I14Y interoperability platform is in accordance with ISO standard 11179.\nStatus DE Status EN Description Who assigns the status? Initial Initial Newly saved metadata are initially given the status Initial. This makes it visible to the users of their own organisation that the work on these metadata has not yet been completed. Data Producer Candidate Candidate Entries that are completely documented are marked with the status candidate. The status is proposed by the persons who enter the data. It is assigned by the data stewards. Local Data Steward Recorded Recorded Metadata with the status Recorded have been saved and checked. The status is proposed by those who have saved the metadata. The change is confirmed by the local data stewardship unit. This is the final status for non-standard data elements. Local Data Steward Qualified Qualified Offers that could one day become a standard are marked as Qualified. Local Data Steward bzw. Interoperability Office Standard Standard This status is awarded if the offer complies with a standard adopted by a specialist body such as eCH or ISO. Local Data Steward or Interoperability Office Preferred Standard Preferred Standard In individual cases, there may be several standards for one topic. A Preferred Standard is a concept that must be used in public administration, provided that there are no important reasons not to do so. The definition of a preferred standard is the responsibility of the Swiss Data Steward. Swiss Data Steward Superseded Superseded If the offer is based on a standard that has since been superseded by another, the status is set to Superseded. Local Data Steward or Interoperability Office Retired Retired In individual cases it may happen that the standardisation organisation withdraws a standard. In such a case, the status of the offer concerned is set to Retired. Local Data Steward or Interoperability Office Publication channel There are two publication channels on I14Y. Metadata can be made available within one\u0026rsquo;s own organisation \u0026ndash; for example, to inventory one\u0026rsquo;s own data holdings. Otherwise, they can be published publicly. Initially, the metadata collected are only available within the organisation. If they are to be made visible to the public, the publication channel is changed to I14Y. This is desirable for harmonised and standardised data structures and concepts. This is because they are suitable for further use.\nAs a rule, public publication is proposed by a person with the role of Local Data Steward. The Interoperability Office, the I14Y team, then checks the metadata. It releases the entry on the jointly agreed publication date.\nDepending on the status in the publication workflow and on one\u0026rsquo;s own role, the saved metadata cannot be changed. For example, entries marked as \u0026ldquo;Registered\u0026rdquo; cannot be edited without the status being reset. In this case, a new version is normally created.\n","description":"","keywords":"I14Y, I14Y interoperability platform, work process, workflow, status, publication channel","title":"Work process","url":"/handbook/en/gouvernance/workflow/"},{"breadcrumbs":"Gouvernance and Roles › Information model","content":"On the I14Y Interoperability Platform, data sets, electronic interfaces (APIs) and data elements as well as government services can be described. There are two entry points. In the catalogue part, data sets, electronic interfaces (APIs) and government services are managed. The descriptions of individual concepts can be found under \u0026ldquo;Concepts\u0026rdquo;.\nflowchart TD catalog(catalogue) publicservice(government service) dataservice(electronic interfaces) dataset(data sets) distribution(distribution) concept(concept) catalog---|contains|publicservice catalog---|contains|dataservice catalog---|contains|dataset dataset---|has a|distribution dataset---|referenced \\nvia structure/ data element|concept dataservice---|delivers data to|dataset style catalog fill:#Ff987a style catalog stroke:black style concept fill:#Ff987a style concept stroke:black style publicservice fill:#6CC8FF style publicservice stroke:black style dataservice fill:#6CC8FF style dataservice stroke:black style dataset fill:#6CC8FF style dataset stroke:black style distribution fill:#6CC8FF style distribution stroke:black The diagram provides a simplified representation of the different parts of I14Y. A detailed summary can be found in the Information model on I14Y.\nTo do justice to the different offers, the platform uses various information models. For example, the Data Catalogue Vocabulary (DCAT) with the Swiss application profile is used for data sets and APIs. The Core Public Service Vocabulary (CPSV) is used for government services.\nData set A data set is a group of data elements with related content in a uniform structure. It can exist in a wide variety of forms and formats: for example, as a CSV file, as a database or stored in a distributed system such as a blockchain.\nA data set can be exported in several formats, i.e., contain so-called distributions. The distributions do not necessarily have to contain the full data. The data set can also form the basis for an electronic interface (API) through which specific individual information can be queried.\nData sets can be described in detail on I14Y: in addition to the catalogue entry, which contains the basic information such as the title, the description and the issuing organisation, information on the structure can also be saved. A structure usually contains several data elements, and each data element has a concept that describes the type of content. A concept is thus the smallest unit of a data set, often also called a (defined) variable or attribute.\nflowchart TD dataset1(data set) structure1(structure) dataelement1(data element) concept1(concept) codelist(code list) numeric(number) string(string) date(date) dataset1---|has a|structure1 structure1---|contains a|dataelement1 dataelement1---|has a|concept1 concept1---|is a|codelist concept1---|is a|numeric concept1---|is a|string concept1---|is a|date style dataset1 fill:#6CC8FF style dataset1 stroke:black style structure1 fill:#Bfe2ab style structure1 stroke:black style dataelement1 fill:#Fbb54e style dataelement1 stroke:black style concept1 fill:#Ff8076 style concept1 stroke:black style codelist stroke:#Ff8076 style numeric stroke:#Ff8076 style string stroke:#Ff8076 style date stroke:#Ff8076 It is possible that several data sets have the same structure. The individual concepts, in turn, are often integrated into different structures.\nflowchart TD dataset1(data set 1) dataset2(data set 2) dataset3(data set 3) structure1(structure 1) structure2(structure 2) dataelement11(data element 1) dataelement12(data element 2) dataelement13(data element 3) dataelement21(data element 1) dataelement22(data element 2) dataelement23(data element 3) concept1(concept 1) concept2(concept 2) concept3(concept 3) concept4(concept 4) dataset1---structure1 structure1---dataelement11 structure1---dataelement12 structure1---dataelement13 dataset2---structure2 dataset3---structure2 structure2---dataelement21 structure2---dataelement22 structure2---dataelement23 dataelement11---concept1 dataelement12---concept2 dataelement13---concept2 dataelement21---concept2 dataelement22---concept3 dataelement23---concept4 style dataset1 fill:#6CC8FF style dataset1 stroke:black style dataset2 fill:#6CC8FF style dataset2 stroke:black style dataset3 fill:#6CC8FF style dataset3 stroke:black style structure1 fill:#Bfe2ab style structure1 stroke:black style structure2 fill:#Bfe2ab style structure2 stroke:black style concept1 fill:#Ff8076 style concept1 stroke:black style concept2 fill:#Ff8076 style concept2 stroke:black style concept3 fill:#Ff8076 style concept3 stroke:black style concept4 fill:#Ff8076 style concept4 stroke:black style dataelement11 fill:#Fbb54e style dataelement11 stroke:black style dataelement12 fill:#Fbb54e style dataelement12 stroke:black style dataelement13 fill:#Fbb54e style dataelement13 stroke:black style dataelement21 fill:#Fbb54e style dataelement21 stroke:black style dataelement22 fill:#Fbb54e style dataelement22 stroke:black style dataelement23 fill:#Fbb54e style dataelement23 stroke:black For example: the data set of a veterinary clinic contains information on dogs \u0026ndash; name, date of birth, breed, dog chip number and the name and address of the dog owner. Each of these pieces of information is a data element with a concept. The type of concept for the name of the dog is a string, for the date of birth it is a date and for the breed it is a code list. These concepts can also be used in other data sets: thematically closely related ones such as a veterinarian\u0026rsquo;s client database, or \u0026ndash; in the case of the date of birth \u0026ndash; also in completely different data sets.\nflowchart TD dataset1(data set \\veterinary clinic 1) dataset2(data set \\veterinary clinic 2) dataset3(data set \\veterinary clinic 3) structure1(admission form dog) structure2(admission form bird) dataelement11(dog breed) dataelement12(coat colour) dataelement13(gender) dataelement21(gender) dataelement22(plumage colour) dataelement23(bird breed) concept1(dog breed \\string) concept2(colour \\ code list) concept3(gender \\code list) concept4(bird breed \\string) dataset1---structure1 structure1---dataelement11 structure1---dataelement12 structure1---dataelement13 dataset2---structure2 dataset3---structure2 structure2---dataelement21 structure2---dataelement22 structure2---dataelement23 dataelement11---concept1 dataelement12---concept2 dataelement13---concept3 dataelement21---concept3 dataelement22---concept2 dataelement23---concept4 style dataset1 fill:#6CC8FF style dataset1 stroke:black style dataset2 fill:#6CC8FF style dataset2 stroke:black style dataset3 fill:#6CC8FF style dataset3 stroke:black style structure1 fill:#Bfe2ab style structure1 stroke:black style structure2 fill:#Bfe2ab style structure2 stroke:black style concept1 fill:#Ff8076 style concept1 stroke:black style concept2 fill:#Ff8076 style concept2 stroke:black style concept3 fill:#Ff8076 style concept3 stroke:black style concept4 fill:#Ff8076 style concept4 stroke:black style dataelement11 fill:#Fbb54e style dataelement11 stroke:black style dataelement12 fill:#Fbb54e style dataelement12 stroke:black style dataelement13 fill:#Fbb54e style dataelement13 stroke:black style dataelement21 fill:#Fbb54e style dataelement21 stroke:black style dataelement22 fill:#Fbb54e style dataelement22 stroke:black style dataelement23 fill:#Fbb54e style dataelement23 stroke:black Data sets are described in I14Y using the Data Catalogue Vocabulary (DCAT). DCAT is a standardised model for describing data catalogues, maintained by the Internet Standards Board W3C. The application profile for Switzerland is largely used on the platform (DCAT-AP CH 2). DCAT specifies which information must be saved. In addition, the vocabulary suggests further possibilities for describing the data set.\nTo store information about a data set on I14Y, the minimum requirements set by the DCAT standard must be met. I14Y offers some additional fields that go beyond the current DCAT standard. Which fields are filled with which information when entering data sets is listed in the chapter publication.\nStructure The structure describes how the contents of a data set are organised. Each structure consists of at least one data element (see below). The individual structures can be used in several data sets. For example, the identical structure is usually used in a recurring publication of a register (version).\nFor the description of the structure, the DCAT standard with the Swiss application profile is largely used for I14Y.\nData element The data element is the smallest descriptive unit of a data collection. Often the data element is also called an attribute, a (defined) variable or \u0026ldquo;column\u0026rdquo;. The data element contains the individual values, such as the OASI numbers, the number of vacant flats or measured water temperature values. Each data element references a concept.\nConcept The concept uniquely and completely describes the information contained in the data element. A concept can be a number, a string, a date or a code list with predefined values.\nThe standard ISO 11179-1:2023 is used to describe the concepts in I14Y. The type of concept is documented. Dependent upon this, further details such as the length or the possible minimum and maximum values are necessary. Step-by-step instructions for documenting a concept can be found in the chapter publication.\nElectronic interface (API) An Application Program Interface (API)_ \u0026ndash; allows machines, among other things, to specifically request individual pieces of information from a set of data. Thanks to APIs, isolated systems can exchange information in an efficient and standardised way. In order for developers to be able to programme their software to obtain information from external systems, they need to know these interfaces. I14Y offers the possibility to describe the interfaces in a central location.\nOn I14Y, in addition to the title and description, a so-called endpoint from where data can be obtained or a link to the documentation must be given. If possible, reference is also made to the data set upon which the API is based.\nAPIs are also thoroughly described on I14Y using the data catalogue vocabulary DCAT. It is imperative that some fields that are optional in the standard must be filled in. Thus, the DCAT standard recommends that only a description is documented when an API is catalogued. On I14Y this information is mandatory. All fields specified in the standard must also be filled in on the platform.\nA step-by-step guide on how to create electronic interfaces is given in the chapter publication.\nE-government service E-government services can also be described on the I14Y interoperability platform. The web or mobile applications that simplify certain tasks are thus documented. Information is also documented on how the app in question can be accessed and which organisation is responsible for it. Thanks to the central directory, e-government services should be easier to find.\nThe Core Public Service Vocabulary defined by the European Union is used to describe public services. The structure and the entire vocabulary are available on the European Commission\u0026rsquo;s Interoperability Platform Join up. The reusable and expandable vocabulary specifies certain fields that must be filled in. Each government service can be assigned to a channel \u0026ndash; an internet address, for example, or a telephone number.\nOn I14Y, the chapter publication describes in detail how a government service is documented.\n","description":"","keywords":"I14Y, I14Y interoperability platform, Data model, information model, catalogue, DCAT, structure, concept","title":"Information model","url":"/handbook/en/gouvernance/informationmodel/"},{"breadcrumbs":"Operation and development of I14Y › Road map","content":"The I14Y Interoperability Platform is being developed on the Confederation’s behalf by the Federal Statistical Office (FSO) in collaboration with the Federal Office of Information Technology, Systems and Telecommunication (FOITT). The project phase runs until the end of 2026. After that, the FSO will take over the operation of I14Y.\nDuring the project phase, the platform’s functionality is continuously expanded. Requests for new features can be submitted to the Interoperability Office. It then prepares the detailed specification, prioritises development requests together with the Steering Committee and the National Data Management Committee (NaDB), and coordinates development and implementation work.\nYour suggestions are welcome If you discover an opportunity for improvement or a bug on the I14Y Interoperability Platform, the Interoperability Service would appreciate a note. You can submit proposals for new features in the Feature Requests repository on GitHub or via email. Please describe the requested functionality as precisely as possible. On GitHub, proposals can also be commented on. I14Y is developed in a so‑called Agile Release Train (ART). Features are continuously specified, developed and implemented. The roadmap below documents which features are planned for which development period; for details on individual functionalities, please contact the Interoperability Office. Priorities may change, for example if new functionalities are given high priority. The roadmap is updated before the start of each new development period (Program Increment, PI). The next stages are described in more detail, while later phases are formulated as more general goals.\ntimeline title Roadmap Interoperability Platform I14Y section 2026 Q1 2026 (01.2026 - 03.2026) : ⭐ Introduce mapping tables to document differences between concepts. : URIs/permalinks will be introduced for all objects. : Complex data set structures can be edited via the web interface (part 1/2). : Additional work on structures – reuse of concepts (part 1/2). Q2 2026 (03.2026 - 06.2026) : Complex data set structures can be edited via the web interface (part 2/2). : Reuse of concepts (part 2/2). : Release of the programme code (open-source publication). : Introduction of audit metadata (minimal audit trail). : Improve the user experience. : Joint developments with metadata.swiss. Q3–Q4 2026 (06.2026 - 12.2026) : Maintenance work (bug fixes and small improvements). : Completion of the project phase. : Joint developments with metadata.swiss. section 2027 Q1–Q4 2027 : Operational phase ⭐ Entries marked with a star are suggestions from the DVS BS+ project.\nOpen Source The programme code of the I14Y Interoperability Platform is to be published under a free licence. The Interoperability Office will publish the source code by the end of the project phase at the latest, i.e. by the end of 2026. This is in line with the Federal Act on the Use of Electronic Means to Conduct the Tasks of the Authorities (EMBAG). According to Article 9, federal authorities should — where possible — make their source codes freely available.\nLegal basis Art. 9 Open Source Software The federal authorities subject to this Act shall, if it is possible and reasonable and if the rights of third parties are respected, disclose the source code of software which they develop or have developed for the performance of their tasks. They shall allow any person to use, develop and pass on the software and shall not charge any licence fees. Federal Act on the Use of Electronic Means to Conduct the Tasks of the Authorities (EMBAG) I14Y publishes source code and scripts under the name i14y-ch on the GitHub platform.\n","description":"","keywords":"I14Y, I14Y interoperability platform, system architecture, technology, database","title":"Road map","url":"/handbook/en/platform/roadmap/"},{"breadcrumbs":"Operation and development of I14Y › Migration to the Public Cloud","content":"I14Y is moving to the Public Cloud. Using the Public Cloud simplifies numerous technical processes, enabling faster and more flexible development. Additionally, operating costs can be reduced, allowing I14Y to remain attractive in the long term.\nThis webpage provides updates on the status of the migration work.\nMigration Status The migration to the Public Cloud was completed on Thursday, November 27, at 5:30 PM.\nStep Status Note Migration STG ✅ The staging environment is now running in the Public Cloud. Read-only PROD ✅ The production environment has been set to read-only mode. Currently, no metadata can be entered or edited. Migration data PROD ✅ The data has been migrated. Migration software PROD ✅ I14Y is now in the Public Cloud. Activate write permissions PROD ✅ The platform can be used normally again. Planned Schedule Monday, 17.11.2025: The internet address for the staging environment will be updated. Once the internet directories are updated, the staging environment will be delivered from the Public Cloud.\nFrom Tuesday, 18.11.2025: The staging environment will now run in the Public Cloud and can be tested, provided the necessary access is available. Issues should be reported to i14y@bfs.admin.ch.\nWednesday, 26.11.2025: The read-only mode will be activated for the production environment. The metadata from the previous platform will be synchronized with the new installation. The internet address for the production environment will be updated. Once the internet directories are updated, the staging environment will be delivered from the Public Cloud.\nThursday, 27.11.2025: I14Y will be available again with its usual functionalities \u0026ndash; including the ability to publish metadata.\n","description":"","keywords":"I14Y, I14Y interoperability platform, user account, account, connection, EIAM, Login, Migration, Public Cloud, Azure","title":"Migration to the Public Cloud","url":"/handbook/en/platform/migration/"},{"breadcrumbs":"Gouvernance and Roles › The right platform for every application","content":"There are several metadata catalogues in Switzerland. These differ in function and thus in the areas of application. The platform operators aim to coordinate their development work with each other.\nI14Y Interoperability Platform The I14Y Interoperability Platform publicly describes data offers that are suitable for multiple use. In addition, the platform can be used to create an inventory of one\u0026rsquo;s own data holdings and data elements in the internal area. All concepts published publicly on I14Y can be reused \u0026ndash; regardless of whether the actual data is freely accessible. The content can also be retrieved automatically. This makes the platform a central tool for the harmonisation and standardisation of data. The platform is operated on the Confederation\u0026rsquo;s behalf by the Federal Statistical Office\u0026rsquo;s Interoperability Office.\nopendata.swiss The catalogue opendata.swiss, operated by the Open Government Data Office at the Federal Statistical Office, describes only open government data, i.e. data that can be used by anyone. The Swiss Confederation, as well as many cantons and some cities and communes, are committed to making their data available to the public, as much as possible, as so-called Open Government Data.\nMost of the offers published on opendata.swiss are aggregated data. The original data may often not be published for data protection reasons. The platform therefore proposes distributions of a data set intended for the public in advance.\nThe opendata.swiss catalogue can be searched directly from I14Y via the metasearch.\nLINDAS Only linked data is available via the Linked Data Service of the Swiss Federal Archives. These are not stored in a conventional database. Instead, the data are given unique identifiers and linked to each other. A special query language, Sparql, is used to search and retrieve the data.\nLinked Data is mainly used by IT professionals to build automated data processing operations. Some of the data offers published on LINDAS are also described on I14Y. Trials are currently underway to link the two platforms more closely.\nGeocat The platform Geocat.ch, which is operated by the Federal Office of Topography (swisstopo), describes data sets and electronic interfaces with a geographical reference. Geocat can also be searched directly from I14Y via a metasearch.\n","description":"","keywords":"I14Y, I14Y Interoperability Platform, Meta data, Meta data catalog, Lindas, Opendata, opendata.swiss, Geocat","title":"The right platform for every application","url":"/handbook/en/gouvernance/platforms/"}]