gatemezing / Ontology_Workflow_Testing

Verified Permissions ontology
Apache License 2.0
1 stars 0 forks source link

Detailing vp:Requirement's Compliance #13

Closed Certiman closed 3 months ago

Certiman commented 3 months ago

Observation

We have the following data in ERATV:

CCS TSI (Regulation (EU) N° 2016/919) - Sections not complied with :
4.2. Functional and technical specifications of the subsystems
4.2.1. Control-Command and Signalling safety characteristics relevant to interoperability
4.2.2. On-board ERTMS/ETCS functionality
4.2.5.2. Eurobalise communication with the train
4.2.5.3. Euroloop communication with the train
4.2.6. On-Board Interfaces Internal to Control-Command and Signalling
4.2.7. Track-side Interfaces Internal to Control-Command and Signalling
4.2.7.2. RBC/RBC
4.2.12. ERTMS/ETCS DMI (Driver Machine Interface)
4.2.13. GSM-R DMI (Driver-Machine Interface)
4.3. Functional and technical specifications of the interfaces to other Subsystems

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

  1. Provide sections to Requirements: add a new ObjectProperty vp:sections with domain vp:Requirement and range a SKOS CS containing the sections as Concepts.
  2. To document the compliance in the vp:DocumentedEvidence:
    • provide a new ObjectProperty vp:checked with range: new Class vp:Compliance
    • this new Class vp:Compliance has:
      • a new ObjectProperty vp:checkedSection with range the same SKOS Concept Scheme as above;
      • a new DatatypeProperty vp:compliant with range xsd:boolean, stating whether the section was checked as compliant or not.
      • reuse the ObjectProperty vp:withRestriction with range vp:Restriction to indicate exactly what requirement caused the mentioned restriction.
  3. In order to explain how a vp:Scope | vp:Case is "compliant or not", a new ObjectProperty vp:supportedBy for both is required, which has range vp:DocumentedEvidence. See example.

This would allow:

Example

The era:VehicleType above is a vp:Scope belonging to era:AuthorisationCase. The dataset /ERALEX already contains the instance for the mentioned TSI and could refer to a SKOS CS containing all of its sections:

@prefix eralex-skos: <http://data.europa.eu/949/concepts/eralex-sections/> # SKOS CS for sections in all TSI's
@ prefix eralex: <http://data.europa.eu/949/legislation/eralex#>

eralex:reg-2016-919 a vp:Requirement ;
                                  vp:section  eralex-skos:reg-2016-919 ; # the sections for this TSI

The compliance on a certain VT can now be expressed by using vp:supportedBy and vp:checked, but in the example of ERATV, by using an artificial bridging property era:subScope as follows:

era:vtype-T a era:VehicleType , vp:Scope ;
              hasSetOfParameters [ 
                      a era:SubsetWithCommonCharacteristics ; 
                      era:parameter [INF],[ENE],[CCS] ; # In what configuration is the Evidence submitted for
                      era:subScope [
                              a vp:Scope
                              vp:supportedBy [
                                      a vp:DocumentedEvidence ;
                                      vp:checked [
                                               a vp:Compliance ;
                                               vp:checkedSection <era:SKOS Concept of Section 4.2 of TSI 2016-919> ;
                                               vp:compliance "false"^^xsd:boolean ;
                                      ] , [ ... ]
                              ]
                       ]
              ]

If compliance results are reused many times, the blankNode representing the vp:DocumentedEvidence could become a NamedNode, as such:

era:vtype-T a era:VehicleType , vp:Scope ;
              hasSetOfParameters [ 
                      a era:SubsetWithCommonCharacteristics ; 
                      era:parameter [INF],[ENE],[CCS] ; # In what configuration is the Evidence submitted for
                      era:subScope [
                              a vp:Scope
                              vp:supportedBy era:evidence-XYZ ;
                       ]
              ], ... reuse here.

era:evidence-XYZ  a vp:DocumentedEvidence ;
                  vp:checked [
                                a vp:Compliance ;
                                vp:checkedSection <era:SKOS Concept of Section 4.2 of TSI 2016-919> ;
                                vp:compliance "false"^^xsd:boolean ;
                  ] , [ ... ]
             ... 
Certiman commented 3 months ago

Reuse

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.