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

On 10/30/15 6:22 AM, Arthur Ryman wrote:
> Holger,
>
> The way this was handled in OSLC was to allowed multiple values for
> oslc:range, which is like sh:class here. The semantics was UNION of
> the classes which is the same as your proposed Or. Why not simply
> allow a multiple-valued property, or a List if you really want to
> stick with single-valued properties?

Yes, an rdf:List is what I am proposing. All other constraint properties 
are single-valued, and I would not support making an exception just for 
this single case. It would also introduce unintuitive consequences with 
subclassing.

Holger



>
> -- Arthur
>
> On Fri, Oct 23, 2015 at 1:11 AM, RDF Data Shapes Working Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
>> 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 Thursday, 29 October 2015 20:34:54 UTC