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

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.

This is acceptable.

Note that it is the current syntax that is contributing to this terribleness.
  Other syntaxes allow disjunctions of this sort in a much more compact manner.

> 
> 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 ;
>     ] .

This is even more terrible.  If sh:class does not apply to literals, what else
should it not apply to?  Should it not apply to blank nodes?  Should it not
apply to SHACL instances of classes that are disjoint from the class being
checked for?

> 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.)

How is typing of these anonymous constraints going to work?  In your example
they are not sh:PropertyConstraints.  How is the predicate going to be pushed
into them?

> 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.


I think that the good solution would have been to have an sh:typeIn construct
that allows for both classes and datatypes.  However, the current semantics
for sh:class and sh:classIn do not match up with the current semantics of
sh:datatype.  sh:datatype is instead analogous to sh:directType.  Mixing the
SHACL subclass typing from sh:classIn with the direct Literal typing of
sh:datatype would lead to confusion.

peter

Received on Monday, 28 March 2016 16:42:30 UTC