Re: shapes-ISSUE-23 (punning): Shapes, classes and punning [SHACL Spec]

On 4/3/15 8:12 PM, Richard Cyganiak wrote:
> In a punning design, I think the main difference would be that the triple { rdfs:Class rdfs:subClassOf sh:Shape } would be absent.
>
> To make specialisation work, the cleanest version would appeal to RDFS inference to get additional rdf:type triples, and thus any constraints that happen to be attached to these types would go into effect as well. (I’m not saying that this would necessarily be my preferred solution, because it sucks for implementers. It’s just the simplest to specify.)

We need to be careful here. This is not just a topic that matters to the 
specification, but also to end users. Whether inferencing is 
present/mandatory would change how people write the WHERE clauses of 
constraints. For example when they query the rdf:type of an instance 
they would iterate over all superclasses of the directly asserted type 
too. Is this desirable? Also, is it even realistic to assume that all 
implementation have RDFS inferencing activated? Do these implementations 
handle incremental updates/edits well enough? Don't we exclude too much 
of the real-world market by making RDFS inferencing mandatory? What 
about all those light-weight implementations, even client-side data 
models - do they have RDFS engines available? Does the notion of 
entailment appeal to people coming into SHACL from some mainstream OO 
technology? I am not sure about all this.

My current preference would be to have switches where each constraint or 
maybe graph can point to one of the SPARQL entailment profiles (which 
already have proper URIs [1]). This would allow them to activate not 
just RDFS but also OWL and rule-based entailments such as SPIN or (dare 
I say it) RIF, while at the same time not making either mandatory. I 
believe the engine can written in such a way that it does the bit of 
inheritance treatment (for shape specialization) correctly no matter of 
whether entailment is activated on triple-level or not.

> In both your draft design and a punning design, the difference between sh:valueType and sh:valueShape is very subtle and difficult to explain. Shape authors that decide to attach constraints directly to classes would likely be confused which of those to use.

To me the difference looks pretty clear (but it may only be me). The 
value of sh:valueType is a class, while sh:valueShape is a shape (which, 
depending on the design, may also be a class although this is unlikely). 
We would explain that sh:valueType is similar to rdfs:range, while 
sh:valueShape is for nested additional tests that need to be true for 
the values in addition to being instance of the specified sh:valueType. 
To me, sh:valueShape is mostly syntactic sugar so that people can 
express more things in the high-level language, than relying on SPARQL.

Holger

[1] http://www.w3.org/TR/sparql11-entailment/#RDFSEntRegime

Received on Saturday, 4 April 2015 04:22:31 UTC