Re: ISSUE-131: Cleaned up definition of sh:hasShape

Holger,

Given that there is never going to be any generally agreed upon definition 
of what's pedantic and what's not I don't think it's productive to make 
any such references. What you see as pedantic is I assume simply being 
precise to Peter. So let's accept we have different views on this kind of 
stuff without trying to cast others negatively.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Cloud


Holger Knublauch <holger@topquadrant.com> wrote on 04/10/2016 04:48:49 PM:

> From: Holger Knublauch <holger@topquadrant.com>
> To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
> Date: 04/10/2016 04:50 PM
> Subject: Re: ISSUE-131: Cleaned up definition of sh:hasShape
> 
> On 9/04/2016 7:31, Peter F. Patel-Schneider wrote:
> > The definition is looking better.  The extraneous argument has been 
removed
> > and its incorrect use in the examples have also been removed.
> >
> > However, some of the problems that I had identified remain.
> >
> > The section still uses the undefined notion "Value Type" in the 
> argument table.
> 
> I believe there is a fine line between useful feedback and pedantic 
> feedback. The term "value type" is just meant in its intuitive English 
> meaning here. Also, the term is already used in other parameter tables, 
> and carries no implications whatsoever, but just to illustrate the 
> expected type of nodes for those parameters or function arguments.
> 
> Anyway, I have added a sentence
> 
>      Note that the parameter tables in each of the following sections 
> have a column
>      called Value Type which indicates the expected type of the 
> parameter values for
>      documentation purposes, without enforcing any formal restrictions.
> 
> which hopefully satisfies your concerns.
> 
> >
> > A SHACL shape that recursively refers to itself is currently 
syntactically
> > illegal in SHACL.  The definition of sh:hasShape still does not detect 
such
> > constructs and when encountering them will sometimes return true, 
sometimes
> > false, and sometimes "undefined".
> 
> Re-reading the current state of ISSUE-22 I notice that we made a 
> mistake. Luckily the ISSUE is still open so that we can fix this. The 
> problem is that the current resolution even disallows "static" 
> recursion, even if no instance in the data graph are ever recursive. I 
> will argue in favor of changing this so that only run-time recursion is 
> detected as an error. Otherwise, it becomes impossible to model acyclic 
> tree structures, which are harmless but very common in practice.
> 
> My preference is to leave the current definition unchanged until we have 

> clarified this. The comment about ISSUE-22 in the document allows this 
> flexibility.
> 
> >
> > The passing of a graph has been removed.  However, the replacementis 
to use
> > "the IRI of the current shapes graph", which may not exist.
> 
> The shapes graph MUST have a IRI. Only the data graph may be the default 

> graph. I don't see how else to implement all this.
> 
> >
> >
> > As well, as far as I know undefined is not a permissable return value 
for a
> > SPARQL function.
> 
> SPARQL functions may returns errors. I am not sure what the official 
> term for these errors is, but the effect is that the resulting variable 
> remains unbound. The SPARQL reference itself refers to
> 
> https://www.w3.org/TR/xquery/#dt-type-error
> 
> which also links to static errors and dynamic errors. Do you think we 
> should use the term "error" instead of unbound/undefined?
> 
> >
> > It is also unclear as to what counts as the production of a validation
> > result.
> 
> Earlier we state that each row of a SELECT constraint query counts as a 
> validation result, so this is hopefully clear (with a bit of good will).
> 
> >
> > The treatment of failures is quite complex.  There is disagreement 
between
> > text and SPARQL code on how they are to be treated in core constraint
> > components.  There is no discussion of what a failure means.  Without 
some
> > notion of what it supposed to be happening there is no way to 
determine
> > whether the description of sh:hasShape is correct or even that using
> > sh:hasShape can support failures.
> 
> This should be clear:
> 
>      If a row in a SPARQL result set produces <code>true</code> as value 

> for the variable
>      <code>?failure</code> then a <span class="term">failure</span> must 

> be reported.
> 
> Please suggest specific re-wording that satisfies your understanding.
> 
> Holger
> 
> 
> >
> >
> > On 04/07/2016 04:52 PM, Holger Knublauch wrote:
> >> Peter,
> >>
> >> last month you raised ISSUE-131 on the sh:hasShape function. I 
> have tried to
> >> address your concerns here:
> >>
> >> https://github.com/w3c/data-shapes/commit/
> e5f6a0a84f6f9cc58c07e16863c7bfa7bd7777f9
> >>
> >> https://github.com/w3c/data-shapes/commit/
> d979121751c86004174ccfd26b0de1cbcd13aea9
> >>
> >>
> >> See
> >>
> >>      http://w3c.github.io/data-shapes/shacl/#hasShape
> >>
> >> Responses inline:
> >>
> >>> There are several problems with this definition.
> >>>
> >>> First, it uses type in a way different from the rest of the 
document. This
> >>> is not just a case where SHACL typing changed---literals never 
> had types in
> >>> SHACL. (This is a good argument to use a qualifier wherever 
> SHACL typing is
> >>> meant.)
> >> The only use of the term "type" that I found was in "Value type". I 
have
> >> changed them all to rdfs:Resource (one of them was sh:Shape). Is 
> this what you
> >> are referring to?
> >>
> >>> Second, dependency loops are currently invalid in SHACL. The precise
> >>> meaning of what is a dependency loop is is a bit uncertain, but it 
is
> >>> certainly the case that recursively running the same shape on the 
same
> >>> resource counts as a dependency loop. sh:hasShape needs to be 
defined in
> >>> such a way to signal that an invalid situation has occured.
> >> I have adjusted the definition so that it reports a failure 
> ("undefined") when
> >> the function was called with the same parameters recursively. 
> Could you verify
> >> whether this is sufficiently precise and correct now?
> >>
> >>> Third, some constraints need to have bindings passed through the
> >>> sh:hasShape, or they cannot correctly compute validation results. 
However,
> >>> SPARQL is silent on the variable environment available inside 
functions so
> >>> any information has to be passed via arguments.
> >> I don't see why bindings have to be passed through the function. A 
function
> >> takes parameters and then operates on those parameters and the 
> current dataset
> >> (which it inherits from the surrounding call). Could you clarify 
> where you see
> >> problems? To clarify that there are no bindings involved, I changed 
from
> >> <code>$shape</code> to <code>shape</code>.
> >>
> >>> Fourth, arguments to SPARQL functions are RDF terms and thus are
> not graphs.
> >> I clarified that shapesGraph is the IRI of a graph, not a graph by 
itself.
> >>
> >> Holger
> >>
> >>
> 
>