Re: Anyone in support of CONSTRUCT constraints?

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. 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.

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.

The current draft already uses name-value pairs. 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.

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.

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.

Thanks,
Holger

Received on Sunday, 29 March 2015 06:53:31 UTC