Re: Anyone in support of CONSTRUCT constraints?

We agree that the mapping between named variables such as "message" and 
corresponding property IRIs in the SHACL namespace (sh:message) is 
trivial. Yet I would turn your arguments around. By defining an RDF data 
model we get a lot of stuff for free without any extra work, including 
several exchange formats. For example if we leave the details 
unspecified, how would implementers know how to serialize the values - 
whether something is a IRI or a literal? I believe there is value in 
having a serialization format, and there will be value in being able to 
run SPARQL queries across the results of constraint validation. And you 
haven't shown how to represent path expressions yet.

Thanks
Holger


On 3/29/2015 23:11, Richard Cyganiak wrote:
>> On 29 Mar 2015, at 07:52, Holger Knublauch <holger@topquadrant.com> wrote:
>>
>> On 3/29/15 4:29 AM, Richard Cyganiak wrote:
>>> 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 am puzzled by this discussion, Richard. We need to define one interoperable mechanism similar to an API interface that allows different implementations to be used.
> My proposal is an interoperable mechanism similar to an API interface. It’s just not RDF. It’s isomorphic to SPARQL results, if you prefer that way of looking at it. I just didn’t want to mention that to avoid agitating the SPARQLphobes.
>
>> For example, a future database with SHACL support may return a set of constraint violations. Until the databases have this natively, I would use some generic Java API to run SHACL constraint checking. I want my tool (e.g. TopBraid Composer) to be able to freely switch between those implementations and display their results consistently.
> You can get all that with my proposal.
>
>> And the authors of custom constraints need clear guidance about which fields they need to produce, just a boolean would be extremely poor and sacrifice a lot of flexibility and useful metadata.
> You brought up the idea of using just a boolean. I certainly never did.
>
>> The current draft already uses name-value pairs.
> Yes, and my proposal, in a nutshell, is to leave it at that, and not stick an RDF layer on top of it.
>
>> But with any name-valur pairs system, we need to at least agree on the names and expected values. sh:root, sh:value etc just happen to names that are also URIs. This allows them to be trivially mapped to, for example, JSON-LD, but also spreadsheets. The draft also provides rules for how queries can produce dynamic results, with static values used as fallbacks.
> Exactly. That’s all good and should stay. I just don’t want to turn the keys into URIs and don’t want to turn the simple structure into RDF.
>
>> All this doesn't mean that every possible implementation needs to only produce its results in triple format, but whenever something gets serialized or sent back from a database, we need to agree on names and value ranges.
> Yes. I broadly agree with the names and value ranges in your draft. I just don’t want to add an RDF layer on top of it.
>
>> I guess I'd need to see a counter proposal to understand what you are suggesting. Just leaving it vague and allowing any variables to be sent back isn't going to fly for interactive tools that need to highlight input fields etc.
> I’d propose that a constraint violation is a set of key-value pairs, with keys like “level”, “root”, “path”, “value”, “source”, “detail” and “message” having the obvious meanings in line with the current draft. I don’t have a worked-out proposal for multi-part paths and inverse paths. Other user-defined keys may be present.
>
> The rules in 13.1.2 can stay as they are, but would produce simple string keys instead of URI keys. (The rules can, in fact, be implemented as a SPARQL SELECT header using COALESCE.) Section 13.1.3 could be replaced by a simple rule that retrains any extra variables returned from the SPARQL query in the violation.
>
> I think this is simpler, and nothing is lost.
>
> Best,
> Richard

Received on Sunday, 29 March 2015 23:13:08 UTC