- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sun, 22 Mar 2015 05:38:51 -0700
- To: Jose Emilio Labra Gayo <jelabra@gmail.com>
- CC: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2015 10:17 PM, Jose Emilio Labra Gayo wrote: >>>> >>>>> There are several implementations for ShEx, which is a similar >>>>> language to the one described there. > > [...] > >> >> Because you are saying that there is a significant difference between >> ShEx and SHACL and I say that the people behind ShEx are flexible >> enough to adapt what has been proposed for ShEx to SHACL. > > This also does not, by itself, mean that implementations of ShEx > demonstrate implementation feasibility of the core of SHACL. > > > Of course not, how can one demonstrate without a crystal ball when SHACL > has not been defined? My assertion was precisely that implementing ShEx > was feasible and that if the SHACL high level language is similar it > should also be feasible. Similar languages can have very different implementation feasibility. In particular, inclusive and exclusive or can give rise to very different implementation characteristics. (Of course, it may be that inclusive or is easier than the exclusive or in Shape Expressions.) So, again, the implementability of Shape Expressions is not direct evidence of the implementability of the core of SHACL, unless the core of SHACL is equivalent to a subset of some correctly implemented version of Shape Expressions. > Furthermore, all ShEx implementations that I know have been done by > single individuals as a proof-of-concept. > >> As an example, I am more inclined to have both inclusive and exclusive >> or, so the user can chose which one depending on its validation needs. > > I'm not sure how adding features makes the core of SHACL more > implementable. > > > It was an example about design language flexibility, not > implementability. At this moment we are not adding features, we are > choosing which are the features. It is better now to put every language > construct on the table so the WG can select which ones should or should > not be part of the language. That's why I to propose to start designing > the SHACL high-level language instead of imposing an implementation based > on SPARQL. > > Best regards, Jose Labra peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVDrfbAAoJECjN6+QThfjzggUIAJAGNJRTxW8GqxRsXz3ak0Qa SWGKHlxMtlMjBWbU+cqGAbMuMMyclwT9sS5NjYAvzYvwxDmGMJQcF8P3y4K6w+eD cHUEwU3wzI4JET+r7FuGPjah7NoZ1LzqrmXEormNqK09c8Q9nXGGS/QsGBZswwpY tnyP/amJ0J8VP8+EvYems80cridYkENkZTzoctT0xcaaMicnelfEDHiUC+6eChEA OPSCPKX6LNO2Xk3gl43B6vVAfTM1altZS6IKix7EFKNIY6+HFtSFOsP644XiD/2m UUZr4X9aN2loAWKOtbbiKbkn2y7fcOCYURYrBBLjdsjhvTNcdL/3oarUUtB+gNc= =/L/g -----END PGP SIGNATURE-----
Received on Sunday, 22 March 2015 12:39:19 UTC