Re: the current situation with respect to ISSUE-134

(Finally getting back to older emails, too much work...)

On 12/04/2016 1:01, Peter F. Patel-Schneider wrote:
> On 04/07/2016 05:53 PM, Holger Knublauch wrote:
> [...]
>
>> Overall, if you have specific suggestions on what is missing, please send
>> instructions on what needs to be edited.
>>
>> Holger
> 2.3
>
> Replace up to "Constraints can have" with
>
>   Shapes can be linked to their constraints via the following properties.
>
> -   sh:property links to constraints on the value of a property on the focus node
> -    sh:inverseProperty links to constraints in the value of the inverse of a
> property on the focus node
> -    sh:constraint links to constraints on the focus node itself

If the above is supposed to replace the whole upper part of section 2.3, 
then I believe we would be loosing too much detail. I would like to pass 
this on to Dimitris for his opinion.

>
> 3
>
> Replace the first bullet list with
>
> -  For objects of sh:property triples in a shape the value nodes are the
> objects of the triples that have the focus node as subject and the given
> property as predicate. Each produced validation result must have the focus
> node as its sh:subject, the sh:predicate as its sh:predicate and the
> respective violating value node as its sh:object.
> -   For objects of sh:inverseProperty triples in a shape the value nodes are
> the subjects of the triples that have the focus node as object and the given
> property as predicate. Each produced validation result must have the focus
> node as its sh:object, the sh:predicate as its sh:predicate and the respective
> violating value node as its sh:subject.
> -   For objects of sh:constraint triples in a shape the value nodes are the
> focus nodes.

This is assuming that the values of sh:constraint are only 
sh:NodeConstraints, but they may also be sh:PropertyConstraint, and 
under that design the current wording is more correct.

>
> Replace the paragraph before the big table with
>
> The following table summarizes the parameters used by the core constraint
> components. The table clarifies whether these parameters can be used in the
> object of a sh:constraint triple in a shape (NC), in the object of a
> sh:property triple in a shape (PC), or in the object of a sh:inverseProperty
> triple in a shape (IPC).

Again, this is a different policy than currently specified.

>
> 4.1.1
>
> Replace first paragraph with
>
> SHACL validation engines MUST reject shapes graphs that are invalid, according
> to the following rules and the rules in the preceding sections. No validation
> results must be produced, but instead a system error reported by other means.

Ok, I added the sub-sentence about rules in other sections.

>
> Remove second paragraph
>
> Replace third paragraph with
>
> The values of sh:property, sh:inverseProperty, and sh:constraint must be IRIs
> or blank nodes.  The values of sh:property and sh:inverseProperty must be the
> subject of precisely one triple with property sh:predicate, whose object must
> be an IRI.
>
> Remove third paragraph

Dimitris, this is an area that you recently edited with the new policy 
for disjointness. What do you think about this prose?

Holger


>
>
> Some other text is no longer needed and can be removed.
>
> peter

Received on Friday, 22 April 2016 04:10:44 UTC