Re: Decomposing shapes

* 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

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 13 October 2016 14:35:37 UTC