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

Sure, I don't want to treat sh:class different from sh:datatype. Did I 
say this somewhere?

Holger


On 11/6/15 2:09 AM, Arthur Ryman wrote:
> Holger,
>
> I don't understand why you would treat IRIs different than datatypes.
> In both cases we should consistently define the meaning of a List of
> values to have union (or) semantics.
>
> -- Arthur
>
> On Thu, Oct 29, 2015 at 6:15 PM, Holger Knublauch
> <holger@topquadrant.com> wrote:
>>
>> 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, 5 November 2015 18:59:01 UTC