Evidence of roadworthiness

Abstract

Evidence of roadworthiness is a simplified data model describing an evidence regarding the vehicle's roadworthiness. It draws upon the specifications of Annex II, of Council Directive 2014/45/EU.

Terminology

An Application Profile (AP) is a specification that reuses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.

A Core Vocabulary (CV) is a basic, reusable and extensible data specification that captures the fundamental characteristics of an entity in a context-neutral fashion. Its main objective is to provide terms to be reused in the broadest possible context. More information can be found on the SEMIC Style Guide.

This specification uses the following prefixes to shorten the URIs for readability.

Prefix	Namespace IRI
`auto-vc`	`https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/`
`cv`	`http://data.europa.eu/m8g/`
`dct`	`http://purl.org/dc/terms/`
`legal`	`http://www.w3.org/ns/legal#`
`rdf`	`http://www.w3.org/1999/02/22-rdf-syntax-ns#`
`rdfs`	`http://www.w3.org/2000/01/rdf-schema#`
`sdg`	`http://data.europa.eu/p4s/`
`skos`	`http://www.w3.org/2004/02/skos/core#`
`xsd`	`http://www.w3.org/2001/XMLSchema#`

	Property	Range	Card	Definition	Usage
	is about	Road Vehicle	1	Entity that is the subject in the provided Evidence.
	requires	Check	1	A related resource that is required by the described resource to support its function, delivery, or coherence.

Supportive Entities

The supportive entities are supporting the main entities in the Application Profile. They are included in the Application Profile because they form the range of properties.

Attribute

Definition: The optional property that provides additional descriptive information about a concept.
Properties: This specification does not impose any additional requirements to properties for this entity.

Attribute Set

Definition: The collection of attributes grouped to provide additional descriptive information about a concept.
Properties: For this entity the following properties are defined: has attribute .

	Property	Range	Card	Definition	Usage
	has attribute	Attribute	1..*	The optional property that provides additional descriptive information.

Check

Definition: A mandatory or optional technical inspection, e.g. the MOT, a vendor-specific certification of used cars, etc.
Properties: For this entity the following properties are defined: date of expiry roadworthiness test , date of roadworthiness test , has attribute set , odometer reading at the time of the check , place of roadworthiness test , publisher .

Property	Range	Card	Definition	Usage
date of expiry roadworthiness test	Date Time	0..1	The end of the validity of the inspection.
date of roadworthiness test	Date Time	0..1	The beginning of the validity of the inspection.	This is typically the day of the inspection.
has attribute set	Attribute Set	0..1	Relates a concept to the AttributeSet that provides its additional descriptive information.
odometer reading at the time of the check	non Negative Integer	0..1	The total distance travelled by the particular vehicle since its initial production, as read from its odometer at the time of the check.
place of roadworthiness test	Code	0..1	Code of the country where the check was recorded.
publisher	Legal Entity	0..*	The entity responsible for making the item available.

Evidence

Definition: Proof that a Requirement is met.
Usage Note: The Evidence class is defined in the Core Criterion and Core Evidence Vocabulary (CCCEV). Although the wording of the definition is different, the semantics are an exact match for CPSV's Input class which it replaces. Evidence can be any resource - document, artefact - anything needed for executing the Public Service. In the context of Public Services, Evidence is usually administrative documents or completed application forms. A specific Public Service may require the presence of certain Evidence or combinations of Evidence in order to be delivered. In some cases, the Output of one service will be Evidence for another service. Such relationships should be described in the associated Rule(s).
Properties: This specification does not impose any additional requirements to properties for this entity.

Legal Entity

Definition: A self-employed person, company, or organization that has legal rights and obligations.
Properties: For this entity the following properties are defined: legal name .

	Property	Range	Card	Definition	Usage
	legal name	Text	0..*	The name under which the Legal Entity is legally registered.

OOTS Evidence

Definition: Proof exchanged through OOTS that a requirement is met.
Subclass of
: Evidence
Properties: For this entity the following properties are defined: has attribute set .

	Property	Range	Card	Definition	Usage
	has attribute set	Attribute Set	0..1	Relates a concept to the AttributeSet that provides its additional descriptive information.

Road Vehicle

Definition: Land vehicle other than a railway vehicle.
Properties: For this entity the following properties are defined: country symbol of the State of registration , has attribute set , registration plate number , vehicle category , vehicle identification number .

Property	Range	Card	Definition	Usage
country symbol of the State of registration	Code	0..1	The country code of State of registration.	The recommended code list is the Unece code list
has attribute set	Attribute Set	0..1	Relates a concept to the AttributeSet that provides its additional descriptive information.
registration plate number	String	0..1	A vehicle registration number.
vehicle category	Code	0..1	A type of vehicle.
vehicle identification number	String	0..1	The Vehicle Identification Number (VIN) is a unique serial number used by the automotive industry to identify individual motor vehicles.

	Class	Definition
	Code	An idea or notion; a unit of thought.
	Date Time	dateTime values may be viewed as objects with integer-valued year, month, day, hour and minute properties, a decimal-valued second property, and a boolean timezoned property.
	non Negative Integer	nonNegativeInteger is derived from integer by setting the value of minInclusive to be 0.
	String	The string datatype represents character strings in XML.
	Text	The text data type is a combination of a string and a language identifier.

