ISSUE-141: Proposal for sh:type

Here is a proposal to replace sh:datatype and sh:class with sh:type, 
implemented with the following semantics:

sh:TypeConstraintComponent
   a sh:ConstraintComponent ;
   sh:parameter [
       sh:predicate sh:type ;
     ] ;
   sh:context sh:InversePropertyConstraint ;
   sh:context sh:NodeConstraint ;
   sh:context sh:PropertyConstraint ;
   sh:inversePropertyValidator dash:hasType ;
   sh:nodeValidator dash:hasType ;
   sh:propertyValidator dash:hasType ;
.

dash:hasType
   a sh:SPARQLAskValidator ;
   sh:sparql """
         ASK {
             FILTER IF(dash:isDatatype($type),
                 datatype($value) = $type,
                 EXISTS { $value rdf:type/rdfs:subClassOf* $type })
         } """ ;
.

dash:isDatatype
   a sh:SPARQLFunction ;
   sh:parameter [
       sh:predicate sh:type ;
     ] ;
   sh:returnType xsd:boolean ;
   sh:sparql "ASK { FILTER (EXISTS { $type a rdfs:Datatype } || 
dash:isSystemDatatype($type)) }" ;
.

dash:isSystemDatatype
   a sh:SPARQLFunction ;
   sh:parameter [
       sh:predicate sh:type ;
     ] ;
   sh:returnType xsd:boolean ;
   sh:sparql "ASK { FILTER ($type IN (xsd:string, xsd:integer, xsd:date, 
...)) }" ;
.

The definition above uses helper SHACL functions, but these can of 
course be in-lined for the official document. The definition of such 
functions has the benefit that the logic to determine whether something 
is a datatype or not can be reused.

The enumeration in isSystemDatatype would be extended with the other RDF 
1.1 datatypes including rdf:langString and rdf:HTML.

Open questions include whether the rdf:type rdfs:Datatype triple needs 
to be in the shapes graph and whether we need to support subclasses of 
rdfs:Datatype. I have no strong opinions, and changing this would be 
trivial.

This would close ISSUE-141 for me, assuming we add a corresponding 
sh:typeIn.

Holger

Received on Friday, 29 April 2016 03:17:46 UTC