comments on current version of SHACL document

I took a quick look at the version of the document current on 15 September,
concentrating mostly on Sections 1-6.

The document is looking better, but there are still several significant
problems.

- With the new emphasis on SPARQL, there should be a part of Section 1 that
  introduces the use of SPARQL as the definition of SHACL.  This would
  include some of the stuff from the beginning of Section 3.  There needs to
  be more information on how SPARQL is used in the definition of SHACL in
  the discussion that is currently at the beginning of Section 3, such as
  how the results of the queries are combined.  This would also discuss the
  problem with blank nodes.  As well, sh:hasShape needs to be better
  described.  Several SPARQL queries provided require that the shapes graph
  be accessible.  As this is not guaranteed, there needs to be an
  explanation of what is going on.  It would also be better to have SPARQL
  definitions for more of SHACL, such as scopes.  (This would require moving
  the details of using SPARQL to define SHACL earlier in the document.)

- The handling of results is poorly defined.  There is no discussion of how
  the results of embedded constraints and shapes are to be handled.  This
  needs to be cleaned up before FPWD publication.

- With the user-friendly syntax, shapes do not necessarily need to be in an
  RDF graph.  I think that this means that the early part of the document
  should not say "shapes graph", but instead something like "shapes".  Then
  the document can say "SHACL shapes are often encoded in an RDF graph,
  which is called the shapes graph."  Then later on it can say "shapes
  encoded as an RDF graph" where necessary.  I don't know what should be
  done for constructs that are not going to be part of the user-friendly
  syntax.

- SHACL is not an RDF vocabulary.  It is a language that can be encoded in
  RDF, and that uses a particular vocabulary in the encoding.  Any time
  SHACL shapes are discussed as being part of an RDF graph, careful
  attention needs to be paid ot the wording used so as to not give incorrect
  information.

- What happens with cyclic shapes references that do not involve a property
  constraint?  Are these handled the same as cyclic references that do
  involve a property constraint?

- All uses of RDFS notions, e.g., subclasses, should be qualified, e.g.,
  SHACL subclasses.

- The relationship between shapes and constraints is poorly explained.  A
  shape has a bunch of constraints, which together serve to define the
  shape.  Constraints are not just validated against the same focus nodes.

- Most of the document is about the definition of SHACL.  There is little or
  no need for MUST, etc., in this definition.  Where MUST, etc., should show
  up is when describing the behaviour of SHACL implementations.  For
  example, a good description of scope combination would be "The scopes of a
  SHACL shape are considered additively, so, for example, in a shape with
  two individual scopes both individuals are in the scope of the shape."
  with no MUST, etc., needed.

- The description of the various bits of property constraints obscures the
  independence of some of the bits.  For example, splitting sh:minCount and
  sh:maxCount would eliminate talk about defaults.

There are few things that would make the document better, but that are
certainly not needed immediately.

- It would be nice to have an option to hide the SPARQL definitions.

- It might be better to turn Section 2.3 into the beginning of Section 3.

Received on Wednesday, 16 September 2015 15:29:17 UTC