- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 14 Oct 2016 08:43:40 +1000
- To: public-data-shapes-wg@w3.org
On 14/10/2016 1:33, Karen Coyle wrote: > Eric, your solution changes the terminology for constraints and > parameters (which I would like to see), but doesn't touch on the issue > that I brought up to Dimitris (and that I had also mentioned to you), > which focuses on this: > > Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], > constraints:Set[Test] > > Because filters are shapes, this means that a filter can have targets, > filters, and constraints. It seems that is not the intention -- > filters cannot have targets and filters. Any shape can (also) be a filter. For example someone could have a shape that uses ex:PersonShape as a filter. Yet, sh:PersonShape may also be used "stand-alone" and thus have its own targets and filters. Holger > There are at least two different "shapes" in the core: > > 1) The shape, above, with targets, filters and constraints > 2) the "filter shape", which further refines the target but does not > define targets or filters. > > I believe that the filter shape of today would be defined as: > > filterShape := label:IRI|BNode, constraints:Set[Test] > > filterShape does act as a constraint, IMO, and could be considered a > "selector" in your terminology. That would change the nature of the > shape, as Dimitris says below. > > kc > > On 10/13/16 7:35 AM, Eric Prud'hommeaux wrote: >> * Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> >> [2016-10-13 14:47+0300] >>> There have been quite a few talks lately about what is a shape, focus >>> nodes, referenced shapes, filters etc and most boil down to how >>> shapes are >>> used and different roles shapes take >>> e.g. as a simple shape, as a filter shape, constraining shape (in >>> sh:shape, >>> sh:or, etc) >>> >>> One idea to fix this that came up after yesterday's telco with Karen >>> was to >>> differentiate these cases as follows >>> A shape is a constraint with optional targets (currently shape is a >>> subclass of Constraint so this is true anyway) >>> All other cases will be referring to constraints, not shapes >>> e.g. the range of a filter is a constraint, not a shape >>> similar the range of sh:shape is again a constraint as for sh:and, >>> sh:or, >>> sh:qualifiedShape >>> >>> this fixes the problems of what we do with targets of a shape when that >>> shape is referenced from another shape. With this change, the reference >>> will be only to constraints, not shapes. >>> >>> This will require the renaming of some SHACL Core constructs but I >>> believe >>> it will improve the language. >>> e.g. sh:filterShape could be renamed to sh:filterConstrain, sh:filter, >>> sh:condition >>> sh:shape to sh:constraint >>> sh:qualifiedValueShape to qualifiedValueConstraint >>> (sh:not/or/and are not affected) >>> >>> Any feedback is welcome >> >> In the abstract syntax, I made an effort to follow the SHACL >> terminology: >> [[ >> Schemas and Shapes >> Schema := shapes:Set[Shape] >> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], >> constraints:Set[Test] >> Test := Constraint|Algebraic >> Constraints >> Constraint := NodeConstraint|PathConstraint >> NodeConstraint := parms:Set[Parameter] >> PathConstraint := path:SPARQLPropertyPath, parms:Set[Parameter] >> Parameters >> Parameter := UnaryParameter | NaryParameter >> Unary Parameters >> UnaryParameter := NodeKind | In | Class | Datatype | MinLength | >> MaxLength | Pattern >> | Stem | MinInclusive | MinExclusive | MaxInclusive >> | MaxExclusive >> | LessThanEquals | LessThan | Equals | Disjoint | HasShape >> RDF term type of value node >> NodeKind := kind:"IRI"|"blank node"|"literal" >> RDF term equivalence >> In := vals:Set[RDF term] >> Class := t:IRI >> Datatype >> Datatype := dt:IRI >> XML Schema string facets >> MinLength := ref:numeric >> MaxLength := ref:numeric >> Pattern := pat:RDFLiteral, flagstr:RDFLiteral >> Stem := str:RDFLiteral >> XML Schema numeric facets >> MinInclusive := ref:RDFLiteral >> MinExclusive := ref:RDFLiteral >> MaxInclusive := ref:RDFLiteral >> MaxExclusive := ref:RDFLiteral >> Comparison with specified property >> LessThanEquals := siblingProp:RDFLiteral >> LessThan := siblingProp:RDFLiteral >> Equals := siblingProp:RDFLiteral >> Disjoint := siblingProp:RDFLiteral >> Nested shape constraints >> HasShape := nested:Shape >> N-ary Parameters >> NaryParameter := UniqueLang | HasValue | MinCount | MaxCount | >> QualifiedMinCount >> | QualifiedMaxCount | QualifiedValueShape >> Uniqueness >> UniqueLang := b:boolean >> RDF term equivalence >> HasValue := val:RDF term >> Cardinality >> MinCount := ref:numeric >> MaxCount := ref:numeric >> QualifiedCardinality >> QualifiedMinCount := ref:numeric >> QualifiedMaxCount := ref:numeric >> QualifiedValueShape := nested:Shape >> Logical operators >> Algebraic := And|Or|Not >> And := shapes:Set[Shape] >> Or := shapes:Set[Shape] >> Not := shape:Shape >> Targets >> Target := TargetNode|TargetClass|TargetSubjectsOf|TargetObjectsOf >> TargetNode := node:IRI|literal|BNode >> TargetClass := type:IRI >> TargetSubjectsOf := predicate:IRI >> TargetObjectsOf := predicate:IRI >> ]] >> >> I think it would be greatly improved if we renamed >> s/Constraint/Selector/g >> s/Parameter/Constraint/g >> as what are currently called constraints select a bunch of triples which >> are then constrained by "parameters". >> c.f. http://w3c.github.io/data-shapes/shacl-abstract-syntax/#issue-1 >> >> It would look like this: >> [[ >> Schemas and Shapes >> Schema := shapes:Set[Shape] >> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], >> selectors:Set[Test] >> Test := Selector|Algebraic >> Selectors >> Selector := NodeSelector|PathSelector >> NodeSelector := parms:Set[Constraint] >> PathSelector := path:SPARQLPropertyPath, parms:Set[Constraint] >> Constraints >> Constraint := UnaryConstraint | NaryConstraint >> Unary Constraints >> UnaryConstraint := NodeKind | In | Class | Datatype | MinLength | >> MaxLength | Pattern >> | Stem | MinInclusive | MinExclusive | MaxInclusive >> | MaxExclusive >> | LessThanEquals | LessThan | Equals | Disjoint | HasShape >> RDF term type of value node >> NodeKind := kind:"IRI"|"blank node"|"literal" >> RDF term equivalence >> In := vals:Set[RDF term] >> Class := t:IRI >> Datatype >> Datatype := dt:IRI >> XML Schema string facets >> MinLength := ref:numeric >> MaxLength := ref:numeric >> Pattern := pat:RDFLiteral, flagstr:RDFLiteral >> Stem := str:RDFLiteral >> XML Schema numeric facets >> MinInclusive := ref:RDFLiteral >> MinExclusive := ref:RDFLiteral >> MaxInclusive := ref:RDFLiteral >> MaxExclusive := ref:RDFLiteral >> Comparison with specified property >> LessThanEquals := siblingProp:RDFLiteral >> LessThan := siblingProp:RDFLiteral >> Equals := siblingProp:RDFLiteral >> Disjoint := siblingProp:RDFLiteral >> Nested shape selectors >> HasShape := nested:Shape >> N-ary Constraints >> NaryConstraint := UniqueLang | HasValue | MinCount | MaxCount | >> QualifiedMinCount >> | QualifiedMaxCount | QualifiedValueShape >> Uniqueness >> UniqueLang := b:boolean >> RDF term equivalence >> HasValue := val:RDF term >> Cardinality >> MinCount := ref:numeric >> MaxCount := ref:numeric >> QualifiedCardinality >> QualifiedMinCount := ref:numeric >> QualifiedMaxCount := ref:numeric >> QualifiedValueShape := nested:Shape >> Logical operators >> Algebraic := And|Or|Not >> And := shapes:Set[Shape] >> Or := shapes:Set[Shape] >> Not := shape:Shape >> Targets >> Target := TargetNode|TargetClass|TargetSubjectsOf|TargetObjectsOf >> TargetNode := node:IRI|literal|BNode >> TargetClass := type:IRI >> TargetSubjectsOf := predicate:IRI >> TargetObjectsOf := predicate:IRI >> ]] >> >> Of course, we could do this in the abstract-syntax doc, but I think >> this would improve readability for the SHACL doc as well as make it >> easier for folks writing code or papers about it. >> >> >>> Best, >>> Dimitris >>> -- >>> Dimitris Kontokostas >>> Department of Computer Science, University of Leipzig & DBpedia >>> Association >>> Projects: http://dbpedia.org, http://rdfunit.aksw.org, >>> http://aligned-project.eu >>> Homepage: http://aksw.org/DimitrisKontokostas >>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT >> >
Received on Thursday, 13 October 2016 22:44:14 UTC