W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

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

From: RDF Data Shapes Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Tue, 22 Mar 2016 04:16:53 +0000
To: public-data-shapes-wg@w3.org
Message-Id: <E1aiDkT-0005cp-Al@deneb.w3.org>
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, 22 March 2016 04:16:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC