SHACL Inference Rules - Use Case: Data Filtering

[robert-david]

This use case originates from a project about wood production and DPPs. Production data is processed in a distributed environment, and basically handed over from one part in the production chain to the next one. During this process, there needs to be a clear definition of which data has to be there, but also which data should not be handed over because of confidentiality reasons. This is basically a data filtering use case. Systems should be able to automatically filter out confidential data based on the declarative description in shapes. The following example data is anonymised because of project confidentiality reasons.

Data graph:

@prefix ex: <http://example.com/ns#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

ex:F1L1 a ex:Log, ex:RawMaterial .
  ex:F1L1 ex:label "F1L1" .
  ex:F1L1 ex:hasProvenance "forest" .
  ex:F1L1 ex:GPS_coordinate_lat "12.345678" .
  ex:F1L1 ex:GPS_coordinate_long "12.345678" .
  ex:F1L1 ex:trunc_diameter "67" .
  ex:F1L1 ex:wood_species "spruce" .
  ex:F1L1 ex:country "austria" .
  ex:F1L1 ex:customer "anonymous" .

  ex:F1L1 ex:isUsedToProduce ex:F1B1 .
  ex:F1L1 ex:refersToTransport <http://example.com/transport/58480> .

  ex:F1B1 a ex:Board, ex:Material .
  ex:F1B1 ex:label "F1L1B1" .
  ex:F1B1 ex:boardNo "1" .
  ex:F1B1 ex:assortment "Sawn Board" .
  
<http://example.com/transport/58480> a ex:Transport .
  <http://example.com/transport/58480> <http://example.com/loading_point_(GPS_lat)>
      "12.345678" .
  <http://example.com/transport/58480> <http://example.com/loading_point_(GPS_long)>
      "12.345678" .

Shapes graph:

@prefix ex: <http://example.com/ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

ex:MaterialFilterShape a sh:NodeShape ;
    sh:targetClass ex:RawMaterial ;
    sh:property [
        sh:path [ sh:alternativePath
            ( ex:customer ex:GPS_coordinate_lat ex:GPS_coordinate_long ) ] ;
        sh:maxCount 0 ;
    ] .

ex:TransportFilterShape a sh:NodeShape ;
    sh:targetClass ex:Transport ;
    sh:property [
        sh:path [ sh:alternativePath
         ( <http://example.com/loading_point_(GPS_lat)> <http://example.com/loading_point_(GPS_long)> ) ] ;
        sh:maxCount 0 ;
    ] .

[afs]

(Edited to put Turtle in " ```ttl " blocks.)

[ajnelson-nist]

There's an interesting response mechanism I see coming out of this. In some cases, a sh:ValidationReport could be consumed by another application to address the reported matters, such as a max count 0 violation on a sh:Literal-constrained property leading to cutting triples. Cutting triples linking sh:BlankNodeOrIRI-constrained properties would probably be harder.

[bergos]

I see two ways to implement this that fit well with the tools we already have or with planned features.

SHACL Rules
If we add rules similar to SHACL Rules as defined in SHACL Advanced Features, we could define a new rule type sh:MinusTripleRule that removes triples instead of adding them.

Coverage / Fragments
With the inversed logic of filters, shapes can be used to describe sub-graphs. shacl-engine and a fork of pySHACL support that feature. See my blog post for more details. You can try it yourself on the SHACL Playground

[ashleysommer]

This is an interesting use case, but I don't think it comes under the scope of SHACL Inferencing.

@bergos

we could define a new rule type sh:MinusTripleRule that removes triples instead of adding them

The SHACL spec states that a SHACL engine may not modify the input data-graph. To get around this, engines which implement SHACL Inference Rules typically emit the new triples into a separate Named Graph, to avoid polluting the input data-graph.

If there was a new MinusTripleRule, which graph would the triple be removed from?

@ajnelson-nist

a sh:ValidationReport could be consumed by another application to address the reported matters ... leading to cutting triples

This makes sense to me. It seems more like a job for a secondary application-specific script. It can check the ValidationReport to find any violating rules, and remove the offending triples.

[bergos]

@ashleysommer Two named graphs can be used - One for new triples and one for triples that should be deleted.