Re: shapes-ISSUE-141 (Mixed ranges): How to represent mixed datatype-or-class ranges [SHACL - Core]

On 11/04/2016 20:55, Peter F. Patel-Schneider wrote:
> Option 2 is to permit sh:or and sh:and to take property constraints.   This
> only works here because the sh:or is in a property constraint.   If the sh:or
> were inside an inverse property constraint then it would be taking inverse
> property constraints and if it were inside a node constraint it would be
> taking node constraints.  This would be a further complication of the syntax.

I believe this approach is quite doable and easy to explain. In Proposal 
3 the three cases have different validators, and each validator can call 
the sh:hasShape function with different arguments. We should probably 
rename sh:hasShape to sh:checkConstraints, so that it can take either a 
shape or a constraint, but that's an internal implementation detail. 
Like our names (sh:equals etc), people will eventually get used to the 
design patterns that we give them.

>
> If, on the other hand, the syntax was simplified everything would work out.
> If constraints and shapes were one, then sh:or and sh:and would just take
> shapes and there would be no need to have either the burdensome alternation of
> shapes and constraints or the repetition of the property.

Merging these concepts is just blurring the lines and makes the use of 
constraint components unpredictable, see ISSUE-139.

If we were to merge shapes and constraints and drop sh:constraint, how 
could people express different severities, e.g.?

ex:MyShape
     a sh:Shape ;
     sh:constraint [
         sh:closed true ;
         sh:severity sh:Warning ;
     ] ;
     sh:constraint [
         sh:stem "http://aldi.de/" ;
         # default severity is sh:Error
     ] .


But for this specific use case in ISSUE-141, my preferred solution is to 
replace sh:datatype and sh:class with sh:type, as outlined as Option 3 
on the Proposals page:

https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-141:_Mixed_ranges

The syntax would then be exactly what users would want:

schema:AddressShape
     a sh:Shape ;
     sh:property [
 sh:predicate schema:address ;
 sh:typeIn ( xsd:string schema:PostalAddress ) ;
     ] .


Holger

>
> peter
>
>
>
>
> On 03/21/2016 09:16 PM, RDF Data Shapes Working Group Issue Tracker wrote:
>> shapes-ISSUE-141 (Mixed ranges): How to represent mixed datatype-or-class ranges [SHACL - Core]
>>
>> http://www.w3.org/2014/data-shapes/track/issues/141
>>
>> Raised by: Holger Knublauch
>> On product: SHACL - Core
>>
>> Some ontologies contain properties that can either take literals or resources. Example: http://schema.org/address takes either xsd:string or schema:PostalAddress. I believe many DC properties are frequently used with mixed values. RDF has rdf:Property, only OWL separates datatype and object properties.
>>
>> The current syntax to represent those in SHACL Core is terrible:
>>
>> schema:AddressShape
>>      a sh:Shape ;
>>      sh:constraint [
>>          sh:or (
>>              [ sh:property [ sh:predicate schema:address ; sh:datatype xsd:string ] ]
>>              [ sh:property [ sh:predicate schema:address ; sh:class schema:PostalAddress ] ]
>>          )
>>      ] .
>>
>> Some options:
>>
>> 0) Do nothing, consider this a rare (anti) pattern.
>>
>> 1) Change sh:class and sh:datatype so that they only apply to resources or literals, respectively. Using a literal with sh:class would no longer be a violation. sh:nodeKind would have to be used for most other properties:
>>
>> schema:AddressShape
>>      a sh:Shape ;
>>      sh:property [
>>          sh:predicate schema:address ;
>>          sh:datatype xsd:string ;
>>          sh:class schema:PostalAddress ;
>>      ] .
>>
>> 2) Improve syntax of sh:or (and sh:and) to allow for property constraints:
>>
>> schema:AddressShape
>>      a sh:Shape ;
>>      sh:property [
>>          sh:predicate schema:address ;
>>          sh:or (
>>              [ sh:datatype xsd:string ]
>>              [ sh:class schema:PostalAddress ]
>>          )
>>      ] .
>>
>> (The values of the list would be sh:PropertyConstraints that use the same sh:predicate from the surrounding property constraint.)
>>
>> A follow-up of 2) would be that we could drop sh:classIn and sh:datatypeIn to avoid too many syntaxes for the same thing.

Received on Tuesday, 12 April 2016 01:02:03 UTC