Re: ISSUE-141: Proposal for sh:type

Option 1:

sh:type type
argument IRI

A validation report is produced for a node
if
it is not a literal and there is no rdf:type/rdfs:subclassOf* path in the data
graph from the node to the type
or
it is a literal and its datatype is different from type


Option 2 (preferred):

sh:type type
argument IRI

A validation report is produced for a node
if
it is not a literal and there is no rdf:type/rdfs:subclassOf* path in the data
graph from the node to the type
or
it is a literal with known datatype and type is a known datatype and the value
of the literal, if any, belongs to the value space of the type
or
it is a literal with known datatype and type is not a known datatype
or
it is a literal with datatype that is not a known datatype and that datatype
is different from type



peter


On 04/29/2016 02:12 AM, Holger Knublauch wrote:
> Such as?
> 
> Sent from my iPad
> 
>> On 29 Apr 2016, at 5:50 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>> Why not use instead a formulation that does not depend on whether the type is
>> a datatype?
>>
>> peter
>>
>>
>>> On 04/28/2016 08:17 PM, Holger Knublauch wrote:
>>> 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 09:44:48 UTC