shapes-ISSUE-104 (Union ranges): Should sh:datatype and sh:class have better support for OR? [SHACL Spec]

shapes-ISSUE-104 (Union ranges): Should sh:datatype and sh:class have better support for OR? [SHACL Spec]

http://www.w3.org/2014/data-shapes/track/issues/104

Raised by: Holger Knublauch
On product: SHACL Spec

While playing with SHACL in practice, I noticed a gap in the spec.

It is quite common to have properties that can take multiple types of values.  sh:text is one example where we hard-coded the pattern rdf:langString OR xsd:string, but a similar variation is xsd:date OR xsd:dateTime. Another example is skos:member, which is skos:Concept OR skos:Collection. schema.org is full of such examples.

To express such unions, the current syntax is very verbose and not suitable for static analysis:

ex:MyShape
    sh:property [
        sh:predicate ex:property ;
        sh:maxCount 1 ;
    ] ;
    sh:constraint [
        sh:or (
            [
                sh:property [
                    sh:predicate ex:property ;
                    sh:datatype xsd:string ;
                ]
            ]
            [
                sh:property [
                    sh:predicate ex:property ;
                    sh:datatype rdf:langString ;
                ]
            ]
        )
    ] .

An option would be to use OWL's unionOf:

ex:MyShape
    sh:property [
        sh:predicate ex:property ;
        sh:maxCount 1 ;
        sh:datatype [
            a owl:Class ;
            owl:unionOf ( xsd:string rdf:langString )
        ]
    ] .

which is much better because it allows us to put everything into a single sh:property node. However, it adds a dependency on OWL, setting wrong expectations about inferencing and all kinds of other unsupported features such as further nested classes, NOT, AND etc, which are usually unnecessary.

I believe we should support this syntax:

ex:MyShape
    sh:property [
        sh:predicate ex:property ;
        sh:maxCount 1 ;
        sh:datatype ( xsd:string rdf:langString )
    ] .

In this proposal, the values of sh:datatype, sh:directType and sh:class may either be IRIs of classes or an rdf:List of IRIs. The SPARQL queries in the spec would need to be adjusted accordingly. We can delete sh:text instead.

I believe this covers a large number of additional use cases while keeping the complexity and implementation burden to a minimum. I believe it is of strategic importance to have a natural way to express schema.org and other common use cases with SHACL.

Received on Friday, 23 October 2015 05:11:09 UTC