Re: ISSUE-141: Proposal for sh:type

I believe option 1 would work. It has the advantage that it is faster to 
execute and easier to specify than my previous proposal. It wouldn't 
help with the logic for form builders etc - when you don't even have a 
value yet - but that can be defined (easily) by 3rd parties using 
similar functions as in my draft below.

Holger


On 29/04/2016 19:44, Peter F. Patel-Schneider wrote:
> 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 Monday, 2 May 2016 02:57:27 UTC