Examples

Example Evidence of roadworthiness

Usage Guidelines

Support for implementation

The following section provides support for implementing the Evidence of roadworthiness.

JSON-LD context file

One common technical question is the format in which the data is being exchanged. For conformance with the Evidence of roadworthiness, it is not mandatory that this happens in a RDF serialisation, but the exchanged format SHOULD be unambiguously be transformable into RDF. For the format JSON, a popular format to exchange data between systems, SEMIC provides a JSON-LD context file. JSON-LD is a W3C Recommendation [[[json-ld11]]] that provides a standard approach to interpret JSON structures as RDF. The provided JSON-LD context file can be used by implementers. This JSON-LD context is not normative, i.e. other JSON-LD contexts are allowed.

The JSON-LD context file is downloadable here.

Validation

SHACL

To verify if the data is (technically) conformant to the Evidence of roadworthiness, the exchanged data can be validated using the provided SHACL shapes. SHACL is a W3C Recommendation to express constraints on a RDF knowledge graph.

To support the check whether or not a catalogue satisfies the expressed constraints in this Application Profile, the constraints in this specification are expressed using SHACL [[shacl]]. Each constraint in this specification that could be converted into a SHACL expression has been included. As such this collection of SHACL expressions that can be used to build a validation check for data.

It is up to the implementers to define the validation they expect. Each implementation happens within a context, and that context is beyond the SHACL expressions here.

The shapes can be found here.

RDF representation

The RDF representation of the Evidence of roadworthiness is available here.

UML representation

The UML representation from which the Evidence of roadworthiness has been built is available here.

XML schema representation

The XML schema representation from which the Evidence of roadworthiness has been build is available here.

The XML schema is based on the OOTS requirements and it allows some flexibility to include fields that Member States can add in addition to those foreseen in the OOTS requirements.

The XML schema is based on 3 parts:

The subject part, to indicate the Person subject of the evidence
The event/status part, to indicate the data about the event related to the subject
Optional additional part, to add optional fields (attributes) for the evidence type, such as issuing date or issuing authority

All the parts with their respective attributes are optional (min cardinality set to 0).

The XML schema is based on the SEMIC Core Criterion and Core Evidence (CCCEV) specification, and on the Core Business vocabulary. An EvidenceOfRoadworthiness is then an OOTSEvidenceType (based on CCCEV Evidence) by having the 3 parts:

cv:isAbout referring to the subject of the Evidence with an sdg:AttributeSet, that it means that is possible to add additional fields to the subject.
dct:requires, defined by the OOTSCheckType including different properties as foreseen in OOTS requirements) and sdg:AttributeSet
sdg:AttributeSet, that can contain many attributes, where the name, language and type fields could be defined for each attribute

The design of the XML schema is based on the Garden Of Eden Pattern where complex types and elements are defined globals so they can be reused.

Restrictions on the presence of fields and on their values are delegated to schematron file, that can vary per XML consumer and could be provided by XML providers, such as those on code list. OOTS provides certain code list in Genericode format that can be used via schematron. Additional code lists could be taken from the Publications Office Authority Tables.

Governance

Versioning governance

All specifications produced in SEMIC will follow the versioning rule described by the SEMIC Style Guide rule PC-R3. In case a SEMIC asset is deprecated the asset will remain available through its PURI.

The serialisation will have:

a dct:isReplacedBy referencing the new assets used instead and
an adms:status indicating its deprecated status.

Governance requirements for re-used assets

In order to adhere to the SEMIC Style Guide rule GC-R2 a specification should have quality and governance standards for the assets that are being reused.

In order for an asset to be considered for reuse within a SEMIC specification it can be requested by a community member or it requires to adhere to the following requirements:

The asset is part of a recommendation by a major standards body or an EU institution.
The asset is actively being maintained.

After being taken into consideration the asset will be validated in three steps:

Syntax validation will be performed on the relevant artefacts.
Constraint validation will be performed on the relevant artefacts.
The PURI will be validated.

Once considered and validated an asset can be adopted if it is approved by the community.

Lexicalisation rules

In order to adhere to the SEMIC Style Guide rule SC-R3 a specification requires formal lexicalisation rules. The Style Guide proposes two options either by using RDFS or SKOS lexicalisation.

SEMIC uses and will use the RDFS lexicalisation for all of its specifications. More specifically:

rdfs:label is used to provide a human-readable version of a resource's name.
The usage of certain resource can be clarified in a skos:usageNote.

Mapping

This section offers a condensed tabular overview of the requirements mapping from OOTS to EUCARIS.

