Re: ISSUE-133 syntax simplifications & regularizations

On 05/10/2016 01:16 PM, Dimitris Kontokostas wrote:
> 
> 
> On Tue, May 10, 2016 at 6:55 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     OK, no more sh:defaultValueType.  Good.
> 
>     How does the syntax of constraints work now?
> 
> 
>     Can any triples be removed from the following RDF graph without changing
>     its validation behaviour?  If so, which ones?
> 
>     @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>     @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>     @prefix sh: <http://www.w3.org/ns/shacl#> .
>     @prefix ex: <http://example.com/ns#> .
> 
>     ex:s1 a sh:Shape ;
>      sh:scopeClass ex:Foo ;
>      sh:node [ a sh:NodeConstraint ;
>                sh:nodeKind sh:IRI ] ;
>      sh:property [ a sh:PropertyConstraint ;
>                    sh:predicate ex:p ;
>                    sh:class ex:Bar ] .
> 
> 
> imo this shapes graph is valid and  both type triple can be removed 

If the type triples can be removed then what happens to
"sh:PropertyConstraint is the class of all property constraints"?   The object
of sh:property is a property constraint but then doesn't seem to belong to the
class sh:PropertyConstraint.

>     Does the following RDF graph contain a syntactically-valid SHACL shape?  If
>     not, why not?
> 
>     @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>     @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>     @prefix sh: <http://www.w3.org/ns/shacl#> .
>     @prefix ex: <http://example.com/ns#> .
> 
>     ex:NodeConstraint rdfs:subClassOf sh:NodeConstraint .
>     ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf .
>     ex:PropertyConstraint ex:subClassOf sh:PropertyConstraint .
> 
>     ex:s2 a sh:Shape ;
>      sh:scopeClass ex:Foo ;
>      sh:node [ a ex:NodeConstraint ;
>                sh:nodeKind sh:IRI ] ;
>      sh:property [ a ex:PropertyConstraint ;
>                    sh:predicate ex:p ;
>                    sh:class ex:Bar ] .
> 
> 
> I think this shapes graph is valid as well but other may correct me if I am
> wrong but let me explain why first
>  - I believe  we still need to say that (sh:NodeConstraint,
> sh:PropertyConstraint, sh:InversePropertyConstraint, sh:SparqlConstraint) are
> pairwise disjoint.
>  - As long as the above rule is not violated we are fine
>  - we do not say that values of sh:node / sh:property must not be instances of
> other classes only that they must be instances of sh:NodeConstraint /
> sh:PropertyConstraint, so a shacl engine can assign the proper types even
> without any inferencing at all

But determining that the object of sh:property above is an instance of
sh:PropertyConstraint *is* inferencing!

> if on the other hand you stated
> ex:PropertyConstraint ex:subClassOf sh:InversePropertyConstraint .
> this would be problematic but I think we should avoid such (edge) cases

Without inferencing how could this problem be detected?

peter

Received on Tuesday, 10 May 2016 20:51:42 UTC