Re: Proposal to close ISSUE-51 as specified in shacl-ref

On 8/3/2015 21:01, Dimitris Kontokostas wrote:
>
> Looks good to me, I suggest we move the sh:root, sh:subject, 
> sh:predicate, sh:object to sh:ValidationResult class

Done.

I have also renamed sh:root to sh:focusNode, which represents more 
clearly what it does. I did leave it at sh:AbstractResult, because this 
means that every result can provide a reasonably complete picture of 
what was executed: focusNode, constraint and shape. This info will also 
be useful for Failure and Success results.

I guess some people will also find time stamps useful as well as other 
metadata about which graphs were involved. Do you think these should go 
into the standard? sh:timeStamp is easy. More difficult would be to 
identify the graphs. We have the URI of the shapesGraph but no way to 
get the URI of the query graphs.

>
> I thing we should start with 10.0 for sh:Info with a 10.0 step between 
> each value in order to give room for others to define intermediate 
> levels easier

Done.

BTW, do we still want sh:FatalError on top of sh:Error? I took it out 
because I assumed that it would be replaced by Failures.

>
>     Then I added a class sh:Failure to enumerate the various reasons
>     for "unexpected" situations such as timeouts:
>     - sh:IOFailure
>     - sh:UnsupportedRecursionFailure
>     - Are there any other identifiable causes?
>
>
> what about syntax error or timeout?

My thought was to use IOFailure for time outs, with the sh:message 
pointing at the actual cause - in addition to time outs they could be 
404s and other network outages. We can easily change this later based on 
implementation experience, but I suggest we first try to get the coarse 
grained changes through the next meeting.

> Q: For syntax errors (esp for sparql) do we report them during loading 
> or during execution?

For syntax errors I was assuming that the engine would handle them 
differently, e.g. via an Exception, but I can see that some 
implementations may indeed walk through the SPARQL queries one by one 
(possibly discovering templates and functions on the fly), so that we 
should indeed have a property mechanism for those. Furthermore there may 
be other syntactical issues such as a sh:property without a sh:predicate 
that some engines may want to report.

I am nervous about making all these details part of the standard - we 
probably would need to write down precisely which syntax errors must be 
reported when. So for now I have added sh:SyntaxFailure with the 
expectation that their use is undefined, just like any engine may 
produce different IOFailures.

Together with the addition of sh:SuccessResult (see parallel email 
thread), I have pushed my latest changes to the ISSUE-51 branch:

https://github.com/w3c/data-shapes/commit/3fbc0c14049f44c0c353c935b8609b9ef539b936

I will send yet another email to summarize our changes in a proposal to 
the group.

Thanks,
Holger