Closed Certiman closed 3 months ago
We can provide for full NoBo verification reports with this ontology extension, NoBos can now go in detail to the TSI-requirements they have checked off.
Further, the same extension can then finally document also the Section 2.3 of a vehicle type, treating special sections in the TSI which were complied with.
Observation
We have the following data in ERATV:
The 4.x strings in fact represent sections within the vp:Requirement. As recommended in Dublin Core, the sections should be made explicit via a Controlled Vocabulary (SKOS CS).
Proposal
vp:sections
with domainvp:Requirement
and range a SKOS CS containing the sections as Concepts.vp:DocumentedEvidence
:vp:checked
with range: new Classvp:Compliance
vp:Compliance
has:vp:checkedSection
with range the same SKOS Concept Scheme as above;vp:compliant
with rangexsd:boolean
, stating whether the section was checked as compliant or not.vp:withRestriction
with rangevp:Restriction
to indicate exactly what requirement caused the mentioned restriction.vp:Scope
|vp:Case
is "compliant or not", a new ObjectPropertyvp:supportedBy
for both is required, which has range vp:DocumentedEvidence. See example.This would allow:
vp:Requirement
in a controlled voc.vp:closes
would be refined by thevp:compliant
detailed check.Example
The
era:VehicleType
above is avp:Scope
belonging toera:AuthorisationCase
. The dataset /ERALEX already contains the instance for the mentioned TSI and could refer to a SKOS CS containing all of its sections:The compliance on a certain VT can now be expressed by using
vp:supportedBy
andvp:checked
, but in the example of ERATV, by using an artificial bridging propertyera:subScope
as follows:If compliance results are reused many times, the blankNode representing the
vp:DocumentedEvidence
could become a NamedNode, as such: