Re: the current situation with respect to ISSUE-134

On Fri, Apr 22, 2016 at 7:10 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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


I revised 2.3 based on this feedback (see reply on issue 110) but also
tried to keep most of the previous details


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


I replied about disjointness on the other mail and I added this paragraph
in section 2.3

I would generally prefer to remove 4.1.1 completely and move the content
directly in the related spec sections
The reason is that there are (too) many different ways a shape can end up
invalid and there is no way we can re-enumerate them in a separate section
e.g. sh:maxCount "-1" or sh:minCount "a", sh:scopeClass "1232" are valid or
not?
If we keep this section I would prefer it to say something like. "A shapes
graph is valid if it conforms to the following shapes graphs ... " and
nothing more


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


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT