Contents

1. Overview

The Semantic Repository is a central service that provides commonly agreed semantic specifications for the exchange of evidences. It includes specifications composed of definitions of data elements, data types and names, associated with specific evidence types. Existing technical specifications and the work done in the past years in the framework of large-scale projects, ISA² Programme, SEMIC and Publication Office serve as a solid base for the development of the Semantic Repository. The goal is to ensure mutual understanding of the Evidence exchanged cross-border through the OOTS between evidence providers, evidence requesters and users.

This specification describes a minimum subset for Semantic Repository covering short-term requirements for OOTS EB, DSD and eID. Some artifacts will be described within this working group while others will be developed in collaboration with other subgroups or taken over from different standard bodies. The SR will also include a Workflow description to formalize the development of new data models and a Storage description to show the structure of the assets.

2. Requirements

The Semantic Repository Requirements are derived from Implementing Act, SDGR Regulation, OOTS TDDs, Common Services implementation team and other OOTS Subgroups developments. Thus, the following functional and non-functional requirements were identified: 

Functional Requirements

• Asset Creation and Management (Schemas, Rules, Codelists, URIs)
• Description of shared assets (Procedures, Requirements, EvidenceTypes, Conformance Profiles)
• HTTP resolvability of assets
• Distribution and reuse of shared assets (Procedures, Requirements, EvidenceTypes, Conformance Profiles)
• Enable cross-referencing of information entities (e.g. procedures-requirements) 
• Distributed maintenance from OOTS and MS teams (depending on the asset)
• Support the development of components (EB, DSD) and transactions (Queries & LCM)
• Version control and release management
• Automated publishing
• Accompany associated assets (visualizations, stylesheets).

Non-functional (High Level Requirements)

• Reuse
• Interoperability
• Uniqueness
• Usability
• Extensibility
• Human readability
• Non-collision
• Efficiency.

3. Semantic Repository Structure

The Semantic Repository assets will be used by OOTS services. The figure below shows the assets and the services that use them.

The Semantic Repository comprises several types of assets:

• Codelists will ensure the automated processing of evidences:
  • Reused codelists (EAS, NUTS, Standardization of Data Models for the OOTS, etc) 
  • OOTS specific defined codes by OOTS team
  • Codes agreed upon and defined by Member States.
• Exchange Data Model Assets used for the evidence exchange:
  • Schema Definitions (XML, XSD)
    • XML samples for Evidence Request, Response, EB, DSD, LCM.
    • XSD schemas for RegRep v4, XML and SDG XSD which was developed specifically for OOTS
  • Rules
    • Business Rules which describe the OOTS transactions.
    • Schematrons for validating the business rules defined for Evidence Request/Response, EB, DSD and LCM.
• URIs used both as identifiers and locators for the assets
• Workflow formalizes the development of new Data Models for OOTS
• Storage reflects the location where the assets are stored and the tree structure.

4. Identifier Types

For the description of the assets in the Semantic Repository URIs (Uniform Resource Identifiers, RFC 3986) and UUIDs(RFC 4122) will be used. URIs are preferred because of their widespread use for resource identification and also because the URI class provides methods for building URIs from their parts, as well as for splitting URIs into their parts. Also, they serve as canonical identifiers that can be used in the OOTS data structures and resolve to the OOTS Git repository. UUIDs can be created as an RFC4122 v4(random) UUID or name-based(usually from a URI).

5. Evidence Broker and DSD Semantic Assets

It covers five classes of assets for OOTS and the functionality will be completed in collaboration with other subgroups. The following table illustrates the Evidence Broker and Data Service Directory semantic assets used in the OOTS Evidence Exchange:

Further assets for the Semantic Repository will be provided by the:

• Subgroup on the Standardization of Data Models for the OOTS 
• Evidence Mapping sub-group 
• Testing and Deployment sub-group 
• EC Common Services
• Member States.

6. Data Interaction Flow

The following figure describes the interaction flow of the identified data assets within the OOTS evidence exchange.

7. Workflow and versioning

The SR  include a workflow description to formalize the development of new data models and a storage description to designate the location and structure of assets.

When requesting a Proof of birth the user will access a procedure, for example „Requesting proof of registration of birth”. This procedure needs to have a unique identifier (e.g. https://sr.oots.tech.europa.eu/codelist/procedures/t1) shared among MS to ensure the retrieval of the correct Evidence. In order to add a new Procedure in the Semantic Repository the first step is to create a definition which includes assigning an identifier. Then, the OOTS Team publishes the Procedure in the Semantic Repository and it can be used in OOTS specific use cases.

The  Requirement for this procedure, „Proof of birth”, needs to have a common agreed identifier shared among MS (e.g.

https://sr.oots.tech.europa.eu/requirements/98466f2f-1694-4d95-9f28-cb25e0aa4f5d) 

SR Workflow enables Member States, providing evidence, to add a new Requirement and Evidence Types for it. At the same time, it is necessary to define a mapping between the Requirement and the list of Evidence Types that prove the requirement added. These Evidence Types MUST be registered in the codelist of Evidence Type Classifications, published in the Semantic Repository.

Also an assets versioning management sub-section will be developed shortly.

8. Storage

The assets are stored on GitLab code.europa.eu repository in OOTS-EDM folder. For codelists representation Oasis Code List Representation(Genericode) V1.0 is used.

• OOTS-EDM
  • Codelists
    • External
      • BinaryObjectMimeCode-2.3.gc
      • CountryIdentificationCode-2.3.gc
      • EAS.gc
      • LanguageCode-2.3.gc
      • NutsCodes.gc
    • OOTS
      • AgentClassification-CodeList.gc
      • DSDErrorCodes-CodeList.gc
      • EBErrorCodes-CodeList.gc
      • EDMErrorCodes-CodeList.gc
      • ErrorSeverity-CodeList.gc
      • Gender-CodeList.gc
      • IdentifierSchemes-CodeList.gc
      • JurisdictionLevel-CodeList.gc
      • LAU-CodeList.gc
      • LCMErrorCodes-CodeList.gc
      • LevelsOfAssurance-CodeList.gc
      • OOTSMediaTypes-CodeList.gc
      • Procedures-CodeList.gc
    • CodeLists-OOTS v05.xlsx
  • Schematrons
  • Business Rules
  • XML
    • DSD
    • EB
    • LCM
    • Request-Response Samples
  • XSD
    • Regrep4
    • SDG
    • XML

9. Maintenance of the assets

The maintenance of the assets will be achieved by taking into consideration their source.  For example, the codelists provided by the Publication Office will be maintained by the Publication Office. Other assets will be maintained according to the OOTS Governance depending on their nature.