W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > October 2016

Re: Decomposing shapes

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 14 Oct 2016 08:43:40 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <0da2da08-c879-fb07-5405-b436fd7c9c51@topquadrant.com>


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:37 UTC