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

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 16:10:06 UTC