SHACLE Type fixes

[sebastiankb]

it seems there are some mistakes defined in the validation file coming from PR #1574. This result to strange rendering behavoir in PR #1638 and #1639 (many places have "any type" defined instead of the specific datatype).

This PR should fix this issue and the render script should work correct again.

[relu91]

I was digging into the issue too. I stumble upon this commit message from @ethieblin (original commit

shacl: use sh:Literal instead of xsd:string to allow language tagged literals

When Things have a global language tag, the resulting literals in RDF are "tagged literals"
which cannot be considered as "xsd:string"

Are we sure that sh:Litteral can be used together with sh:datatype ?

[relu91]

Are we sure that sh:Litteral can be used together with sh:datatype ?

Answering my own question, from the spec there seem no constraints on the usage of the two terms... https://www.w3.org/TR/shacl/#DatatypeConstraintComponent https://www.w3.org/TR/shacl/#NodeKindConstraintComponent

[relu91]

Digging deeper, probably what @ethieblin meant in the commit above is that when the language tag is used all the string literals are tagged with the lang tag. This in practice means that the datatype of the literal became http://www.w3.org/1999/02/22-rdf-syntax-ns#langString as explained in Section 3.3

Similarly, most concrete syntaxes represent language-tagged strings without the datatype IRI because it always equals http://www.w3.org/1999/02/22-rdf-syntax-ns#langString.

[ethieblin]

Even though this PR would fix the renderer, it brings the issue of the use of SHACL shapes as validation for the RDF version of a TD.

The use case is the following:

1. Take this TD, a valid TD with a global language tag.
2. Transform it into RDF for example with JSON-LD playground.
3. Now the generated RDF should be compliant with the SHACL shapes in this repository. You can use this validator to check if RDF data conforms to a set of SHACL rules.

Note: Perhaps, adding a few tests like that in the repository would ensure that the JSON-LD context is compliant to the OWL ontology and to the SHACL shapes ?

[relu91]

I think the question is, does it makes sense and is it even possible to state that title, descriptions, etc. are literals and they might have http://www.w3.org/1999/02/22-rdf-syntax-ns#langString or xsd:String as dataType?

Note: Perhaps, adding a few tests like that in the repository would ensure that the JSON-LD context is compliant to the OWL ontology and to the SHACL shapes ?

I think it might catch some errors, we can automate the check in the CI.

[ethieblin]

Apart from the issue on the "datatype" vs sh:Literal issue, there are changes in this PR that make the SHACL rules not compliant with the TD ontology anymore.
If the ontology states that something is a owl:ObjectProperty, then in the SHACL rules, its expected node type is sh:IRI. It cannot be a sh:Literal.

Also, you cannot state that a property expects both a sh:IRI and give it a datatype.
Small example: (check with https://shacl-play.sparna.fr/play/validate)

SHACL rule:

@prefix : <http://www.w3.org/ns/td-validation#> .
@prefix td: <https://www.w3.org/2019/wot/td#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix hctl: <https://www.w3.org/2019/wot/hypermedia#> .

:ThingShape a sh:NodeShape ;
    sh:targetClass td:Thing ;
    sh:property [
         sh:path hctl:hasAnchor;
         sh:nodeKind sh:IRI ;
         sh:datatype xsd:anyURI ;
         sh:minCount 1 ;
         sh:maxCount 1 ;
        ] 

RDF with an IRI as object. It raises a validation error.

@prefix td: <https://www.w3.org/2019/wot/td#> .
@prefix hctl: <https://www.w3.org/2019/wot/hypermedia#> .
<urn:1234> a td:Thing;
    hctl:hasAnchor <urn:something:else:uri>.

RDF with a typed xsd:anyURI Literal as object. It raises a validation error.

@prefix td: <https://www.w3.org/2019/wot/td#> .
@prefix hctl: <https://www.w3.org/2019/wot/hypermedia#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<urn:1234> a td:Thing;
    hctl:hasAnchor "urn:something:else:uri"^^xsd:anyURI.

[sebastiankb]

@ethieblin many thanks for your feedback.

I think we need to follow these strategies:

1. this PR helps that the render scrips works again and we can generate the correct specification document for the CR transmission
2. in the meantime we should work on the render script especially on templates.sparql that it also process the sh:nodeKind statements correctly
3. if the problem is fixed we can go back to the sh:nodeKind only definitions which results to correct SHACL validation again

@ethieblin can you quickly check what can be the issue in the templates.sparql file?

[sebastiankb]

from today's TD call:

• decided to merge to run the render scrip again correctly
• @relu91 will provide another PR to fix the shacl issue above