Add something similar to dash:hasValueWithClass

[HolgerKnublauch]

OWL has this owl:someValuesFrom construct that is quite popular to declare relationships between classes. To express this in SHACL, one would need to create a verbose qualifiedValueShape with minCount 1 and a sh:class in an inner node shape.

I suggest to add something like dash:hasValueWithClass to SHACL Core.

[HolgerKnublauch]

More general might be sh:hasValueWithShape [ sh:class X ] for QCR with qualified min count of 1.

But I'd be happy to withdraw this issue if there is not enough interest. We want to keep SHACL Core focused.

[ajnelson-nist]

This is one of the points where I think SHACL and OWL do not overlap philosophically, and I don't think SHACL can provide a good mechanism. Fundamentally, it's a matter of OWL's "Open world" vs. SHACL's "Closed world."

owl:someValuesFrom is a statement of general existence, but not a requirement that "the node that exists somewhere" be defined in the graph. Today, the SHACL qualified-min-count shape you suggested imposes a requirement that the node exist and be defined in the graph.

The OWL spelling is still useful, say, for generating "fill-in-the-blank" data without raises validation issues for users who opt to leave something blank. Take this OWL Class that expresses every person has some mother:

ex:Person
    a owl:Class ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:hasMother ;
        owl:someValuesFrom ex:Person ;
    ] ;
    .

The equivalent SHACL spelling in SHACL 1.0 is:

ex:Person
    a owl:Class , sh:NodeShape ;
    sh:property [
        sh:path ex:hasMother ;
        sh:qualifiedMinCount 1 ;
        sh:qualifiedValueShape [
            sh:class ex:Person ;
       ] ;
    ] ;
    .

With that SHACL, data is flagged invalid if I don't have a node linked with ex:hasMother. That shapes graph ends up never being satisfiable, because recursion is an infinitely hungry beast.

The same happens if instead we use a qualified cardinality & qualified min count, reducing the specification to "Something could be linked with ex:hasMother":

ex:Person
    a owl:Class ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:hasMother ;
        owl:minCardinality "1"^^xsd:nonNegativeInteger ;
    ] ;
    .

sh:minCount hits the same issue requiring a node be in the graph. sh:qualifiedMinCount seems to work having no constraints in the qualified value shape...which looks odd, but I think checks out, and did work in a tool I just tried, even against SHACL-SHACL...

ex:Person
    a owl:Class , sh:NodeShape ;
    sh:property [
        sh:path ex:hasMother ;
        sh:minCount 1 ;
    ] ;
    .

ex:Person
    a owl:Class , sh:NodeShape ;
    sh:property [
        sh:path ex:hasMother ;
        sh:qualifiedMinCount 1 ;
        sh:qualifiedValueShape [
           rdfs:comment "This shape intentionally left blank."@en ;
       ] ;
    ] ;
    .

BUT, the same problem comes that I need to have a node specified. This fails validation under both SHACL spellings:

ex:Bob a ex:Person .

But this passes:

ex:Bob a ex:Person ; ex:hasMother [] .

The OWL spelling doesn't care. ex:Bob is DL-conformant and not-inconsistent in any of the above data graphs or all of them combined.

If the minCount or qualifiedMinCount is dropped to 0...what's the SHACL saying, then? If there's no constraints, is there still a shape worth defining?

The problem is, for the data to validate with SHACL, some node needs to be put in place, which can cause a later data cleaning issue. I work with a community that disallows blank nodes in the data/individuals graph. SHACL's minimum-count constraints can cause workflow issues where a node could need to be invented, given a name, and then possibly replaced later, depending on the timing of when the "final" object node is expected to be defined vs. the subject node.

Would dash:hasValueWithClass have any different effect from qualified minimum counts when using SHACL for validation?

[HolgerKnublauch]

I see dash:hasValueWithClass and variations like sh:hasValueWithShape as syntactic sugar. The problem with QCRs is that they are very verbose, esp they need a separate shape for each statement. So to say a Person has one father and one mother requires two property shapes just for syntactic reasons, while in OWL this would be just two triples. This was particularly obvious to me when I wrote an OWL to SHACL converter.

Many OWL ontologies heavily use classes because that's the main thing that OWL has to offer. Back in the old days, working on the NCI thesaurus, there were thousands of someValuesFrom restrictions, but they were just a syntactic trick to express simple relationships between entities.

So instead of

ex:Class1 ex:relation ex:Class2

which would be OWL full and not support inferencing, the OWL DL solution is more like

ex:Class1
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:relation ;
        owl:someValuesFrom ex:Class2
    ] .

The examples that I have seen don't really care about actual instances (of Class1 or Class2) but are purely axiomatic. Therefore whether it's used on closed or open world semantics doesn't really matter that much.