- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 21 May 2015 07:08:46 -0700
- To: Arthur Ryman <arthur.ryman@gmail.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----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-----
Received on Thursday, 21 May 2015 14:09:19 UTC