Shapes for classification of nodes

[HolgerKnublauch]

The focus of SHACL so far has been on validating nodes so that when we know that a node is targeted by a shape we can confirm that it conforms to all the conditions laid out in the shape. This is similar to how OWL uses rdf:type and rdfs:subClassOf: If we know that someone is an instance of ex:AdultPerson we can restrict ex:age to >= 18.

However, the same validation could also be applied on untargeted nodes. This is similar to the "sufficient" conditions expressed using owl:equivalentClass, where OWL can express "if we know that some ex:Person is >= 18 years old, then we classify them as ex:AdultPerson".

In SHACL this would be useful not only to cover the same use cases (as an "inference") but also for user interfaces. For example, if we know that some Person also conforms to an ex:AdultPersonShape, the form could show additional input fields for properties that are only available to adults.

The following suggests to introduce some property sh:mayTargetClass (or other syntax) to indicate that instances of Person should be classified against AdultPersonShape.

ex:Person
    a sh:ShapeClass ;
    rdfs:subClassOf owl:Thing ;
    sh:property [
        sh:path ex:age ;
        sh:datatype xsd:integer ;
    ] .

ex:AdultPersonShape
    a sh:NodeShape ;
    sh:mayTargetClass ex:Person ;
    sh:property [
        sh:path ex:age ;
        sh:minInclusive 18 ;
        sh:minCount 1 ;
    ] ;
    sh:property [
        sh:path ex:votedFor ;
        sh:class ex:Party ;
    ] .

The key is that unlike targets, this means that only SOME of the Persons need to conform to the shape, but we want to indicate which nodes are candidates.

If a Person fulfills all constraints of AdultPersonShape, an engine could also "infer" a triple such as

ex:Bob sh:shape ex:AdultPersonShape

similar to how an OWL reasoner would infer extra rdf:type triples. In fact if the AdultPersonShape was also a class, it could infer an extra rdf:type triple just like OWL would.

There are many syntactic variations of this idea, above is just a first draft to start the discussion and capture the use case.

[nicholascar]

How about sh:targetConstrainedClass since what you're proposing would still apply only to instances of the targetClass, albeit declared or inferred ones, but not all of them, so there's a constraining on the targetClass, not really a loosening.

[HolgerKnublauch]

Possibly. It could also be something like sh:targetSomeInstancesOf, sh:targetSomeNodes, sh:targetSomeSubjectsOf, sh:targetSomeObjectsOf to mirror the existing target types.

It could also be solved completely differently, e.g. with a dedicated type or marker on the shape itself and then it would use its own intelligence to figure out which nodes to target in the graph (e.g. anything that has an ex:age in the first place).

Maybe sh:targetSome with a node expression would work:

ex:AdultPersonShape
    a sh:NodeShape ;
    sh:targetSome [ shnex:instancesOf ex:Person ] ;
    sh:property [
        sh:path ex:age ;
        sh:minInclusive 18 ;
        sh:minCount 1 ;
    ] ;

Many variations, and they are all reasonably easy to specify in a small section of the Core spec, without adding too much work, yet opening up many new use cases.

[tfrancart]

Necessary conditions can be expressed using sh:hasValue or sh:in on a specific path.
So maybe there is even no need fur such an additional property. An engine can figure it out for itself, if the node shape contains a property shape indicating its rdf:type is always Person with an sh:hasValue:

ex:AdultPersonShape
    a sh:NodeShape ;
   # All Adult persons necessarily have an rdf:type with the value of ex:Person
   sh:property [
     # this could be generalized to e.g. rdf:type/rdfs:subClassOf of course
     sh:path rdf:type ;
     sh:hasValue ex:Person ;
   ];
    sh:property [
        sh:path ex:age ;
        sh:minInclusive 18 ;
        sh:minCount 1 ;
    ] ;
    sh:property [
        sh:path ex:votedFor ;
        sh:class ex:Party ;
    ] .

This would open the possibility to generalize the approach to something else than rdf:type of course.

In a similar way as an OWL inference engine can classify classes based on their formal definitions, a SHACL engine maysvery well determine from the above description that, necessarily, all targets of ex:AdultPersonShape are also targets of ex:Person (note : but there are not really targets of ex:AdultPersonShape in this case this there is no target definition).

[tfrancart]

ex:Bob sh:shape ex:AdultPersonShape

This looks very similar to the need expressed in #326 with a discussion in #325 (comment)

[HolgerKnublauch]

@tfrancart that is what I meant with "it would use its own intelligence to figure out which nodes to target in the graph".

However, to me it still seems sensible to have some way of marking those shapes that may be used for classification purposes. Otherwise it becomes rather arbitrary, intransparent to the user what the engine will do, and depending on the implementation of how deeply it will understand the various patterns. With something like sh:targetSome we give quite "targeted" instructions to an engine and human reader of what is supposed to happen.

BTW instead of

ex:AdultPersonShape
    a sh:NodeShape ;
    # All Adult persons necessarily have an rdf:type with the value of ex:Person
    sh:property [
        # this could be generalized to e.g. rdf:type/rdfs:subClassOf of course
        sh:path rdf:type ;
        sh:hasValue ex:Person ;
    ];

we could write

ex:AdultPersonShape
    a sh:NodeShape ;
    # All Adult persons necessarily have an rdf:type with the value of ex:Person
    sh:class ex:Person ;

[nicholascar]

maybe there is even no need fur such an additional property. An engine can figure it out for itself

I was thinking this too, that there's no need for an engine to have the class indicated if the real targeting is based on predicates and values, but I do understand the need for documentation/obviousness.

Perhaps though, if the engines can implement the targeting without the class indicator - if it's optional - then people will simply not bother with indicating it in real use given the redundancy. Experienced shape makers might be lazy...

[HolgerKnublauch]

Without such indicators I believe we are putting too much pressure on implementers. With the class info, it's trivial: just loop over all instances and check if they conform or not. Also, easy to identify which shapes to validate when you have an existing instance.

[afs]

See #251 for using the word "inference" in the WG in a general sense.

[TallTed]

Nothing is as simple as it seems at first glance.

If we know that someone is an instance of ex:AdultPerson we can restrict ex:age to >= 18.

An emancipated minor (under 18) is legally considered an ex:AdultPerson in many jurisdictions, so ex:AdultPerson doesn't guarantee ex:age >= 18.

Examples like this are why data modeling remains a task that should be assigned to more experienced workers.

[afs]

it could infer an extra rdf:type triple just like OWL would.

If this - or any "infers"-like form such as sh:values - is making new (virtual) triples then do other constraints see the (virtual) triples? targets may change; constraints may become satisfiable.

Currently: Core:

During validation, the data graph and the shapes graph MUST remain immutable,
...
SHACL processing is thus idempotent.