- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 11 May 2016 08:58:15 +1000
- To: public-data-shapes-wg@w3.org
On 11/05/2016 6:51, Peter F. Patel-Schneider wrote: > > 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? I think all of these issues are rather minor problems that can be written up. The concept of default value types was providing one solution, and if you prefer to call this an "inference" I don't care as long as we remain sure that this doesn't mean the same as "RDF inferencing". Maybe we should come up with a different term to avoid confusion, such as "type derivation" or even "SHACL instance classification". Holger
Received on Tuesday, 10 May 2016 22:58:50 UTC