Re: Proposal for ISSUE-1

I have updated the draft* to make a specific simple suggestion on how to 
resolve this issue.

1) sh:valueType. This case was already handled. The SPARQL query does 
the rdfs:subClassOf* trick to walk into subclasses, if necessary. This 
will ensure that the system will produce transitive subclass handling 
even if the graph doesn't support formal RDFS inferencing:

SELECT?this  (?this  AS ?subject)?predicate  ?object
WHERE {
 ?this  ?predicate  ?object .
 FILTER NOT EXISTS {
  ?class rdfs:subClassOf*?valueType  .
  ?object a ?class .
 }
}


http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueTypePropertyConstraint


2) validateNode (this is the default algorithm to validate a given focus 
node). I made a simple change to rdf:type/rdfs:subClassOf* to the effect 
that the engine will walk up the class hierarchy to detect associated 
shapes for these classes. This is how I have been implementing my engine 
all along. Keep in mind this is just a specification, and other 
implementations may solve this differently, e.g. by creating a single 
large SPARQL query that does the right thing, depending on whether the 
entailment is already present on the graph, as Peter suggests.

http://w3c.github.io/data-shapes/shacl/#operation-validateNode


3) Per-query entailment. I have added a section 12.4

http://w3c.github.io/data-shapes/shacl/#sparql-entailment

that introduces a new property sh:sparqlEntailment that points at a 
required entailment regime. This information can be used by engines to 
ensure that the graph does supply this level of inferencing, or 
otherwise throw a fatal error. In systems like Jena this is in fact 
quite easy to do, because any Jena Graph can be wrapped with a virtual 
graph that adds certain inferences at query time, without having to mess 
with the underlying graph.

Arthur, I have seen you suggested sh:assumes for the same job, but I 
believe this is SPARQL-specific (a JavaScript implementation may not 
require the same level), and the property name should reflect that. On 
your original proposal email, I don't think we need a special construct 
to check for direct rdf:type triples - this can already be done via a 
sh:constraint with sh:hasValue ex:Person.

Would this work for now? What else is missing?

Thanks,
Holger

* being fully aware that in the future I should not make such edits 
directly without WG resolutions


On 5/22/2015 0:08, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> If SHACL needs to determine whether a node belongs to an RDFS class and also
> uses some kind of reasoning over RDFS subclass links then the only clean way
> forward is to use RDFS reasoning.
>
> It appears, however, that support for RDFS reasoning may be somewhat lacking
> in major SPARQL engines.  If so, then there may be a regrettable need to
> support other mechanisms in SHACL systems that use SPARQL engines.
>
> One possible semi-clean way forward is to:
> 1/ For certain SHACL constructs perform RDFS class membership inferencing by
> the SHACL system itself as needed.
> 2/ Add a construct to SHACL that states which kind of inferencing is
> required.  If this inferencing cannot be effected, then the SHACL engine
> would signal a fatal error and not do any constraint processing.
> The kinds of inferencing would include none, RDF entailment, and RDFS
> entailment.
>
>
> Having the SHACL system perform RDFS class membership reasoning itself does
> not necessarily mean that the SHACL system would have to take a data graph
> and add entailed triples to it.  The SHACL system could modify its emitted
> SPARQL queries so that they do the right thing.  (To make this actually
> easily doable SHACL might be defined as not working completely correctly on
> data graphs that have subproperties of rdfs:subClassOf.)
>
>
> peter
>
> PS:  Inconsistency of data graphs could be handled in the same way that it
> is handled in SPARQL entailment regimes.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVXebuAAoJECjN6+QThfjzydUIAJyeEKXQHex+FYlHA3y5p1QX
> 2toPpYfNpiyaqB+ZvjWnmGFK3IPEtH6UVFD5zyvB7s34m1/GRU5dROyow0mfdYOT
> xPK0eZdAjQ9fLwChA238e7wpkl72L36sZItYYeyRH5VKS01J3E4bJAj2gkHoVAO6
> BHAV1f1Kp2UxBMgRX8ExaXZ8uJ2vA7rfDI55RaRyCdwyv6rD7Pag7w/qtrc48zwm
> bhXEL2qS9/W0J2i+g51ao7IT7B2G+bK2+Vaj+V/9Yhoewx4LnAalJf/yBVObqVU0
> xozjNOM3CjWJ7n2ZFEpUywCLwTRDNApHduws8/4enHuNyMoY6hD0gnLMNQk0ghY=
> =K7+3
> -----END PGP SIGNATURE-----
>