Re: the current situation with respect to ISSUE-134

On 05/07/2016 06:08 AM, Dimitris Kontokostas wrote:
> 
> 
> On Fri, Apr 22, 2016 at 7:10 AM, Holger Knublauch <holger@topquadrant.com
> <mailto: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

In my previous message I noted that there is a problem even in this wording.
(I'm not sure whether "constraints on the value of a property" is my wording
or something I copied from previous wording.)

>         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 <http://aligned-project.eu/>
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>

Received on Saturday, 7 May 2016 13:40:06 UTC