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 NAMETYPEVOCABULARIES CARDINALITY
Top-Level Slots
SpecificationIdentifierStringValueTypeSDGR Application Profile1..1
IssueDateTimeDateTimeValueTypeSDGR Application Profile1..1
ProcedureInternationalStringValueTypeSDGR Application Profile0..1
PreviewLocationStringValueTypeSDGR Application Profile0..1
PossibilityForPreviewBooleanValueTypeSDGR Application Profile1..1
ExplicitRequestGivenBooleanValueTypeSDGR Application Profile1..1

Requirements

CollectionValueTypeCore Criterion and Core Evidence Vocabulary 0..1
EvidenceRequesterCollectionValueTypeCore Public Service Vocabulary Application Profile 1..1
EvidenceProviderAnyValueTypeCore Public Service Vocabulary Application Profile 1..1
EvidenceProviderClassificationValuesCollectionValueTypeSDGR Application Profile0..1
Query Slots
EvidenceRequestAnyValueTypeDCAT Application Profile1..1
LegalPersonAnyValueType

Core Business 

0..1 → Must contain either a Legal or a Natural Person but NOT both.
NaturalPersonAnyValueTypeCore Person 0..1 → Must contain either a Legal or a Natural Person but NOT both.
AuthorizedRepresentativeAnyValueTypeCore 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 AttributeValue / Structure
Query DefinitionDocumentQuery
Response Option AttributeLeafClassWithRepositoryItem
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: ResponseAvailableDateTime

OR

Failure: Error Response

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

 


  • No labels