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

On 10/30/15 7:10 AM, Arthur Ryman wrote:
> Holger,
>
> OK, I see it now: sh:datatype ( xsd:string rdf:langString )
>
> So are you still proposing sh:or?

Yes, sh:or would still be needed for other use cases such as

     ex:PersonShape or ex:CustomerShape.

Holger


>
> -- Arthur
>
> On Thu, Oct 29, 2015 at 4:34 PM, Holger Knublauch
> <holger@topquadrant.com> wrote:
>> 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 22:16:26 UTC