Re: Anyone in support of CONSTRUCT constraints?

Hi Dimitris,

> On 27 Mar 2015, at 15:16, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> I think the results of an RDF validation should have a canonical RDF representation.

Well, that’s your opinion. My opinion is that we should deliver on the charter and go home. The charter doesn’t mention an exchange format for validation reports as a deliverable. So I think the working group should not work on such a thing, unless it’s required to deliver on something else, or most of the working group thinks that it is useful and easy to do.

There is a pretty good case to define *some* form of structured validation report, because that makes it easier to produce human-readable error messages, and those speak to a number of points mentioned in the charter.

But the more a design goes beyond this minimal goal, and the more complex it gets, the more likely it is to face opposition, and ultimately fall by the wayside as not required by the charter.

I prefer a simple mechanism for structured validation reports to none at all.

That is why I am pushing back against making the reporting aspect more complex.

> If this is the base we can transform the resulting RDF graph into any form we want, e.g. html for users or csv as you suggest but 'd prefer not to use csv as the base.

I didn’t propose using CSV as the base. I don’t know where you get this idea.

> In this case, what would be the interpretation of these additional variables if not bound to a property? 

The interpretation would be in out-of-band documentation.

>> - Test cases might become simpler, as comparing SELECT results is easier than comparing RDF graphs.
> 
> I agree but should this be a reason for limiting the result expressiveness?

My proposal doesn’t limit expressivity at all. In fact, the RDF graph structure in the current draft is *created from* a simple key-value-pair structure that fits my proposal. Surely, that graph doesn’t express anything that wasn’t already expressed in the key-value-pair form.

> I also suggested to allow different types of results, each one for a different audience. 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Constraint_Violations_Reporting_Details
> 
> The current one we define is the richest one in terms of metadata but this is not always required.
> Maybe we can define an additional one where we report only the resource (sh:root) and a message (sh:message) without the path or any other annotation metadata
> Would this limit your concerns?
> 
> An approach for this is to have  something like the following
> sh:ViolationResults a superclass 
> sh:ViolationResources,  subClassOf sh:ViolationResults and allowed to contain only sh:root and sh:message
> sh:ViolationResourcesEnriched, subClassOf sh:ViolationResources and allowed to contain sh:path and everything else
> 
> When the user runs the evaluation he can request either of the two formats as his result

I understand the motivation behind those features for performing validation on large-scale datasets, and they would be useful additions to implementations aimed at that goal.

I am not convinced that they should be in the standard, and I would be opposed to making them required for all SHACL processors.

Richard

Received on Saturday, 28 March 2015 18:30:11 UTC