Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec]

Hi Holger,
I know we didn't get to look into this issue last week but we will do so 
this week.

I don't think the change you're proposing qualifies as merely editorial in 
nature given that it would require a change of an existing implementation 
if there were one. But I agree it is fairly straightforward and I hope it 
won't be controversial.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


Holger Knublauch <holger@topquadrant.com> wrote on 08/13/2015 03:45:40 PM:

> From: Holger Knublauch <holger@topquadrant.com>
> To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
> Date: 08/13/2015 03:46 PM
> Subject: Re: shapes-ISSUE-79 (Validation functions): Cleaner 
> separation  between value checking and property iteration [SHACL Spec]
> 
> Arnaud,
> 
> we did not open this ISSUE today, so now I am not sure how to proceed. 
> It feels like a rather low-level issue that (hopefully) few people will 
> have a strong opinion about. Templates are probably an area where most 
> WG members have not even taken a deep look at. If that is the case, may 
> I treat this as an editorial issue and update the spec accordingly?
> 
> Thanks,
> Holger
> 
> 
> On 8/13/2015 16:25, Simon Steyskal wrote:
> > Hi!
> >
> >> Yes correct. A naive implementation would auto-generate a query such 
as
> >>
> >> SELECT ?this ?subject ?predicate (?value AS ?object) ?datatype
> >> WHERE {
> >>     ?this ?predicate ?value .
> >>     FILTER (!sh:hasDatatype(?value, ?datatype)) .
> >> }
> >>
> >> based on the sh:validationFunction=sh:hasDatatype triple. It walks
> >> through the result set and for each row produces one violation, using
> >> the sh:message attached to the template. If the sh:message = "Your
> >> literal must have datatype {?datatype}" then the engine can determine
> >> that ?datatype is needed to populate the message, and therefore needs
> >> to be projected out from the SELECT. The same applies to ?this or the
> >> other variables. (I have implemented this today to confirm that it
> >> works).
> >
> > Ahh ok.. If we agree on this approach, those implications should be 
> > explicitly mentioned in the respective sections of the spec, though.
> >
> > thanks,
> > simon
> >
> > ---
> > DDipl.-Ing. Simon Steyskal
> > Institute for Information Business, WU Vienna
> >
> > www: http://www.steyskal.info/  twitter: @simonsteys
> >
> > Am 2015-08-13 08:15, schrieb Holger Knublauch:
> >> On 8/13/2015 16:09, Simon Steyskal wrote:
> >>> Hi!
> >>>
> >>>> The message is defined by the surrounding template, using 
sh:message.
> >>>> I cannot think of other important information that could not be
> >>>> generalized.
> >>>
> >>> I thought that the results of the SELECT query were responsible for 
> >>> "populating" the sh:message.
> >>> In the sense that, if e.g. one wants to specify the node that has 
> >>> violated a constraint in the message too, ?this (retrieved from the 
> >>> query results) would have to be used.
> >>
> >> Yes correct. A naive implementation would auto-generate a query such 
as
> >>
> >> SELECT ?this ?subject ?predicate (?value AS ?object) ?datatype
> >> WHERE {
> >>     ?this ?predicate ?value .
> >>     FILTER (!sh:hasDatatype(?value, ?datatype)) .
> >> }
> >>
> >> based on the sh:validationFunction=sh:hasDatatype triple. It walks
> >> through the result set and for each row produces one violation, using
> >> the sh:message attached to the template. If the sh:message = "Your
> >> literal must have datatype {?datatype}" then the engine can determine
> >> that ?datatype is needed to populate the message, and therefore needs
> >> to be projected out from the SELECT. The same applies to ?this or the
> >> other variables. (I have implemented this today to confirm that it
> >> works).
> >>
> >> HTH
> >> Holger
> 
>