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

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.

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.

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 Monday, 11 April 2016 10:55:41 UTC