Re: Decomposing shapes

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. 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
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 13 October 2016 15:34:20 UTC