Contents
1. Overview
The Exchange Data Model makes use of the functional capabilities that are provided by the RegRep V4 Query Protocol. In the following section, we describe the query that is supported by the OOTS.
2. Common Query Attributes
2.1. Common Query Attributes
The following table depicts the attributes that are common between all the types of requests and are expressed as Top-Level Slots and specific Query Slots of the RegRep Information Model.
| SLOT NAME | TYPE | VOCABULARIES | CARDINALITY |
|---|---|---|---|
| Top-Level Slots | |||
| SpecificationIdentifier | StringValueType | SDGR Application Profile | 1..1 |
| IssueDateTime | DateTimeValueType | SDGR Application Profile | 1..1 |
| Procedure | InternationalStringValueType | SDGR Application Profile | 0..1 |
| PreviewLocation | StringValueType | SDGR Application Profile | 0..1 |
| PossibilityForPreview | BooleanValueType | SDGR Application Profile | 1..1 |
| ExplicitRequestGiven | BooleanValueType | SDGR Application Profile | 1..1 |
Requirements | CollectionValueType | Core Criterion and Core Evidence Vocabulary | 0..1 |
| EvidenceRequester | CollectionValueType | Core Public Service Vocabulary Application Profile | 1..1 |
| EvidenceProvider | AnyValueType | Core Public Service Vocabulary Application Profile | 1..1 |
| EvidenceProviderClassificationValues | CollectionValueType | SDGR Application Profile | 0..1 |
| Query Slots | |||
| EvidenceRequest | AnyValueType | DCAT Application Profile | 1..1 |
| LegalPerson | AnyValueType | 0..1 → Must contain either a Legal or a Natural Person but NOT both. | |
| NaturalPerson | AnyValueType | Core Person | 0..1 → Must contain either a Legal or a Natural Person but NOT both. |
| AuthorizedRepresentative | AnyValueType | Core Person | 0..1 |
2.2. Evidence Request Subject
The Evidence Subject is either a Natural Person or a Legal Person. The Query Slots contain the required information to identify the Evidence Subject.
A Query Request may either contain a NaturalPerson OR a LegalPerson depending on the subject of the query, but NOT both. An additional Authorized Representative may be specified.
In order to describe the Natural Person and the Legal Representative, the eGovernment Core Person Vocabulary is used. For the Legal Person, the eGovernment Core Business Vocabulary is used. The vocabularies are maintained by Interoperable Europe which succeeds the ISA2 action.
The Document-Based Query defines a structure for requesting unstructured or structured pieces of evidence that will be used in a specific procedure. The Query Response contains the evidence and evidence metadata with a reference to the document itself.
3. Document Query
3.1. Document Query attributes and Process Model
The Evidence Exchange is always based on a document query. The ER requests for the evidence document and its metadata to be provided in the response. The table below shows the query attributes and their value/structure.
| Query Attribute | Value / Structure |
|---|---|
| Query Definition | DocumentQuery |
| Response Option Attribute | LeafClassWithRepositoryItem |
| Request Parameters | Elements to identify the Evidence Type issued by a Data Service like identifer, evidence type and title. Distribution attributes of the document, like the format, transformation or conformance profile. Optional EvidenceProviderClassificationValues that help the evidence provider to identify the evidence or data service. |
| Response Values | Success: Evidence Metadata and attached Evidence document indicated though a RepositoryItemRef OR Unavailable: ResponseAvailableDataTime OR Failure: Error Response |
The following process model provides an overview of the One Step Document-Based Query. The process model depicts the specific query attributes of a Document Query as transaction notes. These attributes are required to formulate a valid query for the desired query type. The common query attributes are not illustrated in the process model but the next section provides a brief overview.
3.2. Query Request
The ER needs to provide an Evidence Request that contains several evidence-related request parameters. The details contain the following attributes which act as a filtering mechanism to the EP:
- The Identifier of the Data Service Evidence Type received from the Data Service Directory
- The Evidence Type Classification and Title of the evidence received from the Evidence Broker and/or Data Service Directory
- The Format and Conformance Profile of the selected Distribution retrieved from the Data Service Directory.
- A desired Transformation of the Evidence described in the Semantic Repository.
- Optional Classification Values indicated in the Data Service Directory for the EP that help the EP to identify the evidence or data service.
The response option attribute 'returnType' is set to "LeafClassWithRepositoryItem" in order to explicitly state that the requested document MUST be inside Query Response from the EP.
The Evidence Request is expressed along the Evidence Request Syntax Mapping.
3.3. Query Responses
The Query Response can be either an Evidence Response or an Error Response whereas the status of the Evidence Response can be success of unavailable.
Success: The Evidence Response is sent after a successful validation of the request received and it contains the Evidence Metadata of the attached Evidence together with the Evidence documents themselves. The status of the Evidence Response is set to 'Success'. The Evidence Response with the status 'success' is specified along the Evidence Response Syntax Mapping. The Evidence Metadata described in the Evidence Request is expressed using DCAT Application Profile.
Unavailable: In situations where evidences may exist that are not immediately available, a Data Service may notify the user and start a process to make these evidences available at a later point in time in the Evidence Response. The status of the Evidence Response is set to 'Unavailable'. The status may be used by a Data Service that generates evidences using a process that cannot be completed within the duration of an interactive user session. Based on this response, the Online Procedure Portal has an obligation to inform the user accordingly. It is up to the user to decide whether to proceed with the procedure without the unavailable evidences, or to stop (or, if supported by the Online Procedure Portal, pause) the procedure and re-start (or, if supported, continue) it at a later point in time and re-request the evidences at that later time. This mechanism is opt-in for Data Services. A Data Service that supports the mechanism may, optionally, indicate at which date and time any evidences may be made available, helping the user decide whether and when to return to the Online Procedure Portal and continue the procedure. The Evidence Response with the status 'unavailble' is specified along the Evidence Response Syntax Mapping.
Failure: The Error Response contains the exception raised by the EP. The exception can be either a handled one, which means that the ER SHOULD retry the submission of the Evidence Request fulfilling the requirements present in the exception or an unhandled one which the ER must accept and inform the user of the unsuccessful transaction. The Query Model caters for both handled and unhandled exceptions. A typical example for a managable exception is the need for an Evidence Provider side preview which is declared in the Error response. The Error Request is expressed along the Error Response Syntax Mapping.