Information requirement	EUCARIS Xpath	Note
Vehicle Identification Number (VIN number or chassis number)	/xs:schema/xs:complexType[@name="AVIVehicleTechnicalDataType"]/xs:sequence[1]/xs:element[@name="VehicleIdentificationNumber"]
registration plate number of the vehicle	/xs:schema/xs:complexType[@name="AVIVehicleRegistrationDataType"]/xs:sequence[1]/xs:element[@name="VehRegistrationNumber"]
vehicle category (if available)	/xs:schema/xs:complexType[@name="AVIVehicleTechnicalDataType"]/xs:sequence[1]/xs:element[@name="VehicleCategoryCode"]
country symbol of the State of registration	/xs:schema/xs:complexType[@name="AVIVehicleMileageDataType"]/xs:sequence[1]/xs:element[@name="MileageRecordings"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="MileageRecording"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="MileageRecordingCountryCode"]
date of roadworthiness test	/xs:schema/xs:complexType[@name="AVIVehicleRegistrationDataType"]/xs:sequence[1]/xs:element[@name="VehRoadworthiness"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="VehRoadworthinessTestDate"]
odometer reading at the time of the roadworthiness test (if available)	/xs:schema/xs:complexType[@name="AVIVehicleMileageDataType"]/xs:sequence[1]/xs:element[@name="MileageRecordings"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="MileageRecording"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="Mileage"]
identified deficiencies and their level of severity	/xs:schema/xs:complexType[@name="AVIVehicleRegistrationDataType"]/xs:sequence[1]/xs:element[@name="Remarks"]	"Remarks" could contain the information, but does not necessarily contain multiple string fields.
result of the roadworthiness test	NA	Not present in EUCARIS
date of the next roadworthiness test or date of expiry of the current roadworthiness certificate (if this information is not provided by other means)	/xs:schema/xs:complexType[@name="AVIVehicleRegistrationDataType"]/xs:sequence[1]/xs:element[@name="VehRoadworthiness"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="VehRoadworthinessTestEndDate"]
name of roadworthiness testing organisation/centre	/xs:schema/xs:complexType[@name="AVIVehicleMileageDataType"]/xs:sequence[1]/xs:element[@name="MileageRecordings"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="MileageRecording"]/xs:complexType[1]/xs:sequence[1]/xs:element[@name="MileageRecordingOrganisation"]
signature/ identification of the inspector responsible for the roadworthiness test	/xs:schema/xs:complexType[@name="SigningAuthorityGroup"]/xs:sequence[1]/xs:element[@name="NameOfSigner"]

Quick Reference of Classes and Properties

This section provides a condensed tabular overview of the mentioned classes and properties in this specification. The properties are indicated as mandatory, recommended, optional and deprecated. These terms have the following meaning.

Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property.
Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide the information for that property if it is available.
Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property but is not obliged to do so.
Deprecated property: a receiver SHOULD be able to process information about instances of that property; a sender SHOULD NOT provide the information about instances of that property.

Class	Class IRI	Property	Property IRI
Attribute	http://data.europa.eu/p4s/Attribute
Attribute Set	http://data.europa.eu/p4s/AttributeSet	has attribute	http://data.europa.eu/p4s/hasAttribute
Check	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/Check	date of expiry roadworthiness test	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/validThrough
Check	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/Check	date of roadworthiness test	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/validFrom
Check	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/Check	has attribute set	http://data.europa.eu/p4s/hasAttributeSet
Check	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/Check	odometer reading at the time of the check	http://data.europa.eu/p4s/odometerReading
Check	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/Check	place of roadworthiness test	http://data.europa.eu/p4s/placeRoadworthinessTest
Check	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/Check	publisher	http://purl.org/dc/terms/publisher
Evidence	http://data.europa.eu/m8g/Evidence
Evidence of roadworthiness	http://data.europa.eu/p4s/EvidenceOfRoadworthiness	is about	http://purl.org/dc/terms/subject
Evidence of roadworthiness	http://data.europa.eu/p4s/EvidenceOfRoadworthiness	requires	http://purl.org/dc/terms/requires
Legal Entity	http://www.w3.org/ns/legal#LegalEntity	legal name	http://www.w3.org/ns/legal#legalName
OOTS Evidence	http://data.europa.eu/p4s/OOTSEvidence	has attribute set	http://data.europa.eu/p4s/hasAttributeSet
Road Vehicle	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/RoadVehicle	country symbol of the State of registration	http://data.europa.eu/p4s/countrySymbolStateRegistration
Road Vehicle	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/RoadVehicle	has attribute set	http://data.europa.eu/p4s/hasAttributeSet
Road Vehicle	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/RoadVehicle	registration plate number	http://data.europa.eu/p4s/registrationPlateNumber
Road Vehicle	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/RoadVehicle	vehicle category	http://data.europa.eu/p4s/vehicleCategory
Road Vehicle	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/RoadVehicle	vehicle identification number	https://spec.edmcouncil.org/auto/ontology/VC/VehicleCore/vehicleIdentificationNumber

Abstract

Introduction

Status

License

Terminology

Overview

Main Entities