Re: read-through of Sections 5 and 7

I have counted 42 questions and comments in the mail below. I will try 
to get these into the wiki page table by Wednesday, and perhaps will 
manage to turn some into issues. To save effort in creating issues, I 
may gather each set around its quote rather than making separate entries 
for each.

kc

On 11/26/16 6:56 AM, Peter F. Patel-Schneider wrote:
> I did a read-through of Section 5 and Section 7.  I found many problems.
> Some of these are likely simple problems of wording.  Many others are
> problems with undefined or poorly defined notions.
>
> There isn't even any definition or even description of how SPARQL-based
> constraints actually work within the larger context of a SHACL Full system.
> To see that, note that SPARQL-based constraints are to be "executed", but
> there is no discussion of when that happens.
>
>
> Section 5 SPARQL-based Constraints
>
> "As elaborated in the section on prefix handling rules, the value of
> sh:select must be transformable into a SPARQL 1.1 SELECT query. The query
> must project the result variable this in its SELECT clause."    There is no
> definition for the notion of projection here.
>
> "The property sh:declare is used to make individual prefix declarations. The
> SHACL vocabulary defines the class sh:PrefixDeclaration for the values of
> sh:declare although no rdf:type triple is required for them."  Remove
> 'individual'.  What is the SHACL vocabulary?  Is the expected type
> sh:PrefixDeclaration?
>
> "The recommended subject for values of sh:declare is the IRI of the graph
> containing the shapes that use the prefixes. These IRIs are often declared
> as an instance of owl:Ontology, but this is not required."  Not all shapes
> graphs will have IRIs.  How is an IRI declared as an instance?
>
> "These nodes can use the property sh:prefixes to specify a set of prefix
> mappings."  "The values of sh:prefixes must be IRIs or blank nodes. A SHACL
> processor collects a set of prefix mappings as the union of all single
> prefix mappings that can be reached by the property path
> sh:prefixes/owl:imports*/sh:declare starting at the SPARQL-based
> constraint. If such a collection of prefix declarations contains multiple
> namespaces for the same sh:prefix, then the shapes graph is invalid. A SHACL
> processor transforms the values of sh:select (and similar properties such as
> sh:ask) into SPARQL by prepending PREFIX declarations for all namespace
> prefix mappings. Each value of sh:prefix is turned into the PNAME_NS, while
> each value of sh:namespace is turned into the IRIREF in the PREFIX
> declaration."  What is a 'single prefix mapping'?  Why is this couched as
> the actions of a SHACL processor instead of just being a relationship
> between a node and a set of prefix mappings?  What happens if an invalid set
> of prefix mappings exists in a shapes graph but is not used by any shape in
> the graph?  What does 'the same sh:prefix' mean?  The values of sh:select
> and similar properties are generally already SPARQL so why do they need to
> be transformed *into* SPARQL?  What is a 'namespace prefix mapping'?
>
> "The following table enumerates variables that have special meaning in
> SPARQL constraints."  It is not clear whether this is a complete enumeration
> (as suggested by the use of the word enumerate) or just some examples of
> variables that have special meaning.
>
> "When SPARQL constraints are executed, the SHACL Full processor pre-binds
> values for these variables."  There is no notion of when SPARQL constraints
> are to be executed.
>
> "If one of the solutions of the result set produced by a SELECT query
> contains the binding true for the variable failure, then the SHACL Full
> processor MUST signal a failure."  Produced under what circumstances?
>
> "Otherwise, each row of the result set produced by a SELECT query MUST be
> converted into one validation result node."  This states that this MUST be
> done for all queries, even those queries that produce result sets due to
> being a value for sh:shape or similar parameters.
>
> "The properties of those nodes are derived by the following rules, through a
> combination of result variables and the properties linked to the constraint
> itself. The production rules are meant to be executed from top to bottom, so
> that the first bound value will be used."  What is a property of a node?
> What is a production rule?
>
> "The value of the variable path (only supports property IRIs, no complex
> paths)"  What does the parenthetical remark mean?
>
> "The values of sh:message of the subject of the sh:select or sh:ask
> triple. These string literals may reference any binding of the SELECT result
> variables via {?varName} or {$varName}. If the constraint is based on a
> constraint component, then the component's parameter names can also be
> used. The {?varName} blocks SHOULD be substituted with suitable string
> representations of the values of said variables."  Which sh:select or sh:ask
> triple?  How does a string literal reference anything?  What is a suitable
> string representation of a variable value?  Why is this only a SHOULD?
>
> "Any such property needs to be declared via a value of sh:resultAnnotation
> at the subject holding the sh:select or sh:ask triple."  How does a subject
> hold a triple?
>
> "Property  Value type  Count  Description
> sh:annotationProperty  rdf:Property  1 (mandatory)  The annotation property
> that shall be set
> sh:annotationVarName  xsd:string  0..1  The name of the SPARQL variable to
> take the values from
> sh:annotationValue   0..unlimited  Constant nodes that shall be used as
> default values"
> What does the value type column mean here?  What does the count column mean here?
>
> "For each solution of a SELECT result set, a SHACL Full processor MUST walk
> through the declared result annotations."  This should be specified as a
> relationship, not something that a SHACL processor does.
>
> "1. If a sh:resultAnnotation has a value for the property
> sh:annotationVarName then the SHACL Full processor MUST look for the
> variable named after the sh:annotationVarName 2. Otherwise, the SHACL Full
> processor MUST derive a variable name from the value of
> sh:annotationProperty using the same local name mechanism as described
> earlier " What does it mean for a variable to named after something?  There
> is no local name mechanism described earlier in the document.  In one case
> the processor looks for something, in the other case the processor derives a
> name.   These are different categories of action.
>
> "If a variable name could be determined, then the SHACL Full processor MUST
> copy the bindings for the given variable into the constructed validation
> results for the current solution."  This reads as if all the bindings are
> copied into each validation
> result, which doesn't appear to make sense.  How are the values copied into
> the result?
>
> "The values of sh:annotationProperty must not be from the SHACL namespace,
> to avoid clashes with variables that are already produced by other means."
> This does not prevent clashese with other variables.
>
> Section 7 SPARQL-based Targets
>
> "All subjects of sh:target triples must be IRIs."  This makes absolutely no
> sense.  Why should the shapes that have SPARQL-based targets be IRIs.
>
> "The SPARQL queries linked to a target via sh:select must be of the query
> form SELECT."   This doesn't apply the prefix handling rules.
>
> "The SELECT queries must project to the result variable this."  There is no
> definition for "project to".
>
> "The resulting target consists of all distinct bindings for the variable
> this."  The target is the value of sh:target so how can it be the bindings?
>
> "The SELECT queries must also be executable when converted to an ASK query
> and with a pre-bound value for ?this."    There is no definition for
> converting a SELECT query to an ASK query.  There is no notion of a query
> being executable.
>
> "The set of bindings for ?this that return true for such ASK queries must be
> identical to the set produced by the SELECT query. This design makes sure
> that SHACL Full processors can validate whether a given shape applies to a
> given individual focus node."   A SHACL Full processor can always just run
> the SELECT query and check whether the individual focus node is in the
> result set.   So this condition, which is difficult and maybe even possible
> to check, is unnecessary.  The checking can even be done completely within
> SPARQL by appending a values clause to the query, which can then be
> optimized by the SPARQL processor, so there is not even any particular
> reason to have this condition for efficiency purposes.
>
> "Similar to constraint components, such targets take parameters that are
> interpreted when the target is evaluated."  There is no notion of evaluation
> of targets.
>
> "All parameters of target types are expected to have sh:maxCount 1."  What
> does expectation mean in the context of parameters?
>
> SPARQL-based target types appear to have many of the same characteristics of
> sh:SPARQLTarget targets.  Why then do the underlying queries not have the same
> restrictions?  Why are the queries not restricted to those whose top-level
> SELECT includes (or has only) this in the variables of its select clause?
> Why are queries not restricted to ones that can be converted to ASK queries
> that have the same behaviour?
>
>
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>

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

Received on Sunday, 27 November 2016 19:26:02 UTC