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

Holger,

OK, I see it now: sh:datatype ( xsd:string rdf:langString )

So are you still proposing sh:or?

-- 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 21:10:34 UTC